How can Linux containers save your day?

Because the containers are isolated to each other, they are not able to interfere with others in terms of software versions and runtime behavior. For each container you can plan separately on which Linux operating system, web server, language interpreter, etc. your service will rely on — which best fits to your needs. That means, that for example for excessive use of threading or performance needs a single service could be written in Go Lang based on Alpine, while another one uses Apache with PHP also on Alpine and a third one needs to comply with prerequisites using Tomcat with Java on CentOS. All this is possible with containers even running on the same host.

I’m an administrator, why do I need containers?

Containers enable you to split services into their dedicated and isolated runtime environment. Updating the software of one container cannot interfere with or even break the other ones. Instead of overloading a single virtual machine with too much software, you can create smaller software units (the containers), which can be better managed than a monolithic virtual machine. Of course containers run also on (physical or virtual) machines, but they are flexible enough (because of their self-contained nature) to be moved from one location to another one.
Containers are created by script files, which are run unattended and in an automated way, so you always have reproducible results — no more this »little« undocumented changes which disables you to create a new copy of the same instance. Based on all these automatism, multiple / redundant services can be hosted to provide fault tolerance and load balance. Redundancy is usually managed by orchestration software.

I’m a developer, why do I need containers?

With containers, you can try new things very quick and quite easy inside a container and throw it away when not used anymore without any effects on the hosting system. You can create separate containers dedicated to specific projects, and changes on the containers only affect the appropriate project. For new projects, you can pull these pre-built containers you need for the corresponding project. You can also provide pre-built containers to your customers or infrastructure guys, so that the customer can quickly get started using your application instead spending a lot of time for installation purposes.

I’m from quality assurance or responsible for regulated projects, why do I need containers?

With containers, the automated scripts ensure reproducible containers. By using containers, manual installations are not necessary. Sometimes some minor configuration adjustments are also done in a declarative way. With this idiom, installation qualifications shrink from hundred pages to a single page — wow! Containers, if built in a meaningful way, can be used without changes for your staging and production environment, therefore you are well guarded against unpleasant surprises when moving from staging to production!

I’m a service owner or system lead, why do I need containers?

With containers, you are able to choose different programming languages, software versions, web servers and other platforms for each container, which best fit your needs. Choosing the best constellations results in a more efficient service architecture with more reliable services, better to manage services, a shorter go-into-market period and more cost efficient implementation phases.
Together with orchestration tools, the services are monitored with the ability to automatically re-create failing containers. With multiple instances of a service beside of load balancing and fail over, it is also possible to perform a blue-green-deployment, which means to upgrade all containers one-by-one without interruption of the appropriate service.

I’m a business analyst, why do I need containers?

Containers can be quickly downloaded and launched without major configuration changes and so everyone can focus on software functionalities / business logic and not on software installations. This feature makes containers very valuable for software evaluations, providing software portions to end users or providing engineering tools (mockups, test case documentations, etc.) to end users.

I’m a key or end user, why do I need containers?

With containers, downtime for e.g. upgrades are reduced (in best case, there is no downtime at all) and roll-out phases are getting very short, which means that the benefits of new functionalities are usable much faster and that the services are running in a stable way without major interruptions.

I’m a manager of the above guys, why do I need containers?

Presumable you have a quite huge team. Each team member must have nearly the same skills as each other one to cover all needs in maintaining all services your team is providing. This makes it very difficult to extend your team.
As with Microservices complex software architecture can be split into separated containers dividing a single complexity into multiple better-manageable pieces. Each piece could be managed by a smaller team (similar to DevOps). Each team then has clear responsibilities and new members can be better integrated in terms of technical and soft skills.

I’m none of the above guys, why do I need containers?

To make a complex story short: It is simply cool and a modern technology with a lot of use cases!

Summary

As summary containers can provide following features:

• Installation isolation: No more side-affects onto other software during software changes
• Runtime isolation: No more (or at least less) security concerns what software can do if compromised
• Enforced standards: Less effort in introducing new project / team members, and the risk of »undocumented« changes is nearly gone
• One-pager for installation guides: According to the unattended installation script files, only some few configuration adjustments have to be performed
• Pre-built container images: The container images are ready-to-use. Therefore, the instantiation of such containers are a one-liner
• Health checks: Orchestration tools are able to check the health status of each container and are able to destroy failed containers and re-create fresh ones
• Redundancy: Running multiple instances per container / services ensures load balancing and fail over
• Reproducibility: The container images are reproducible because of the enforced script files which are needed to create the images
• Simplified software architecture: Complex software architecture can be split in more simple software pieces (e.g. Microservices) which can be better managed on their own
• Encourages more but smaller teams with clearer responsibilities: Teams assigned to a limited set of services / containers have clearer defined responsibilities and it is easier to integrate new team members

Maybe this datasheet “Distributed Environments With Containers” is also of interest for you?

If you have any questions or thoughts, feel free to contact me.
I’m looking forward to hearing from you!
Jörg Friedrich