In our last post, we discussed the growing production use of application containers in the enterprise. App containers are lightweight, portable bundles that include all the resources an application needs to run, so software can be deployed on various systems without rewriting code.
Containers also eliminate the need to launch a virtual machine (VM) for each app, making it possible to support more apps on the same infrastructure.
That’s because containers provide abstraction at the operating system (OS) level, enabling the OS to support multiple application instances. VMs, in contrast, virtualize at the hardware level, requiring a hypervisor and full OS installation along with virtualized device drivers, memory management, etc. As a result, VMs consume far more resources and are much less flexible.
The technology behind application containers isn’t really new — it builds upon a 10-year-old open source technology called Linux containers. However, app containers are optimized for software deployment and provide portability across multiple OSes.
This portability makes containers ideal for hybrid- and multi-cloud environments. Containerized applications can move freely among physical, virtual and cloud platforms, increasing flexibility and minimizing vendor lock-in. They can be provisioned in seconds and enable both horizontal and vertical scalability. Multiple copies of a container can exist on the same system, and failed containers can be removed and replaced without impacting the system.
Containers are commonly associated with microservices, in which applications are built as collections of small, independent services that run their own distinct processes. The idea is to break up rigid, monolithic applications into smaller, more manageable pieces that can be released rapidly for increased agility and scalability. Containers allow developers to choose the best tools for each microservice by making it possible to deploy and update each service independently from each other and from the operating system or cloud platform.
Continuous integration is another use case for app containers. In this model, programmers frequently merge their code into a central repository, and the software is built and tested automatically in the production environment. The goal is to increase developer productivity and release new software faster while improving quality. With containers, the software can also be pushed out to the production environment for more thorough testing.
The growth of the DevOps IT movement has spurred more widespread adoption of container technology. As the name suggests, DevOps brings software development and system operations under the same collaborative umbrella, enabling applications to be developed and rolled out more quickly. Containers are well-suited for a DevOps environment as well as for development team collaboration.
Of course, containers aren’t suited for every situation. They likely will not work with legacy systems, and may not be a good fit for applications that emphasize data management or that need to interact with specific platforms. Containers may not be necessary if application portability isn’t important, and the benefits of containerization will be lost if code must be substantially rewritten.
Nevertheless, containers can help organizations create a more flexible, scalable and responsive environment that enables the faster delivery of IT services. Let us help you evaluate containers and determine how they might benefit your operations.
Comments