DEVOPSdigest

So what are the additional roles/skills needed for successfully deploying Containers in Production besides SRE? They are Container Engineering, CMDB Dependency Mapping, Product Management (not just project), and Release Management.

Start with Debunking Myths About Containers in Production Impacting Transformation - Part 1

Different Skills Require Different Expertise: Rise of Container Engineering

Think of the DevSecOps (Continuous Integration/Continuous Delivery or CI/CD) pipeline as the highway. Think of containers as a Tesla. A logical person would never dream of having a concrete mixer work on their new Tesla. Nor would they ask their Tesla mechanic to lay the foundation for the road in front of their home. So why do some believe that Site Reliability Engineering can solve all the diverse set of challenges for DevSecOps?

Containers have worked in production for vendors and for ISVs since the late 90s because they come with the assumption that the role of Container Engineering exists within development. Container Engineering is not a freeway or pipeline issue. Containers are realistically all about packaging. Not just the application but how it works within the underlying registry of the operating system. They need to thoroughly understand the limitations and implications of the type of container they are deploying. Container Engineers also need to understand the policies, procedures, and regulations that govern their company and industry during the creation of containers, not just deployment of them.

That is not to say certain skills needed to drive the car and understand how it performs on the freeway are not required. Similar to building a car, Container Engineers need to understand what instrumentation (telemetry) is required to monitor, maintain and address issues that come up with the container when they are designing/building it. They must also understand what resources they will need to support it in production.

Configuration Management Database Engineers Are Essential

Similar to a Tesla needing charging stations, not just petrol dispensaries, containers require a well thought out ecosystem to support their overall performance in production. Part of the challenge leading to confusion is: more often than not SRE skills are overpromised and under-delivered. Just as a logical person would not have a concrete mixer work on their car — they also would not have them design charging stations to fuel their new Tesla.

However, more often then not, SREs are volunteering to work on building either Microservice Management and/or Hybrid Application Dependency Mapping within the CMDB — another area that requires a uniquely different set of skills and understanding of Integration, Tuning and Timing.

As the luminary that started both, I cringe when I hear that pitch and/or limited lack of understanding.

Why? Few realize that the CMDB was actually designed with containers in mind. Configuration items were not only created to map back to applications but also business services. CIs can be defined at the Microservice Level. There is no need for yet another tool but there is a need to expand/design the commercial CMDBs that were built pre-cloud to scale using modern technologies.

Before you pay to train a consultant in another area, see who you have working in those areas that understand containers, cloud, natural language processing and the limitations of the current CMDB providers. Chances are they may already have a solution and more importantly can get the company to a working one before reinventing the wheel.

Why? The CMDB was designed to operationalize new (and legacy) technology throughout the IT Service Management Lifecycle. Companies that try to deploy containers without including and incorporating their production implementation into their existing ITSM processes will fail. The cultural shift from legacy to new environment will spread the resources too thin and leave them in a broken state. This is especially true for companies practicing project-based SDLC over product-based SDLC.

Product Management is the Glue

One of the biggest failure points — not just for containers but for digital transformation in general — is the lack of real product management skills and roles within IT.

Why? Project/Program Managers with product management titles will not have the know-how to extract requirements needed to build out the Agile Business Requirements Document or backlog.

More often than not architects are overloaded with the documentation, requirements gathering, and backlog creation. The lack of product also creates unrealistic timelines and gaps in leadership understanding.

Why? Project/Program Managers are amazing at tracking action items, timelines and deliverables as the roles require it. They are however, not the technical experts that understand how the technology works, how to build a profit and loss business case on all the dependent pieces, scope the body of work with development and groom the backlogs. Pushing this critical role on either Architecture or Project Management is unrealistic and ultimately ends in failure.

Why? The needed vision, and ability to quickly consolidate requirements down to critical path elements, usually comes from having technical chops and is a full time job in and of itself.

Orchestrate Success Through People and Processes Not Just Technology

Site Reliability Engineering is a critical new role but let's not forget the other roles needed to be successful. If your company is not willing to invest in building out these areas or retooling — then think about how you acquire those skillsets and resources. Product Management and Container Engineering (Packaging) will be critical elements to the overall success.

Leadership is intentionally not included in this part of the blog, as the attributes, requirements, and impact from lack there of will be covered in Part 3 of the blog series: Leading by Example — Transformation Leadership Requires DevOps Chops.