Part 2: Implementing and consuming Web Application Services on VCD
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.
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:
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:
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.
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
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.