In his most recent GigaOm article, “We’re finally headed towards autonomous, self-migrating containers for cloud-application automation“, David Linthicum discusses the value that containers, such as Docker and CoreOS Rocket, are bringing to DevOps and cloud systems management. For the record nothing Dave states in the article is incorrect with regard to the expressed value that containers provide for portability, however, there is an issue with the big picture view discussed for the role of containers in cloud application delivery.
Containers are predicated on the goal of deploying and managing n-tier application designs. By their nature, containers manage n-tier application components, e.g. database servers, application servers, web servers, etc., at the operating system level. Indeed, portability is inherent because all operating system and application configuration dependencies are packaged and delivered inside a container to any other operating system platform. Containers are…
An honest question for you: what is the next step, then, if not VMs or containers? Just using the AWS/Azure services? I see a potential problem with that as well. I’m just getting my feet wet, so maybe there’s some “grand plan” I’ve missed. Any help appreciated.
My recommendation is to use a Platform-as-a-Service, which in turn may use VMs and containers, to manage runtime. Of course this is not always possible with legacy applications, but for new applications, direct use of containers implies running and managing OS components, which has inherent limitations and incurs operational overhead to manage.
Why not mention that one word which I’ve been missing in your article: microservices
Containers are just a nice way to deploy parts of an application.
Lots of people who do microservices use containers to do so.
microservices are easier to scale-out.
especially if you build them correctly. 😉
Yes, this means stateless. And yes, a lot of the time this means single-process.
But you still need data-stores. Those are not stateless.
The first trick is to have only one webservice in front of each data-store. That way you know there is no other service writing the same data-store and this also makes it easier to do caching as well.
And you need to keep these data-stores/microservices focussed on a single task. Otherwise these services aren’t micro any more.
Something else to keep in mind is: some data-stores scale-out better than others.
What is really going on here is abstraction, abstraction, abstraction. It’s the Unix philosophy: Write programs that do one thing and do it well
Scale-out state-less micro (web)services is a form of abstraction. Other services don’t talk directly to that data-store.
The other form of abstraction is obviously containers. Abstracting the machine, including the parts of the operating system you need preferable nothing else.