Pitfalls and Successes in Operational and Cultural Change when Adopting Container Platforms

Failure to Iterate

The technology itself is changing and evolving rapidly. The inability to quickly iterate and consume changes in the products and tooling can put you far behind recent features and potentially cause a lot more rework or re-invention of features already in development. If you try to solve for everything on day one, the time it takes often can put you several versions behind and also could result in solving for scenarios that aren’t necessary at that moment, on both the Infrastructure and the development side.

Preparing for Change

Trying to force the platform into a set of rigid existing practices sometimes is far more difficult than starting from scratch and designing the processes that are based on your business or operational needs.  Re-evaluating what requirements must be met for the various stakeholders and then working on those use cases will focus the efforts on highest value vs. just achieving a parity with existing systems or practices which may or may not meet the actual needs of the organization.  Building a capability to respond and change quickly is just as important if not more important than the initial delivery of the platform.  Being prepared to consistently make changes to the environment in a predictable manner allows for new features, functions and integrations to become more of a non-event vs. major deployment exercises.

Where will my job go?

As the container development paradigm can be used to enforce standardization, often whole teams of people are currently tasked with managing the configuration of specific VMs and the application runtime configurations on them (Tomcat, JBoss, Weblogic). The shift to containers doesn’t mean these runtimes no longer need to be configured, however the point in time that this occurs is upstream and becomes baked into the images instead of waiting on the VMs to receive the code artifact deployments. This change in ordering of when configurations happens often brings together the platform and infrastructure teams and middleware configuration teams to work together to provide a set of base images or standard application stacks for the organization. The chain of custody of a VM from Provisioning, OS Installation, Infrastructure tooling and then passing that on to downstream teams is converted into the multiple teams all participating to build the layers of the images and then making them available for general use.   The move to the configuration happening as code in the underlying image definitions frees up many resource to focus on additional value added activities such as automations or additional quality assurance integrations.

Shift Left Strategies:  

Adoption of a container platform such as OpenShift doesn’t mean that entire app teams have to start using all the features in the product day 1.  Gradually shifting some of the control from one or more groups that currently manage the application lifecycle and enabling the application teams to take on more of the DevOps roles with subsequent iterations can be a strategy to initially adopt the container platform as a deployment runtime and not causing significant disruption to the ongoing application development work.
Over several iterations the teams can work to push the activities to the  left and give their development teams increasing control and responsibilities over their application life cycles with guidance from the first iterations.  Gradually increasing the Roles played by the Development Teams and transitioning the team from a development team to a DevOps team.  

In summary, taking on the collective challenge to adopt containers in an organization must be met with obvious changes in technologies being used, but also to changes in the people and how they are organized around the processes that are used to deliver code more quickly with higher quality and increased automation.   

I’ll be speaking more about this at Red Hat Summit. If you are attending, please make sure not to miss the Discovery Zone session entitled “Defining operational roles with containers and DevOps” on Tuesday, May 2nd at 10:15AM.  Looking forward to seeing you there! For more information, visit red.ht/discoveryzone.