kelseyhightower
Joined 14 years ago
Karma
2,133
Submissions
101
Member since
Aug 25
Recent submissions
Comment · 10 months ago
It's rare that I get to reflect back on my entire tech career and my philosophy towards work and life, but this interview captures it perfectly.
Comment · 1 year ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
[1] https://github.com/kelseyhightower/serverless-vault-with-clo...
Comment · 5 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
[1] https://cloud.google.com/load-balancing/docs/negs/serverless...
Comment · 6 years ago
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.
[1] https://cloud.google.com/run/docs/configuring/min-instances