Improve Your DevOps Strategy Through Platform Ops

Organizations looking to scale DevOps implementations, improve their DevOps strategy, and deliver production code fast and reliably should take note of Platform Ops. Platform Ops will reshape the way we deliver value to the customer by offering an internal marketplace of self-service capabilities to many different internal business consumers.

Platform Ops is an implementation of broader DevOps strategy, philosophies, and principles. When considering success factors for Platform Ops implementations, there are three key checkpoints:

1. A shared, self-service platform should offer an array of capabilities.
2. Those capabilities will be enhanced, in context of the business, using development/engineering resources.
3. Those capabilities will then be productized and internally marketed for consumption, able to fulfill the needs of many different consumers.

What Is Platform Ops?

Platform Ops can be defined define as follows:

The assignment of development resources to enhance the capabilities of shared self-service platforms. Those capabilities are internally productized and marketed for consumption by developers and other relevant business owners.

Wondering how that works in “real life”? Let me explain

A Personal Tale of an IT Ops Practitioner

To appreciate and understand the potential value of Platform Ops in your DevOps strategy, consider this evolution from my time as a (former) ITOps practitioner.

I will never forget my first SaaS subscription. It was an email anti-spam tool named Postini. Gone were the days of having to argue with other business owners over which servers should get to consume precious power and cooling resources. Forget about going through the procurement process and waiting for that shiny new server to arrive, only to wait weeks before it was finally racked and stacked in our server room. And remember the arguing and red tape with the network team to have them open the right ports on the firewall?

Yikes! When I think back to how many servers for which we had to go through this rigmarole, I realize how amazing it was that anything got done at all!

But Postini was not really a platform. It was a spot tool.

Catchpoint: A Digital Monitoring Platform

Fast forward many subscriptions later to when I established a client-partner relationship with Catchpoint. As a digital monitoring platform offering an array of monitoring capabilities, I was happy as can be setting up my various monitoring data sources, choosing endpoints to target, and creating alerts and dashboards for myself, and others, to consume.

But I was doing all this manually in the UI.

Then one day a developer asked me if Catchpoint had an API, they wanted to incorporate some web performance testing as part of a new product they were working on. After a quick search in Catchpoint’s documentation, I sent the API documentation to the developer. This singular moment was the snowflake that turned into an avalanche. Soon, word started to spread beyond us of a new monitoring platform that developers could incorporate into their workflows. Most of the work we were doing manually became replaced by APIs. This work was then turned into an internal marketplace of capabilities consumed by an array of developers with many different contextual use cases.

Changes I witnessed:

• Web performance testing was incorporated earlier in development.
• Chaos engineering exercises became more automated, ultimately leading to business-level recognition, which drove changes to datacenter and cloud architecture.
• NOC/SOC operators developed enhanced playbook capabilities to hasten actionability (specifically triage pathing and fault isolation techniques).

And even though others have taken over the management of the Catchpoint platform (since I came to work for Catchpoint), those same capabilities are deeply embedded to this day.

How Can You Improve Your DevOps Strategy With Platform Ops?

Note that none of the benefits above would have resulted without the following discrete checkpoints:

• Catchpoint had to be a platform offering an array of capabilities.
• Those capabilities had to be enhanced (and business contextualized) using development/engineering resources.
• Those capabilities had to be productized and internally marketed for consumption, able to fulfill and meet the needs of many different use cases.

The prolific use of cloud, and other, platforms have removed so much of the operational toil spoken of above. It has never been easier to realize gained levels of efficiency resulting from cloud platform use. As I look ahead to what the next evolutionary DevOps’ implementation strategy might be, I realize it now has a name.

That name is: Platform Ops.