Google Cloud products including GKE (Kubernetes), Cloud Run/Functions, the gcloud CLI, and a number of other utilities and control plane components sit it direct revenue paths. In the case of Cloud Run/Functions (Go support) and GKE, those products generate direct revenue, and the amount is much higher than you would think.
The one benefit you get is protection from bugs in Kubernetes itself and a reduced blast radius. Even if you could produce a secure and H/A cluster, you still leave yourself open to Kubernetes bugs and configuration mistakes such as adding a network policy that blocks all communication across all namespaces.
Multiple clusters protects you from these types of configuration mistakes by reducing the blast radius and providing an additional landing zone to roll out changes over time.
And making it so that "many clusters" look exactly like "one cluster" is one of the goals the kcp prototype was exploring (although still early) because I hear this ALL the time:
1. 1 cluster was awesome
2. Many clusters means I rebuild the world
3. I wish there was a way to get the benefits of one cluster across multiples.
Which I believe is a solvable problem and partially what we've been poking at at https://github.com/kcp-dev/kcp (although it's still so early that I don't want to get hopes up).
I'm currently testing our (GCP) solution to the CPU throttling you've highlighted. I've been using Vault[1] as my test case, and so far so good. Be on the look out for early sign up if you're interested.
Stay tuned. A lot of the tech behind El Carro can be extracted into a generic controller and serve as the foundation for other databases including Postgres.
Thanks for your comment. This is something the team keeps top of mind and influences our decisions and road maps. Please continue to keep us honest here. I'll get others to weight in on this, but here's my personal opinion on the matter.
AppEngine has been around for a long time, 12 years to be exact, and in my mind it's a completely different product, and still one of our most successful. While Cloud Run competes with AppEngine on some fronts, customers really appreciate AppEngine's deep integration with other GCP managed services. It's a full blown PaaS.
I expect Cloud Run to improve over time and gain more features that will no doubt match the requirements of many AppEngine customers, some may switch to Cloud Run, but we are not forcing them to.
Cloud Functions already shares a lot of underlying infrastructure with Cloud Run, which shares a lot of underlying infrastructure with AppEngine, and that's by design. These days I like to think of Cloud Functions as a simplified developer experience on top of Cloud Run focused on task orientated workloads backed by events and triggers.
Can we continue to support 3 somewhat overlapping Serverless platforms going forward? I believe the answer is yes, thanks to the shared infrastructure, and the fact we truly believe all three platforms offer a unique set of developer experiences worth preserving. Maybe there is future state where one product satisfies all use cases, but that's not today, so we plan to keep listening to customers, and invest across the board.
One recent example of investing across the board: you can now leverage global load balancing[1] across all three Serverless platforms.
Hi Kelsey! Appreciate your take here. You obviously have deeper insight than I do. Honestly I'm in favor of the path I described. Engineers I work with spend too much time already arguing the best platform for any given service, especially when the pros and cons are very, very similar. That being said, with the recent features released for Run (load-balancing, min instances, streaming gRPC) we're basically 100% bought in to that direction. I can't think of any feature AppEngine or Functions have (esp AppEngine) that would pull me back.
Though I will say I dearly miss the days of first generation GAE standard, when things like memcache, taskqeue, datastore, auth and logging were all baked in as first-class citizens and Just Worked™.
Cloud run is attempting to enable that "Just Works" experience, but we are trying to do it by leveraging the best of open source, and native client libraries. Feels like we are getting close and I'll be sure to share this feedback with the rest of the team.
Cold starts can be one of the biggest trade offs when adopting a Serverless platform like Cloud Run, especially with 30 second start up times. We introduced minimum instances[1], currently in beta, which will allow you to specify a minimum number of container instances to be kept warm and ready to serve requests.
There is a cost for doing so as instances kept running in this way do incur billing costs [1].
I've done some work with Ruby in the past, and based on my experience, you might not be able to take advantage of Cloud Run's best feature, concurrency[2], which is another way to reduce cold starts by routing concurrent requests to the same container instance. Ruby maybe blocking in flight requests and forcing us to fire up another instance to handle it. Once the first request has completed there is a chance the container instance processing that request will be spun down, this is something minimum instances can help with. You might need more than one minimum instance to compensate for the lack of concurrency if you really want to see improvement in overall latency.
McDonald's was my starting point. It's where I developed much of my work ethic and my first taste of leadership in a professional setting. I was a shift manager for most of that time and remember learning about the restaurant business, food cost, working with customers, and managing people.
A lot of stuff did not make the article but who I am today was greatly influenced by that job. I chipped in on the bills, bought my own school clothes, and my first car (1987 Jeep Cherokee), thanks to that job, so for me it was very foundational.
Oh wow that saying brings back memories. All this time I thought my store manager had invented it.
McDonalds for me was pretty fun. At the time I could well see how the ease of promotion trapped some people. If you had any motivation at all you'd soon find yourself running a night shift.
Even now, a decade later, I get nightmeres where I'm back working there. Nothing feels longer than an 8 hour shift at McDonalds.
I could not fit the entire title "From McDonald's to Google: How Kelsey Hightower became one of the most respected people in cloud computing" when submitting the post.
Ronnie taught me that making people smile should be part of the job. We both learned that you really need to understand the world around you if you want get people to laugh at it.
