The creation of applications is relatively difficult: there is obviously the development phase, the packaging, the configuration, the provisioning of servers and finally the deployment of software. All of these steps are time consuming, require varied skills, and server provisioning is expensive. Serverless architectures disrupt its various stages by allowing development teams to focus on the code to be written, to consume the different services offered by the cloud provider (storage, bus, Api Gateway, etc.). to support an infrastructure that will be able to adapt to the load. We are moving from a static fixed cost model to a dynamic billing model that adapts the price to usage. FaaS (Function As a Service) is a type of cloud service that allows you to deploy a single function in serverless. It allows a very fine and highly dynamic configuration.
On the FaaS, the billing model is based on the number of function calls, the memory consumed and the execution time. Developers are therefore encouraged to create smaller functions and minimize both their execution time and memory consumption.
This type of cloud service divides traditional microservices into smaller pieces of software that can be executed very quickly. Where previously the microservices were composed of a set of functions called between them, these microservices are now split into a set of independent functions. Making the best use of these architectures also poses new challenges:
- How to maintain applications’ state?
- Then, How to effectively compose functions to develop complex applications?
- And, How to plan the executoin of functions?
- How to monitor functions and debug them?
The need for an orchestrator
These challenges naturally refer to the choice of an orchestrator because the more complex the application to be performed, the more functions it requires, and thus the more the orchestration needs are felt.
Currently, there is neither an orchestration standard for FasS nor a standard for the functions themselves.
The different cloud providers each offer their orchestration solution (and how they write the functions): Step Functions for AWS, Durable Functions for Azure and Google Cloud Composer for GCP. Choosing an orchestration solution is therefore currently choosing a cloud provider. We can also mention a high-level development tool like IBM Node-Red that allows to create flows. However, this type of product is specifically designed for IoT functions. More generic tools are needed to enable rich and personalized coordination.
A sophisticated level of abstraction is needed to hide the complexity of the heterogeneity of application development and deployment processes. Tools are needed not only to simplify resource discovery and monitoring tasks, but also for end-to-end lifecycle management.
To orchestrate functions several approaches exist. You can consult this presentation (Serverless-Function-Composition) which details the different approaches of possible orchestrations.
XComponent orchestration models
At INVIVOO Software, we offer orchestration methods through the creation of models. In particular, these models have the advantage of strongly decoupling the code from the orchestration logic. This greatly facilitates the readability of the code and its evolution as well as the management of errors and “retries”. We offer three types of models:
- State machine models
- They allow developers to define the business or technical logic of their services. State machine modeling makes it possible to address “event driven” issues with state management: for example, the progress of an order on an electronic market or the life cycle of a commercial website.
- Model of dependency trees
- They allow DevOps teams to declare the restart and monitoring procedures of their business applications
- Scenario model
- They combine services made available by IT. Scenarios can coordinate batch or streaming processing while including manuel processing.
FaaS orchestration via XComponent models
At first, we wanted to use scenario models to orchestrate FaaS functions. This type of model seemed appropriate to answer the main problems of orchestration. The treatments coordinated by our solutions can be distributed anywhere on the system (s) of information. Indeed, thanks to the scenario models, we can, for example, orchestrate Lambdas deployed on AWS with functions deployed on Azure and then execute a processing on the IS (Information System) internal to the company (Fig. 3) . Our XC platform Koordinator automatically integrates into its service catalog the FaaS functions deployed at different Cloud Providers.
This highly distributed orchestration is made possible via the following elements:
- A service discovery mechanism built into the solution. This mechanism allows abstraction of services. This level of abstraction makes it possible to coordinate any type of service. It is this mechanism that dynamically integrates the lambdas deployed on AWS. Each user of the solution can enrich this mechanism.
- Services integrated into the platform have typed inputs / outputs. This makes it possible to chain the processes easily while being able to verify the compatibilities between services before execution.
Monitoring and debugging executions are also facilitated by XC Koordinator. A screen makes it possible to follow the execution of the scenarios at each stage. We can thus:
- View the inputs / outputs of the scenario
- Know the progress of the scenario
- Visualize the inputs / outputs of a particular treatment
If some treatments fail, the treatments can be restarted automatically or stopped after a certain number of tests.
XC Koordinator also offers rework mechanisms. It is thus possible to restart a scenario as a whole or to restart only certain treatments.
The complexity of the infrastructure, process flow and error management is hidden from the users of the solution. We are also working on the use of our state machine models to orchestrate FaaS functions.
This approach is interesting because the model of state machines is richer for developers than scenarios: functions can trigger transitions from the code, there are transitions Timeout (which run by themselves after a while), transitions allowing the allocation of new state machines … The level of abstraction is both very high and very rich.
CONCLUSION
We believe that models are essential for orchestrating functions in an optimal way. Indeed, managing all calls between functions from the code does not seem viable. Some of the inherent advantages of FaaS are lost: such as scalability of functions or ease of deployment.
Finally, another major interest is to write “simple” code. To keep this simplicity of code writing, it seems essential to us to create models expressing all the business logic and masking the problems inherent to the orchestration.
