Not Just in the Cloud: Serverless in Your Own Data Center – Data Center Knowledge

If you follow conversations about trendy DevOps technologies, you have probably heard of serverless functions. But you may not realize that serverless functions arent just something available from public cloud providers. They can run out of on-prem or colocation data centers, using hybrid or private cloud architectures.

If you've wanted to explore serverless functions without having to depend on a public cloud provider, keep reading for an overview of how and why to deploy serverless functions in your own data center or colocation facility.

Related: Explaining Knative, the Project to Liberate Serverless from Cloud Giants

A serverless function is an application or part of an application that runs as part of serverless architecture. Developers can simply load serverless functions into a serverless hosting environment, then configure the conditions that should trigger the functions to execute.

There is no need to configure entire operating system environments or install software in the traditional sense -- hence the "serverless" label, which is somewhat of a misnomer, because the functions are still hosted on servers, even though the server environment is abstracted from end users.

Related: Cloudflare Wants to Eat AWSs Serverless Lunch

The serverless platforms that get the most attention, like Azure Functions and AWS Lambda, are public cloud services. The solutions are sometimes referred to as Functions-as-a-Service, or FaaS, because they enable users to deploy and execute serverless code using a cloud-based architecture that is similar to SaaS.

Although public cloud vendors have dominated the serverless market, there is nothing inherent in the serverless model that requires functions to be hosted in a public cloud. You can just as easily set up an environment within your own data center that allows your developers to deploy functions in a pain-free serverless way and execute them using an event-driven framework.

There are a number of reasons you may want to run serverless functions in your own data center. One is cost. Public cloud vendors charge you each time a serverless function executes, so you have a continuous ongoing expense when you use their services. If you run functions on your own hardware, most of your investment occurs upfront, when you set up the serverless environment. There is no direct cost for each function execution. Your total cost of ownership over the long term may end up being lower than it would be for an equivalent service in a public cloud.

Security is another consideration. By keeping serverless functions in your data center, you can keep all of your data and application code out of the cloud, which could help avoid certain security and compliance challenges.

Performance, too, may be better in certain situations for serverless functions that run in your own data center. For example, if the functions need to access data that is stored in your data center, running the functions in the same data center would eliminate the network bottlenecks you may face if your functions ran in the cloud but had to send or receive data from a private facility.

A final key reason to consider serverless solutions other than those available in the public cloud is that the latter services offer native support only for functions written in certain languages. Functions developed with other languages can typically be executed, but only by using wrappers, which create a performance hit. When you deploy your own serverless solution, you have a greater ability to configure how it operates and which languages it will support.

That said, the various serverless frameworks that are available for data centers have their own limitations in this respect, so you should evaluate which languages and packaging formats they support before selecting an option.

Deploying serverless functions in your own data center (or a colocation data center) is not much more complicated than running them in the public cloud. There are two main approaches to setting up a serverless architecture outside the public cloud.

The first is to run a private cloud within the data center, then deploy a serverless framework on top of it. In an OpenStack cloud, you can do this using Qinling. Kubernetes (which is not exactly a private cloud framework but is similar in that it lets you consolidate a pool of servers into a single software environment) supports Knative, Kubeless, and OpenWhisk, among other serverless frameworks.

The second approach is to use a hybrid cloud framework that allows you to run a public cloud vendor's serverless framework in your own data center. Azure Stack, Microsoft's hybrid cloud solution, supports the Azure serverless platform, and Google Anthos has a serverless integration via Cloud Run. (As for Amazons cloud, AWS Outposts, its hybrid cloud framework, does not currently offer a serverless option.)

The first approach will require more effort to set up, but it yields greater control over which serverless framework you use and how its configured. It may also better position you to achieve lower costs, because many of the serverless solutions for private clouds are open source and free to use.

On the other hand, the second approach, using a hybrid cloud solution from a public cloud vendor, will be simpler to deploy for most teams, because it does not require setting up a private cloud. It also offers the advantage of being able to deploy the same serverless functions in your data center or directly in the public cloud. A serverless function deployed via Azure Stack can be lifted and shifted with minimal effort to run on Azure Functions.

Serverless functions in the public cloud are very easy to deploy, but they do not offer the best cost, performance, or security for all types of workloads. For situations where the public cloud vendors' serverless solutions come up short, consider deploying serverless functions in your own data center or colocation facility.

Read more:

Not Just in the Cloud: Serverless in Your Own Data Center - Data Center Knowledge