Blueprints Challenges

Providing a set of approved blueprints to application teams allows them to quickly spin up resources on demand. However this approach puts a heavy burden on the applications teams:

• Operationally expensive. The teams are now responsible for operating the services they need, but did not author the blueprints that created those services. The reverse of DevOps has occurred; platform teams are developing blueprints and application teams are operating them.

• Duplication of effort. Multiple teams are deploying and managing the same stack with no easy way to introduce cost saving efforts. Each team is doing their own deployments leading to a sprawl of dated services across multiple landscapes (cloud, Kubernetes, etc)

• Unmanageable. Application teams continue to grow the number of services they have to maintain, upgrades and security patches become more costly every time a new service is introduced.

Blueprints provide a convenient way to provide a set of organisationally bespoke tools to application teams. They are often cheaper than just offering pure cloud services as they open the door for using other deployment services, like helm charts on Kubernetes. A natural progression from this approach might be moving the logic of how the blueprints are consumed to a shared repo, where application teams can contribute changes rather than keeping their own versions and potentially reduce the overheads by re-using existing automation systems. However, this iteration on the platform journey has enough drawbacks that the costs of maintaining this approach long-term is high. The platform team wants to continue to offer this opinionated tooling to the application teams, but without asking them to bear the cost of learning, running and maintaining them.