Container Adoption


Posted on: February 2, 2018 by Darren Ratcliffe

In the first part of this series we went over the basics of what a container is and its high level technical evolution up until now.

In this part, we will look at how to begin to consider adoption of containers within your business.

Openness is a key adoption consideration

These container 'layers' are being built completely in the open, with contributions from many organisations from both the supplier and consumer side. They are steered by open foundations to ensure there is purpose, direction and progress and importantly that they are not tightly controlled by a few kingpins with agendas. This ensures that broad and mainstream adoption can occur with the confidence that the choices you make today will serve you well in the future.

What is it your consumers require?

A good place to start when determining what you need to provide from a container perspective is with your consumers. In most cases, for this type of consumable service, within a business this will be the tech savvy consumer. They are the builders and / or providers of discreet technology based business functions.

If they are building bespoke tailor-made software to deliver this business function then their desired interface to the provided service is likely to be oriented around developer tooling and CI/CD (Continuous Integration / Delivery) suites that automate the process of software release engineering.

If they are building the business function(s) using third party packaged software then their desired interface to the provided service is likely to be oriented around deployment and configuration management tooling.

It is not uncommon to have both types of consumer within a business.

Depending upon your consumer needs, your choice of opensource projects that you need to combine, your choice of commercial supplier(s) you choose or your choice of service(s) to consume will vary and require a fully considered approach.

So where to begin?

Typically, you begin at the container orchestrator layer, anything deeper than that is beyond where you need to go if your focus is to provide a consumable platform, utilising containers.

It then depends on what type of company you are and what you are looking to achieve. You might be the type of company that:

  • Wants to contribute to the core opensource projects so that you can be satisfied that all within meets your needs and standards. This isn't for the faint of heart, you should be familiar with opensource contributions and the commitment required. To do this you need to ensure that you build a highly skilled, multi-disciplined team capable of working on the frontiers of technology. They should also ideally be organised as a DevOps function so that they can deliver the entirety of the spectrum between code writing to day to day operations as you build out your service.
  • Is happy to handoff the responsibility of day to day evolution of the projects and have this replaced by SLA backed commercials from a supplier with your remaining focus being on how you implement, operate, maintain and supply it to your internal consumers. The team you build will need to be much more oriented towards the lifecycle of the service you produce. You can probably manage by simply delivering an Ops function but the focus should be on automation, the projects upstream from your commercial supplier will version, feature and patch release very frequently. Your suppliers release cadence will more than likely be less frequent but it will be often and your service will need to be capable of rolling out these releases with a minimum amount of friction to your consumers.
  • Wants to go down the SLA backed commercial route but also handoff the operational and lifecycle complexity and just focus on the supply to your internal consumers. If this is the case then the teams focus will be on ensuring that the internal consumers have easy access to the service. The service itself will be lifecycle managed by the supplier, you may have some operational control such as electing when to roll a version forward or adding capacity to the service but how this is done will be within the remit of the supplier.

So where do I get this stuff from?

If you are going to build it yourself then you need to investigate the various foundations and communities (CNCF, CFF, Linux, Eclipse, etc.) to collate the right mix of projects.

If you are going to operate it yourself then you need to investigate the various commercial suppliers (RedHat, Pivotal, CoreOS, Docker, Rancher Labs, etc.) to determine the best functional fit.

If you are going to consume and supply to your consumers then you need to decide if from the public cloud is suitable (Microsoft Azure AKS, Google Cloud GKS, RedHat Openshift Dedicated, Amazon AWS ACS, etc.), if not then from a service provider who offers either the opensource projects or commercial software as a service deployed on premises.

Is that all?

Unfortunately not, in the final part of this series on containers we will take a look at what else you need to consider to have an end to end platform in place to service and most importantly support your consumers.

Share this blog article


About Darren Ratcliffe

Distinguished Expert & Cloud Domain lead
Darren Ratcliffe became the Head of technical strategy, Business & Platform Services, Centres of Excellence in July 2016. Previously he was the Cloud CTO of Atos and Canopy. Darren has led the creation of many innovative cloud services. His objective is to support Atos customers on their digital journey. He is passionate about open innovation and helping the enterprise take a fresh look at their business models supported by cloud, digital and emerging technologies.

Follow or contact Darren