In this new installment of Inspiring Technology, our Hunters delve into serverless architecture. This new form of software development using cloud services focuses on developing specific parts of the application without having to worry about managing a server infrastructure and all that entails.
Various cloud service providers, such as AWS, Google , and Azure , offer all types of services in a fully managed manner. One example is databases as a service , in which the service provider manages all aspects necessary for its operation: installation, configuration, hosting, security, maintenance, etc. This allows them to be used for application development without having to worry about the infrastructure.
In addition, the execution of functions is also offered as a service, so that once the code is provided to the service provider, it can be executed whenever needed. This allows developers to focus solely on developing the specific parts of their application , leading to increased development speed and efficiency.
Advantages and disadvantages of serverless architecture
Scalability
One of the greatest advantages of serverless architecture is that it allows for significant horizontal scalability . When faced with a large number of requests, the service provider automatically instantiates more worker nodes in parallel. However, it's important to keep in mind that dependencies on external third-party services could pose a bottleneck.
Additionally, it allows scalability to zero , that is: when a specific service is not used, no instance of it is kept running, avoiding unnecessary resource consumption.
Pay per use
Another major advantage is that since services are only instantiated when used, service providers bill based on usage.
This way, if the application is not running for a month, it will not generate any costs. However, if the usage is very high in a month, the cost will increase with usage, being more expensive than an on-premise solution when usage is very high.
This is especially beneficial for applications that by nature have a low workload for certain periods of time.
Vendor lock-in
An important aspect to keep in mind when developing a serverless application is vendor lock-in . This term refers to the dependency that is generated with a specific provider.
Typically, each service provider offers its own services, each with specific functionality, capabilities, and configurations . Developing with a provider's services creates a dependency on them, which is particularly difficult if you want to switch to another provider.
Performance
While scaling to zero saves costs, it can also have a significant performance impact in certain situations.
Every time a service runs without any running instances, it must be initialized by instantiating it, downloading the necessary code, and preparing the execution environment, which will significantly increase response time. This problem is known as cold start.
Figure 1: Diagram of a cold start.
To avoid this problem, we perform sequential executions, which reuse the same container , so this only affects the time of the first execution within a container.
Figure 2: Cold start prevention scheme.
OpenWhisk
OpenWhisk is an open-source platform that offers serverless execution with minimal configuration. This platform offers the option of on-premise hosting using container orchestrators such as Kubernetes, OpenShift, and Docker Compose.
Figure 3: Apache OpenWhisk logo.
Thanks to on-premise hosting, you get greater control over costs , along with greater independence from service providers , allowing you to switch between these providers without complications (you can even have no provider at all if you have all your services on-premise).
OpenWhisk requires a base infrastructure to manage the platform itself, which will consume a relatively constant amount of resources. However, resource consumption by the workload itself will vary.
Figure 4: OpenWhisk infrastructure diagram.
OpenWhisk works through an event-driven system:
An event is generated from an external feed, such as an HTTP request, a modification to an entity in a database, or a message in a Kafka broker.
This event triggers a rule, which has associated actions that will be executed and generate a response in JSON format.
Figure 5: Diagram of the OpenWhisk event-driven system.
OpenWhisk allows for the easy definition of actions in a multitude of languages . Regarding their implementation, a function is defined that receives a JSON object with the input arguments and returns another object with the result.
Figure 6: Example of function with JSON object.
To execute an action, a container is instantiated with the associated runtime, where it is executed, and it is discarded when it has completed. This way, only the resources needed at any given time are used. It also allows for the definition of compound actions, consisting of a series of actions executed sequentially, where the output data of the previous function becomes the input data for the next.
Figure 7: OpenWhisk composition scheme.
OpenWhisk can listen to a multitude of external feeds, executing defined actions in response to, for example, a commit on GitHub or a message on Slack.
Figure 8: Different OpenWhisk functionalities
In this video we will see how OpenWhisk works as a serverless option:
Want to know more about Hunters?
Being a Hunter means accepting the challenge of testing new solutions that deliver differentiated results. Join the Hunters program and become part of a cross-functional group capable of generating and transferring knowledge.
Get ahead of the digital solutions that will drive our growth. Find more information about Hunters on the website.
Joan Galiana - Software Technician at Altia
