4 ms·

"Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the ap

by vp8989 5y ago

"Enter Kubernetes. Now you have a core DevOps/SRE team managing the “platform” (the Kubernetes cluster and various add-ons such as operators) which gives the application developers a high-level interface for operating their applications." I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. The Serverless paradigm just seems fundamentally superior to me, but it also seems like it inherently requires vendors to be very opinionated in order to provide a good developer experience with it which AWS is not and aren't ... at least not yet anyway.

throwaway894345 5y ago
> I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. I wasn’t suggesting standing up K8s from scratch, but rather extending GKE or EKS or similar with things like cert-manager snd external DNS. I was skeptical coming from a shop that was deeply invested in AWS and serverless, but Kubernetes has a lot less friction and the abstractions can be pretty high level. For example, we can create a service with HTTPS, fully managed certificates, reverse proxy, and DNS just by creating an ingress resource for that service. It’s a lot nicer than cobbling together ACM, Route 53, API Gateway, etc (even though I have plenty of experience with the latter). A lot of this is possible because Kubernetes is extensible and there’s a big ecosystem for it. AWS isn’t (particularly) extensible, so you end up depending on them to support your use case. When you have a competent SRE team managing your platform and providing high level abstractions, Kubernetes kind of feels like what serverless promised to be—much more so than AWS’s serverless offerings (and I still like AWS!).
- vp8989 5y ago
  Ye to be clear, I meant even building on top of GKE/EKS it seems like a lot of work configuring things, testing etc ... at least from the outside looking in.
  - throwaway894345 5y ago
    I think it still is a fair bit of work, but it’s something that an SRE team can manage and hand off to users a higher level abstraction than what could be provided atop proprietary cloud APIs (there’s not really a good way to abstract over things in AWS-land because AWS isn’t really extensible). So you actually get some nice separation between folks who manage the Kubernetes-based platform and the developers who interact with high-level Kubernetes resources. The salient point is that developers aren’t the ones doing all of that work and they don’t need to coordinate with the platform team on any regular basis.
urthor 5y ago
Managed Kubernetes is the serverless paradigm, done right I find. Kubernetes is hard because it needs to be hard, stateful machines are stateful because they have to be stateful. Managed Kubernetes is the compromise between vendors desire for vendor lock-in, and customers wanting a standardized interface for serverless applications.

by vp8989 5y ago

throwaway894345 5y ago

> I've personally changed my opinion on this in the last ~2 years ... observing at work what it takes for people to stand up and manage a Kubernetes platform it really just feels like incredible waste that we have hundreds and thousands of SREs across our industry all building their own unique compute platforms when the public cloud vendors have already done that work. I wasn’t suggesting standing up K8s from scratch, but rather extending GKE or EKS or similar with things like cert-manager snd external DNS. I was skeptical coming from a shop that was deeply invested in AWS and serverless, but Kubernetes has a lot less friction and the abstractions can be pretty high level. For example, we can create a service with HTTPS, fully managed certificates, reverse proxy, and DNS just by creating an ingress resource for that service. It’s a lot nicer than cobbling together ACM, Route 53, API Gateway, etc (even though I have plenty of experience with the latter). A lot of this is possible because Kubernetes is extensible and there’s a big ecosystem for it. AWS isn’t (particularly) extensible, so you end up depending on them to support your use case. When you have a competent SRE team managing your platform and providing high level abstractions, Kubernetes kind of feels like what serverless promised to be—much more so than AWS’s serverless offerings (and I still like AWS!).

vp8989 5y ago
Ye to be clear, I meant even building on top of GKE/EKS it seems like a lot of work configuring things, testing etc ... at least from the outside looking in.
- throwaway894345 5y ago
  I think it still is a fair bit of work, but it’s something that an SRE team can manage and hand off to users a higher level abstraction than what could be provided atop proprietary cloud APIs (there’s not really a good way to abstract over things in AWS-land because AWS isn’t really extensible). So you actually get some nice separation between folks who manage the Kubernetes-based platform and the developers who interact with high-level Kubernetes resources. The salient point is that developers aren’t the ones doing all of that work and they don’t need to coordinate with the platform team on any regular basis.

urthor 5y ago

Managed Kubernetes is the serverless paradigm, done right I find. Kubernetes is hard because it needs to be hard, stateful machines are stateful because they have to be stateful. Managed Kubernetes is the compromise between vendors desire for vendor lock-in, and customers wanting a standardized interface for serverless applications.