The most mature organisations in their devops journeys rely on self-service internal platforms, automated change management processes, and integrated security, according to the 2020 State of Devops report by Puppet and CircleCI.

The report surveyed more than 35,000 technical professionals around the world about their continued adoption of devops and agile practices, with three key themes emerging from the most mature, high-performing organizations: leveraging internal platforms, establishing effective change management processes, and tightly integrating security. Let’s tackle them one by one.

Build internal platforms
Internal platforms emerge when organisations have strong, product-focused teams, each responsible for the end-to-end delivery of a product or service.

This internal platform tends to be a homegrown one-stop-shop for self-service provisioning of infrastructure, test environments, deployment pipelines, APIs, tools, knowledge, governance, and support. The team responsible for that internal platform will typically gather business requirements, provide a product roadmap, and help onboard new users.

The internal platform enables application development teams to build, deploy, and run their applications in a standardised way and differs from generic platforms-as-a-service as sold by providers like AWS, Azure, Google Cloud Platform, IBM/Red Hat, or VMware.

As with any grand idea, this can often fall flat on its face when applied to a highly complex enterprise, with hundreds of products or services and various teams serving each one with their own unique processes and tech stack.

“One reason devops often fails to expand further is that most enterprises are structured in ways that create misaligned incentives and lack of accountability or ownership over the outcomes they’re supposed to be driving,” the report authors write.

Enterprise DevOps challenges
That lack of standardisation leads to a common set of enterprise devops challenges. The report identifies three:

Governance becomes expensive, and nearly impossible to manage
Separate stacks reduce knowledge sharing across the organization
Many of your product teams don’t actually have the skills or expertise to operate a full infrastructure and application stack
Organisations that are able to build a platform, with the developer experience in mind, can start to standardise DevOps practices and reduce toil and overhead across the board. This platform should allow for self-service provisioning, configuration, and management, so that each team can focus on its product without having to wait for a centralised team to provision infrastructure for them.

“Focus on developer experience and flow. We can’t stress enough that empathy is a critical skill set. Empathy means understanding someone’s position, and it’s impossible to build a good product without having empathy for your user,” the report warns.

Building an internal platform is an approach that is increasingly popular among respondents to the State of DevOps survey, with 63% saying they have at least one self-service internal platform. Of those who had internal platforms, 60% had between two and four and almost a third of those with internal platforms had 26% to 50% of their developers using at least one internal platform.

The reason for platform proliferation is that the most successful devops practitioners start small, by building platforms for a specific team or for a certain type of infrastructure – like public cloud – and scaling up from there. This approach is better than trying to build one platform to rule them all based on a set of broad assumptions about what your teams need. A ‘build it and they will come’ approach here is destined to fail.

More importantly, the most highly evolved firms, as defined by the report authors, were almost twice as likely as mid-level organisations to report high usage of internal platforms, and six times more likely to report high usage than low-level organisations.

Standardise change management
For those organisations still working their way up towards an internal platform, effective change management is the best on-ramp.

The macro shift from waterfall projects and big software releases to microservices and faster, more regular deployment cycles has enabled devops to flourish, and requires teams to fully embrace constant change. Making that change management process consistent is one of the hardest parts of enterprise-scale DevOps. It’s also a key differentiator for anyone looking to release more software more often.

Survey respondents cited incomplete test coverage as the biggest barrier to effective change management, followed by established organisational mindsets and tightly coupled application architectures.

Only by breaking down silos between change management, release management, and audit and compliance teams, by creating effective feedback loops, and by tracking progress are organizations able to mature their change management processes.

Change management success can be measured by tracking key metrics such as change failure rate and deployment frequency, the level of efficiency around approvals, and the level of acceptable risk to the business.

According to the report, the most effective change management processes come when teams employ:

A high degree of testing and deployment automation
A high degree of automated risk mitigation
Less rigid and much less manual approval processes
Writing changes in code
Allowing employees more scope to influence change management
Devops processes and culture
In short, increased automation breeds confidence in change management. The report found that firms with highly orthodox approvals are nine times more likely to see high levels of inefficiency in their change management process than those with low levels of orthodox approvals.

The spectrum of automated change management starts with secondary review – ie, no automation – all the way to the holy grail of fully automated deployment and testing, with built-in risk assessment and immediate progression capabilities.

Focus on security integration
Lastly, the report focused on security integration. “We found that firms that have achieved higher levels of security integration are much more likely to be at a high stage of devops evolution,” the report concluded.

By security integration the report specifically calls for “a completely different approach, one that emphasises cross-team collaboration and empowers delivery teams to autonomously prevent, discover, and remediate security issues. Breaking down knowledge silos between teams, and collaborating to improve security both raise overall awareness of security concerns, making it more likely that everyone – even those outside the security team – will adopt known patterns for security protection.”

The report showed a strong correlation between the ability to integrate security fully into the software delivery process and an organisation’s ability to remediate critical vulnerabilities quickly.

Specifically, 45% of companies with full security integration reported being able to remediate critical vulnerabilities within a day, while just 25% percent of companies with low security integration could do the same.

IBM has recently announced the beta availability of a new serverless compute service called IBM Cloud Code Engine. The service is a managed serverless platform that runs containerized workloads, for example web apps, micro-services, event-driven functions and batch jobs.

A follow up article describes the use cases and the open source technologies used to build Code Engine, including Knative, the Kubernetes-based platform to deploy and manage serverless workloads, the service mesh Istio, and Tekton, the framework for creating continuous integration and delivery (CI/CD) systems. Cong Nguyen, developer advocate at IBM, tweets:

IBM emphasises the open source layers and the portability of the platform, explaining that while it offers a simplified user experience, developers can still fully customize the Kubernetes data model or reuse existing deployment scripts on Code Engine.

Depending on the load, Code Engine automatically scales the containers, including scaling to zero when no requests are active. A container image is not a prerequisite to use the service: Code Engine can bundle the source-code from a Git repository with a supported runtime environment, what IBM calls a “buildpack”, and generate the container. A guide on how to do it is available in the IBM Cloud Design Engineer Gitbook.

The About IBM Cloud Code Engine covers the main concepts, names and terminology used on the platform. The first tutorial provided by IBM shows how to build a visual recognition platform, using Code Engine and the Cloud CLI.

Harald Uebele, developer advocate at IBM Germany, wrote a detailed article on in his personal blog on how to run containers serverless on Code Engine, highlighting the use cases where the new platform should excel:

While Christophe Boulangé, Cloud Director at BNP Paribas, labels it the “FaaS next-generation” other developers question the advantages against other existing offers: “What is the strongest part of this solution against AWS lambda, or Cloud Functions from GCP?”