# A Comparative Assessment of JVM Frameworks to Develop Microservices
## 2 Background  
As cloud computing has grown in popularity, competition among cloud providers has increased, resulting in, among other things, a wide range of ways to charge for computing power consumed/allocated. On the one hand, the lowest unit prices can be obtained by reserving computing power in advance for a longer period of time, but on the other hand, many currently deployed systems have a volume of users that is difficult to predict, and the high load of the system is only periodic, usually based on daily, weekly or monthly intervals. In such cases, the long-term allocation of computing resources to handle pile-ups over the system's lifetime is usually economically unjustifiable. Therefore, mechanisms are introduced into the system's architecture to enable autoscaling, and the effectiveness of that autoscaling depends on the software means used. However, the world of programming technologies is vast and still expanding rapidly. The choice of technology is a significant architectural decision. The base one, which is the foundation of each project or system, is the programming language. This choice binds to the given tools available within the ecosystem/platform or a runtime environment. None of the microservices, which are presently the basic concept behind horizontal autoscaling, is created directly from scratch--this would be inefficient, time-consuming, and error-prone. From this point of view, the essential part is a framework (or in some cases library) that will be a foundation for system development and is strictly connected to the chosen language platform. Depending on the ecosystem, frameworks have different names or represent different approaches. For example, for the C# language, it is ASP:NET, for the JVM platform it is Spring, while for Node.js it is Express.js. There are many, many others for subsequent ecosystems, but the main purpose of them remains the same-to allow leveraging one of the fundamental software design principles--DRY (Don't Repeat Yourself) [7] by providing designers and developers with an application structure and ready to use solutions for common use cases such as data access, security, communication, creation of API endpoints and many more. When choosing the technology stack and framework that will be used for microservices within the given system one should consider several aspects such as community support, popularity, usefulness but also performance. With the proliferation of IoT-class devices, research began to be conducted, in which scientific interest has not waned to this day, on communication protocols to ensure the integrity and security of messages being transmitted, while at the same time ensuring the lightness of those messages which is required by the relatively low computing capabilities of IoT devices. Moreover, the occupation of considerable transmission bandwidth resulting from the multitude of IoT devices motivates efforts to develop protocols concise in communication. At the same time, some shortcomings of the communication protocol developed in the SOA (service oriented architecture) era for communication between individual network services (SOAP) were recognized, resulting in the RESTful approach, which is also eagerly being adopted in the IoT world today. More and more models are being proposed for IoTs, where middleware is used to expose device data through REST API and to hide implementation details, and act as an interface for the user to interact with sensor data [8; 9]. Research on the use of the REST approach in IoT sensors is carried out in many areas of everyday life supported by IT, such as healthcare [10; 11; 12], agriculture [13; 14; 15], smart cities [16; 17; 18; 19], smart grids [20; 21], and more. In addition to communicating with individual IoT devices or other network services, the middleware layer often aggregates and processes the collected data and stores it in databases.