Serverless Functions and Vendor Lock-in: Can you avoid it?
Short answer: Yes! In this post, I will explain to you how you can avoid vendor lock-in using Azure Functions.
Before we jump into the details, let’s first define vendor lock-in and what it looks like in cloud computing. I like the definition Cloudflare has on their website. They define vendor lock-in as “a situation where the cost of switching to a different vendor is so high that the customer is essentially stuck with the original vendor.”¹ In cloud this would mean that you might want to switch from one cloud provider to another. It could mean you want to move from the cloud to on-premises. You might have various reasons to move and won’t be able to because the cost of doing so will outweigh the benefit.
So, the question stands, how can this be avoided? It can be avoided by using Azure Functions. Before we get to that, let’s briefly discuss Azure Functions.
What is Azure Functions?
Azure docs describe Azure Functions as “a serverless compute service that lets you run event-triggered code without having to explicitly provision or manage infrastructure.”² What this means is that you can run small pieces of code (called “functions”) without having to worry about any underlying infrastructure or environment setup. With Azure Functions, all the setup to get your code to run is provided by Azure and you get great local developing and debugging capabilities. However, as you may have realized, this means that you are locked-in to Azure as a vendor. But is that really the case?
Containerize Your Azure Function
One cool feature of Azure Functions is that your function can be placed into a Docker container. What this means is that you can move your function outside of Azure to another cloud or on-premises. This is possible because of the portability Docker containers offer. One problem we run into is that our Azure Function now loses it’s event driven traits because it is no longer in Azure. Is there anything we can do to fix this? One solution is discussed below.
Note: To containerize your Azure Function today, take a look at this great walk-through here.
Keep Azure Functions Event Driven in Kubernetes
So what if you wanted to keep your containerized function event driven? That is where Kubernetes Event Driven Autoscaling (KEDA) comes into play.
What is KEDA?
The secret sauce is in the name. KEDA is a Kubernetes-based Event Driven Autoscaler. What this means is that “you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.”³ This means KEDA runs on Kubernetes with no ties to the underlying operating environment, e.g. Azure, and KEDA is not specific to Azure Functions, which makes it perfect for our scenario.
KEDA works by playing out two roles. The first is KEDA acts as an agent to activate and deactivate a deployment to scale to and from zero on no events. The second is to act as a Kubernetes metrics server that exposes rich event data to the horizontal pod autoscaler to drive scale out. This diagram gives a visual representation of what KEDA does behind the scenes.
When you combine KEDA with your containerized function, you get back your event-driven traits. Because you’re using Kubernetes, it gives you the same portability as containers which means you’re not limited to a cloud vendor and have the freedom to avoid vendor lock-in.
You can find more information on KEDA at https://keda.sh/concepts/overview/
Why KEDA?
There are a few reasons why, including some we’ve already covered. For example, you would use KEDA if you wanted to⁴:
- Run functions on-premises (potentially in something like an ‘intelligent edge’ architecture)
- Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)
- Run functions outside of Azure (no vendor lock-in)
- Specific need for more control (GPU enabled compute clusters, policies, etc.)
- Keep your containerized functions event driven.
Are there alternatives?
You may be asking yourself, what if I don’t want to use KEDA? Is there something we can use as an alternative? The answer is as my other answers have been; yes! I won’t go into detail in this post but will explain - although KEDA might not be the perfect fit for you, you have to remember that your function is now containerized. Because your function is containerized, that means you can explore other Kubernetes-based event-driven architectures, such as Knative, or even other container orchestration engines other than Kubernetes that support your needs.
If you find alternatives, please share them below and help the community. Happy Coding and God Bless!
[1] What Is Vendor Lock-In? | Vendor Lock-In and Cloud Computing https://www.cloudflare.com/learning/cloud/what-is-vendor-lock-in/
[2] Azure Functions documentation https://docs.microsoft.com/en-us/azure/azure-functions/
[3] Overview. What is KEDA https://keda.sh/concepts/overview/
[4]: FAQ. Why should we use KEDA if we are already use Azure Functions in Azure? https://keda.sh/faq/
