Member post originally published on the Buoyant blog by Tao Hansen

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: garden dev. Developers get the resources they need without request.

A gentleman in hat standing in front of pies counter

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.

  kind: RenderTemplate
template: k8s-container
name: my-service
team: bravo
inputs:
  containerPort: 8080
  servicePort: 80  

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.

Oprah Winfrey meme shouting "Everybody gets a cluster"

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! 🙌 1

— 𝚔𝚊𝚜𝚙𝚎𝚛 𝚗𝚒𝚜𝚜𝚎𝚗 (@phennex) December 13, 202

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.

Diagram flow showing the evolution of Agile organization

The evolution of an Agile organization as they move from a collection of bash scripts to a full-powered Internal Developer Platform and adopt a service mesh. Presented as a Wardley Map.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:

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 linkerd and garden.

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.

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 values.yaml, 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:

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.

Mr McMahon reaction meme showing he is semi interested with "Template Values", very interested with "Composable Infrastructure, Services and Tests", very excited and almost blow his mind on "One Tool", blew his mind on "Self-Service production Multi-Cluster"

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.