Platform Challenge 10: Not All Services are on Kubernetes
One of the challenges of running a Platform is the underlying technology which is, oftentimes, itself a platform. The choice of the underlying platform technology often dictates what sort of services can be offered in it. Platforms running on Kubernetes, for example, are often limited by what's generally available in the form of Helm charts or Operators, since writing your own Kubernetes API extensions can be costly, especially when considering the other challenges highlighted by this series of posts.
Furthermore, platforms often have to integrate with services that can't be easily migrated to run in the platform—things like legacy applications not designed for containerised environments or services provided by a third-party via a SaaS model. Integration with those systems can make-or-break platform adoption and effectiveness. Lack of integration can hinder the platform team's ability to provide a full, self-service experience for their users.
To make matters worse, some teams may have specific requirements or preferences for the technologies they use, and they may not want to migrate their services to Kubernetes. The platform needs to support these cases, so teams may continue to use the technologies they are familiar with while enjoying the other benefits of a centralised platform.
Platforms are a powerful way to unify and simplify the application development team's experience in managing and deploying their services, but without addressing the points above, it may be difficult for teams to fully adopt and utilise the platform.
Kratix allows Platform teams to extend the platform capabilities beyond the boundaries of the platform itself through Promises and Pipelines, which gives users a consistent experience regardless of where the services are running.
The Promise brings to the platform an API for accessing those off-platform resources, which allows users to request and use those resources as if they were running on the platform itself. The Pipeline codifies the steps needed to manage the lifecycle of those resources, which includes tasks such as provisioning and configuring them.
In summary, platforms can only succeed if they support the needs of both the users of the platform and of the organisation as a whole. Off-the-shelf platforms often don't integrate well with some of those needs (see "You can't buy what only you need"), and oftentimes adding changes to the platform is either impossible or too costly.
When deciding on technology, it is important to keep extensibility in mind. A great platform should not get in the way of either the team running it or the consumers using it. It should, instead, enable customisations in a way that the platform fits the users’ needs, not the other way around.
This blog is the tenth in our series, The 12 Platform Challenges of Christmas. Check back daily until January 5th, 2023 for new posts!