Containerisation in the enterprise - Engine Yard: Container fun with Bob and Alice
As businesses continue to modernise their server estate and move towards cloud-native architectures, the elephant in the room is the monolithic core business application that cannot easily be rehosted without significant risk and disruption.
These days, it is more efficient to deploy an application in a container than use a virtual machine. Computer Weekly now examines the modern trends, dynamics and challenges faced by organisations now migrating to the micro-engineered world of software containerisation.
As all good software architects know, a container is defined as a ‘logical’ computing environment where code is engineered to allow a guest application to run in a state where it is abstracted away from the underlying host system’s hardware and software infrastructure resources.
So, what do enterprises need to think about when it comes to architecting, developing, deploying and maintaining software containers?
This post is written by Darren Broemmer in his role as technology evangelist at Engine Yard — the company is known as a data-driven, NoOps PaaS solution for deploying and managing applications on AWS.
Broemmer writes as follows…
The power of containers is often described with words like portability, scalability and resource utilisation. All these terms certainly apply, but I believe a simple story best illustrates how containers make life easier for DevOps practitioners.
Let’s consider Alice and Bob who both work on a team where they are building a Ruby-on-Rails application fronted by an Nginx web server.
Alice in Windows-land
Alice, like everyone on the team, needs to run the Nginx web server while developing. Her development workstation is her preferred environment… and it’s Windows 10.
However, the target deployment platform for the application is Ubuntu Linux.
Rather than patch together an environment, she runs a single Docker command to start a local Nginx container. This container maps the content folder to the corresponding project directory. She now has a web server up and running in a few minutes that matches production.
Bob is a Mac fanboy
Bob has a Mac OS X workstation.
He, however, decides to set up Nginx natively on his host machine. While performing the installation, he runs into some dependency conflicts based on libraries needed for software from his last project. He spends a number of hours resolving the conflicts and eventually gets his development environment setup. If there is an issue, he won’t know if it’s his environment or a true issue, but that is a problem for another day.
What does happen though is his team upgrades to the latest version of Nginx. Now, the problem repeats itself.
Even worse, a bug is reported on a production environment that hasn’t been updated yet. Now Bob has to figure out how to revert to the old version to replicate the issue.
Well, it works on my machine
There are a number of other slight variations to this story, but they all end in basically the same manner. Alice will spend less time on average worrying about infrastructure and more time developing application capabilities. She knows that if a capability works on her local containers, there is a good chance it will behave the same way in production. Over the long term, Bob’s experience will be different. It may even result in the dreaded ‘it-works-on-my-machine’ scenario.
Engine Yard’s Broemmer: Contain yourself and don’t be an ‘it-works-on-my-machine’ killjoy
It is critical to have reliable deployment mechanisms when development teams own the process. The ability to bundle and preserve all the dependencies and environment characteristics into a single deployment artifact is invaluable. The ability is front and center in a DevOps- oriented paradigm.
As many as 27% of developers say that deploying to production is their biggest cause of delay, according to the GitLab 2019 Global Software Engineering Report. The consistency of container deployments drastically reduces the amount of time and effort spent on this area. DevOps scripts and tooling are no longer something to be feared, they become your friend.
Additionally, containers and orchestration environments typically provide for standardised non-functional requirements such as monitoring and logging. They facilitate the decomposition of monolithic applications into services, each of which runs on its own container. The advantage here is that it becomes much easier to observe the behaviour, both good and bad, of that service in isolation. When application services are combined on an instance with a half dozen other components, it becomes more difficult to diagnose problems. Observability is a tremendous benefit of containers in terms of DevOps.
Oh, and did we mention that the deployed application can scale up in milliseconds as compared to seconds or minutes for virtual machines? Now that is something that all the developers can rally around.
With containers, developers get the freedom to focus on the code instead of the deployment, without having to worry about the details… and that, my friends, is power.
Darren Broemmer has been a developer and engineering project manager, working at a range of companies, including AWS. He currently is developer evangelist at EngineYard.