HN user

inscrutable

56 karma
Posts0
Comments25
View on HN
No posts found.

ok, this may be a red herring.

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.

One datapoint is that Google rewrote their Google Docs app in KMM (which doesn't include UI, that's Compose Multiplatform), replacing their legacy in-house framework. They intend to write more of their apps in it.

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...

A monolith on GCP Cloud Run + Postgres Alloy db is as close to Heroku as exists today. No external tools for ci, deployments/rollbacks, logs, metrics are needed. Zero lock-in, nothing to maintain. If for some reason you get to 10+ services and want to go to kubernetes, that's easy.

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.

maybe you're right, but I'd be skeptical. In a non-snarky way, this shows the data sources used in models to date up to GPT 3.

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.

My sweet summer child, this is a closely guarded secret. Will only be revealed if perhaps Europe demands it so that copyright holders can sue.

That's impressive, surprised there's that much juice that could be squeezed without changing architecture. I ask because AWS Aurora is flattered in comparison to RDS due to e.g. some dumb oob pg settings that a lot of people don't change.

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

This looks great! For the 2x general improvement, how much of that is due to setting/modifying postgres settings and adding good indexes, versus improvements to the code itself?

There seems to be major disengenuousness on behalf of EPIC and Cerner, and some ignorance on behalf of WSJ.

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.

started using this... pretty awesome vs the wall of yaml it replaces. Not suitable for all workloads (max 1cpu/2 gigs ram, 4 minute max pod startup time, can't do background work when not serving a request). But it replaces cert-manager, ingress-nginx, oauth2-proxy, k8s service, k8s deployment, k8s secret, k8s configmap, k8s hpa, k8s pdb, helm charts and cluster management.

    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)

https://www.reddit.com/r/googlecloud/comments/ejxxn5/has_any...

I can see independent software vendors like Heptio and Canonical being the main beneficiary of this deal.

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.

very interesting. With this and the new DO kubernetes offering (if both are reliable), DO could be a compelling option for postgres-based kubernetes clusters baseload - circa half the price of google cloud.

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

Fully agree with his comments as someone who's used GKE, AKS, EKS and Hetzner for kubernetes clusters.

GCP's UX is so nice... e.g. compare the equivalent as command line option in the UI vs the automation script that Azure gives you.

If you're going the kube route, I would go with GKE with pre-emptible nodes. You can have a single micro base node ($25/month), and then an auto-scaling, pre-emptible pool for a discount of 80%/month vs spot prices on AWS/GCP. There's not a lot for you to do once you set it up. With pre-emptible the nodes will on average be unavailable 5-10% of the month, but typically not at the same time.

There are cheaper baseload alternatives appearing, but it'll probably be 12 months until they're stable.

https://labs.ovh.com/kubernetes-k8s

https://github.com/hetznercloud/hcloud-cloud-controller-mana...

I watched the overview video below and the tldr for me is that although serverless is doable now and can be done well, the tooling is not there yet, and you're also locked into AWS. So check back in back in 2-3 years.

For me, I think Kubernetes + virtual kubelet (for container instance creation, with per second billing, only on Azure right now) is the safest option. It gives the benefit of easily scalable compute with no need to move to an event driven model or constraints on function duration and resource usage.

https://www.youtube.com/watch?v=1fBbSgJJV_g

https://github.com/virtual-kubelet/virtual-kubelet