Suppose that your company has a large backend application that supplies information to several frontend applications. Right now, when a developer makes changes to one of the applications, they must merge their changes to a develop branch to deploy the changes to the development environment shared by all developers. This setup is fraught with issues. A developer could deploy a change that breaks the development environment thereby getting in the way of other developers' testing until the change is fixed or removed from the branch. Developers must test their changes along with other changes at the same time so it could be hard to isolate where errors are coming from. How many issues can you think of when testing a set of apps in limited environments like only development, staging, and prod?
By creating a short-lived ephemeral environment based on a developer's feature branch, changes can be isolated for better testing. That's where an internal developer platform (IDP) comes in. What is an IDP?
An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service. An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies. Following best practices, platform teams treat their platform as a product and build it based on user research, maintaining and continuously improving it. Source
An IDP makes it easy for a developer to perform some task that combines actions that interact with various systems. In our case, I will walk you through an IDP design that enables easy creation of ephemeral environments.
So, let's go back to the setup I presented in the beginning. Your company has a large backend application that supplies information to several frontend applications. Users interact with the frontends through their browsers:
We could design a system, we'll call it starry, that creates ephemeral environments such that for an environment called test-00 for example a developer can access the apps at test-00.{app-name}.starry.mycompany.com. The test-00 environment could be testing code changes made to the sample-be repo under the feat/myfeature-00 branch. To see how those changes affect the frontends, instances of the frontends are also spun up.
Tooling and Artifacts
Kubernetes
Kubernetes makes spinning up applications and managing resources simpler and there is a rich ecosystem of tools and resources. Let's use Kubernetes to manage our system. Suppose we are running on GCP, our GKE cluster will interact with Artifact Registry for backend and frontend container images and Secret Manager for secrets used by starry.
- This has been simplified for the sake of this article. For example, VPCs and networking are not included here.
Helm
To encapsulate application definitions, we will use Helm charts.
1) For environments, we can create a custom Helm chart that manages backend and frontend deployments, ingress, databases, and cache. The Helm chart will also manage the services needed for the frontend apps to connect to the backend as well as secrets and service accounts. The chart creates a unique namespace for each environment. The environment Helm chart defines a single instance of an environment.
Any environment, whether that be development, staging, production, or an ephemeral one, has two frontend apps, one backend app, two database instances and one cache instance.
2) We will also need a Helm chart for our starry application which will provide a frontend for our users to create environments, view details, and delete environments after testing.
ArgoCD
The starry application as well as the environment applications have Kubernetes resources that have to be managed. When you merge changes to starry's main branch, you want the changes to be reflected in production. When you delete an ephemeral environment all associated resources like config maps need to be deleted, not just deployments, and we want to easily track the status of individual resources. Even for platform developers, we want an interface to our applications that is easy to understand complete with details about individual resource status. We may want to expose some of these details through a custom, well thought out UI to developers as well for their own troubleshooting. A system like ArgoCD makes all of this easier.
Terraform
Finally, all of this infrastructure needs to be bootstrapped and we can use Infrastructure-as-Code (IaC) tool Terraform for that.
Artifacts
We will end up with backend, frontend, Helm chart, ArgoCD, and Terraform repositories in GitHub which will define our system:
There will be 4 container image repositories: 1) sample-be 2) sample-fe-1 3) sample-fe-2 4) starry
There we have our tools and artifacts.
After choosing tools based on our needs, we are ready to think through more specific patterns that we will use, more granular interactions between services, as well as the repository structures that will shape our implementation. Stay tuned.
Top comments (0)