Part 2: Implementing and consuming Web Application Services on VCD
In part 1 of this blog series, we discussed the opportunity for offering developer ready services and serverless options on the VMware Cloud Provider platform, and specifically on VMware Cloud Director. The example we looked at was a serverless web application using the VMware Object Storage Extension to host static HTML content, ready-to-consume databases as a service for persistent data and Kong as an API-Gateway triggered from the web app’s JavaScript – both deployed via the Bitnami Community Catalog. And finally OpenFaaS to execute Functions-as-a-Service and made available through the VMware Cloud Director Extensibility Framework.
Throughout part 2 of this blog series, we will cover the architecture to implement. And we focus especially on the developer experience in a little bit more detail.
Object Storage-as-a-Service
As we did in part 1, let’s start with object storage. The VMware Cloud Director Object Storage Extension allows providers to offer fully S3-compatible object storage. Currently (v1.5), this supports Dell ECS and Cloudian HyperStore, either as a virtual (Cloudian only) or physical appliance in the backend. The following diagram shows the high-level architecture:
Through the Object Storage Extension, customer tenant admins can provision object storage buckets for developers. They can then directly upload the HTML, JavaScript, CSS or any other static web objects they developed as part of their application into the bucket from the VMware Cloud Director UI, by using the S3 API or any S3 compatible solution. The S3 compatibility also allows developers to automate the upload as part of their CI/CD pipeline, for example by using the Jenkins S3 publisher plugin.
S3 is RESTful and thereby inherently HTTP compatible. Therefore, the content for our serverless web app is accessible from the bucket via any HTTP web browser. For more information, also check out Tom Fojta’s blog post:
A developer would now deploy the static website content of the web application into a publicly accessible object storage bucket. This content would typically consist of at least an HTML index.html page, some CSS to make everything look nice and JavaScript for dynamic interaction with the other backend services via HTTP.
Database-as-a-Service
Next, let’s look at the most important backend system for a modern web application: the database.
To offer a ready to consume Database-as-a-Service, we will use the integration between VMware Cloud Director and the Bitnami Community Catalog items from VMware Cloud Marketplace. An easy way to do this is described in the blog post from Jörg Lew.
Providers can simply select the database flavours they would like to make consumable for their tenant developers. For example MySQL or PostgreSQL for relational databases or MongoDB, Cassandra or Redis as NoSQL and Caching Databases. It’s up to the developer based on the app requirements. Through Bitnami, providers can offer a choice of different database solutions. We will choose MongoDB for this example:
The customer tenant admin can select the required database for their developers from VCD using either vApp Templates or the new App Launchpad and have a ready to use database deployment (or really any of the many other development tools available in Bitnami) in minutes.
Instead of using vApp templates from Bitnami to provision into VMs, another option is to deploy the Bitnami apps as Helm-charts into a Kubernetes cluster based on the VCD Container Service Extension. Helm is a packaging manager for containerized applications, that makes it easy to define, install and upgrade applications on Kubernetes. And many of the Bitnami apps are available in both, VM templates as well as Helm-charts. This includes several database systems and developer tools to build serverless web apps. Providing and running serverless offerings in a container backend instead of virtual machines, can greatly improve the provider’s platform utilisation and leverage additional synergies, as we will discuss in part 3 of this blog series.
Nice, now the customers developer has a static web frontend and a database backend. But how do we get the two to talk to each other? After all, static HTML websites can’t execute database queries.
Functions-as-a-Service
This is where Functions and API Gateways come in. A Function-as-a-Service offering allows developers to simply create and upload code to a serverless platform. And that code gets executed based on a certain event – for example an HTTP request. As of writing, neither the pre-build packages from the Bitnami Catalog nor out-of-the-box VCD capabilities offer FaaS functionality. However, VCD comes with a very powerful extensibility framework. This allows providers to build their own Functions-as-a-Service offering, for example based on the OpenFaaS project. To learn more about the implementation and the specific architecture, check out this blog post.
In a nutshell, the VCD UI extensibility for FaaS described in the above blog allows developers to select a desired programming language and simply paste their developed code for the function:
For a serverless web app, the functions would include code to do all the dynamic processing that the web application requires. For example reading / writing into the previously deployed database to store and retrieve information, authenticate users or whatever else the web application needs to do. VCD uses vRealize Orchestrator to setup the function in OpenFaaS, Knative, Kubeless or any other serverless solution. These get deployed and managed in the providers backend and consumed in a serverless way. From there, functions can be executed through the respective trigger, in our example an HTTP request.
API-Gateways and more as-a-Service
The functionality to interact with the backend database can now be triggered via HTTP by using the static HTML or JavaScript website content the developer stored in the object storage bucket. To further improve the capabilities of the platform, providers can offer additional components from the Bitnami Community Catalog in VCD. One example is the open-source API-Gateway Kong that delivers a scalable, modular and fault-tolerant API layer. And this API layer can also be used to securely trigger OpenFaaS functions.
To summarise, in this second part of the blog series, we have seen how providers can leverage:
- Object Storage Extension on VCD to offer developers an object storage solution to store static web site content
- VCD Extensibility and vRealize Orchestrator to offer Functions-as-a-Service that get triggered from the static web site content and execute code
- App Launchpad and Bitnami Community Catalog to offer developers ready to use API-Gateways and Databases-as-a-Service on VCD. These services manage communication and store data for interaction from the dynamic functions.
This concludes part 2 of this blog series. We will take a deeper look into the cloud provider end-to-end business model, managed services for true serverless developer experience and some pricing and packaging considerations in the final part 3.
