{{announcement.body}}
{{announcement.title}}

Make Your Existing Solution Tastier with Serverless Salt: NoOps

DZone 's Guide to

Make Your Existing Solution Tastier with Serverless Salt: NoOps

NoOps makes it quicker and easier to automate in a serverless environment in which not automating is not an option.

· Cloud Zone ·
Free Resource

This article is the fourth in a series on serverless computing. I recommend starting at the beginning of the series, as I introduce concepts incrementally. The links to previous articles on DZone are included here:

In the previous articles, I demonstrated the benefits and challenges of serverless integration for business applications and illustrated them with an example based on the Bonita platform. As you know by now if you have been reading along, the main benefit of serverless is to abstract infrastructure with ephemeral containers using a FaaS service on the cloud.

3_faas

For a distributed application that needs to scale, the challenge of automating its operations has to be overcome. Most applications based on microservices manage this using technologies such as Kubernetes. But what could be considered as a “good-to-have” in the case of a microservices-based application is “mandatory” in the case of a serverless-based application. The unit of scale is basically ten, sometimes several hundred, times more granular. In this article, I’ll demonstrate how I automate the administration of the serverless function used in the business application example — objective NoOps!

As in the previous articles, you can follow along in detail with the development resources I share as a single archive file named “level3-1.0.zip” in the release “level3-1.0” of a dedicated GitHub project. The “Serverless_Level3-1.0.bos” BOS file can be imported in any 7.7.4 or higher version of the Bonita Studio.

Architecture

Like many platforms, the main component of the Bonita architecture is its engine. It handles the execution of the business application processes and is composed of many APIs and services.

3_bonita_services

A useful thing about Bonita is its extensibility when it comes to these APIs and services. Similar to the Spring framework, it uses the powerful concept of the Inversion of Control (IoC). This is what I use to extend the default behavior of the platform.

Service

In short, I want the platform to deploy or delete the serverless functions associated with the connectors used in the process definitions of the application at deployment/undeployment time.

3_bonita_service_extension

We’ve already used the Process Execution service to handle the serverless function invocations via connector executions in the application processes (see previous articles). What we are missing here is an extension of the Business Archive service to automatically create/delete functions.

Implementation

I cloned the GitHub repository related to the platform engine and imported it into a workspace of Eclipse IDE. It is pretty simple to do because these are mavenized Java projects.

Then I created new projects with Bonita and AWS dependencies.

3_maven_project


I created a new class that extends the default service implementation used by the platform BusinessArchiveServiceImpl. I also added a method here to extract the information from the process definition design that is necessary to complete the automatic operations at deployment/deletion time.

3_abstract_extract_code


I extended the two default methods used at deployment and deletion time to automatically create and delete the serverless functions associated with the process design.

3_abstract_deploy_code

3_abstract_delete_code


You may have noticed that there are abstract methods. I used this to separate what is generic and what is specific to serverless providers. I extended these abstract methods for AWS Lambda as this is what I used in the example.

3_aws_impl_code

Deployment

The implementation of the extension done, I built a shaded JAR using Maven to avoid any dependence conflicts and I added it to the classpath of the Bonita application in the application server (Tomcat, in this example). You can find the compiled artifact “bonita-serverless-ext-aws-lambda-0.0.1-shaded.jar” in the ”level3-1.0.zip” archive file.

3_add_jar


To leverage the extended behavior implemented in this library, I needed to edit the platform configuration. To avoid File System (FS) dependencies, the configuration is stored in the engine database. Good thing I can use the provided tool to pull the current configuration files from the database to the FS. From there I can apply the two necessary updates.

The first is businessArchiveService. The default configuration of the related bean looks like this:

3_bean_configuration_before


I changed it to use the extended implementation with the additional constructor argument named expressionResolverService .

3_bean_configuration


The second is constantExpressionExecutorStrategy. The default configuration of the related bean looks like this:

3_bean_configuration_before_2


I also changed it to use the extended implementation with the additional constructor argument named expressionResolverService .

3_bean_configuration_2

The configuration modified, I can use the provided tool again to push it back from the FS to the database. It is only at this time that I restart the platform to apply the configuration and continue. You can find the edited configuration file “bonita-tenants-custom.xml” in the ”level3-1.0.zip” archive file.

Connector

Because I need to provide more information about the serverless function to enable automatic operations, I created a new connector definition that extends the one I used in the previous article. I used the id “aws-lambda-auto” again as this is what I used in the service extension to filter. The main modification is in the definition of the inputs of the connector. I added:

  • jar: process resource path of the JAR that contains the serverless function code
  • role: Amazon Resource Names (ARN) of the role to be used
  • handler: the method to invoke as part of the serverless function

3_connector_before_after


The connector implementation remains the same as before, though. The point of adding these inputs is to be used by the service extension at deployment/deletion time. I do not need to change anything in the way the connector executes.

Application

The new version of the application did not require too much editing. I just needed to configure the connector providing the new inputs with the right values:

  • jar: forms/resources/aws-lambda-example-0.0.1-jar-with-dependencies.jar
  • role: arn:aws:iam:::role/service-role/
  • handler: org.bonitasoft.serverless.aws.RequestHandlerExample::handleRequest

The AWS Lambda serverless function JAR remains the same as the one I used in the previous article. I added it in the process resources to easily store it and make it accessible at runtime by the service extension. A great improvement would be to provide the code as text instead of a compiled JAR which is specific to Java. This would make all AWS Lambda runtimes easily available; your developers would love it!

Run It

I deployed the application with all its dependencies just like I would do for any other. It takes a bit more time than usual because the AWS Lambda function creation takes a few extra seconds. Some information about the serverless function creation is provided in the platform logs.

3_auto_deploy_logs


The deployed application can be used as a regular one — the result is the same as in the previous article.

3_test_form


If I remove the application and its dependencies, it also takes a bit more time than usual because the AWS Lambda function deletion takes a few extra seconds again. Some information about the serverless function deletion is provided in the platform logs.

3_auto_delete_logs


This confirms that I have a platform that automatically deals with serverless function administration, based on the business application definition alone. How sweet is this?

3_noops

Obviously, there will never be anything like actual NoOps and this proof of concept is specific to business applications built with the Bonita platform. But the main idea was to inspire you.

  • For Bonita users: industrialize and you will scale your serverless developments
  • For everyone else: I am sure a similar thing can be done for other platforms or applications you may have, if it is extensible enough.

In the next article of this series, I will focus on the vendor lock-in issue and practical use cases, so check for updates!

I would appreciate your feedback in the comments: enhancements, new topics to cover, etc. If you like what you read, let us know and we will spread the word!

Topics:
aws ,serverless ,architecture ,design ,bonita ,extensibility ,scalability ,integration ,distributed ,cloud

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}