The company is doing great. Your application is finally gaining the traction needed. The load is increasing. But so is the general IT cost. Maybe you have already faced downtime, bug fixing is going too slowly, and the deployment strategy needs work. One solution could be moving into a container environment. But is it really the right choice and will it work well with your application setup? Read more about the requirements from both an organisational and a technical perspective.
First things first: it all starts with the appropriate development and deployment strategy
Regardless of whether you change to containers or not: many of the above-mentioned problems can be solved by finding the right deployment strategy and processes. You can establish a perfect CI/CD process without using containers. A higher level of automation within the development and deployment process reduces errors and makes pushing new code to an environment much faster. In addition, treating the environment as immutable and deploying changes via the Infrastructure as Code pattern ensures a consistent environment through version control, automated updates and trackable changes. Having an efficient team and good control mechanisms are crucial to facing the ever-evolving challenges of running production software.
But if I want to use container technology, what are the technical prerequisites?
The good news is: nearly every app can be containerized. Here are some important points to take note of:
The level of complexity depends on whether the app is stateless or stateful. When using stateful apps, you need to make sure to have consistent disks or databases attached in order to save state.
Apps should be built in a platform agnostic way, since containers include all environmental information
Ideally, you should be able to split your app into microservices , so that you can run each process in a separate container. (Please note that when using windows containers this is not possible.)
As already mentioned above, it is crucial to make sure the environment the containers are run on stays consistent. This is facilitated through automation.
What does containerization mean for the development process?
Building the containers really is the easy part. Working out everything around them to make the system production-ready is the hard bit. For example: when you develop your containers, you probably do not consider the intricacies of issues such as container networking:
You need to develop a thorough knowledge of how to manage the connections between containers, regardless of whether you have a single-host solution or use a cluster.
The concepts differ depending on whether you use Docker or work with Kubernetes, and you need to understand the differences and limitations of each solution.
With Docker, there are different types of network modes and each one comes with distinct trade offs when it comes to ease of use, security and encapsulation.
When running containers on different hosts, IP mapping can quickly get complicated.
When faced with this complexity, you may instead turn to an orchestration platform which abstracts away much of the complexity and allows configuration via yaml objects. However, this is not effort-free and also requires a good understanding of the options available
What are the prerequisites from an organisational point of view?
What is most important is gaining all the knowledge which allows you to run your application on a container platform: knowing how to build and orchestrate the containers, and knowing how the platform’s api works. It is important to have a team that embraces a new way of working and is willing to implement changes where needed. Due to the high complexity of container orchestration platforms, it may be advisable to outsource whatever is not creating direct business value: the platform itself and its supporting services can be run by someone else while you concentrate on your application.
Okay, and how much time does all of that take?
That is not an easy question to answer, because there are a lot of dependencies to consider. It is determined by the complexity of the project. For example, a container for a golang app which does not require any c libraries is something that you could do in a few hours. When containerizing a complex php application with apache, which uses a lot of modules, it could easily take a couple of weeks to iron out all the issues. Once you have the container, the orchestration will also depend on the app, on the degree of variance of load, which other services are needed, which secrets and config you need to inject at runtime, on whether there are any special networking considerations and so on. The list is of course not conclusive
Conclusion: it’s worth the effort
All of this seems like a lot work. But in the long run, the usage of automation and the right tools enables developers to write, review and push code much faster than before. The automation of both application and environmental deployments saves time and money, since knowing exact state means reproducibility and less errors, and the infrastructure as code pattern creates self-documenting setups. Having a reliable partner who takes care of the infrastructure leaves you with more time for your application and your business.