To begin this story, I want to say it’s amazing how complex an enterprise-grade application and the flow of data can be – even for systems that seem quite simple in nature. Expectations like security, availability, monitoring and alerting are only the basic expectations. Now, applications are expected to be deployed through automation tools on-premises or cloud or even with a hybrid footprint. And, the expectations don’t stop there. Maintenance, upgrades, and disaster recovery to the product are every bit as important. These are all things that ultimately make applications so expensive and cause real pain.
There is a silver lining to this story, however. There are some very amazing tools available that can make our lives much easier. This is where Helm steps into the picture. Helm makes it possible to create a consistent and reliable deployment process. When I first started to learn about Helm, I thought it was merely a “package manager”. I think that is an understatement.
Why Helm Charts are good for us
We are human! So, we are inconsistent and sometimes wrong. But, we are also brilliant and have moments of clarity! We can recognize our own failures and build systems to help us. A great example is setting up infrastructure and installing the software. It’s difficult to get it right 100% of the time – especially when many people or possibly multiple organizations are involved.
Now, let’s talk about the fun stuff, Helm! Helm is not just a “Package Manager.” I think it’s much more powerful. Helm allows us to create complex microservices-based applications as code. Rather than humans directly setting up infrastructure and installing applications and messing things up at the command line, we are far better off describing what we want to be done and letting an automated system do the work. A great example of this is from a hobby I enjoy building and flying drones.
If a human were to try to directly control a quadcopter without a computer, it wouldn’t even make it off the ground without crashing. When I fly my drone, I am merely telling the flight controller what direction I would like the drone to move in, and the flight controller determines how to make it happen while reacting to dynamic external input. This is why drones have become a mainstream tool/toy that anyone can fly. It does not require a highly skilled pilot to fly.
We can connect that thought to the way we deploy applications. Thru Helm, a templating engine, we document what we want to build in Helm charts. And through consistent processes that Helm components provide, the application is created in Kubernetes. Now that we have effectively moved up the evolutionary ladder a few rungs, we can make a CI/CD process into reality.
This post from David Mckenna entitled “Keep CALMS and DevOps: A is for Automation” illuminates the importance of automation. Automation is the only path forward. And really, automation is just another way of enabling code to perform a task. Now, we create APIs and bypass the GUI and just allow the machines to deploy applications and infrastructure directly.
The power of containers
Before shipping containers existed, transporting goods were expensive and very labor intensive. Not to mention, the process of packaging was complex. A visionary realized this and invented the shipping container. Consistency and standards were now possible. Individual transporters were able to align around a standard and that sparked the modern transportation industry.
Software is exactly the same. To build an application and package it to run on different systems is very complex. Then, history repeated itself. A concept of a shipping container was reinvented in the computer world. Now, an application can be built targeting a specific system and turned into an image that can run in a container on virtually any system.
Exactly like the shipping industry, the software world evolved with containers.
Deploying and running the API Gateway on Kubernetes
Beginning in version 7.6.2 of the API Gateway, EMT (Externally Managed Topology) mode was introduced. Or in simple terms…it can run in containers now! This opened a whole new world of possibilities. Now, it can run in Kubernetes. Which means we can use Helm to deploy API Gateway or even complex ecosystems that include the API Gateway, API Portal, Cassandra DB, MySQL DB and other resources. We can create a Helm chart and deploy to a Kubernetes environment on-premises or in the cloud and know it’s going to work. We can treat our deployment like code and check it into a GIT repo. We can carefully track and make changes as necessary in a controlled fashion. The API Gateway instances running are externally managed by Kubernetes. If the workload suddenly increases, Kubernetes will scale up the application and add more API Gateway instances. The API Gateway instances automatically join the API Domain without the need to manually register them. Now the API Gateway can truly auto-scale!
Conclusion
In my experience having set up many infrastructures and API Gateway/API Management environments, using Helm charts is definitely a more reliable process. A development team can do the work once and hand it off to an operations/provisioning team who in turn does not require the same level of knowledge about the application when using automated provisioning. The result is a stable process that can scale, yet easily be updated or changed. Also, Helm charts can be shared quite easily–making it easier for developers to learn and develop their own helm charts from an existing Helm chart.
Follow us on social