Over recent years, we have seen the popularity of containers increase to a point where, thanks to their ability to recompile code and test in a lightweight and rapid manner, their use is now integral to simplifying the development cycle. For developers, they have been a welcome change from the previous method of installing the code to be tested onto virtual machines or native OS, which was more time-consuming and required installing software.
Much of the popularity of containers comes down to offering developers increased efficiency and speed of deployment, as demonstrated by a study by Forrester (opens in new tab), which found that 66 per cent of organisations who adopted containers experienced accelerated developer efficiency. The report also revealed that 75 per cent of companies achieved a moderate to significant increase in application deployment speed.
However, the container landscape could be transforming as increased adoption has led the limitations of containers to become more noticeable. So, will providers begin to address these issues, and what does this mean for the future of containers?
The case for containers
Developers have long been in support of using a container-based approach as a runtime unit. However, it has really been the emergence of cloud-based providers, such as Amazon Web Services, that has led the idea of using containers to deploy code for live production applications to become widely accepted as the preferred way to do things. This has largely been driven by stiffer competition, as companies have needed to become more agile in their software development; gone are the days of long production cycles. Instead, they have begun a develop-on-the-fly approach, DevOps, that allows for much shorter innovation cycles.
There are a number of substantial benefits to using containers within a testing environment with one of the most notable advantages for developers being that containers make it easier to implement an agile approach to building, testing and deploying software. This is due to a container-based approach isolating runtime components, which means developers can drop in a new version of the code, immediately test it and see if it is correct, therefore simplifying the development cycle. Ultimately, this more agile and responsive framework means that developers don’t have to go through a long build and deployment cycle.
A further benefit of a container-based approach is that it offers developers integration with mature and mainstream tools that are integrated into the development, production and monitoring technologies that are now available.
The drawbacks of containers
Over recent years, providers have worked hard to overcome the limitations of containers. For example, while running Docker on Windows hasn’t historically been a comfortable fit, Microsoft is working on getting over this stumbling block, meaning it should no longer be an issue in the near future.
Instead, the more pressing problem facing the use of containers is, in fact, a lack of awareness and understanding within the market of what a container is and what the benefits are of the encapsulation of code and the runtime environment which allow it to operate. More often than not, those who fail to understand containers are stuck in a native operating system mindset and have yet to grasp the capabilities and potential of containers. a paradigm shift still needs to occur; however, we are seeing the market begin to get over this stumbling block.
Ultimately, whether you use containers comes down to underlying architecture and the non-functional requirements you need to meet with your deployment. For instance, if a developer wants massive horizontal scaling by spinning up on-demand resources within a major cloud environment then deploying via containers makes sense. Yet, if the user is running an enterprise application on dedicated hardware in a highly controlled environment, and it’s mission critical to have a sub-second response time, for example, containers may not be the best option. Rather, the system is always going to be more predictable, performant and stable when running natively on an operating system, on well-managed dedicated hardware, instead of going through an additional virtualisation layer.
In these high-performance environments, being slowed down for a few seconds by containers may make a dramatic difference and therefore may not be the best choice. It is this impact on performance that can be an issue for enterprise applications and make containers unsuitable for the production systems.
What does the future hold?
In a testing environment, there are very few disadvantages to using a container-based approach over the more traditional method of deploying on a virtual machine or a native OS. In most cases, containers are beneficial in terms of agility and speed of development, as they make deploying new versions of code quick and easy and it is possible to further isolate application code from the underlying hardware.
In the coming years, the shift to a container-based approach is only set to continue. In fact, Forrester reports that while the organisations they surveyed now have an average of 165 different containerised applications, they expect this number to rise by 80 per cent in the next two years. We will also see them adopted within different environments as people buy software as a service and providers behind the scenes start deploying containers in order to roll out an upgrade within seconds and with minimal disruption to service. This popularity among providers is helped by the fact that containers lend themselves to high availability scenarios for applications, making applications highly scalable and it possible to spin up more when demand increases then scale back as needed.
At this stage, the popularity of containers shows no signs of abating and, currently, there are no immediately apparent successors in line to replace their use. That said, in an increasingly cloud-heavy environment, there seems to be a trend for cloud-native applications that are composed of discrete functional units that are capable of being run independently, behaving like micro-containers and supported by the Cloud environment. This would see more features move out of containers and into the underlying platform, with the resultant tie in to a specific flavour of Cloud. However, with such a strong case for the use of containers, it is likely containers will long be the preferred approach for developers, allowing them to deploy software quickly and efficiently and in a manner that reduces the tie-in to specific Cloud vendors.
Jon Payne, InterSystems (opens in new tab)
Image source: Shutterstock/TechnoVectors