🦁 🚜 🧖 Create a scalable and resilient architecture with dynamic microservices 👧 🐷 🚵🏻

Hello again. As you know, in March, OTUS launches a completely new course on Architecture and Design Patterns . Ahead of the start of the course, a lot of material has been translated for you about Creating a scalable and resilient architecture using dynamic microservices. Enjoy reading!

annotation

One of the most important trends in industrial architecture is the use of microservices to the detriment of monolithic architectures that are losing popularity. Thanks to the cloud architecture, the deployment of microservice systems is more productive, flexible and cost-effective. Be that as it may, many companies have already begun to move from one type of architecture to another, but this is still only in its infancy. In this article, we solve problems arising from the need to develop a scalable and fault-tolerant system based on microservices. In our experiments, we consider two types of microservices, simple and advanced, and show that the proposed solution is innovative based on its dynamic behavior.

1. Introduction

In recent decades, the history of programming languages and computer science paradigms has been characterized by increased attention to distribution and modularization to improve code reuse and reliability.

There was a need to increase the quantity and quality of software [1]. One of the key factors in clarifying the various disagreements associated with innovative design is the adequacy of using various tools for the design and development of more advanced software systems [2]. Great success in this process has recently been demonstrated by microservice-based systems [3], which are an architectural paradigm focused on various applications (for example, for people with disabilities) [3]. Under the auspices of microservices, interest in architecture and design is growing. Quality attributes (eg, scalability, performance, and error tolerance) or model selection, such as “contractual de service” [5] or API Gateway,no longer violate the YAGNI principle (“You aren't gonna need it” - “suffering from BDUF errors” (“Big Design Up Front” - “Large-scale design first”). The main research question that this article intends to answer is how can we develop a system based on microservices with the same simplicity as a monolithic system? And further, starting from the previous topic, how can we create an environment that provides dynamic distribution of computing power between clients? Our research hypothesis suggests using a client-server system architecture that combines distributed computing and microservices to solve these problems.The main research question that this article intends to answer is how can we develop a system based on microservices with the same simplicity as a monolithic system? And further, starting from the previous topic, how can we create an environment that provides dynamic distribution of computing power between clients? Our research hypothesis suggests using a client-server system architecture that combines distributed computing and microservices to solve these problems.The main research question that this article intends to answer is how can we develop a system based on microservices with the same simplicity as a monolithic system? And further, starting from the previous topic, how can we create an environment that provides dynamic distribution of computing power between clients? Our research hypothesis suggests using a client-server system architecture that combines distributed computing and microservices to solve these problems.which provides dynamic distribution of computing power between clients? Our research hypothesis suggests using a client-server system architecture that combines distributed computing and microservices to solve these problems.which provides dynamic distribution of computing power between clients? Our research hypothesis suggests using a client-server system architecture that combines distributed computing and microservices to solve these problems.

The structure of the document is as follows: section 2 provides a brief overview of the current literature explaining the importance of microservices, including two well-known services offered by Azure, and section 3 discusses the proposed architecture. Section 4 discusses the evaluation of this system before drawing conclusions in the last section.

2. Literature review of microservices

Thanks to the cloud architecture, the deployment of microservice systems is more productive, flexible and cost-effective [6]. However, Zimmermann notes that microservices are a sensitive topic that is being studied mainly in academia [7] and industry. The term “microservices” was first discussed at a seminar of software architects in Italy in May 2011 to describe what participants saw as a common architectural style recently explored by many of them. A year later, the same group confirmed that the term “microservices” is the most appropriate name. In fact, microservices were developed as an answer to problems in monolithic applications or service-oriented architectures that complicate the scalability, complexity and dependencies of the application being developed,together with the use of lightweight communication mechanisms [8-9]. Since the monolith is a software application whose modules cannot be executed independently, we should consider a solution based on microservices, since it is the only one capable of executing instructions independent from each other [10-11]. Large monoliths become problematic to maintain over time and are difficult to evaluate because of their complexity, but the main disadvantage is that they limit the scalability of the product. Another problem is that they do not provide fault tolerance, and do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.Since the monolith is a software application whose modules cannot be executed independently, we should consider a solution based on microservices, since it is the only one capable of executing instructions independent from each other [10-11]. Large monoliths become problematic to maintain over time and are difficult to evaluate because of their complexity, but the main disadvantage is that they limit the scalability of the product. Another problem is that they do not provide fault tolerance, and do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.Since the monolith is a software application whose modules cannot be executed independently, we should consider a solution based on microservices, since it is the only one capable of executing instructions independent from each other [10-11]. Large monoliths become problematic to maintain over time and are difficult to evaluate because of their complexity, but the main disadvantage is that they limit the scalability of the product. Another problem is that they do not provide fault tolerance, and do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.able to execute instructions independent from each other [10-11]. Large monoliths become problematic to maintain over time and are difficult to evaluate because of their complexity, but the main disadvantage is that they limit the scalability of the product. Another problem is that they do not provide fault tolerance, and do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.able to execute instructions independent from each other [10-11]. Large monoliths become problematic to maintain over time and are difficult to evaluate because of their complexity, but the main disadvantage is that they limit the scalability of the product. Another problem is that they do not provide fault tolerance, and do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.and they do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.and they do not allow an individual component of the system to work when another component does not work, which is possible in microservice-oriented architectures.

In SOA (Service Oriented Architecture), the main services are coordinated using two methods: orchestration (where there is a central microservice that will send requests to other services and control the whole process by sending and receiving responses) and choreography (which does not involve any centralization, but each service knows in advance what it should do) [1]. As in the case of monolithic architectures and SOA architectures, the most difficult problem remains the partitioning of the system into services [12]. Also, in no case should one neglect the issue of providing confidential information through uncontrolled distribution of services [13].

Our architecture combines distributed computing with microservices to create an environment that enables dynamic distribution of computing between clients. By distributed computing, we mean the availability of processing and storing large amounts of data in the cloud, which is a key element in the modern industry both inside and outside the IT field. Distributed storage systems are designed to meet the requirements of distributed and computationally advanced applications with wide applicability, scalability and high performance. A well-known solution is MapReduce [14], which orchestrates calculations by sorting distributed servers, while simultaneously managing various tasks, all communications and data transfer between parts of the system,providing redundancy and fault tolerance.

Azure Batch is another programming model used to efficiently run computerized applications in parallel or large-scale mode, without manual configuration or infrastructure management, with more powerful clusters of high performance computing (HPC - high performance computing) [15]. To illustrate these ideas, let us remind you of SaaS (software as a service) or client applications that need wide execution [16]. In fact, various IT companies are showing increased interest in SaaS, being interested in lowering their operating expenses and, as a result, in increasing the flexibility of their business [17]. Another service offered by major cloud service providers is Azure Functions,which allows on-demand launch without the need for explicit provision or management of infrastructure [18].

It also increases the interest of applications in easily launching small pieces of code or “functions” in the cloud. The growing interest in the Internet of Things (IoT) makes Azure Functions [19] an excellent solution for data processing, system integration and the creation of simple APIs and microservices.

3. Methodology

The structurally proposed system can be divided into 3 different areas: (1) the client - that will perform the tasks assigned by the server; (2) server - an interface with a client, the brain of monolithic applications; (3) a client-server communication management area that encapsulates all the details associated with the transfer of execution from the server to the client. All information transmitted over the network between the client and server is encrypted using the DES (Data Encryption Standard) algorithm, and the key is changed using the Diffie-Hellman protocol [20], which, although it is vulnerable under certain conditions, yet implemented in a variety of Internet security solutions.

3.1. System architecture

Our system is heavily based on the architecture of dynamic microservice systems. The architecture takes as the basis the client-server, in which the server corresponds to a larger number of clients. Both the server and the client perform web microservices, the communication protocol is HTTP, the data format is JSON. This architecture is useful for distributing and dynamically redistributing resources between clients. Such an architectural model is used to build large, complex and horizontally scalable applications consisting of small, independent and separate processes that interact with each other using the API [21].

In fig. Figure 1 shows how a server distributes functionality packages for its clients. Depending on the number of clients, there may be instructions that will not be assigned to any client, or the same set of instructions assigned to several clients.

Fig. 1. Distribution of services to customers.

The application architecture was built using the ASP.NET MVC framework from Microsoft. In the central part, we see server microservices on the server itself, and on the left and right there are many clients waiting to start tasks from the server. The service component of orchestration provides, on the one hand, communication between the server and clients, sending tasks to clients, and on the other hand, it monitors the status of these requests.

This architecture allows one microservice to call another microservice (thus we get an extended (extended) microservice) or to call each other, which can lead to circular dependence, which should be prevented at the user level. The client-server communication protocol is carried out in the following steps:

The client connects to the server and initiates a key exchange protocol. He will also provide them to the server and port to which they will correspond.
The server notifies the client of the next task to be performed (the task is represented by a pair (microservice, input data)).
The client receives the job, and then notifies the server that the transfer and download have completed either successfully or unsuccessfully.
As soon as the connection between the two objects is established, the server sends the data in JSON format, encrypted using DES, to the client for processing.
( , ) JSON, DES.
, .
— .

A special case of this interaction is a scenario when a client performs a task for the result of which the result of another client is required. For this case, two existing possibilities were evaluated: orchestration and choreography.

In the case of choreography, we identified several obstacles: (a) a list of clients available for performing an external task had to be sent by the server to the client, and maintaining this list of updated values would often result in increased load on the information exchange network; (b) the communication between the two clients was vulnerable to attacks. Two situations were resolved through orchestration. In fact, all management care lies with the server, and clients are just simple objects that are easy to work with.

For the extended microservices option, the phases of client-client interaction will be as follows:

. , . , DES.
, , . , , , , . , ( . .).
, ( ), , .
.
The client decrypts the result with a one-time password and continues execution.

3.2. Application

To test and evaluate this architecture, we implemented several microservices that we called on for what we wanted to check at a time.

Fig. 2. The interface.

In the first experiment, we used 3 microservices as follows: (1) a microservice that performs a mathematical operation on two numbers (using LibraryMath), (2) a microservice that tells us whether the number is positive (MasterOfNumbers) and (3) an extended microservice, which will call the first microservice when it receives two numbers, and the result will be sent to the second microservice to extract information about this number (UniverseOfSuperMath).

Figure 2 shows how we obtain mathematical calculations using the presented microservices. At the interface level, only the result of a mathematical operation is displayed, the rest of the information can be seen as a result of the server receiving an AJAX call by pressing the equal key (both results are positive).

Next, we will consider the main functionality of the application, which focuses on what happens when there are one, two or more connected clients. In Figure 3 we see how in our experiments we launched more clients on the local computer, using different ports for each of them.

Fig. 3. The interface.

We have 6 fields: ClientToken - a unique token associated with each client (when the call is local and has localhost value); Date - the moment when the request was made; IP & Port = IP address of the client and the port through which communication is made; Function - name of the called function; Success - a boolean flag indicating the success of the call. For example, we notice that on the first call (h: 8:38:21 the client is not connected to the server, the process is performed by the server). At the second call, we observe the dynamic behavior of the system, one of the tasks of which is performed by one of the clients, and the other two are performed by the server. More specifically, UniverserOfSuperMath is called (locally - the client is not available for this task), which, in turn, calls two other microservices, one local and one through a client delegated to use a specific instruction, etc.d.

Fault tolerance
Another functionality that I took into account when creating this architecture was related to the fault tolerance of the system. Based on the previous scenario, we can observe what happens if one or more clients choose to leave the system.

In Figure 3 on the right, the call at 8:46 demonstrates this scenario. Clients on ports 8390 and 8827 have a local or network problem or simply close the connection to the server, and the server does not receive a notification in time to remove them from the list. The server will try to contact clients and run commands, but if they do not respond in a timely manner, the server takes on their tasks and returns the requested result. For confirmation, customers will be requested again after a while, and if they continue to not respond, they will be removed from the list of available customers. The next call (8:47) will no longer uselessly request clients that are no longer available, and tasks that are skipped by available clients will be performed by the server.

Advantages and disadvantages of the proposed solution

The advantages of this architecture are obvious: low hosting costs, microservices offered in a distributed network are dynamic and automatically scalable (when customers also offer computing power as they increase, the computing power of the system increases).

The limitations should be emphasized equally: when the computing power curve does not match the customer power curve. We also have a restriction on the ability to run this application on any operating system. To do this, we decided to convert an affordable solution from .NET to Java. But this solution has some drawbacks with respect to the original solution (Java offers lower data processing speed and less dynamic packet transfer than we do in .NET). We are currently using this solution because the .Net Core offered by Microsoft for working on several platforms is not yet a mature solution and does not offer all the functions of the standard .NET platform).

3.3. Client-server components

3.3.1. Customer

In this architecture, the client is a Windows Presentation Foundation (WPF) desktop application specifically designed to communicate with the server and perform various tasks received from it. Since the application is an executable file that does not require installation, the operating system must work with the .Net Framework. Essentially, a web microservice will interact with another web microservice.

First, the client starts the task scheduler in a parallel thread, which every minute will try to notify the server of its presence. A task can take two states: (1) either there is a task to execute (initialization of the code package has already been completed) - in this case it only notifies the server of its presence; (2) or requires initialization with the server.

Initialization with the server includes, first of all, an arbitrary choice of code and port that will start the server, which in turn are sent to it using the Diffie-Hellman key exchange protocol (IKE). As soon as the connection between the two objects is established, the server will notify the client with a package of instructions for installation. The main role of the client is to receive a package of instructions from the server, load it into memory, process the information received from the server, and then return the result obtained by executing this package of instructions. The first step performed by the client is to contact the server for a package of instructions. This package of instructions comes as a ZIP archive.

Before extracting this package, delete the previous directory with instructions from the “process” folder (if it exists), then extract the new content to this folder and load it into memory. Memory loading starts once, regardless of how many calls the client receives. This is possible because three properties remain unchanged in the session: assembly, methodInfo, and type. Assembly stores a link to the loaded DLL, the methodInfo property contains the method called from the DLL, and type describes the type of the DLL. The install.zip file is a package of instructions received from a server that contains DLLs, XML, images, configuration files, etc., and all compiled code that will be executed in a future process.

This step marks the beginning of communication between the client and server to perform a specific task. As soon as the client is successfully initialized to perform a specific task, the server will send only the data packet in encrypted form, which must be processed, and will also wait for a response in encrypted form.

By executing the code received from the server, the system is “locked”, the client can connect to the databases, call other APIs, in particular, call other clients that execute the same or different instructions. The connection is made in the orchestration system, where the server searches for the next available client, requests the result and its response is redirected by the server back to the client. This microservice orchestration is called “ExtendedService”, and the only difference at the client level is that the encryption is optimized.

The technical problem was to reinitialize the client with another package of instructions to execute. Since loading memory is static in a special context (web server), this was only possible by restarting the entire process to process DLLs loaded into memory. To do this, we created events in Windows that we run from a web application running in a desktop application. This is necessary because we are dealing with two different contexts in two different threads of execution.

3.3.2. Server

The embedded microservice has an ILibraryMath interface, which provides the SimpleMath method, and the interface is implemented by the LibraryMath class. The LibraryMath class extends the universal abstract class MicroCore, which has two corresponding parameters for input and output. Extending this abstract class, the ProcessTask method should be implemented where all the code to be executed is written, and the Run function is called in the extended abstract class to execute this code in the SimpleMath method. Thus, it is possible to define interfaces and methods, not limited to any specific name, but, passing the code through an abstract class, we will get full control over the code, which we can distribute among different clients. Inside this class, we can easily have more functions and imported libraries,if they are grouped in one package.

The next step is to write this interface to SimpleInjector, a library that facilitates the deployment of a dependency injection pattern with loosely coupled components. In addition to recording interleaved classes in the Simple Injector container, in order to break the dependency between application levels (introducing template dependencies), we need to register the class in the microservice storage container, which will be scaled by the application. After this step, we will be able to use the function provided by the interface for the created purpose.

Service1 implements IService1 and extends the abstract MicroCore class, and then registers with MicroContainer.RegisterMicro in this container. It is worth mentioning the existence of APIs available in localohst / DynamicMicros / {Service} through which clients communicate with the server. Important actions available through these APIs: the client connects, the client notifies the server of its activity, the microservices expand, etc. Next, we introduce the MicroCore and MicroContainer classes, which together form the basis of our application.

The MicroCore class is an abstract, universal class and is responsible for calling code from the ProcessTask virtual method. This is done by calling the Run method, which in turn calls the public TaskManager method. Note that the microservice, in turn, will also call this method. When a ZIP package is sent to the client for loading into memory and execution, it is sent with all its dependencies, including this class, which is used to manage the client’s microservice. Execution control includes deserializing / serializing the data packet to send, calling the code itself, calling other APIs, and so on.

Returning to the server side, controlling the execution of the code consists of the following steps:

If it is an ExtendedService call, the server will be called to answer.
If a client is available for the request, it will be sent to him to process the result; in the negative case, the server itself will process the data.
We request a client for data processing.
If the client has problems, we again ask for confirmation of availability, but send a server response (to avoid downtime and long waiting times).
We register current activity.

The MicroContainer class is the management space for the entire embedded microsystem. Here, the clients that connect the application (server) connect, and there are function calls that extend the MicroCore abstract class for “advanced services”. This is a static class in which the list of tasks performed on microservices, the list of connected clients and the list of client tasks that perform these tasks are stored in the dictionary.

When launched, the class will be registered for integration into the microservice using RegisterMicro. This will happen only once during initialization. The AddNewClient method provides us with the registration of a new client, key exchange, registration of the IP address of the server and the port on which it will work. The token received by the new client will be checked before being inserted into the list of clients to confirm its uniqueness. Once the connection with the client is established, the server will call the InstallService method, which packs the data, sends it, and after the client responds, it will be added to the dictionary for this task. The service time that will be allocated to each customer depends on the strategy used. When you start the abstract MicroCore microservice, called both on the server and on the client (with ExtendedService),a request is made for available clients for the requested task using the GetNextClient function. This operation will be performed very often, and its complexity will directly affect the application response time. That is why our approach was to randomly select a client. This is done quickly and from our experiments ensures even distribution of calls.

Another option was to implement a round-robin list — a solution that has the drawback that in the event of a large client I / O stream, updating the round-robin list will require more time and complexity, which we tried to avoid. The RecordClientError method is called when the client does not respond to the received request. After answering this question, a decision is made to save or delete this client. Clients are uniquely identified by the token code sent by the client during initialization, and each microservice is identified by a namespace and class name. All resources (clients, code) are managed through this unitary unit, which provides support for necessary operations.

Regarding system security, measures have been taken to prevent attacks, intercepts, and data protection. All messages sent between the server and clients are encrypted using the symmetric DES key algorithm and the Diffie-Hellman key exchange between the client and the server, which occurs during client initialization. Available clients and running programs are stored in server memory. We chose this solution because, in our opinion, it was the best option, because it provides high speed access to data, information can change very often, and the memory area is very difficult to attack.

3.4. Dynamic behavior of a microservice system

First of all, all the computers on which the clients will work can be in the same or in different networks. Two elements are in priority: (a) time spent on data transfer; and (b) the overhead added by the system for data management (e.g., customer search, encryption, decryption, error handling, etc.). We were mainly interested in the behavior of our system in local (LAN) and global (WAN) networks (Fig. 4).

Fig. 4. Record of the system working in a local area network (the first column of logs) and global (the second column of logs).

The Task name column contains all the registrations made by the client call for each task, and the Logs columns are hours and duration in ms for each task processing (on the left in the local network and on the right in the global network). Note that tasks have the longest response time to the first call, after which it decreases. Naturally, because all memory downloads, saving addresses, etc. are usually done on the first call. The first three tasks are simple mathematical operations that are usually performed within milliseconds - the time that is also required for our system.

For a local network, we have an average of 20-30 milliseconds per task, which comes from encryption, logging and transmission over the network (even if it is local). This model of LAN communication is also used in the cloud, where computers are located in the same place (data center), and the communication between them is via fiber optic, the network delay is minimal. The results are shown in fig. 4 in the left column of logs.

To test our WAN application, we configured the router to route a call from port 80 to:http://192.168.1.160/(network address), and IIS (Internet Information Services) launched the application, and it was accessible from anywhere outside the local network. To run the application at the client level, the right to use ports 8000: 9000 (arbitrary ports) was required. Clients are arranged at arbitrary points, connection to the public IP been ascertained via API: https://api.ipify.org/. The results are shown in fig. 4 in the log column on the right.

In the results presented in fig. 4, the values in the right column of the journal are 16-17% higher than the values in the left column of the journal for the first three tasks (without communication with other microservices) and ± 10% for microservices that downloaded documents from the Internet or interacted with the database on specific server.

4. Evaluation

In this study, we monitored the behavior of the system both in the local network (connecting 5 computers via a wireless network) and in the global network (using the mihaidm.ddns.net namespace ), comparing our system with a monolithic system, these operations are performed on the same computer (see table 1).

Table 1. System rating for networks.

	calculation (ms)	write to database (ms)	pdf generation (ms)
localhost	1	4.458	15.449
lan	25	4.408	16.415
wan	54	4.826	29.309

Testing was carried out sequentially on one device with 5 connected clients for network testing. Each task was completed 100 times, evaluating the total number of milliseconds in all calls.

It was a product of two numbers as a numerical calculation. A microservice does not interact with other microservices, the amount of information transmitted over the network is small, and the complexity is minimized to strictly study the time spent on server, client, and network management tasks. If the calculation is performed by the server (localhost), it is first checked if there is an available client, and since the client is not connected, the server processes the result. In the following case, the presence of clients in the local network shows the completion of the task in conditions of very fast network operation, and from the processing side, encryption / decryption, finding the client’s response. For 100 executions, the average time required to complete the operation was 25 ms, which is a promising value considering the flexibility / speed ratio. In case of WAN, the time is twice as longthan in the local network (54 ms), this is due to the encryption process, transport costs, but for the actual execution requires half a millisecond.

Another task that we investigated is writing to the database. In particular, the word that will be written to the database is taken as a parameter. We are interested in how quickly the client will contact a database located outside the local area (for this study, the database was located at www.my.gearhost.com ). Note that the runtime values on LAN and localhost are close. In the global network, the difference is noticeable, because processing, managing data and clients does not take as much time as the range of clients that connects to the database to insert the value.

The last task performed in this study was the creation of a PDF file, our focus was on estimating the transmission time of the data in the system. To do this, we download the PDF file from www.pdf-archive.com/2018/05/14/diploma/diploma.pdf , which is loaded into memory. The system will write the name to a specific position and return the result (in the form of byte vectors) back to the server. For a local host and a local network, a difference of about 1000 ms represents the time required to encrypt and transfer PDF files locally. For the WAN, the resulting value is higher because the transmission cost of the byte vector is very high.

5. Conclusions and future work

The general and abstract nature of the system architecture, presented in this work on the server side, made design difficult, since the same code is executed by both the server and the client. We can argue that the current architecture is compact, simple, easy to understand and expand; the client can perform the tasks assigned by the server, the server is a monolith and the client interface.

The proposed architecture makes it very easy to create new microservices, which are then automatically integrated into the embedded system. Innovative elements of this architecture: it can be scaled very easily, each new client receives a task from the server in accordance with the strategy pursued (the most expensive tasks, the most common, a combination of the two previously listed or purely just an arbitrary strategy). In fact, we have a monolith with the flexibility of a microservice system. The server processes the dynamic distribution of tasks between clients, providing dynamic scaling based on a number of parameters (the number of calls to the task, its execution time, or a combination thereof).

One of the future directions takes into account that this system can be successfully integrated into a website or API system with a pronounced applicative character. The proposed architecture can be improved and expanded at any time due to availability for several platforms (for example, for mobile phones).

Another direction in the future that we are considering is considered extremely attractive today - is that the user provides computing power in exchange for a fee (for example, the BITCOIN system), our application is developed to run microservices on certain computers.

Source Link

This study was published with the support of the POC-A1-A1.2.3-G-2015 program, as part of the PrivateSky project (P_40_371 / 13/01/01/2016) and the README project “Interactive and innovative application for assessing the readability of Romanian texts and improving user writing styles ”, contract No. 114/15.09.2017, MySMIS 2014 code 119286.

References

[1] Dragoni, N., Giallorenzo, S., Lluch-Lafuente, AL, Mazzara, M., Montesi, F., Mustafin, R. (2017a) "Microservices: Yesterday, Today, and Tomorrow." Mazzara M., Meyer B. (eds.), Present and Ulterior Software Engineering. Springer
[2] Mazzara, M., Khanda, K., Mustafin, R., Rivera, V., Safina, L. and Silitti, A. (2018) “Microservices Science and Engineering”. In: P. Ciancarini, S. Litvinov, A. Messina, A., Sillitti, G. Succi (eds.) Proceedings of the 5th International Conference in Software Engineering for Defense Applications, SEDA 2016, Springer, 10-20.
[3] Dragoni, N., Lanese, I., Larsen, ST, Mazzara, M., Mustafin, R., and Safina, L. (2017b) “Microservices: How To Make Your Application Scale”. In: Petrenko A., Voronkov A. (eds.) Perspectives of System Informatics. PSI 2017. Lecture Notes in Computer Science, 10742. Springer, Cham.
[4] Melis, A., Mirri, S., Prandi, C., Prandini, M., Salomoni, P., and Callegati, F. (2016) “A Microservice Architecture Use Case for Persons with Disabilities”. At the 2nd EAI International Conference on Smart Objects and Technologies for Social Good, DOI: 10.1007 / 978-3-319-61949-1_5.
[5] Zimmermann, O. (2017) “Microservices Tenets: Agile Approach to Service Development and Deployment, Computer Science - Research and Development”, 32 (3-4): 301-310.
[6] Xia, C., Zhang, Y., Wang, L, Coleman, S., and Liu, Y. (2018) “Microservice-based cloud robotics system for intelligent space”. In: Robotics and Autonomous Systems 110, DOI: 10.1016 / j.robot.2018.10.001.
[7] Bogner, J., Fritzsch, J., Wagner, S., and Zimmermann, A. (2019) “Microservices in Industry: Insights into Technologies, Characteristics, and Software Quality”. At the 2019 IEEE International Conference on Software Architecture Workshops (ICSAW) At: Hamburg, Germany.
[8] Akentev, E., Tchitchigin, A., Safina, L., and Mzzara, M. (2017) “Verified type checker for Jolie programming language”, https: // arXiv.org/pdf/1703.05186.pdf.
[9] Černý, T., Donahoo, MJ, and Trnka, M. (2018) “Contextual understanding of microservice architecture: current and future directions”. ACM SIGAPP Applied Computing Review 17 (4): 29-45, DOI: 10.1145 / 3183628.3183631.
[10] Larucces, X., Santamaria, I., Colomo-Palacios, R., and Ebert, C. (2018) “Microservices”. In: IEEE Software, 35/3: 96-100.
[11] Kalske, M. (2017) “Transforming monolithic architecture towards microservice architecture”. M.Sc. Thesis, Univ. of Helsinki.
[12] Lenarduzzi, V., and Taibi, D. (2016) “MVP Explained: A Systematic Mapping Study on the Definitions of Minimal Viable Product”. At the 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 112-119.
[13] Taibi, D., Lenarduzzi, V., Janes, A., Liukkunen, K., and Ahmad, MO (2017) “Comparing Requirements Decomposition within the Scrum, Scrum with Kanban, XP, and Banana Development Processes”. In: Baumeister H., Lichter H., Riebisch M. (eds.) Agile Processes in Software Engineering and Extreme Programming. Lecture Notes in Business Information Processing, 283. Springer, Cham.
[14] Gómez, A., Benelallam, A., and Tisi, M. (2015) “Decentralized Model Persistence for Distributed Computing”. At the 3rd BigMDE Workshop, L'Aquila, Italy.
[15] Kandave, KR (2018) “High performance computing on Azure”. Nanette Ray (ed.), AzureCAT, Microsoft Corporation.
[16] Sreenivas, V., SriHarsha, S., and Narasimham, C. (2012) “A Cloud Model to Implement SaaS”. In: Advanced Materials Research 341-342, Trans Tech Publications, Switzerland, 499-503.
[17] Badidi, E. (2013) “A Framework for Software-As-A-Service Selection and Provisioning”. In: International Journal of Computer Networks & Communications (IJCNC), 5 (3): 189-200.
[18] Lynn, T., Rosati, P., Lejeune, A., and Emeakaroha, V. (2017) “A Preliminary Review of Enterprise Serverless Cloud Computing (Functionas-a-Service) Platforms”. At the 2017 IEEE 9th International Conference on Cloud Computing Technology and Science, 162-169.
[19] Adzic, G. and Chatley, R. (2017) “Serverless Computing: Economic and Architectural Impact.” At: ESEC / FSE'17, September 4-8, 2017, Paderborn, Germany, ACM.
[20] Diffie, W. and Hellman, M. (1976) “New directions in cryptography”. In: IEEE Transactions on, Information Theory, 22 (6): 644–654.
[21] Kratzke, N. (2015) “About Microservices, Containers and their Underestimated Impact on Network Performance”. At the CLOUD Comput. 2015, 180 arxiv.org/abs/1710.04049 .

Learn more about the course

Create a scalable and resilient architecture with dynamic microservices