Authors: Javier Berrocal (@jberolm), Jose Garcia-Alonso (@jmgaralo), Juan Manuel Murillo (@juanmamuro)
The increase in the capabilities of near-to-the-edge and end devices has allowed developers to take these devices as a possible destination for the deployment architecture of any API. They can better satisfy the essential requirements of some APIs, such as responsiveness, location-awareness, etc., but they also present some restrictions regarding resource consumption (battery, data traffic, and so on). Currently, developers have to analyze every architectural style carefully and available device to meet the system requirements better. Different tools and proposals are available to facilitate both the decision-making process and the application of the selected architecture.
Increase in the capabilities of near-to-the-end devices
During the last few years, the predominant architectural style for the deployment of APIs has been the Server-Centric or Cloud-Centric style. In these styles, the most demanding features, like storing or computing of the managed data, are offloaded to cloud environments. These styles provide improved scalability, fault tolerance, and greater control of the operational costs. They allowed developers to implement applications with an excellent response time that can be visualized and used from end devices, that until a few years ago had very limited capabilities.
In the last few years, end devices and near-to-the-edge devices capabilities have increased tremendously. Their storage and computational capabilities have increased in order to be able to execute more complex tasks. This allowed researchers to develop new paradigms, such as Fog, Mist or Edge Computing, in which the whole or part of an application or API is loaded in end devices or near-to-the-edge devices, reducing the network load and the dependency of the cloud environment and improving response time. For instance, by using data closer to, or even inside, the targeted device.
Therefore, developers not only have to make decisions about how to develop a specific API but also what architectural style to apply and where each microservice should be deployed to meet the system requirements better. Initially, one may think that the behaviors implemented with one style, cannot be achieved with others. Our experience, however, has shown us that similar behaviors can be obtained with any of them.
Trade-off among capabilities and limitations
Therefore, just at the moment in which the developer has to select what architectural and deployment style to use, s/he has to do a complex trade-off among the system requirements, and the capabilities and limitations of the different devices in the environment. Deploying an API following a server-centric style could increase the system scalability or the fault tolerance, but could also negatively affect the operational cost, location-awareness, and responsiveness. Deploying an API in near-to-the edge devices could positively impact these requirements, but they also present some significant limitations. For instance, a constraining factor of these devices is the resource consumption (battery, data traffic, etc.). Many of these devices, such as mobile phones, smart speakers, etc. are battery-powered. Likewise, some of them have to interact using the mobile network, either because they are mobile or because of their specific situation, which entails the consumption of the data plan. In the deployment of any API, the correct management of these resources is crucial for user satisfaction. It is well known that resource consumption, is a factor determining the application success.
Therefore, all these dimensions have to be taken into account to select the architectural style that best fit the system requirements, doing a trade-off among the capabilities and limitations of every connected device and the system requirements.
Tools helping in the decision-making process
During the last few years, researchers have been working on defining methods for measuring whether the requirements are met, from those directly related to the system behavior to those that impact on other non-functional dimensions such as the resource consumption.
Some works both in the academia and in the industry domains are focused on analyzing the final developed and deployed an application for identifying if those requirements are met. For instance, Giovani et al. presented some years ago, a monitoring framework able to adjust the resources assigned to the deployed application or to face transient failures replicating and restarting components to provide resiliency. Leitner et al. proposed a tool to re-evaluate the cost of an application in the background continually. Alternatively, for end Android devices, Batterystatscould be used to collects battery data about the consumption of a specific application.
Another proposal, however, is focused on evaluating during the early stages of the development process how these requirements can be met, helping in the decision-making process of which architectural design are the most suitable. For instance, some works propose a different heuristic to identify where the microservices should be deployed to meet some requirements such as responsiveness better. Likewise, the authors of this post have been working on defining a conceptual framework to identify in early development stages what architectural style is the most appropriate to achieve a reduction in terms of resource consumption.
Generating microservices for different architectures
Once identified the most appropriate style for achieving the system requirements, the API has to be developed and deployed.
Currently, the specification and development of microservices are supported by a large number of tools that facilitate the work of the developer. Specifications such as OpenAPI, are widely used to detail an API, generate the documentation, perform tests and, even, generate the API skeleton. This type of tools can even generate the source code for different technologies such as Node.JS, Kotlin, JAX-RS,etc., but they are focused on deploying the API in a server or a cloud environment.
Fewer commercial tools are supporting other architectural styles, such as client-centric or others architectures based on fog or mist computing. However, at the research level, more and more proposals are presented detailing how to use these specifications to generate the skeleton and to deploy microservices in other elements of the network. For instance, Noura et al. propose WoTDL2API tool, that automatically generates a running RESTful API based on the OpenAPI specification and its code generation toolchain to control different IoT devices. The generated source code can be deployed in near-to-the-edge devices, such as gateways, routers, and so on.
Likewise, the authors of this post have recently proposed a set of tools to generate and deploy a running RESTful API based on the OpenAPI standard on end devices such as smartphones, IoT devices, etc., providing support to client-centric architectures.
Summarizing
APIs and microservices until now have been designed and developed to be deployed on a cloud environment because of its computing capabilities, fault tolerance, responsiveness, etc. Nevertheless, the ever-increasing capabilities of other elements in the networks have fostered the deployment of these APIs in these devices to better meet some requirements such as scalability, interoperability, real-time responsiveness, security, or location-awareness.
Nevertheless, for developers to apply the best architectural style, first, they need tools helping in the decision making process by providing information for each style on the degree of compliance of the requirements; and, secondly, tools supporting and reducing the effort required to develop and deploy the microservices for each architectural style are needed. If these tools are not provided developer, tend to use only known architectures and those with greater support.
No comments:
Post a Comment