Developer Services & Developer Platforms. A distinction without difference?
Last week, I attended KCD Munich, a fantastic community conference that provided attendees with space to come up with their own discussion topics. I suggested a conversation around Platform Engineering, undoubtedly one of the hottest topics in DevOps at the moment. While one participant explained their setup, they used the words services and platform interchangeably, which prompted this question for me:
What exactly is the difference between services and a platform?
In everyday speech, we often say service to mean a piece of software that will return something on request. To that end, platforms may consist of many services or be considered a service of services. However, this belays some differences that are important to understand when you want to advocate for and educate on your platform.
Developers are clients to services, but contributors to platforms.
In a service-based model, service providers see developers as clients. They may decide to engage in user-research, but ultimately the service team is considered the domain expert and owner of their respective services. Collaboration between developers and service teams usually happens — if at all — through support issues.
Whereas in a platform-based approach, developers are considered both users and contributors. They are educated on the inner workings of the platform and can submit their own suggestions on how to change or improve a certain service. By being deeply involved in the conception and building of the platform, developers gain a sense of ownership and are more likely to actively use and engage with it.
Services are loosely coupled, if at all.
The idea behind services is that they are single-purpose. They exist completely independent of other services and often do not know about the overall architecture they are embedded in. Unlike platforms, services don’t share the same patterns, practices, or target audiences. They are typically being maintained by separate teams, divided by domain boundaries (e.g. testing & security). Though not a requirement, they tend to be less opinionated.
Taking software delivery as an example, a developer may need a service to build a container image and another to push it onto a production environment.
With services, developers stay in full control of how-and-when to use them. They may even choose not to use a service to build the image, but do it on their local machine instead, which could lead to discrepancy issues. Since the services operate completely independent of each other, they could also differ in formats, leaving the developer to deal with inconsistencies.
Platforms optimise for the golden path
They are conceived to be one fully integrated, albeit modular and composable product. Meaning, a developer may use all or just some services provided by the platform. And while there may be configuration parameters, the how-and-when is still strictly controlled by the platform itself. More than a group of services, a platform serves as a way to enforce governance and best practices, which is especially important when it comes to auditing security. To protect the integrity of deployment artefacts, developers may have no or only limited access to the results of intermediate steps within the delivery process. They could still have access to all necessary information and metadata necessary to debug an issue without ever touching the actual container image.
Services are an evolutionary step towards platforms
In some ways, services can be considered an intermediary step on the way to a fully-fledged developer platform, similar to how Docker was to Kubernetes.
Much of what the new discipline of platform engineering aims to do, is to tie existing services together into a platform, presenting developers with a single point of entry and unified experience. Ultimately, the goal is to reduce cognitive load for the developer so they can focus on application development.
As holds true for most architectural decisions, just because Platform Engineering is currently discussed a lot, it does not mean that is the best solution for your organisation. Important aspects to consider could be the size and maturity of your development organisation and the capabilities of your infrastructure team. But more on that in a future blogpost.
Further reading:
