Why PlatformOps is the natural evolution of DevOps

DevOps is a popular software development methodology that stresses communication, collaboration, and integration between software developers and IT operations professionals. The goal of DevOps is to produce faster, more reliable software releases by shortened development cycles and more frequent communication between teams. DevOps is often seen as a response to the 'siloed' approach of traditional software development, where developers and operations teams are isolated from each other. 

As teams mature in their use of DevOps, they often find that this comes with tool sprawl, ill defined processes and a 'you build it, you run it' mentality which takes the focus away from developing and places the emphasis back on operating.

More and more functions are also 'shifting left' into the developer remit, adding to the developer burden. According to CIO Dive, more than half of executives said that shifting left has strained developers. Take for example security. If more and more security functions are added to the plates of developers that has serious implications for the security of the product being developed. In 2021, 95% of executives were confident in the security of their supply chain. This year, that has dropped to 88%.

The DevOps Institute calls this Extraneous Cognitive Load, and it leads to poorer outcomes for digital products and the people who are developing them.

So, how can teams reduce their cognitive load and focus on developing more quickly and reliably?

Enter PlatformOps.

PlatformOps is a natural evolution of DevOps. It places a greater emphasis on the use of automation and standardisation to manage the software development lifecycle and helps DevOps teams to operate at scale.

Like DevOps, the goal of PlatformOps is to improve the speed and quality of software releases. However, PlatformOps takes a more 'industrialized' approach to software development, with a focus on repeatability and consistent outcomes. 

This isn't the first time that Platforms have been offered up as a solution for developers. However, the new, redefined 'Platform' is a much leaner, more agile cousin to the bloated slow and buggy internal platforms forced onto developers in the past. And the growing popularity of the ‘platform reborn’ can be seen in the inclusion of Platform Engineering in Gartner’s Hype Cycles for Emerging Technologies and for Software Engineering for the first time this year.

Like DevOps, PlatformOps is as much a cultural practice as it is a technical one. PlatformOps teams should be an enabler, providing developers with a golden path to production. The platforms they build should balance the freedom to choose the right tools for the job with the confidence that the infrastructure and lifecycle management is well governed.

So, what is a platform?

'Platform' is, by necessity, a nebulous term, but there are some common features which touch the span of technologies used by different engineering teams within the same organisation. This includes:

• physical/virtual infrastructure
• container deployment & orchestration
• CDN
• CI/CD tooling
• monitoring.

Essentially, a platform is the baseline environment upon which a company builds, deploy, delivers and manages its services.

Perhaps the most famous example of a modern platform is Spotify's Backstage, which it developed as an internal developer portal for Spotify's engineers and has since spun out into its own stand-alone product.

As Spotify grew, the model of autonomous product teams created a more fragmented and complex tech ecosystem which inevitably slowed teams down. As a solution, Spotify built Backstage to provide an 'app-store' of developer tools for product teams to "supercharge developer productivity". What started life as a 'portal' for developers has become a more sophisticated platform which includes health monitoring, microservice templates and workflow management.

So, what does good PlatformOps look like?

PlatformOps teams should unify disparate capabilities across the 'Build, Deploy, Operate' software lifecycle. This means that they often absorb functions like Site Reliability Engineering (SRE), security and networking, whilst sitting above and guiding these disparate teams. They should also have integration into Product teams to ensure the platform continues to deliver the capabilities developer teams need to build the best products.  

Once a platform is built, it’s important that the PlatformOps team continues to iterate and update it in line with developer feedback and infrastructure strategy. It’s not about forcing engineers down a specific path, but about abstracting away tasks that take developer time away from development.

The diagram above, based on research from Gartner, shows the capabilities that should be covered by a PlatformOps team at each stage of the software lifecycle.

A platform therefore acts like a ‘common rule book’ for developers and operations to work from, but how do organisations go about building this rule book and make it easy to implement and update?

How does Environment-as-Code make PlatformOps easier at scale?

More often than not, companies want to build rather than buy their platforms. This provides the level of customisation and flexibility required, ensures that teams can integrate with the full range of tools and environments they are managing and also helps to make sure platforms take account of regional regulatory contexts too. 

However, this build process can be accelerated with ‘internal developer kits’ or ‘platform construction kits’. Many of these are geared towards cloud-native environments, and so don’t always fit the full range of needs of large, complex organisations who are running complex hybrid IT stacks.

What these teams need is Environment-as-Code.

Environment-as-Code provides a centralised way to deliver self-service capabilities to Product teams whilst providing ITSM with governance. It brings automation and agility to legacy systems, and control and governance to Developer teams working in cloud environments.

In practice, Environment-as-Code means that PlatformOps teams can establish consistent guardrails and governance for all their environments - whether they’re cloud native or not. They can use environment-as-code to codify best practices, policies, processes, runbooks and more into reusable elements. It can also help to orchestrate between multiple platforms in more complex organisations. 

With tools like Cloudsoft AMP, you can also add in automation and integrations with powerful tools like Terraform and ServiceNow and even use environment-as-code to plug the gaps in these tools. For example, you can add the drift detection capabilities that Terraform lacks or you can create certified environments in AMP and share them with your platform users via ServiceNow’s Service Catalogue.  

You can then store these blueprints and development teams can choose the ones which work for them whilst they're composing their applications.

Conclusions

• Platforms provide a common rule book for everyone to work from.
• Platforms must be light-weight, self-service and a Golden Path.
• Environment-as-Code is an innovative way to build platforms in complex environments.
• Environment-as-Code delivers 'living platforms' which mature with your PlatformOps efforts.

Resources

For more on how platforms play a key role in modernising tech architecture and service delivery, download our free infographic:

Download your copy