3 ms·
The author seems to be mixing some valid observations regarding the difficulty of stateful containers with some paranoia about the growth of cloud deployments a
by markbnj 11y ago
The author seems to be mixing some valid observations regarding the difficulty of stateful containers with some paranoia about the growth of cloud deployments and ownership of data. Or maybe it's not paranoia. I don't know. But it's different.
First off, containers don't absolutely have to be stateless. The first and foremost benefit of containers is dependency isolation and configuration management. Once you use them for any length of time this becomes clear. You make them, put them on a machine with a compatible kernel and network access to the right stuff and they just run.
It's a pretty short leap from containers that just run to the idea of container orchestration systems like kubernetes. We just deployed a new staging environment built on Google Container Engine, an implementation of kubernetes, and it's pretty damn amazing what you can do at the services layer, and yes, even at the gateway and persistence layers. But you have to treat the needs of these layers differently.
Statelessness is important at the services layer because ultimately you want to scale up and down seamlessly and automatically, and kubernetes allows you to do just that.
In the persistence layer it's the opposite: state is all that's important and scaling is a more complicated affair. That doesn't mean containers aren't useful in that layer. They still provide the above-mentioned benefits. The aforementioned staging environment uses elasticsearch running in a dedicated kubernetes cluster, where each pod is bolted to a persistent disk at cluster creation. It also uses a mongo replicaset that is just deployed on instances in the old manner, but we have a prototype containerized install and will be moving toward that. Lastly it uses mysql via Google's cloudsql managed offering.
So you have a lot of differences in the persistence layer, and a lot of choices for how to manage those differences. Things are a lot simpler and cleaner at the services layer, but that doesn't mean the benefits of containers in one layer are somehow less of a win than in the other. After three years of using and deploying them my feeling is it's pretty much all win.
- TheIronYuppie 11y agoDisclaimer: I work at Google on Kubernetes. This is a really good point - I've said it before and I'll say it again - containers neither add to (nor subtract) from whatever you're doing today. If you have a single VM and no shared storage, you're exactly as vulnerable as if you were doing things in a container. And, in the majority of cases, the exact same techniques you'd use in a VM work in a container or Kubernetes too.