Benefits of an internal developer platform as told by the automat
The automat of the 50s was a marvel. It was a vending machine that served hot food. It was a restaurant without waiters. It was a miracle of modern technology. For the first time, people could serve themselves without having to wait for a waiter to take their order, and without having to wait for the food to be prepared.
Like the automat, an internal developer platform removes the boundary in the experience of desire to delivery. If you, the developer, want to spin up a database, message broker, and your microservice suite, with network-level observability across any topology of cloud, hybrid and local, it's one command: <span class="p-color-bg">garden dev</span>. Developers get the resources they need without request.
An internal developer platform, or IDP, is a self-service platform that enables developers to build, test, and deploy their applications without having to wait for an operations team to provision resources for them.
Local development done without an IDP is like sourcing, prepping, and cooking your own food. It's a lot of work, and it's hard to get right.
With just two tools we'll transform the experience of development into a highly-observable, V8 fire-breathing beast that meets developers on their terms without the complexity of a rosebush of Kubernetes YAML. Impossible, you say? Not with Linkerd and Garden.
TL;DR: A service mesh for your internal developer platform (IDP)
Linkerd's support for vendor-agnostic multi-clusters enable a self-service IDP that is equal to production but feels locally as light as gossamer. Linkerd takes the pain out of observability, security, and resiliency. Garden takes the pain out of building, testing and deploying applications to Kubernetes.
- Developers are still using Docker Compose to develop microservices locally
Because Kubernetes manifests are complex litanies, around which a cottage industry of solutions have sprung up to address. But this comes with downsides. Testing services in isolation is hard. Developer laptops are inconsistent pets, not cattle. Workloads and the nodes they run on should mirror production.
The solution: give every team a cluster.
- Bring Heaven to Earth
The rise of the Platform Team has spawned nurseries of developer stacks vended to developers. These stacks are flexible abstractions that bring the power of production to developer machines without the fuss.
In Garden, this abstraction builds an image from source and deploys it to team Bravo's K8s cluster in just 5 lines! If the target cluster doesn't exist, it's created automagically. Not seen by developers is the Terraform program, Dockerfile and Kubernetes manifests that make this just work without any existing clusters or resources.
- By vending resilient platforms that teams own, developers move at the speed of thought
Teams get a homoiconic platform that they can use to build their applications, and that they can customize to their needs. With Linkerd's multi-cluster support, teams can work across multiple clusters, and even across multiple clouds and on-premises data centers as if they were a single cluster.
- Linkerd + Garden = ❤️
Where Linkerd fits into the self-service developer platform
With Kubernetes we’ve abstracted away the individual computer into herds of cattle. From the beginning of computing, we've trended toward ever-larger synecdoches that are easy to reason, deploy and maintain. One sacred cow remains, the Kubernetes cluster.
At financial services company Lunar, teams are organized into squads, “small decoupled, self-contained and autonomous teams [that] own their own destiny”. Bringing the convenience of the automat to your developers means radically rethinking the self-service model all the way down to the clusters themselves.
We can now treat our production clusters as cattle instead of pets, or maybe more accurately, herds of cattle. Big shout out to the team! 🙌
— 𝚔𝚊𝚜𝚙𝚎𝚛 𝚗𝚒𝚜𝚜𝚎𝚗 (@phennex) December 13, 2021
Now teams own their own production-like clusters, and can use them to build, test, and deploy their applications. Production-like dev environments are vital to your team's operational efficiency.
The advantages of multi-cluster for your internal developer platforms
Security, Resiliency and Reliability are the three pillars of the benefits of multi-cluster according to Alejandro Pedraza, a Linkerd Maintainer at Buoyant. We'll cover two of these and add a third freebie you get with Linkerd when operating microservices, observability.
Linkerd's implementation of multi-cluster is transparent to the service. For developers, two key benefits:
- Easy failover
If a cluster becomes sick or inaccessible, it can be deleted without harm to a developer's productivity. Services can also be tested against inclement network conditions, not possible on a dev's laptop. Your developer environment should always surface this level of reality: the rolling hills and valleys of global networks and how an application behaves when the pristine landscape mutates.
- Latency; traffic splitting and fault injection
There's been a big push to the edge with platform as a service providers like Vercel, Cloudflare, and Fly.io. With Linkerd's network-level golden metrics and traffic split features, developers can run canary releases that automatically reach users as close as you can get to them.
Observability
Installing Linkerd doesn't take more than a few minutes and some cloud providers like Civo offer Linkerd as an add-on right out of the box. Platform Teams will want to take advantage of the composable nature of infrastructure as code to vend a cluster and its microservices suite to any team with Linkerd's "golden metrics" available right away. Golden metrics are the success rate, traffic and latency of applications in your cluster.
Resiliency
Multi-cluster services are resilient to any one cluster failure. If a cluster goes down, the service is still available. Platform Teams provide a kubeconfig that spans multiple clusters so developers can rely on their testing environment as if was production. There's no special training required and no other tools to install locally other than <span class="p-color-bg">linkerd</span> and <span class="p-color-bg">garden</span>.
Security
A shared trust anchor allows for clusters to encrypt and verify identity between every cluster. For Platform Teams, cloud, hybrid and on-prem clusters can share this single source of truth.
Services can be mirrored and divvied in any Byzantine topology Platform Teams prefer. With team-owned clusters, the security boundary recedes from the important task of a developer's work.
Garden's self-service developer experience
Developer velocity
Developer velocity is the north star of Platform Teams. Developers move fastest in small, resilient, and independent teams that each tend their own garden of tools, services and clusters. By moving permissions out to the invisible, developers move at the speed of thought.
Garden helps to address cross-cutting concerns by allowing teams to create portable pipelines, which enable developers to see how the individual piece they are working on fits into the larger picture.
Lunar's squads are an ideal example of what happens when teams own their own destiny: they become creatively independent. The industry-trending pushback against microservices is really a symptom of a failure to meet teams where they desire to be, not tending to the particulars of your Garden of YAML.
Config templates
If you've gone anywhere near the Cloud Native landscape, you're well-acquainted with Helm charts. They're a good comparison to the Config Templates of an IDP because Helm charts are a templated abstraction for operating purely on Kubernetes resources.
Config Templates, like Helm Chart's <span class="p-color-bg">values.yaml</span>, expose key-value fields to your teams of developers. Unlike Helm Charts, Config Templates take advantage of Garden's broad catalog of plugins so you can vend a:
- Terraform configuration to create a cluster on any cloud.
- kubeconfig fetched from the same cluster, ready to use on a developer's laptop
- Redis Helm chart launched inside this same cluster with provisioned credentials ready to accept pub/sub messages
- team's purpose-fit suite of microservices
- tests for those services
all in dependency order, with caching across the entire SDLC.
We can go a step further and initialize and then bind the new cluster to your existing cluster topology. Your developer only needs to wait once for the cluster to create. Thereafter, network-level golden metrics, multi-cluster failover, and latency aware services are available. Squeezing that automation, breadth and depth of databases, services, and orchestration, all just like production, would be impossible on a lone developer's laptop.
Bring developer velocity and production-grade reliability to your internal developer platform
If you'd like to try it for yourself, you can get started with Garden and Linkerd in just a few minutes. Head on over to the repo to build your own cluster and microservices stack with message broker and test ready to go.
Conclusion
The problem facing most Platform Teams is just the sheer size of the CNCF landscape. The solution is not a surgeon's collection of Cronenburg implements but just a few, lightly interwoven, that offer front and back of the house an easy, total coverage solution.
Visit Garden's blog for more on improving developer velocity in your organization and slide on over to Garden's Discord to join our delightful community of Garden-folk.
