For the name of the internal framework, I can't remember which podcast I heard it on, but they haven't mentioned it publicly much if at all. It's something they threw together in like 2012.

Still, in a couple of years when Compose Multiplatform is mature, and Google is looking to boost profit margin, they may rationalise their investment in multiple Cross Platform toolkits. I think most agree that, from a technical viewpoint, KMP + Compose Multiplatform offers the most flexibility.

They also recently offshored some Flutter roles which may be a sign of how central they view Flutter. In a few years it may be in the graveyard.

https://touchlab.co/KMP-at-google

https://www.reddit.com/r/FlutterDev/comments/1chwqtu/flutter...

If AWS is required, a monolith on ECS Fargate + Aurora Postgres Serverless is perfectly cromulent. You'll need to string together some open source tools for e.g. ci/cd.

https://lifearchitect.ai/whats-in-my-ai/

OpenAI paid $2m/year for twitter feeds until Elon cut them off, and Sam Altman has mentioned they'd paid a lot for scientific journals and Reddit mention they'll start charging. Given how central data quality and curation is, if these private data sources give a significant boost, it won't be available for Apache2 models.

From seeing the cloud alloydb I had imagined most of the improvements were due to the wal-shipping and cloud native aspects.

GCP != Google Health, at least for the purposes of patient privacy. If you hold the encryption keys, google can't do anything, or am I wrong in that assumption?

It is fine, and expected, to rule out GCP for storing your own records for competitive reasons (e.g. choosing them would make future Google Health integrations easier). It is also expected, if not quite fine, to try to actively prevent your customers from using GCP.

Cerner seemed happy to play a few rounds of golf with Eric Schmidt regarding using GCP, presumably to try to glean insight into Google Health, while EPIC flat out refused a meeting. Cerner then helpfully provided a misleading quote to the WSJ to help spread FUD.

    On GKE, you don't need to define node-pools if you tick enable node-autoprovisioning. This is effectively an EKS fargate profile without any of the limitations (discrete node size, inability to mount volumes etc)

    On GKE there's no need for bastion hosts, you can connect to private nodes automatically by tunneling through identity-aware-proxy

    On GKE, there's no faffing about with aws-auth-configmap, nodes automatically join the cluster

    On GKE, you can use regional persistent disks if you need to store state rather than single zone EBS

    On GKE, you can use a single static ip for your nginx-ingress load balancer without needing to faff about with AWS global accelerator (which in any case gives you multiple ips)

    On GKE, managed node pools are automatically repaired and upgraded with the choice of google's OS or ubuntu unlike Amazon Linux which is currently the only choice for EKS' managed node pools. GKE can automatically use spot instances unlike the farce on AWS with a 3rd party (spotinst) charging a premium for the same functionality

    On GKE, managed istio is ticking a box versus a self-install on EKS

    On GKE you need to worry much less about ip exhaustion as they use alias ips vs dedicated ENIs for EKS

    Associating IAMs with kuberenetes service accounts is much easier with GKE workload identity than with EKS' oidc webhook

    GKE has several features which EKS doesn't (calico, vertical pod autoscaling, binary authorisation, export of cluster data to bigquery)

IBM can sweat the old large companies but they have no credible cloud offering and this doesn't change that. Converting on-prem to kubernetes and using a proper cloud like Google, AWS or Microsoft without also paying steep margin to IBM would seem to be more attractive.

All the other stuff you need like logs and monitoring can be installed with helm charts.