Public Cloud Evolution

Giving application teams access to the cloud accounts they need immediately unblocks the team, but it also puts the burden on those teams to understand and manage these complex services. The tradeoff quickly becomes unsustainable, but transitioning away from this direct-access model can be challenging. Removing access to the cloud accounts from the users before having a fully-built replacement is difficult and disruptive.

In response to mismanaged public cloud usage, some organisations switch to a ticketing approach to ensure that services are designed exactly to organisational requirements. We see this approach as shifting the pain, not solving the problem.  

Other organisations choose to equip application teams with blueprints or shared templates so that teams can continue to self-serve but with a higher likelihood that services are compliant. We also see this approach as shifting the pain, not solving the problem. 

Platform teams that want application teams to willingly switch to managed services need to offer something that keeps the benefits of public cloud (on-demand) and removes the drawbacks (high cognitive load where teams need to know too much about the infrastructure). What does this look like? An on-demand, customised, internal platform API that provides the services teams want, configured the way business requires. 

App teams can go to the platform API to get a managed, standardised service.

Building out this API should be done incrementally. Surveying application teams to discover which service is the most widely used (or which service is the most ‘mismanaged’) and releasing the API with only that service is a very productive first step. You ask teams to use the new API for one of their services, gather feedback to see how the teams are finding it, and continue learning which changes to make and what capabilities to add. As we’ve written about previously, the cost of a complete rewrite is very high, and releasing everything at once comes at the expense of valuable learning.

Kratix is a framework for building platforms and is built upon a concept called Promises. Promises are the encapsulation of a service you want to provide. You define how you want your application teams to consume Promises (API), and what should happen when they are consumed, via the execution of pipelines. Kratix makes the transition from a self-service cloud workflow to a high-level, opinionated API easy.

Eventually all services are consumed through an internal platform API