The tech ecosystem is a rapidly changing space. Companies are often grappling
with staying up-to-date with the latest technologies and supporting existing, likely legacy services. This problem gets amplified when organisations also adopt new techniques and practices for managing software. Rather than simply migrating to a new tool, the organisation is also being required to adjust the way in which it goes about providing and leveraging the tools, e.g. DevOps.
Platform Engineering as a label for a role and discipline is new but growing rapidly, for good reason. Companies have been feeling the pain caused by not providing a consistent, easy-to-use internal platform for their application teams to consume. As the problem space develops, more and more organisations are recognising the value of creating an internal platform and treating that platform as a product.
Most organisations have something vaguely resembling a platform. Often it's a rigid, bespoke system that's driven by ticket flows. How can you go from this legacy internal system to a new product-driven, self-service platform? Existing teams that focus on these kinds of platform concerns are already having to support and maintain their existing setup, which is often full of technical debt and complicated legacy systems. The idea of committing months to a rewrite is unthinkable.
The key to treating your platform as a product is...to treat it as a product. Product development today isn't about a single release after a year of work that was designed and scoped once at the beginning. Instead, product iterations are short and feedback loops are fast, with the goal being to deliver value as soon as possible directly to your users. Product teams collaborate with and learn from their users to validate ideas quickly, and product releases are much more likely to give the highest-value features to users in the order in which they need them.
This product development mindset is as helpful for building an internal platform as it is for releasing an external product. A simple way to start with product thinking on your platform is to pick a single valuable service that your application teams need and start from there. (If you don't know which service your application development teams would find most valuable, your actual first step should be to collaborate with those teams to learn). Focusing on a single service and collaborating directly with the application teams to understand why they need it and how they intend to use it will enable you to quickly deliver value to them. Once your first service is published to the new platform and you have a team consuming it, the next service you bring over will be easier because of prior knowledge and will be more likely to be adopted quickly as your consumers will have seen the benefits of this new self-service, high-velocity world.
Deciding how to go about providing the services to them in a consistent way that supports the variety of modern and legacy services within your organisation is challenging. Kratix is a framework designed to help with exactly this.
Kratix provides a consistent API for your application development teams, and it helps with heavy lifting of orchestrating your tech stack. Kratix is built upon concepts called Promises. Promises are the encapsulation of a service you want to provide. You define how you want your application teams to consume it, and what should happen when they are consumed, via the execution of pipelines. It's up to the platform team to encode into these pipelines whether it should provision some software on your legacy infrastructure, or orchestrate the creation of more modern day cloud-native applications, such as creating Redis instances on Kubernetes. Kratix provides the flexibility to integrate with your existing in-house services while also paving the way for your organisation to adopt cloud-native applications.
This blog is the second in our series, The 12 Platform Challenges of Christmas. Check back daily until January 5th, 2023 for new posts!