days
1
8
hours
0
0
minutes
1
3
seconds
4
4
search
Interview with Michael Bruns at DevOpsCon 2017 in Munich

“Putting a malfunctioning application into containers does not make it better”

Dominik Mohilo
containers

Containers are definitely not a panacea for all problems and sometimes they are even more of a burden than an advantage for a project. In our interview at DevOpsCon 2017 in Munich, Michael Bruns, software developer and architect at inovex, explains which projects can really benefit from Docker, Kubernetes and the like. He also reveals to us, whether serverless will soon replace container technology.

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 than 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.

JAXenter: Your session at DevOpsCon had the topic of “Docker or Kubernetes – must it always be this way?” Which projects benefit the most from this combination and container technology and what are they best suited for?

“If I put a malfunctioning application in a container, I get just that: a malfunctioning application in a container”

Michael Bruns: Just like I mentioned above: I think there are projects, which have a simple set-up and where it pays off to make use of containers. Take the relatively classic company as an example, which has its own data center or more hardware resources. They might say that they want a simpler approach, automatic scaling and a more efficient use of the current hardware. That is a scenario in which it is completely valid from the very start to use container technology or something similar to Kubernetes.

Another point where it is sensible to use containers is when I am forced to pursue a multi-cloud strategy. There are cases where both AWS and Azure, as well as Google Platforms or something similar must be supported. However, I do question whether these cases really do exist that often. If it were indeed the case, that I would have to drive multi-cloud strategies for some failover scenario, I would also say that containers do not really help there either. AWS is no longer the lowest common denominator and you need another one, which containers can definiteley and easily deliver at this point.

SEE ALSO: Geographically distributed microservices: Do containers solve all our problems?

JAXenter: Are there any cases where it is absolutely pointless to use a container and Kubernetes or Docker?

“I think both, serverless and Container technology, can actually coexist”

Michael Bruns: It’s somewhat questionable to declare something to be “absolutely pointless”. In my opinion there simply doesn’t exist a “silver bullet” solution which works for everything and it’s also hard to say that everything is “absolutely pointless”. If I start a new project and I am not certain what to expect (e.g. how the number of users will develop, what kind of peak loads are to be expected and so on), then I probably should concentrate on other things first.

So, in the beginning one should consider how the application should be developed, so that it can reasonably implement the things which are already clear as a premise. And if this works out then I can still think about whether it makes sense to put the whole thing into containers.

In my opinion, it is much more important to structure an application so that it does have a sensible, internal structure and that it’s also in accordance with the current patterns of a cloud application. For example, there are these 12-factor apps that have certain guidelines which can be used as an orientation. If I set up my application according to this, then it is no longer so difficult to put it into a container afterwards.

But if I put a monolith into a container, then we’re right to where we’ve just been, so I say it again: It doesn’t make any sense at this point. And then I would rather do something else first. Nevertheless, even in such a project a container can help me in the long run, but I would just put the focus somewhere else for a while.

JAXenter: How about a small look into the future? Is container technology future-proof or will serverless outperform it?

Micheal Bruns: I think both can actually coexist. In the end, serverless features are nothing more than small containers that boot up and shut down quickly. In the meantime, there’s also the possibility to build such solutions yourself with Kubernetes. And of course there are tools for this purpose, such as Fission. There are still some barriers to break down because the aforementioned tools are still relatively new and you have to be on the lookout for personnel with the necessary expertise (if there are even enough of them around).

I think it will get more exciting, when more cloud providers offer something like Google, which just recently published Cloud Platforms. This is basically “managed Kubernetes”. There are also of course Azure Functions and AWS Lamda, where I can achieve the whole thing now due to fewer obstacles. Just like saying that everything will get better with containers, it is my opinion that it is equally wrong to say that everything will get better with serverless technology.

Or so to say, that there’s no one size fits all solution. I use everything with moderation and that’s the reason why I think that both will continue to coexist for years to come.

JAXenter: Thank you Michael!

Author
Dominik Mohilo
Dominik Mohilo studied German and sociology at the Frankfurt University, and works at S&S Media since 2015.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of