Containers as artifacts the container lifecycle at scale
Source: www.pexels.com

Nowadays, containers are booming. More and more companies are moving away from Virtual Machines every day. Companies follow the trend to package their applications into containers, they clearly see the business value of it. With the increasing popularity of Kubernetes services, many companies jump to this kind of deployment pattern. The managed Kubernetes offerings of big public Cloud providers accelerate this even further by lowering the barrier of entry. This article gives some tips and tricks to treat containers as artifacts.

A blurred line

Simply speaking, a container image is like a wrapper around a (compiled) software binary, blurring the line between infrastructure and software. It does not matter if you work in a large enterprise organization or a small company which produces software.

You probably remember a lot of discussions about responsibility for the development of container images, the container run-time environment and all components which come along with proper life-cycle management of containers: the container Registry, scanning containers for vulnerabilities, patching etc. Oh, and don’t forget the discussion on the development and maintenance of container base images which acts as building blocks for other teams to derive their application container image from.

This topic is really in the middle of everything.

Break the discussion

But how do you get out of this discussion? Multiple options here: give the development teams total freedom in the creation and care of containers including the run-time environment or let all be created by a (central) infrastructure/operations department. Both are not ideal.

Source: www.freepik.com
Source: www.freepik.com

Too much freedom for developers can quickly result in spaghetti infrastructure which is insecure and difficult to manage. When the central department takes care of it, the development teams are often faced with delays while waiting for the things which needs to be in place for the deployment of their applications.

Another solution lies in the middle: treat containers just like software artifacts.

Containers as artifacts: 5 tips

If containers are treated as artifacts and follow the same procedures as other artifacts, we can make sure that containers are part of the existing workflows for managing those. For containers, this means:

  • Ownership is an important aspect of IT Governance who owns and maintains which software component and who is ultimately responsible for it. This is the same for every container image (template). If container images don’t have an owner, it is difficult to maintain them – especially if a large organization has hundreds or maybe thousands of them.
Source: www.isaca.org
Source: www.isaca.org
    • New software versions are released every now and then to provide end-users with new features. The birth and growth of an application is called “software life-cycle management”. Container images should also follow the same principles. All versions should have proper release notes which make clear what the recent changes are.
  • A running container is just like a deployed application. It is very important to know the exact contents of it. The data that describes the contents is called meta-data. With proper meta-data, the running container can be traced back to the actual source code. Examples of meta-data are: the date and time container image was built and updated, the location of the source code, the version, the owner, etc.
  • Software components which are ready to deployed are stored in a repository. Container images should also be stored in a container registry. Development teams are already familiar with this so the adoption of containers is a bit easier and consistent just like other software components.
Source: www.rancher.com
Source: www.rancher.com
  • A good advice is to check the source code of your container images with a special tool called “Lint”. With Lint the quality of the source code is checked for potential problems or inconsistencies.  It reveals upfront problems. And be sure to check your container images for security vulnerabilities. The earlier you do this, the easier and less costly it is to fix it.

These five tips and tricks are to get you started. All of them are written from multiple perspectives, relevant for a business person, a developer or an operator.

Conclusion

No one can deny the popularity of containers nowadays, everyone is in the middle of discussions about how to use containers which best serves the business. Hopefully this topic and the tips gave you some insights to break the discussion so your company can focus on what really matters: delivering business features in a fast and reliable way.