My history with containers goes back a long way. A while ago I described them as a solution looking for a problem. I have worked with AKS a number of times, implemented it, designed monitoring and integrated pipelines, however the whole technology still gets me wound up and I wanted to share some of that.
Firstly, let me explain that I am not at all anti-containers, in the right environment for the right solution, of course the technology has it’s place. I think my biggest problem is that like a colleague put it to me, in the infancy of cloud it came across as a self-fulfilling prophecy, containers I think has become similar in some ways.
Secondly, I do believe like the same colleague above that containers can be a great stepping stone out of the traditional ways of infrastructure to more serverless technologies, platform as a service and data platform. The real problem is when the containers technology is misued.
How can you misuse containers?
If you have an application that at its core is based on micro-services architecture and you need your application the scale horizontally, be self-healing (one of the many fantastic features of AKS) and have load balancing built in, then containers is most certainly the way for you to go, and if you are deploying on Microsoft Azure, then Azure Kubernetes Service or AKS is certainly something you should look at. The technology even compliments your DevOps investments around continuous integration and continuous deployment really well, making the whole management experience pretty seamless.
When you take an existing application from a server and wrap that into a container and deploy it to a container, you are probably leaving yourself with a number of problems in the future, this is where my dislike of containers comes in and to some degree the ease at which it can be done and the architects which follow this design pattern.
Taking a monolithic application, wrapping a container around it and deploying a 2 GB containers image is not in the spirit of the technology, but it works. You will not be able to make use of the fantastic scalability and health benefits when deploying 2 GB images. However, if your application is small, micro-service based and your images are very small, then you can deploy in seconds.
When should we use containers?
I mentioned above briefly, but if you are heading your application towards micro-services, then containers is an approach you may want to look at. Helpfully, Microsoft have published a number of solution architecture patterns on the feature page for AKS, this should help define an appropriate pattern for you.
When you take legacy applications, think about how you can re-architect them first, don’t just fall back instantly to deploying to containers, it may be easier but you may be best deploying to another cloud service such as app services or Azure SQL for example. You will find in many scenarios this is a better option given the feature set of those services and cheaper than putting it on containers.
My key takeaway here is really think about the right place for the application. It’s some of the basics of system architecture, think about longer term strategy, don’t just think about what is the next best technology today or what will look good.
Make sure you deploy your applications to the most suitable place possible for that workload.