Japan
Germany
Ideal granularity to enable agility and reuse
Microservices typically run in individual processes, giving them an ideal level of granularity: neither too small nor too big. Typically, each Microservice implements a single business function, which ensures that the interfaces remain simple (typically one or a few inputs and a similar number of outputs). Because of their simple, often data-format-driven interfaces, Microservices can be rapidly and efficiently "rewired", allowing developers to prototype multiple scenarios of a solution very rapidly. Such agility is impossible to achieve with monolithc application development techniques and difficult even with classic SOA approaches. Combined with a platform that allows dynamic deployment, Microservices can be deployed as 'agents' at runtime to remote machines across cloud and hybrid environments; Solution composition can thus be performed on a single machine, while the Microservices in the composed assembly are deployed on demand across the cloud or enterprise as required at runtime, leading to the ultimate deployment agility.
Easy, unbounded Scalability
Since each Microservice typically runs in its own process and is stateless (in the sense that there is no centralized state-manager in a well-implemented Microservices Plarform), it can be scaled and managed independently of other Microservices in an assembly. For instance, if a given Microservice participating in an application is performing poorly, it is possible to redeploy it by simply moving it to a more powerful hardware platform. The redeployment does not affect other Microservices sending messages to (or receiving messages from) the Microservice being scaled. Multiple concurrently running copies of a single Microservice can be created and deployed easily across the enterprise network or cloud, allowing performance to be scaled linearly by distributing incoming messages across multiple instances of the Microservice as required.
Independent Teams for Service Development and Application Assembly
In the Microservices approach, Service-development is separated from Application Assembly. Further each Microservice (or set of Microservices relevant to a particular business domain) is typically developed by an independent team, where each team has all the required expertise (including core domain knowledge, user-interface development skills, etc.). Once developed and tested, the Microservices are typically published to a 'registry' on the Microservices Platform. Instances of multiple services can then be used to create application assemblies to accomplish a given business task. This independence and separation of development, both of the Microservices themselves and later of the application assembly, enables further agility and better quality in the creation of end-user business solutions. Unlike Monolithic systems, applications are not developed ground-up in the Microservices approach; rather, they are assembled from previous built and tested Microservices.
Multi-language Development for added Flexibility
Each Microservice can be developed in any programming language, allowing true multi-language, multi-platform flexibility in application deployment. For instance, a single application assembly can be composed using Microservices written in Java, C, C++ and C# and JavaScript, since each Microservice can be written in any programming language chosen by the developer(s) of the Microservice. This level of flexibility is again in stark contrast with existing Monolithic application development techniques, where systems are typically tightly coupled and typically developed in a single, chosen programming language.
Easier testing and deployment across multiple Environments
Since each Microservice is designed, built and tested in an independent team responsible for ensuring both the correctness and quality of the developed Service, the Application developer assembling multiple Microservices to solve a business problem has a relatively stronger degree of confidence in the individual components of his/her solution in comparison with the monolithic approach. For each Microservice, it is possible to set 'profiles' for multiple environments including Development, Test, Staging and Production. To move an entire application assembly from "Development" to "Testing" (or another downstream environment like "Staging" or "Production"), all that the application composer needs to do is choose the target environment; the underlying platform then picks up the relevant profiles, applies them to each Microservice in the assembly, and moves the entire assembly to the new environment. This dramatically eased, automated deployment process is again in stark contrast to the monolithic approach, which is typically script-based and error-prone.