Linux containers are the best thing since sliced bread! Forget everything you’ve ever learned about developing applications and focus on Linux containers instead! Linux containers are the solution to every application development and delivery problem!
Amid all the Linux container hype these days, you’re likely—and rightly—casting a suspicious eye on the model. No, Linux container technology doesn’t make sense in all situations (despite what you may be hearing), but there are a great many use cases for which container technology does make perfect sense. The trick is to know when containers are well suited to the task at hand, and in what context.
Quick like a container
Linux containers enable developers to package and isolate applications with their entire runtime environment—all the files necessary to run. This makes it easy to move the containerized application among environments—such as dev, test, and production—while retaining full functionality. In today’s on-demand business environment, all of this is a really good thing. Using Linux containers, developers can quickly (and recursively) develop, deploy, and test applications to meet internal and external demand that is growing in pace, variety, and scope.
Another benefit of the Linux container model is that it, by its nature, creates clean separation between the development and operations teams. With layered container images, devs and sys admins can each make changes to different layers. Developers can focus on apps, and sys admins can focus on the infrastructure—and everyone can focus more on meeting business goals.
From a more pragmatic perspective, because containers rely on the host machine’s OS (unlike virtual machines, which package everything together), you can run more containers than VMs on host hardware.
Container compatibility
What organizations will benefit most from container technology? Specifically, organizations that are feeling competitive pressures are a good fit. If an organization needs to create business facing apps faster and/or continually iterate on those apps, it’s probably a good fit. That would include a wide number and variety of businesses today, because the ability to meet internal and external customer requirements for applications is often the difference between gaining and retaining customers or turning them away.
Indeed, with containers it’s all about speed and agility. You can quickly and easily develop an app by putting together the right microservices, and then test that app in exactly the context that the end user will experience it in. If the app works well, great; if not, that’s OK, too, because you can easily tweak, test, and deploy it again—without having to build up massive infrastructure.
However, while it is easy enough for developers to use Linux container technology, it’s not so easy to manage an entire container environment, especially as the number of containers a company uses grows. Fortunately, as container technology matures, so too do the tools that support organizations’ use of containers. For example, platform-as-a-service, or PaaS, systems provide the equivalent of a driverless container car: You may have to push a button or two, but most of the heavy lifting is done for you.
The rub may lie therein for some developers and/or for some projects. PaaS will certainly get the container deployment job done, but developers will not have as much granularity or control as they would be using something like Docker.
It’s kind of like the difference between driving a family sedan and a dump truck: Like a PaaS, the family sedan is a fine machine that will get you from Point A to Point B safely and reliably, without the driver having to think too much about it. The dump truck, like Docker, will also get you from Point A to Point B, but the driver will have much more granular control over the cargo. Drivers may need more skill out of the gate to effectively operate a dump truck (or a container platform), but they can also do a lot more with the tool once they get going.
Organizations will need to determine whether it makes sense to always deploy containers on a PaaS, or if there are some use cases that require more granularity and control.
With that said, providers in the container space are working to give organizations the best of both worlds.
When to take a container pass (or pause)
Still, the container model is not right for every application. For example, while monolithic legacy applications can be broken up into microservices and containerized, it might not be worth the time and trouble to do so if the application is chugging along nicely on dedicated on-premises hardware (especially for applications built over decades with a Frankenstein-level collection of parts and processes).
Companies will also have to determine whether the container model will let them meet current security, privacy, and regulatory mandates, and they will need to establish whether current developer skill sets will support effective use of container technology.
No one said the container choice would be easy, but it’s certainly easier than a great many development decisions have been in the past. The new container and container image paradigm seems to be just right as companies struggle to meet demand for applications that expand business processes across all digital platforms. Determining what to use containers for, when, and how can only help position your organization for innovation and growth.