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.
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.
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.
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.
Given Reddit's inability to keep their website functioning (unless you use the far superior old.reddit.com) I find it hard to believe they would be able to stop a motivated developer from scraping the whole site.
this is about the time that i expect sites to begin returning intentionally corrupt/incorrect/perhaps outright garbage (subtle or not, probably better subtle so they don't realize it until it's far too late) data in order to intentionally poison enemy wellscraping. where "ethics" dissolve into the inherent raw cannibalistic laws of capitalist ventures.
then you can sell them back the TBs they scraped at a 1000x markup for the real data.
or attempt to watermark it so you can prove their illegal(?) usage of your services in their training.
You might be right. What a dystopian future that will be. Make a few requests too many and the webserver might think you're scraping data so it gaslights you into reading bullshit.
It's not. The internet will be crazy once compute will be cheap enough to slightly modify all displayed content slightly to suit your personal user profile.
So you think Reddit is going to replace their actual content… with very believable generated text? And that’s going to fool people at scale? How does that help Reddit (or other org) combat bots? You can just put garbage text that seems real but has nothing to do with todays news (or politics or science).
I’m really struggling to understand how you think this is going to work and result in harm.
This assumes both the site and the reader are really dumb.
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?
Code improvements. Indices aren't taken into account at all since that's so workload dependent. Having said that, the index advisor can make finding the right indices to improve performance there more easily as well. Vacuum management handles figuring out the right time to do garbage collection for you, etc. None of that is part of that 2x improvement.
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.
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.
Disclaimer: I work closely on Cloud Run as an SRE.
IF you want, you can still have it by use "Cloud Run for Anthos", and deploy your container to your GKE cluster with the same Knative API. This allows you to have more control on memory/CPU etc.
I believe there's no requirement if you just want to use Anthos on GKE (I could be wrong though, Anthos is relatively new).
Alternatively, if what you really want is the ease to manage and deploy containers and automatically scale according to traffic, my understanding is you can always use the open source Knative project with your Kubenetes cluster. This provide you the exact same API supported by Cloud Run and makes it very easy to migrate from managed Cloud Run to on-prem K8s cluster (or K8s clusters from other Cloud vendors).
thanks, I hope you're right, GCP doesn't appear to be clear on this point, seems to be offering free trial up to May 2020 and then who know. I'm aware of the ability to set it up from open source which is a great fallback!
I tried out Azure Container Instances a while back, and the startup times were also what killed it for me - they were all over the shop. It was 1-2 years ago, so I don't recall exactly and things may well have improved now, but I seem to recall they ranged from 1-5m.
So far what I've observed is <10s cold-start times on GCR. This is a fairly lightweight web app written using Undertow in Java so carries a JVM as overhead.
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)
yea this seems a lot like how I do things with Jenkins-x preview environments. Other parts of the stack are pulled in based on the latest version of the respective helm charts.
Dockup is like Jenkins X, but easy to setup for people who do not know Kubernetes or helm charts. Also we have features like single-use pre-seeded DBs and a deployment form for deploying a custom combination of branches, for example, development branches from two different repositories.
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...