TL;DR
- Kubernetes needs an application-level API.
- GitOps, new IaC tools, and more are great, but without that application-level API, your challenges will keep growing.
- You unlock many benefits by detaching the application from the infrastructure and making the underlying infrastructure and components an implementation detail.
The API Economy
I guess at this point, you have heard of a company called Amazon and its business unit called Amazon Web Services, or AWS.
Although you can read different stories about its beginning, one common thread across all of them is that it started with the need to scale quickly while enabling developers to deploy their services rapidly.
According to Andy Jassy himself: “We expected all the teams internally from that point on to build in a decoupled, API-access fashion, and all of the internal teams inside of Amazon were expected to be able to consume their internal services in that way.”
APIs are a common way for developers to communicate with services without worrying about the complexity of infrastructure choices made by the service provider or the operations team. That was one of the key reasons AWS became what it is today and one of the main reasons many organizations globally adopted AWS and cloud computing in general.
Do you remember when developers required VMs for development, and we, System Admins (before the fancy new titles we see today), had to create storage disks, use Virt to create the VM, mount ISO images, and more? That was all gone and replaced by a simple API as we started moving to the cloud.
All we had to do was call an API, passing a few arguments to inform the API on the specification of the VM (or service) we wanted, and that’s it. We don’t really care what hypervisor AWS uses, storage vendor, load balancer, routers, etc. Those became implementation details hidden behind a structured API.
If AWS (or your cloud provider) changed networking vendors, load balancers, hypervisors, or others, it does not impact you. You now become a service provider to your internal customers, allowing developers to deploy their applications quickly.
Enter Infrastructure as Code
Calling an API and having the underlying infrastructure components choice hidden was great. You now have to scale across different services and cloud providers and store the desired infrastructure definition in a source code repository to have a repeatable and scalable model.
That’s when we saw tools such as CloudFormation, Terraform, and other Infrastructure as Code (IaC) tools take off.
Using different providers allowed you to use the same (or very similar) infrastructure definition to deploy your services across multiple infrastructures. This brought many benefits, ones such as:
- You can now define infrastructure in a human-readable way and store them in Git.
- A repeatable and scalable infrastructure model by leveraging those definitions and a pipeline.
- You can track the state and changes in your infrastructure.
When Fast was Not Fast Enough
Cloud-native architecture and technologies have been front and center as part of the strategy to enable developers to deploy fast, often, and to troubleshoot their applications issues quickly.
Technologies such as containers, Kubernetes, and more took the main stage. While it allowed DevOps and Platform teams to have incredible flexibility when building their infrastructure, it also brought back challenges around how much infrastructure is exposed to developers.
If you look at the deployment API that is exposed by Kubernetes today, you will find something similar to this:
Confusing, right? And that’s just the API for the deployment object!
Now, when defining the desired state of your applications, you are no longer focusing on the application itself but many of the infrastructure components required to run your application.
I’ve seen the model above bring a few challenges:
- Developers can’t define their apps and now rely on DevOps teams to keep creating and maintaining Helm Charts and Terraform templates for each new service, team, application, and so on.
- The amount of repetitive YAML the DevOps team has to maintain is unimaginable, and this will keep growing.
- As you adopt different delivery strategies or IaC tools for your various projects, such as GitOps, you must create and maintain even more templates.
- Moving cluster API versions can easily break a lot of your templates.
- Changing ingress controllers or infrastructure components of your Kubernetes cluster can also break many of your definitions.
- If you are part of a medium to large organization, most likely you will have multiple pipelines, and how each deploys to Kubernetes might be different.
- Even though you might think developers HAVE to learn Kubernetes, the value they deliver is the application, not infrastructure. Most of them have no idea how to troubleshoot their applications on Kubernetes, and an application outage will fall under your responsibility.
- Application security policy is very infrastructure-focused, and scaling it is complex.
While the benefits are many, the challenges are also many, and they will scale together as you onboard more applications and developers.
An Application-Level API
A standard application API can enable faster delivery, security, and management of applications, making the underlying infrastructure choices implementation details (Kubernetes cluster version, provider, ingress controller, etc.)
GitOps is interesting, the new IaC tools are great, but I believe that while we don’t fix the problem above, we are just repeating and increasing the challenges above.
That’s the reason why we focus on building a Cloud-Native Application API layer here at Shipa. We want you to have the same experience you had when consuming cloud APIs but on cloud-native infrastructure, doing what Terraform did for infrastructure but for applications.
By connecting a standard application API to your Kubernetes clusters, you:
- Drastically reduce complexity and standardizes your pipelines
- Detaches the application from the underlying infrastructure, so you are free to experiment with different IaC tools, pipelines, cluster versions, providers, and more. All without impacting how applications are deployed, managed and secured.
- Enable developer self-service and reduce the dependency on the DevOps team to onboard services and support applications.
- Drastically reduce the repetitive YAML definitions you have to create and maintain.
- Changes in the underlying infrastructure
We have divided this application API into two primary purposes:
1 – Application definition
The goal is to enable you to deliver pipeline simplification and for developers to onboard their applications, adopt different pipelines, and more.
2 – Application policy definition
Point 2 focuses on enabling application-level policy and security, where you can define policies across networking, RBAC, resource limits, auto-scale, and more without worrying about the underlying cluster infrastructure.
Where Does Shipa Fit In?
You can connect Shipa’s application API layer to specific namespaces in your cluster. Because if it does not “take over” your cluster, you can still run your existing pipelines and definitions using different namespaces.
Shipa will connect to specific namespaces in your clusters to bring that application-level API when deploying applications and enforcing policies.
To fit into your existing workflow and infrastructure, Shipa has also connected both the application and policy definitions to all major IaC tools and pipelines, including Terraform, Pulumi, GitHub Actions, GitLab, and others.
Conclusion
We are just at the beginning of our journey. We want to deliver an application vision to help you overcome the challenges above.
You can get started with Shipa free of cost by visiting https://apps.shipa.cloud.
You can also visit our open source project Ketch, where you can learn more about how we implement the application definition inside Shipa here: https://github.com/theketchio/ketch
Finally, you can see here how a standard application API can enable you to experiment with different IaC tools without impacting the developer experience: https://shipa.io/development/from-terraform-to-gitops-to-pulumi/
