Lifting your serverless app to on-premises with KEDA and K8s. Part 1.
Or how-to move Azure Functions to your client data center.
--
Why? A few years ago the main scenario was to lift application to the cloud, nowadays things changed ))). Last spring, I was asked to move an existing serverless application built around Azure Functions to on-premises for compliance purposes.
Here is the link to the follow-up article.
This publication is a part of a #AzureFamily community event, check other publications at https://azurebacktoschool.tech and follow #AzureBacktoSchool.
TL;DR; In this article, I will share steps to move a serverless application from a consumption plan to a client data center with the help of Kubernetes and KEDA for an event-driven cluster scale.
This is the first article in the series of three. The following two articles will be dedicated to the replacement of Azure Storage Queue with a Rabbit MQ broker and the replacement of Azure SQL Database with SQL Server on Linux.
Introduction
About 90% of customers are ok with Azure and the cost-effective Functions Consumption plan at the cloud, but there are others, who need mixed edge scenarios or entire infrastructure in the private data centers. And sometimes 10% of customers can generate around 30% of annual profits :).
Kubernetes(K8s) usage is unfortunately inevitable and something everyone should know around at least at the basic level. The problem with K8s is a reactive scale that doesn’t provide a good fit for event-driven apps, but Microsoft with an open source community created KEDA to solve the issue.
With KEDA K8s cluster is able to scale based on the number of events in the message broker, rather than consumed memory and CPU. While it's not really necessary in general scenarios, with Functions based on queue triggers is a recommended approach.
