Jon Payne, developer engineer at InterSystems gets inside the container, outlining their purpose, benefits, (and shortcomings) and takes a look at what’s next.

A container-based approach has long proven to be popular with developers, particularly within a testing environment as an enabling part of a DevOps pipeline. While containers do offer an effective way to recompile codeand test in a lightweight and rapid manner, the container landscape could be transforming.

In recent years, the popularity of containers has increased, largely due to the fact that they are easier to work with than the alternatives thanks to increased efficiency and speed of deployment.

According to a study by Forrester, 66% of organisations who adopted containers experienced accelerated developer efficiency, while 75% of companies achieved a moderate to significant increase in application deployment speed.

As such, for developers, they have become integral to simplifying the development cycle, resulting in more widespread adoption.

Forrester reports that the organisations they surveyed now have an average of 165 different containerised applications, a number that they expect to rise by 80% in the next two years.

However, as adoption increases, the shortcomings of containers have become more noticeable, forcing providers to begin to address some of the disadvantages of using this approach.

But, why exactly have containers become so instrumental to development work, and will this continue to be the case moving forward?

Why we use containers

There has long been support for 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 benefits to using containers, in particular,that they make it easier to implement an agile approach to building, testing and deploying software.

This is because a container-based approach isolates runtime components, allowing developers to drop in a new version of the code, immediately test it and see if it is correct, therefore simplifying the development cycle.

This is significantly easier than the previous method of installing the code to be tested onto virtual machines or native OS, which was more time-consumingand required installing software.

Ultimately, containers offer a more agile and responsive framework and mean that developers don’t have to go through a long build and deployment cycle.

Additionally, a container-based approach offers developers integration, with mature and mainstream tools that are integrated into the development, production and monitoring technologies that are now available.

Limitations of containers

Fortunately, many of the disadvantages of using containers have largely been or are in the process of being overcome.

For instance, running Docker on Windows historically isn’t a comfortable fit, but this is something we know Microsoft is working hard to overcome, and in the imminent future it should no longer be an issue.

The more common problem facing the use of containers is, in fact, the number of people in the market who don’t understand what a container is and what the benefits are of the encapsulation of code and the runtime environment which allow it to operate.

Quite often, these people are stuck in a native operating system mindset and have yet to grasp the capabilities and potential of containers.

In these cases, 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-secondresponse 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.

Looking to the future

Overall, 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 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 future, we will continue to see a shift to a container-based approach 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.

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.

Currently, there are no immediately apparent successors in line to replace the use of containers.

However, 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.