This blog is the second in our series on platform engineering. In this edition, I am excited to talk about an internal project that we have been working on under the wraps at Devoteam NL for a few months now.
About Project Unox
In the fall of 2022, I sat down with a few of my colleagues to kickstart a new internal project. The idea was to create a blueprint of an internal platform that could serve as a north star for platform implementations across the organization and for our customers. We needed to practice before we preached. The project is code-named “Unox” (famous brand of sausage soup) and metaphorically could denote what it felt like at the time; a hearty soup of ideas and technologies.
Our vision statement is to create a solution showcase of a full self-service platform for developers to build and deploy cloud-native applications securely using best-of-breed techniques.
But why (should enterprises) build a platform?
Or the better question would perhaps be: why treat the platform as a product? Chances are there is already existing infrastructure and many tools that constitute ‘a platform’ at the organization. This topic has been explored in greater detail in my previous blog post about Internal Developer Platforms and Golden Paths, a recommended read. In essence, it comes down to whether you answer yes to either of two things.
- Speed
Do you want to enable the developer, make things easy for them, and improve productivity? Do you want to accelerate product development by offloading responsibility for common services, with the use of Golden Paths? - Standardization
Do you have a plethora of tools and services in your organization that are maintained by multiple teams, which sometimes resemble a maze? Do you want a single, consistent experience that streamlines all of your IT environment?
The platform building blocks
Platforms can mean different things depending on context. A developer platform offers capabilities for supporting application development. Some of the building blocks required for cloud-native application development are: elastic compute environments, pipeline runners, data and storage, messaging queues, identity management, security and observability. Each of these building blocks could be provided by the platform itself, or by a different team or service provider. We researched on what is emerging as an industry standard, and the work being done by the CNCF Platforms working group served as a great starting point.
Every block in our Building blocks architecture is an essential capability provider for the platform. The platform also enables use of these capabilities through platform interfaces that provide a portal, documentation, and APIs to these platform services. In the diagram above, you can see a mapping of each building block with one or more technologies from the cloud-native toolset. This forms our opinionated, yet modular, building blocks architecture for the platform we are building. Designing the platform in this way makes it very pluggable and resilient to changing organizational needs down the lane.
Tabulated below is a listing of our chosen technologies, mapped against given capability. These are in different stages of implementation and subject to change as the platform evolves. We will explore a few of the important pieces of this landscape in subsequent blog posts.
| Capability | Description | Technology |
|---|---|---|
| Documentation and developer portal | Documentation and code templates. All the self-service experiences and capabilities provided by the platform. | Github, Backstage |
| Compute, network and storage | Run application code, connect application components and persist application data. | Azure Kubernetes Services, Azure Cloud DNS, Azure Storage |
| Source code and artifacts | Store source code and publish and secure built artifacts. | GitHub, Helm, Terraform, Devcontainers, Ghcr docker registry |
| Pipelines and reconcilers | Automate delivery of services and applications with features like canary, blue/green, and feature flags. | ArgoCD, Github actions |
| Observability | Enabled emission of metrics that can be gathered and analyzed by product stakeholders. | OpenTelemetry, Elastic, Fluentd, Grafana |
| Identity and access | Enable users (and services) to identify themselves securely to platform services. | Github Oauth, Cert-manager, Keycloak |
| Secrets | Ensure workloads have the locators and secrets to access and use provisioned resources and services | Vault |
| Policy and scanning | Observe runtime behavior and report, remediate or constrain activities on anomalies. Verify that builds and artifacts don’t contain vulnerabilities. | Open policy agent, Kubescape |
How do we implement a platform the right way?
We adopted some principles for a well-architected platform, which will be listed below. These are essential to build a platform the right way.
Everything in Git
Everything is defined in code and checked into Git (Github in our case). This is the first thing on this list, because if we are not starting at Git, we are starting wrong.
Customer-driven development
We adopted a problem-driven approach, rather than feature-driven. Everything that was built was to solve a problem or achieve something. In an actual implementation, this would mean a lot of talking to the customer or the end-users of the platform, at every step. We are building towards a perpetually moving minimal viable solution, just solving the problems then at hand.
Keep things simple
The cloud-native toolset is plentiful and there is a definite tendency to get carried away. Consciously sticking to building what is just enough, watching for scope creep and working towards waypoints on the roadmap will keep unnecessary complexity in check.
Inner source model
This was an experiment, but in hindsight feels quite essential for platform building. As mentioned before, all our source code is in Github (organization private for now). Inner sourcing allows us to connect directly with end users who could be potential contributors. This means we will be solving the right problems. Inner sourcing also forces us to think very critically about what to document (and what not to) and write readable code.
What’s next?
Project Unox was created to serve as a blueprint. We intend to feature freeze and open source the project, but documentation and readability is going to be a focus in the coming period. It is already serving as a baseline for several of our customers who are on different stages of platform implementation. We will be sharing more details in upcoming blogs, including technical challenges and lessons learnt.
