Skip to main content


Key Considerations When Adopting Containers

The following is the fifth blog in a series about software containers and Kubernetes, and their importance in modern application delivery.

In this series so far, we have looked at why businesses are turning to containers, their benefits, the importance of container management platforms, and how to choose the container management platform that’s right for you. In this blog, we’re going to focus on how to prepare your organization to best leverage containers when adopting them.

Adoption of software containers is not without challenges. Once the choice has been made to adopt containerization as an application strategy, there are new challenges to overcome in terms of people, processes, and technology.

T-shaped skillsets

Container-based software delivery requires individuals to operate in a model of mixed development and operations exposure. Whereas historically the norm may have been for engineers to be deeply functional in only one core skill (e.g. database administration or IBM WebSphere administration), a common expectation today is for engineers to have a deep core vertical skillset and also a broad range of horizontal skills – hence the “T” shape.

There should be people in the organization that are cross-skilled and full-stack aware helping to usher along adoption of software containers. Finding these people in an organization is not always a simple task. You should also create road maps and enablement plans to help people to grow into and successfully operate in the new model. Ultimately, the journey of enterprise container adoption requires a lot of change and people with the right skills to support. Position those individuals with deep, diverse expertise to help drive the transformation when adopting containers.

Revisit and revise processes

Organizationally, software delivery is normally a complex process that involves input and validation across different parts of the organization. As change flows through an organization, focus on traditional handoffs and collaboration points as these start to break down in a microservices and container workflow. This normally involves an aspect of software-defined infrastructure.

As software-defined infrastructure and infrastructure as code become more pervasive, the lines blur between traditional organizational silos that have been in place for a combination of historical, separation of duties, highly specialized skillsets, political, and compliance reasons. You should not deemphasize the importance of compliance and process. However, this is an opportunity to revisit the process handoffs, checkpoints, and validations that are in place and refactor to think more about how to strike a balance between low-friction processes and meeting audit and compliance needs.

Long-term technology vision

Technology tends to be the area that gets the most attention and focus from the implementation and leading edge teams that are in the trenches doing the first-of-a-kind implementations and out solving first-order problems. A common challenge that comes up is a lag in the ability to operationalize the follow on to innovation at the edge of the system of interaction moving quickly and independently of the core IT operation teams. This usually occurs specifically around initial difficulties to support these new technologies easily with existing provisioning/orchestration, governance, charge-back, storage, security, monitoring, and logging solutions.

Keeping up with the new developments around containers, container orchestrators, and the ecosystem of software-defined technologies required to support and how to choose solutions is more often being deferred to the team leads and project architects that have the domain expertise. Thanks to that flexibility, the applications are able to innovate and produce results more quickly.

On the flip side, building ad hoc, purpose-built systems leaves a support problem around limited consistency, disparate frameworks, and choosing varied implementations. Businesses that implement and disband short-term tactical projects can further exacerbate this challenge, too.

The benefits of using containers in the “risk versus reward” model still favor leveraging containers for the great benefits discussed in this guide. The key takeaways are to understand some of the risks of adopting containers are much the same as adopting any new technology or standard. Building a plan for mitigating and overcoming these initial risks is key to success beyond the first few pilot applications as the organization looks to adopt an enterprise approach.

Learn more

Either click here or fill out the form below to learn more about containers and prepare your business to develop an effective container strategy.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Sean Wilbur, Senior Solution Architect

DevOps Architect with 10+ years in change & configuration, agile methodologies, build automation, release engineering, infrastructure provisioning, and development best practices. Provide across Perficient around devops practices as well as lead and design solutions for engagements in the IBM, Cloud and DevOps practice.

More from this Author

Follow Us