FORMCEPT Goes ‘Serverless’
Adopts Sparkling Architecture Pattern
Published in January this year, my book on building Microservices with Clojure addresses the key pillars of building Microservices-based architecture using Clojure language and Pedestal framework. In particular, it focuses on architecture based on Monolithic and Microservices and then stipulated when to use what. Very recently, MECBOT, a unified data analysis platform and the flagship product of FORMCEPT, has been migrated from pure Monolithic JVM based stack to Microservices based architecture at its core, orchestrated seamlessly by Kubernetes. It has also been equipped with Weave Scope to monitor the deployed Docker Containers. This is illustrated in the snapshot below:
While Microservices work well for most of our regular functionalities, our newly introduced cloud APIs constitute an excellent use-case for Serverless Architecture. These APIs were introduced in the wake of the launch of MECBOT Blueprint Workflow Engine and Annotation Engine, and their architecture shed interesting spotlight on deploying data processing and analysis workflow using functions-as-a-service.
Rising Popularity of Serverless Architecture
Serverless architecture kickstarted in November 2014 with the launch of AWS Lambda. Since then, it has been a hot trend alongside Microservices. More recently, Serverless Architecture has gained popularity due to the benefits it brings in terms of optimizing both development effort and deployment, culminating into high cost-effectiveness brought about by efficient resource utilization. This is especially true for public cloud, like the AWS.
Sparkling Architecture Pattern
It is worth mentioning at this juncture that Serverless architecture is not here to displace Microservices. Rather, the two are complementary. A typical architecture consisting of back-end services, context driven Microservices and Serverless functions resembles a glass full of sparkling water — hence, the name Sparkling Pattern.
In Sparkling Pattern architecture, water depicts the back-end services consisting of databases, message queues, etc. and the long lasting bubbles comprise the context driven Microservices. The final component consists of the sparkles that rise through the water and last for a very short duration. These can be compared with functions that are deployed as a service and are triggered on-demand to perform their designated task. These functions, in turn, rely on the underlying Serverless platform to receive the request and return the response.
When to Use What
There is a fine-line between packaging your business logic as a Microservice versus deploying it as a Function. A typical Microservice must comply to the rules of bounded context and separation-of-concerns without fail. It may contain state and also rely on persistent store for storage and retrieval of application data. Implementation that can be packaged as a self-contained function relying on one or more external services but inherently stateless, are the prime candidates for being deployed using Serverless platforms. There should be a negligible initialization overhead for such functions and ideally they should neither directly interact with persistent stores nor hold connections to external databases.
At FORMCEPT, one of the scenarios in which we considered Serverless platform and specifically function-as-a-service architecture that worked well for us, was our interface to MECBOT Annotation Engine. We could have deployed our entire Annotation Engine as a function but that would have been a disaster w.r.t. resource utilization and initialization overhead, thus offsetting the gains of function-as-a-service architecture.
Our NLP based Annotation Engine relies on one or more trained models that may often run into GBs (for example GloVe). In serverless mode, with each request, the function needs to be initialized (cold start). If the function uses models similar to that of GloVe, it will have to load it in the memory before querying it which may take upto a minute. These models must be loaded into the memory to start serving the requests. If a function that loads such models on demand is packaged for a Serverless environment as a service and deployed in a cold start mode, the initialization time will be much more than the actual request processing time. This is not the case with functions that are extremely light-weight — like sparkles — with blazing-fast startup time.
Game of (Serverless) Thrones
Serverless Architecture is witnessing a high adoption rate due to the availability of robust platform services offered by leading cloud vendors- AWS Lambda, Google Cloud (esp. Cloud Function) and Azure Cloud (esp. Azure Functions) that allow developers to focus only on the core business logic. This logic is then implemented as a function, often triggered by an event that has a shorter lifetime. On the other side of the spectrum are leading open source efforts, like- Open FaaS, Fn Project and Apache OpenWhisk that are best suited for on-premise deployments.
At FORMCEPT, we have an experimental implementation of function-as-as-service in place for our MECBOT platform that is based on Fn Project and specifically uses Clojure functions-as-a-service that runs on Fn Server.
Sounds Interesting? — Request a demo. Want to work with us? — Please apply.
