Managed Services in the public cloud are important information technology value accelerators and there is a significant opportunity for third parties to provide businesses with Self-Managing Services in cloud marketplaces that provide a similar value proposition. There's no denying that managed services in the public cloud provide a great value by allowing businesses to avoid a fair bit of muck and, instead, apply their efforts to areas that will make more of a difference to the bottom line.

Muck is a word which here means foundational (i.e., unavoidable) work that does not by itself produce a competitive advantage and is often distractingly demanding enough to inhibit the creation of a competitive advantage in other areas. Credit Jeff Bezos for the use of muck and coining the more popular phrase "undifferentiated heavy lifting". This is the effort it takes to achieve production readiness on foundational parts of your solution. There is a continuum of reasonable definitions for what makes a something production ready- a lot depends on the context for a particular solution and the business value it delivers. Those two things factor heavily into what architectural and operational trade-offs you can make. However, the bar continues to go up from performance, availability and, especially, security perspectives. This is why I say the work itself is foundational and unavoidable. Further, getting these right takes deep expertise and the people who can do that job well are both hard to find and expensive to keep. What opportunities are you missing because your brightest minds are working on things that are distractingly demanding?

Now, not all managed services are created equal. Certain managed services (e.g., AWS RDS) allow businesses to avoid muck while simultaneously limiting technical debt because those services use have an Open Source wire protocol and semantics. This matters because proprietary lock-in is a form of technical debt. Good companies use financial debt to create value all the time, so debt is not to be viewed entirely negatively, but you have to keep a balance sheet so that you know when you're in over your head. All forms of technical debt are withdrawals you are taking now that you will almost certainly have to pay back on a long enough time frame. It is good to consider how far in the future the bill will come due, how much it's going to cost, and whether a small change in architecture now can reduce that cost or push that date. Let's look at an example of a managed service with a proprietary semantics and wire protocol like AWS DynamoDB. If the service is a good fit for your application, what are the scenarios that would cause the debt to be due? Perhaps Amazon.com becomes a direct competitor to your business? How about service deprecation? A price hike? However likely or unlikely these may be, ask a simple question- can I reduce the risk now with a small effort? Or, if you've calculated the risk to be large or imminent, perhaps more significant mitigation needs to be done up front. And so, we finally get to the four letter word that this whole paragraph is about- risk.

Using Open Source software that is a fit for your application is a great way to reduce certain kinds of risk (however, do not forget to include your lack of a support contract for critical software on your technical debt balance sheet, assuming you don't have that contract), like the proprietary risk mentioned before or the risk of using a product with limited mindshare. Mindshare can be measured by how often 1) someone has encountered the exact same problem you have and 2) you can find their answer with a Google search. Major Open Source products have a lot of mindshare. Of course, AWS and the other major cloud providers do not offer managed services for every successful Open Source project. So, is there a market for third parties to offer a similar value proposition to cloud customers using Open Source products not offered by the cloud providers?

To answer this, we need to dig into what work disappears when we use a managed service.Here's a non-comprehensive list of categories of work reduced or removed when using a managed service:

• Understanding the myriad configuration options of a piece of software, the best practices, and how the options interact with one another
• Understanding the scaling options (horizontal? vertical?), application statefulness/statelessness, and how to architect & automate High Availability
• Performing backups, patching and upgrades
• Integration into the cloud platform (monitoring, security, compliance, networking, etc.)

The reduction or removal of work varies for each of these, but that is a whole lot of muck that disappears. If we turn this into a set of features, here's what our hypothetical Self-Managing Service should have:

• Limited configuration choices derived from best practices
• Single-click Scaling and High Availability
• Zero-touch backups, Zero-downtime patching and upgrades
• High degree of cloud platform integration

At this point you may be asking yourself, "hasn't this guy heard of Kubernetes?" Never fear, I have heard of the magical Google secret sauce with the strange acronym. However, if I'm a busness using a cloud provider, bringing Kubernetes into the picture may just move the muck to a different corner of the room. Kubernetes is just one way to deliver the features I listed above. When built as a platform for consumption aligned with the Self-Managing Service principle, it can be used to run the things my business needs to deliver value.  However, keep in mind that Kubernetes is many links down in the value chain for the value that a business is directly delivering to its customers.

Simon Wardley, a pioneer in Value Chain Mapping, has done an excellent analysis on the path technology takes as it evolves from Genesis to Custom Built to Product to Commodity. One of the ways he used to determine which phase something resides in is the way people write about it. Is it with breathless wonder? Complete disinterest? It's a good indicator. Many sources of muck are taken for granted, well understood, and yet remain the Custom Build and Product phase. There is room for Self-Managing Services to push things forwards and a business opportunity for those who can provide this value to others. I believe we'll soon see new providers popping up who will supply and support CloudFormation (or Azure Resource Manager / Google Cloud Deployment Manager) templates delivering popular Open Source solutions. The next wave of cloud adoption will see massive commoditization of solutions that, though taken for granted by the early majority, will now become much more accessible to the late majority.

Update 2023-03-23: I was mostly wrong about the technology (CloudFormation / Azure Resource Manager templates), but the Operator pattern for Kubernetes has so far proven to provide the very kinds of benefits discussed above.  Unfortunately, standardization of such lifecycle management at the CSP-native level have yet to emerge.