Platforms usually provide an interface (a contract) between the user and the service it is providing. It usually abstracts away lower-level details of how those services are configured and deployed, often opting for safe and sane defaults.
For example, the Platform team may choose to provide an Environment-as-a-Service abstraction in the platform. A user can request a new "Env" and get a set of services by default, like Nginx, PostgreSQL and Redis. The user may be able to configure a few aspects of the underlying services, like the DB storage size, but some other aspects may be hidden, like number of replicas or backup strategies.
For most of the consumers of the platform, those set of defaults may be just right. It allows for the teams to quickly get access to an environment and focus on the value they add to the business (i.e., the software they are building) rather than spending time configuring supporting software.
However, that set of defaults is unlikely to be a "one-size fits all". Different teams may have different requirements. Also, different teams will have different levels of expertise on the underlying services, and some teams may know more about a particular service than any other team member, including those on the Platform team.
A potential solution for this impasse is to add more and more customisation options at the higher-level abstraction, exposing the lower-level configuration options that some teams may require. While this works, it comes with the cost of increasing the complexity of the abstraction, potentially making it harder for the users that don't care much about the details.
Arguably, a better solution is to keep the high-level abstraction simple, while also providing abstractions for the lower-level services directly. In the Environment-as-a-Service example, the platform could also expose Nginx, PostgreSQL and Redis as-a-Service directly, and each singular service could have a broader set of configuration options. Specialist teams can use the lower-level components to build their own environments, and other consumers can continue to use a simpler API to request pre-configured environments.
Kratix enables Platform teams to build these high-level abstractions through Composite Promises. A Composite Promise is a Promise that contains, in its definition, other Promises. The high-level Promise delivers the high-level abstraction, but does that through the use of the sub-Promises. The sub-Promises themselves are made available as-a-Service in the platform, and they contain a wider array of configuration options for the user, if they wish to request that service directly.
Enabling teams to safely choose the level of abstraction best suitable to their needs is a fundamental part of delivering a successful platform. It stops users from reaching out to either simpler or more configurable options somewhere else, which in turn help Platform teams to build even better platforms.
This blog is the eighth in our series, The 12 Platform Challenges of Christmas. Check back daily until January 5th, 2023 for new posts!
Comments