Does it always have to be Docker & Kubernetes?!
“If I put a malfunctioning application in a container, I get just that: a malfunctioning application in a container”. Michael Bruns shows us how we can develop and operate a stable microservice architecture without the need to put everything into containers.
Everybody talks about Docker, Kubernetes, Rancher, Nomad, Rocket etc. – and for good reasons. But do I really have to use those tools in every project? Can’t I develop and operate a stable microservice architecture without having to put everything into containers and orchestrate them?
A practical example will show that more light-weight approaches still have a right to exist in the year 2017 (and beyond) and that a system based on microservices on AWS can be fun even without containers.
We talked to Michael Bruns about the ups and downs of using containers for your project.
JAXenter: Michael, containers are seen everywhere as a panacea, but what are their real advantages?
Michael Bruns: There are several advantages to them. For example, if I have a large data center and hardware, which I want to use more efficiently, I can do just that with containers and tools like Kubernetes. And then there are also apps which help facilitate local development because it might not be possible for me to bring people together otherwise. It can also happen quite often that you won’t be able to reach a consensus on something, for example choosing a uniform JVM version.
If I have any problems with that, I can find a solution for it with containers. Another thing I already had heard a few times is that containers are being used for languages like Python, where libraries are often installed via the system. Different versions of an application or a service with different levels of dependencies are then packed into these, so not everyone must do this all by themselves. In these cases, containers are completely valid and I can say: the container is helping create a layer of abstraction, which may not exist otherwise, in order to relieve the pain.
JAXenter: If there are advantages, there must also be disadvantages – there’s no light without a shadow. What kind of disadvantages are there with container technology?
Michael Bruns: I am using a layer of abstraction, which otherwise might not be there. And an abstraction is always both a blessing and a curse. On one hand, it can help me, but on the other hand, I think we all should try to the best of our abilities to solve problems without it. Especially in the case of tools like Kubernetes, which are still relatively complex to master. This might change in the future when there are more managed services which support the whole thing. Though at the moment, it is just a very hyped topic.
I also experience relatively often that companies claim the following: “We’re doing everything with containers – we’re doing it all with Kubernetes”, and they think that this makes the world a better place. But the fact of the matter remains that if I put a malfunctioning application in a container, I get just that: a malfunctioning application in a container. This doesn’t help me in the slightest. Yet it is always presented this way and I am a little bit on the warpath with that.
Especially when it comes to containers as a cure-all, I always ask questions like “Is it really the container that brings you an improvement or is it a tool like Docker or Kubernetes”, “Do you perhaps have completely different problems?” or “Do you have to restructure the application before putting it into containers instead of putting a non-functioning application into a container?”. And in my opinion, it doesn’t help to improve things.
Full interview here.