A few months ago, I wrote about how containers can be used to decrease the time it takes to ramp-up a new developer on a project. However, it’s just one of many ways in which the benefits of containers can be used to decrease costs, reduce resources and save time on your projects.
What are containers?
Before we explain why you should be using containers in your environment, let’s level set and understand what exactly we’re talking about when we say containers.
Containers are a standardized way to package up all the code, settings, and dependencies needed to run an application quickly and dependably between environments in a small, lightweight executable format.
They are often compared to virtual machines, where a guest operating system, like Linux or Windows, is run atop a host operating system. But unlike virtual machines that virtualize the hardware stack, containers abstract away the hardware component and virtualize at the operating system. This allows them to be deployed easily and dependably across various environments.
Benefits of leveraging containers
Containers contain everything that’s needed to run the application. Thanks to that, they can be easily moved across various environments—on-premise or in the cloud. And because they are using an industry-standard format, they can even move across cloud providers. Once you build it, it can run anywhere.
Even though multiple containers can run on the same server, they run in an isolated environment—a sandbox—that keeps applications running apart from one another. In case one application crashes the other, they don’t get affected. Or—when the unthinkable happens, and one application is hacked—the attack is contained to that application exclusively.
Containers provide a predictable and repeatable environment in which the various software tests, needed to ensure the functionality of an application, are run. No longer do you need complex scripts to reset an environment after a test run. When a new test is necessary, spin up a new container already configured with all the test data, run your tests and when complete, destroy the container.
Due to their virtualization of the operating system layer, containers do not require an operating system boot. They can start-up in seconds. Therefore, when the next release of an application, or bug fix, occurs, new containers can be spun up quickly. New features and fixes will then get into customers’ hands sooner rather than later.
As mentioned above, containers can be spun up in a matter of seconds. This allows for a quicker reaction to increased demand by spinning up new containers, scaling out the application. When the demand on the application subsides, simply destroy the excess containers.
The other benefits containers provide all contribute to the overall savings you get when you employ them in your environment. Being able to pick and choose where to run your containers allows you to choose the most cost-effective hosting environment. A smaller, lightweight footprint means that you can run more containers on a single server. In turn, when scaling out an application, fewer servers will be needed.
As test environments can be created quickly, there’s no need to keep them up and running when not needed. That way, you can save on total resources throughout the software development lifecycle.
Switch everything over to containers
While it may sound like you should move all your applications into containers, containers won’t solve all your software problems—as the title suggests.
Containers won’t fix bad design or poor code.
A poorly designed, monolithic application doesn’t get better just by throwing it in a container. It may deploy easier, but it remains the same in its core—a badly designed monolithic application. The only way to improve is through development time and effort. Containers can shield other applications from security breaches but won’t prevent the security breach of the application itself.
As noted earlier—quite a bit of the cost savings comes from the other benefits highlighted above. Once those benefits diminish, the cost savings decrease as well.
When to use containers
Containers start to make sense and maximize the benefits when used as part of a microservices architecture. Different areas of the application can be scaled, updated, and maintained separately. This way, multiple teams can work on these areas, releasing them at different times, without stepping on one another’s toes. Besides, infrastructure teams no longer have to worry about the dependency requirements of the many applications running on their servers.
Large corporations and enterprises have long been known for being slow to update and change the infrastructure on which applications are running. With an application’s dependencies being consolidated and isolated inside a container, infrastructure teams can focus on maximizing server and resource utilization without worrying about these dependencies and shift applications around without fear of dependency conflict.
Containers and Kentico Xperience
Once you decide to move your Kentico Xperience environment to containers, a new world of opportunities opens up. As discussed in my previous article, development teams are able to ramp-up quicker on new projects without having to worry about reconfiguring their machines. This also allows teams to rapidly respond to client requests to update their site, long after the original project has closed.
With the frequency of new features increasing for Xperience, customers can now access these features faster because testing and updating to the latest version is faster and more reliable while also providing the ability to quickly rollback, if necessary.
Other scenarios, such as being able to simulate a web farm environment locally, means that teams can more easily reproduce what is going on in the production environment on their machines without giving them access to production.
Given the immense benefits containers provide, they should be on your roadmap in the near term, if not already explored. And if they are not, let me leave you with this final thought: All of the applications at Google, YouTube, Gmail, and search, are all run in containers. Maybe it’s time to start considering a change.