Chapter 14. Technologies for Nanoservices

Section 14.1 discusses the advantages of nanoservices and why nanoservices can be useful. Section 14.2 defines nanoservices and distinguishes them from microservices. Section 14.3 focuses on Amazon Lambda, a cloud technology that can be used with Python, JavaScript, or Java. Here each function call is billed instead of renting virtual machines or application servers. OSGi (section 14.4) modularizes Java applications and also provides services. Another Java technology for nanoservices is Java EE (section 14.5), if used correctly. Vert.x, another option, (section 14.6) also runs on the JVM but supports a broad variety of programming languages in addition to Java. Section 14.7 focuses on the programming language Erlang, which is quite old. The architecture of Erlang enables the implementation of nanoservices. Seneca (section 14.8) has a similar approach as Erlang but is based on JavaScript and has been specially designed for the development of nanoservices.

The term “microservice” is not uniformly defined. Some people believe microservices should be extremely small services—that is, ten to a hundred lines of code (LoC). This book calls such services “nanoservices.” The distinction between microservices and nanoservices is the focus of this chapter. A suitable technology is an essential prerequisite for the implementation of small services. If the technology, for instance, combines several services into one operating system process, the resource utilization per service can be decreased and the service rollout in production facilitated. This decreases the expenditure per service, which enables support of a large number of small nanoservices.

Very small modules are easier to understand and therefore easier to maintain and change. Besides, smaller microservices can be replaced more easily by new implementations or a rewrite. Accordingly, systems consisting of minimally sized nanoservices can more easily be developed further.

There are systems that successfully employ nanoservices. In fact, in practice it is rather the too large modules that are the source of problems and prevent the successful further development of a system. Each functionality could be implemented in its own microservice—each class or function could become a separate microservice. Section 9.2 demonstrated that it can be sensible for CQRS to implement a microservice that only reads data of a certain type. Writing the same type of data can already be implemented in another microservice. So microservices can really have a pretty small scope.

• The expenditure for infrastructure increases. When each microservice is a separate process and requires infrastructure, such as an application server and monitoring, the expenditure necessary for running hundreds or even thousands of microservices becomes too large. Therefore, nanoservices require technologies that make it possible to keep the expenditure for infrastructure per individual service as small as possible. In addition, a low resource utilization is desirable. The individual services should consume as little memory and CPU as possible.

• In the case of very small services a lot of communication via the network is required. That has a negative influence on system performance. Consequently, when working with nanoservices communication between the services should not occur via the network. This might result in less technological freedom. When all nanoservices run in a single process, they are usually required to employ the same technology. Such an approach also affects system robustness. When several services run in the same process, it is much more difficult to isolate them from each other. A nanoservice can use up so many resources that other nanoservices do not operate error free anymore. When two nanoservices run in the same process, the operating system cannot intervene in such situations. In addition, a crash of a nanoservice can result in the failure of additional nanoservices. If the processes crash, their crash will affect all nanoservices running in the same process.

The technical compromises can have a negative effect on the properties of nanoservices. In any case the essential feature of microservices has to be maintained—namely, the independent deployment of the individual services.

In detail the following points need to be achieved:

• The expenditure for infrastructure such as monitoring and deployment has to be kept low. It has to be possible to bring a new nanoservice into production without much effort and to have it immediately displayed in monitoring.

• Resource utilization, for instance in regard to memory, should be as low as possible to enable a large number of nanoservices with little hardware. This does not only make the production environment cheaper but also facilitates the generation of test environments.

• Communication should be possible without the network. This does not only improve latency and performance but increases the reliability of the communication between nanoservices because it is not influenced by network failures.

• Concerning isolation, a compromise has to be found. The nanoservices should be isolated from each other so that one nanoservice cannot cause another nanoservice to fail. Otherwise, a single nanoservice might cause the entire system to break down. However, achieving a perfect isolation might be less important than having a lower expenditure for infrastructure, a low resource utilization, and the other advantages of nanoservices.

• Using nanoservices can limit the choice of programming languages, platforms, and frameworks. Microservices, on the other hand, enable, in principle, a free choice of technology.

However, by no means may the technology require a joint deployment of nanoservices, for independent deployment is the central characteristic of microservices and also nanoservices. Independent deployment constitutes the basis for the essential advantages of microservices: Teams that can work independently, a strong modularization, and as consequence a sustainable development.

Therefore, nanoservices can be defined as follows:

• Nanoservices compromise in regard to some microservice properties such as isolation and technology freedom. However, nanoservices still have to be independently deployable.

• The compromises enable a larger number of services and therefore for smaller services. Nanoservices can contain just a few lines of code.

• To achieve this, nanoservices use highly efficient runtime environments. These exploit the restrictions of nanoservices in order to enable more and smaller services.

Thus, nanoservices depend a lot on the employed technologies. The technology enables certain compromises in nanoservices and therefore nanoservices of a certain size. Therefore, this chapter is geared to different technologies to explain the possible varieties of nanoservices.

The objective of nanoservices is to amplify a number of advantages of microservices. Having even smaller deployment units decreases the deployment risk further, facilitates deployment even more, and achieves better, understandable, and replaceable services. In addition, the domain architecture will change: A Bounded Context that might consist of one or a few microservices will now comprise a multitude of nanoservices that each implement a very narrowly defined functionality.

The difference between microservices and nanoservices is not strictly defined: If two microservices are deployed in the same virtual machine, efficiency increases, and isolation is compromised. The two microservices now share an operating system instance and a virtual machine. When one of the microservices uses up the resources of the virtual machine, the other microservice running on the same virtual machine will also fail. This is the compromise in terms of isolation. So in a sense these microservices are already nanoservices.

By the way, the term “nanoservice” is not used very much. This book uses the term “nanoservice” to make it plain that there are modularizations that are similar to microservices but differ when it comes to detail, thereby enabling even smaller services. To distinguish these technologies with their compromises clearly from “real” microservices the term “nanoservice” is useful.

1. http://aws.amazon.com/lambda

Amazon Lambda can execute individual functions that are written in Python, JavaScript with Node.js, or Java 8 with OpenJDK. The code of these functions does not have dependencies on Amazon Lambda. Access to the operating system is possible. The computers the code is executed on contain the Amazon Web Services SDK as well as ImageMagick for image manipulations. These functionalities can be used by Amazon Lambda applications. Besides, additional libraries can be installed.

Amazon Lambda functions have to start quickly because it can happen that they are started for each request. Therefore, the functions also may not hold a state.

Thus there are no costs when there are no requests that cause an execution of the functions. Each request is billed individually. Currently, the first million requests are free. The price depends on the required RAM and processing time.

The following events can trigger a call of a Lambda function:

• In Simple Storage Service (S3) large files can be stored and downloaded. Such actions trigger events to which an Amazon Lambda function can react.

• Amazon Kinesis can be used to administrate and distribute data streams. This technology is meant for the real time processing of large data amounts. Lambda can be called as reaction to new data in these streams.

• With Amazon Cognito it is possible to use Amazon Lambda to provide simple back ends for mobile applications.

• The API Gateway provides a way to implement REST APIs using Amazon Lambda.

• Furthermore, it is possible to have Amazon Lambda functions be called at regular intervals.

• As a reaction to a notification in Simple Notification Service (SNS), an Amazon Lambda function can be executed. As there are many services which can provide such notifications, this makes Amazon Lambda useable in many scenarios.

• DynamoDB is a database within the Amazon Cloud. In case of changes to the database it can call Lambda functions. So Lambda functions essentially become database triggers.

The technological expenditure for infrastructure is minimal when using this technology: A new version of an Amazon Lambda function can easily be deployed with a command line tool. Monitoring is also simple: the functions are immediately integrated into Cloud Watch. Cloud Watch is offered by Amazon to create metrics of Cloud applications and to consolidate and monitor log files. In addition, alarms can be defined based on these data that can be forwarded by SMS or email. Since all Amazon services can be contacted via an API, monitoring or deployment can be automated and integrated into their own infrastructures.

Amazon Lambda provides integration with the different Amazon services such as S3, Kinesis, and DynamoDB. It is also easily possible to contact an Amazon Lambda function via REST using the API Gateway. However, Amazon Lambda exacts that Node.js, Python, or Java are used. This profoundly limits the technology freedom.

Amazon Lambda offers an excellent isolation of functions. This is also necessary since the platform is used by many different users. It would not be acceptable for a Lambda function of one user to negatively influence the Lambda functions of other users.

Amazon Lambda is a part of the Amazon ecosystem. Therefore, it can be supplemented by technologies like Amazon Elastic Beanstalk. There, microservices can run that can be larger and written in other languages. In addition, a combination with Elastic Computing Cloud (EC2) is possible. EC2 offers virtual machines on which any software can be installed. Moreover, there is a broad choice in regard to databases and other services that can be used with little additional effort. Amazon Lambda defines itself as a supplement of this tool kit. In the end one of the crucial advantages of the Amazon Cloud is that nearly every possible infrastructure is available and can easily be used. Thus developers can concentrate on the development of specific functionalities while most standard components can just be rented.

4. http://www.osgi.org/

5. http://en.wikipedia.org/wiki/OSGi#Current_framework_implementations

Listing 14.1 OSGi MANIFEST.MF

Click here to view code image

Bundle-Name: A service
Bundle-SymbolicName: com.ewolff.service
Bundle-Description: A small service
Bundle-ManifestVersion: 2
Bundle-Version: 1.0.0
Bundle-Acltivator: com.ewolff.service.Activator
Export-Package: com.ewolff.service.interfaces;version="1.0.0"
Import-Package: com.ewolff.otherservice.interfaces;
version="1.3.0"

Listing 14.1 shows an example of a MANIFEST.MF file. It contains the description and name of the bundle and the bundle activator. This Java class is executed upon the start of the bundle and can initialize the bundle. Export-Package indicates which Java packages are provided by this bundle. All classes and interfaces of these packages are available to other bundles. Import-Package serves to import packages from another bundle. The packages can also be versioned.

In addition to interfaces and classes bundles can also export services. However, an entry in MANIFEST.MF is not sufficient for this. Code has to be written. Services are only Java objects in the end. Other bundles can import and use the services. Also calling the services happens in the code.

Bundles can be installed, started, stopped, and uninstalled at runtime. Therefore, bundles are easy to update: Stop and uninstall the old version, then install a new version and start. However, if a bundle exports classes or interfaces and another bundle uses these, an update is not so simple anymore. All bundles that use classes or interfaces of the old bundle and now want to use the newly installed bundle have to be restarted.

In practice a procedure has been established where a bundle only exports the interface code of the service as classes and Java interfaces. Another bundle contains the implementation of the service. The classes of the implementation are not exported. The service implementation is exported as OSGi service. To use the service a bundle has to import the interface code from the one bundle and the service from the other bundle (see Figure 14.1).

OSGi enables restarting services. With the described approach the implementation of the service can be exchanged without having to restart other bundles. These bundles only import the Java interfaces and classes of the interface code. That code does not change for a new service implementation so that restarting is not necessary anymore. That way the access to services can be implemented in such a manner that the new version of the service is, in fact, used.

With the aid of OSGi blueprints⁶ or OSGi declarative services⁷ these details can be abstracted away when dealing with the OSGi service model. This facilitates the handling of OSGi. These technologies, for instance, render it much easier to handle the restart of a service or its temporary failure during the restart of a bundle.

6. https://osgi.org/download/r6/osgi.cmpn-6.0.0.pdf

7. https://osgi.org/download/r6/osgi.cmpn-6.0.0.pdf

An independent deployment of services is possible but also laborious since interface code and service implementation have to be contained in different bundles. This model allows only changes to the implementation. Modifications of the interface code are more complex. In such a case the bundles using a service have to be restarted because they have to reload the interface.

In reality OSGi systems are often completely reinstalled for these reasons instead of modifying individual bundles. An Eclipse update, for instance, often entails a restart. A complete reinstallation also facilitates the reproduction of the environment. When an OSGi system is dynamically changed, at some point it will be in a state that nobody is able to reproduce. However, modifying individual bundles is an essential prerequisite for implementing the nanoservice approach with OSGi. Independent deployment is an essential property of a nanoservice. OSGi compromises this essential property.

However, OSGi does not offer technological freedom: It is based on the JVM and therefore can only be used with Java or JVM-based languages. For example, it is nearly impossible that an OSGi bundle brings along its own database because databases are normally not written in Java. For such cases additional solutions alongside the OSGi infrastructure have to be found.

For some Java technologies an integration with OSGi is difficult since loading Java classes works differently without OSGi. Moreover, many popular Java application servers do not support OSGi for deployed applications so that changing code at runtime is not supported in such environments. The infrastructure has to be specially adapted for OSGi.

Furthermore, the bundles are not fully isolated: When a bundle uses a lot of CPU or causes the JVM to crash, the other bundles in the same JVM will be affected. Failures can occur, for instance, due to a memory leak, which causes more and more memory to be allocated due to an error until the system breaks down. Such errors easily arise due to blunders.

On the other hand, the bundles can locally communicate due to OSGi. Distributed communication is also possible with different protocols. Moreover, the bundles share a JVM, which reduces, for instance, the memory utilization.

Solutions for monitoring are likewise present in the different OSGi implementations.

9. http://www.oracle.com/technetwork/java/javaee/overview/index.html

This section deals with WARs and the deployment model of Java EE application servers. Chapter 13, “Example of a Microservice-Based Architecture,” already described in detail a Java system that does not require an application server. Instead it directly starts a Java application on the Java Virtual Machine (JVM). The application is packaged in a JAR file and contains the entire infrastructure. This deployment is called Fat JAR deployment, because the application, including the entire infrastructure, is contained in one single JAR. The example from Chapter 13 uses Spring Boot, which also supports a number of Java EE APIs such as JAX-RS for REST. Dropwizard¹⁰ also offers such a JAR model. It is actually focused on JAX RS-based REST web services; however, it can also support other applications. Wildfly Swarm¹¹ is a variant of the Java EE server Wildfly, which also supports such a deployment model.

10. https://dropwizard.github.io/dropwizard/

11. http://github.com/wildfly-swarm/

However, the separation between WARs is not optimal:

• Memory and CPU are collectively used by all nanoservices. When a nanoservice uses a lot of CPU or memory, this can interfere with other nanoservices. A crash of one nanoservice propagates to all other nanoservices.

• In practice, redeployment of a WAR causes memory leaks if it is not possible to remove the entire application from memory. Therefore, in practice the independent deployment of individual nanoservices is hard to achieve.

• In contrast to OSGi the ClassLoaders of the WARs are completely separate. There is no possibility for accessing the code of other nanoservices.

• Because of the separation of the code, WARs can only communicate via HTTP or REST. Local method calls are not possible.

Since multiple nanoservices share an application server and a JVM, this solution is more efficient than the Fat JAR deployment of individual microservices in their own JVM as described in Chapter 13. The nanoservices use a shared heap and therefore use less memory. However, scaling works only by starting more application servers. Each of the application servers contains all nanoservices. All nanoservices have to be scaled collectively. It is not possible to scale individual nanoservices.

The technology choice is restricted to JVM technologies. Besides all technologies are excluded that do not work with the servlet model, such as Vert.x (section 14.6) or Play.

12. http://jaxenter.com/java-application-servers-dead-1-111928.html

13. https://github.com/ewolff/war-demo

A customer can use the UI of the nanoservices from the outside via HTML/HTTP. The code contains only small modifications compared to the solution from Chapter 13. The Netflix libraries have been removed. On the other hand, the application has been extended with support for servlet containers.

15. http://vertx.io/

Listing 14.2 shows a simple Vert.x Verticle, which only returns the incoming messages. The code creates a server. When a client connects to the server, a callback is called, and the server creates a pump. The pump serves to transfer data from a source to a target. In the example source and target are identical.

The application only becomes active when a client connects, and the callback is called. Likewise, the pump only becomes active when new data are available from the client. Such events are processed by the event loop, which calls the Verticles. The Verticles then have to process the events. An event loop is a thread. Usually one event loop is started per CPU core so that the event loops are processed in parallel. An event loop and thus a thread running on a single CPU core can support an arbitrary number of network connections. Events of all connections can be processed in a single event loop. Therefore, Vert.x is also suitable for applications that have to handle a large number of network connections.

Listing 14.2 Simple Java Vert.x Echo Verticle

Click here to view code image

public class EchoServer extends Verticle {

  public void start() {
    vertx.createNetServer().connectHandler(new Handler() {
      public void handle(final NetSocket socket) {
        Pump.createPump(socket, socket).start();
      }
    }).listen(1234);
  }
}

As described Vert.x supports different programming languages. Listing 14.3 shows the same Echo Verticle in JavaScript. The code adheres to JavaScript conventions and uses, for instance, a JavaScript function for callback. Vert.x has a layer for each programming language that adapts the basic functionality in such a way that it seems like a native library for the respective programming language.

Listing 14.3 Simple JavaScript Vert.x Echo Verticle

Click here to view code image

var vertx = require('vertx')

vertx.createNetServer().connectHandler(function(sock) {
  new vertx.Pump(sock, sock).start();
}).listen(1234);

Vert.x modules can contain multiple Verticles in different languages. Verticles and modules can communicate with each other via an event bus. The messages on the event bus use JSON as data format. The event bus can be distributed onto multiple servers. In this manner Vert.x supports distribution and can implement high availability by starting modules on other servers. Besides the Verticles and modules are loosely coupled since they only exchange messages. Vert.x also offers support for other messaging systems and can also communicate with HTTP and REST. Therefore, it is relatively easy to integrate Vert.x systems into microservice-based systems.

Modules can be individually deployed and also removed again. Since the modules communicate with each other via events, modules can easily be replaced by new modules at runtime. They only have to process the same messages. A module can implement a nanoservice. Modules can be started in new nodes so that the failure of a JVM can be compensated.

Vert.x also supports Fat JARs where the application brings all necessary libraries along. This is useful for microservices since this means that the application brings all dependencies along and is easier to deploy. For nanoservices this approach is not so useful because the approach consumes too many resources—deploying multiple Vert.x modules in one JVM is a better option for nanoservices.

19. http://www.erlang.org/

Erlang’s strengths are, first of all, its resilience against failures and the possibility to let systems run for years. This is only possible via dynamic software updates. At the same time, Erlang has a lightweight concept for parallelism. Erlang uses the concept of processes for parallel computing. These processes are not related to operating system processes and are even more lightweight than operating system threads. In an Erlang system millions of processes can run that are all isolated from each other.

Another factor contributing to the isolation is the asynchronous communication. Processes in an Erlang system communicate with each other via messages. Messages are sent to the mailbox of a process (see Figure 14.3). In one process only one message is processed at a time. This facilitates the handling of parallelism: there is parallel execution because many messages can be handled at the same time. But each process takes care of only one message at a time. Parallelism is achieved because there are multiple processes. The functional approach of the language, which attempts to get by without a state, fits well to this model. This approach corresponds to the Verticles in Vert.x and their communication via the event bus.

Listing 14.4 shows a simple Erlang server that returns the received message. It is defined in its own module. The module exports the function loop, which does not have any parameters. The function receives a message Msg from a node From and then returns the same message to this node. The operator “!” serves for sending the message. Afterwards the function is called again and waits for the next message. Exactly the same code can also be used for being called by another computer via the network. Local messages and messages via the network are processed by the same mechanisms.

Listing 14.4 An Erlang Echo Server

module(server).
-export([loop/0]).
loop() ->
    receive
      {From, Msg} ->
        From ! Msg,
        loop()
end.

Due to the sending of messages, Erlang systems are especially robust. Erlang makes use of “Let It Crash.” An individual process is just restarted when problems occur. This is the responsibility of the supervisor, a process that is specifically dedicated to monitoring other processes and restarting them if necessary. The supervisor itself is also monitored and restarted in case of problems. This way a tree is created in Erlang that in the end prepares the system in case processes should fail (see Figure 14.4).

Since the Erlang process model is so lightweight, restarting a process is done rapidly. When the state is stored in other components, there will also be no information loss. The remainder of the system is not affected by the failure of the process: As the communication is asynchronous, the other processes can handle the higher latency caused by the restart. In practice this approach has proven very reliable. Erlang systems are very robust and still easy to develop.

This approach is based on the actor model:²⁰ Actors communicate with each other via asynchronous messages. As a response they can themselves send messages, start new actors, or change their behavior for the next messages. Erlang’s processes correspond to actors.

20. http://en.wikipedia.org/wiki/Actor_model

In addition, there are easy possibilities to monitor Erlang systems. Erlang itself has built-in functions that can monitor memory utilization or the state of the mailboxes. OTP offers for this purpose the operations and maintenance support (OAM), which can, for instance, also be integrated into SNMP systems.

Since Erlang solves typical problems arising upon the implementation of micro-services like resilience, it supports the implementation of microservices²¹ quite well. In that case a microservice is a system written in Erlang that internally consists of multiple processes.

21. https://www.innoq.com/en/talks/2015/01/talk-microservices-erlang-otp/

However, the services can also get smaller; each process in an Erlang system could be considered as a nanoservice. It can be deployed independently of the others, even during runtime. Furthermore, Erlang supports operating system processes. In that case they are also integrated into the supervisor hierarchy and restarted in case of a breakdown. This means that any operating system process written in any language might become a part of an Erlang system and its architecture.

Finally, even processes in other languages can be added to an Erlang system. For this purpose, an operating system process that can be implemented in an arbitrary language is put under the control of Erlang. The operating system process can, for instance, be safeguarded by “Let It Crash.” This enables integration of practically all technologies into Erlang—even if they run in a separate process.

On the other hand, Erlang is not very common. The consequent functional approach also needs getting used to. Finally, the Erlang syntax is not very intuitive for many developers.

27. http://senecajs.org/

Seneca introduces a mechanism in Node.js that enables processing of commands. Patterns of commands are defined that cause certain code to be executed.

Communicating via such commands is also easy to do via the network. Listing 14.5 shows a server that calls seneca.add(). Thereby a new pattern and code for handling events with this pattern are defined. To the command with the component cmd: "echo" a function reacts. It reads out the value from the command and puts it into the value parameter of the function callback. Then the function callback is called. With seneca.listen() the server is started and listens to commands from the network.

Listing 14.5 Seneca Server

Click here to view code image

var seneca = require("seneca")()

seneca.add( {cmd: "echo"}, function(args,callback){
    callback(null,{value:args.value})
})

seneca.listen()

The client in Listing 14.6 sends all commands that cannot be processed locally via the network to the server. seneca.client(). seneca.act() creates the commands that are sent to the server. It contains cmd: "echo"—therefore the function of the server in Listing 14.5 is called. "echo this" is used as the value. The server returns this string to the function that was passed in as a callback—and in this way it is finally printed on the console. The example code can be found on GitHub.²⁸

28. https://github.com/ewolff/seneca-example/

Listing 14.6 Seneca Client

Click here to view code image

var seneca=require("seneca")()

seneca.client()

seneca.act('cmd: "echo",value:"echo this", function(err,result){
    console.log( result.value )
})

Therefore, it is very easy to implement a distributed system with Seneca. However, the services do not use a standard protocol like REST for communicating. Nevertheless, REST systems also can be implemented with Seneca. Besides the Seneca protocol is based on JSON and therefore can also be used by other languages.

A nanoservice can be a function that reacts with Seneca to calls from the network—and therefore it can be very small. As already described, a Node.js system as implemented with Seneca is fragile when a function blocks the event loop. Therefore, the isolation is not very good.

For the monitoring of a Seneca application there is an admin console that at least offers a simple monitoring. However, in each case it is only available for one Node.js process. Monitoring across all servers has to be achieved by different means.

An independent deployment of a single Seneca function is only possible if there is a single Node.js process for the Seneca function. This represents a profound limitation for independent deployment since the expenditure of a Node.js process is hardly acceptable for a single JavaScript function. In addition, it is not easy to integrate other technologies into a Seneca system. In the end the entire Seneca system has to be implemented in JavaScript.

An overview of the advantages and disadvantages of different technologies in regard to nanoservices is provided in Table 14.1. Erlang is the most interesting technology since it also enables the integration of other technologies and is able to isolate the individual nanoservices quite well from each other so that a problem in one nanoservice will not trigger the failure of the other services. In addition, Erlang has been the basis of many important systems for a long time already so that the technology as such has proven its reliability beyond doubt.

Seneca follows a similar approach, but cannot compete with other technologies in terms of isolation and the integration of other technologies than JavaScript. Vert.x has a similar approach on the JVM and supports numerous languages. However, it does not isolate nanoservices as well as Erlang. Java EE does not allow for communication without a network, and individual deployment is difficult in Java EE. In practice memory leaks occur frequently during the deployment of WARs. Therefore, during a deployment the application server is usually restarted to avoid memory leaks. Then all nanoservices are unavailable for some time. Therefore, a nanoservice cannot be deployed without influencing the other nanoservices. OSGi enables the shared use of code between nanoservices, in contrast to Java EE. In addition, OSGi uses method calls for communication between services and not commands or messages like Erlang and Seneca. Commands or messages have the advantage of being more flexible. Parts of a message that a certain service does not understand are not a problem; they can just be ignored.

Amazon Lambda is especially interesting since it is integrated into the Amazon ecosystem. This makes handling the infrastructure very easy. The infrastructure can be a challenging problem in case of small nanoservices because so many more environments are needed due to the high number of services. With Amazon a database server is only an API call or a click away—alternatively, an API can be used to store data instead of a server. Servers become invisible for storing data—and this is also the case with Amazon Lambda for executing code. There is no infrastructure for an individual service but only code that is executed and can be used by other services. Because of the prepared infrastructure monitoring is also no challenge anymore.

• Nanoservices require efficient infrastructures that can handle a large number of small nanoservices.