I wrote a little while ago about running a serverless platform on-premises. I have since realized that there are a few more things that we need before such a platform is useful. Serverless is just a way of doing application code execution. Most applications need more than execution. At minimum, they need some sort of storage and some trigger mechanisms to tie together the execution. A serverless platform by itself will not solve many problems. To enable your developers to use on-premises serverless, you need a few other on-premises services. Applications that use serverless also need storage and web services that integrate with the serverless platform.
Applications are more than just a collection of serverless functions. The user interface for a serverless application is likely to be a web page—a web page that is generated by a serverless function. There does need to be a URL for the web application, and this needs to trigger the front-end function. This is what basic serverless platforms provide: the ability to run a function when a URL is accessed. The function returns the resulting web page as HTML code that is rendered by the user’s web browser. These applications may integrate with static web pages and media files served by a normal web server. The serverless platform does require a web server or gateway that will trigger the function in response to the web browser. On AWS, this is the role of the API Gateway service. This web interface is very latency sensitive. Users expect web pages to be very responsive, so the function needs to be launched as fast as possible. This entry point is also going to be used for all end user access, so it needs to be highly available. Most likely, there will be a load balancer in front of a set of gateway instances.
A serverless platform is no place to store application data: it is purely for execution. Data needs to be held somewhere else. Some data needs a database platform, so a serverless platform will probably need a database as a service to enable developers. On AWS, this can be the Relational Database Service (RDS), Aurora, or one of the NoSQL databases like DynamoDB. On-premises, you might have a Microsoft SQL or MySQL platform available for relational workloads. You might have MongoDB or Cassandra for NoSQL uses. You may also have a caching tool like Redis or memcached in front of the databases to speed up access. The important part will be having these databases link back to your serverless platform. Developers will need to have serverless functions execute when databases are updated. Not all data will suit being stored in a database; file or object storage will need to be available and integrated into serverless platforms. Functions will need to be triggered when files or objects are created, removed, or updated. AWS has its Simple Notification Service (SNS), which fulfills this function. The notification tool for on-premises needs to support multiple data storage types, probably using a plugin architecture. Each storage type has its own plugin to trigger off its own data. A good notification system should include plugins for object storage like S3 or Swift as well as a few mainstream databases. These notifications must be highly parallel to ensure that lots of functions can be launched at once. Luckily, the notifications should be a little less latency sensitive than the web interface. Storage notifications might take hundreds of milliseconds to trigger functions, rather than tens of milliseconds for the web interface. These data services will need to be highly available; data replication and failover configurations should be considered.
To get the agility and developer productivity that serverless and microservices offer, you must empower the developers. These services need to be available to developers without needing to contact IT. Ideally, the services would be available programmatically, allowing the automation of the deployment process. Your developers should use a series of API calls or command lines to create the collection of services they require, just as they can on AWS. There should be no help-desk tickets and no requirement to click around a provisioning portal. The services to build an application should be deployed programmatically by your developers.
A serverless, or Functions as a Service, platform is not enough to run any real application. A suite of services will be needed to build an application with serverless. Probably, there will still be parts of the application that are run in VMs. Replicating many of the AWS services is one way to enable your developers to be productive and agile without needing the public cloud. The collection of services is really what private cloud is all about.