Beauty of #microservices: part 1 #entarch #apparch

1 Introduction

This blogpost is inspired by several blogposts about microservices and it is based on the blogpost REF1 “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html which uses other blogposts about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

As usual, some terminology must be clarified.

2 Terminology

2.1 Process

Many articles about microservices mentioned “process”. I believe they mean “computing process” (e.g. an instance of JVM) which should not be confused with “business process”.

2.2 Orchestration

Another confusing term is “orchestration”. In some articles, it means “container orchestration layer” which allows one to specify how the microservices are handled in fault tolerant and in scaling up and scaling down.

O’Reilly book “Migrating to Cloud-Native Application Architectures” (http://pivotal.io/platform-as-a-service/migrating-to-cloud-native-application-architectures-ebook ) says “The ESB becomes the owner of all routing, transformation, policy, security, and other decisions governing the interaction between services. We call this orchestration, analogous to the conductor who determines the course of the music performed by an orchestra during its performance. ESBs and orchestration make for very simple and pleasing architecture diagrams, but their simplicity is deceiving. Often hiding within the ESB is a tangled web of complexity.” I think, this is a wrong analogy. The conductor delivers only one symphony at a time. ESB delivers many symphonies at the same time. Not surprising that it such “centralised orchestration” is difficult.

In other articles, it means one of two BPMN ways to compose business processes – orchestration as a strong coordination and choreography as weak coordination. This orchestration is a domain bounded because it is carried out in the scope of a particular business process.

2.3 Microservice or Autonomous Component (AC)

Microservice is a unit of functionality which is

• explicitly-defined for a potential consumer how to use it (yes, there is a formal contract)
• universally-accessible for its consumers via standard protocols (not just REST)

In addition, microservices are:

• design-interdependent (design-time dependency in accordance with the overall design of a software-intensive solution)
• operationally-independent (i.e. unavailability of a particular microservice may be compensated without total unavailability of the whole solution)
• contractually-dependent (run-time dependency in accordance with the formal contract)

“Unit-of-functionality” means Single Responsibility Principle (SRP). Thus a microservice with a greater and single responsibility may be composed from microservices with lesser and single responsibilities.

Obviously, microservices is that old-known services should be.

2.4 Microservice architecture

Microservice architecture (as well as SOA) is an architectural style for constructing software-intensive solutions from a set of universally interconnected and interdependent services/microservice.

The artificial separation “SOA is for integration between applications” and “microservice architecture is for applications” has no sense anymore because the integration between two “microserviced” applications is the same as integration between microservices within each of “microserviced” application.

3 Review of some posts

Several articles about (mainly negative) about applicability of microservices.

3.1 “Microservices” https://www.linkedin.com/pulse/microservices-matthew-kern-msea-cea-pmp-itil-cissp-issap

START quote

Here are a few reasons the microservices approach is a bad idea:

1. As mentioned above, web services have large overhead and making the invoked service smaller increases that overhead.

2. Increasing the number of service dependencies runs counter to the reliability equation and hard physics. Availability may suffer.

3. Regression testing of such a distributed system with additional parts can increase complexity and time.

4. Web services can be difficult to secure. Additional overhead may be piled on to secure these many services.

5. Additional interfaces to manage means additional governance and work for those not coding.

END quote

RE item 1: Each time people talk about performance of a system to be designed I remember a quote from Prof. Donald Knuth: “Premature optimization is the root of all evil (or at least most of it) in programming.” See a related discussion in https://genehughson.wordpress.com/2015/01/30/microservice-mistakes-complexity-as-a-service/ and https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/

RE item 2: On the contrary, a proper use of microservices makes error-handling explicit and scalability is in the design – see REF1.

RE item 3: Because the context for each microservice is well defined then testing is an integral part of the design.

RE item 4: See REF1 how the security problem can be addressed.

RE item 5: interface must be crafted in any case – either for components of a monolith or components of a distributed system.

3.2 "Microservices: a real world story" http://watirmelon.com/2015/05/14/microservices-a-real-world-story/

A very good article showing that the current “microservice architecture” is a bit weak to be considered as a real architecture (thus provide a solid based for industrial delivery of software-intensive solutions).

Of course, it is very difficult to maintain an application with a rather weak architecture. Just a few points.

1. Structure is necessary instead of a flat microservice-to-microservice topology. It helps to testing, integrity and reducing the level of complexity.
2. Strongly and statically typed language is preferable for interfaces, i.e. between microservices. Weak and dynamic type language is OK within microservices.
3. Monitoring and testing may merge: testing becomes on-going, and monitoring becomes more functional.
4. Real architecture must enable quick deployments of new versions of solutions.

3.3 "MicroservicePremium" http://martinfowler.com/bliki/MicroservicePremium.html

RE “So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.”

This is yet another confirmation that the current “microservice architecture” is a bit weak to be considered as a real architecture. There are two viewpoints: a) external service provider viewpoint who is engaged for a well-defined scope and b) enterprise-wide viewpoint for considering software-intensive systems within an enterprise TOGETHER. The different between them is like seeing the trees or the forest.

Obviously, some initial efforts are necessary to establish microservice-centric environment and practices. These efforts will pay-off after several applications.

In addition, each subsequent solution is cheaper because it reuses the same tools, the same services, the same architecture.

3.4 "Making Architecture Work in Microservice Organizations" http://tech.gilt.com/post/102628539834/making-architecture-work-in-microservice

An excellent example of bring an enterprise-wide apparch approach to an enterprise.

See also “Enterprise patterns: Platform-Enabled Agile Solutions (PEAS)” http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html and http://improving-bpm-systems.blogspot.ch/search/label/PEAS


Thanks,
AS