Beauty of #microservices: part 2 architecting for change

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

See the part 1 “Beauty of #microservices: part 1 #entarch #apparch” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-1-entarch.html for the definition of the following terms: business process, orchestration, microservice or Autonomous Component (AC), and microservice architecture.

2 Review of two recent posts

Several articles about changeability of microservices-based solutions.

2.1 “Rotem Hermon on Change Driven Design” http://effectivesoftwaredesign.com/2015/05/12/rotem-hermon-on-change-driven-design/

START quote

In particular I like very much Rotem’s definition of the four principles of Change Driven Design:

1. Areas of change should be contained.

2. Things that are more likely to change should be easier to change.

3. Things that are less likely to change should not depend on things that are likely to change.

4. Change should entail extending the system rather than refactoring.

END quote

RE item 2: Many types of changes must be anticipated in the architecture and thus they are easy to do. Other changes must be possible. For example, [REF1] states that business-process-centric solutions have several types of artefacts: event, business-process, rule, role, activity, data, document, audit trail, and KPI. Their changes are anticipated and these artefacts are structured as shown below.

All artefacts are available as microservices – see below (only 4 lower layers are shown).

Techniques for composition of microservices: DSL (BPMN, DMN), interpretive general languages (Groovy), compiled generic languages (Java). Off-The-Shelf (OTS) microservices can be used as necessary, e.g. business process engine for BPMN.

RE item 4: Technical changes should be fused with business changes in accordance with the PDCA cycle.
  • [Plan] measure how the work is done,
  • [Plan] observe the business environment,
  • [Plan] decide in what areas the solution should advance,
  • [Do] implement the decisions taken,
  • [Check] validate the effect of those decisions, and
  • [Act] refactor some microservices to adopt internally the improvements.

2.2 Microservices – Sharpening the Focus https://genehughson.wordpress.com/2015/05/18/microservices-sharpening-the-focus/

RE “In short, the application architectural style known as microservice architecture (MSA), is unlikely to be an appropriate choice for the early stages of an application.”

On the contrary, at the early stages of solution elaboration as a functional prototype, a high rate of changes is mandatory thus microservices-based solutions offer a huge gain in development time.

RE “The moral of the story, at least in my opinion, is that intentional design concentrating on separation of concerns, loose coupling, and high cohesion is beneficial from the very start. Vertical (functional) slices, perhaps combined with layers (what I call “dicing”), can be used to achieve these ends. ”

Yes and [REF1] offers slicing and dicing out-of-the-box – vertical separation by business processes and horizontal layers as shown in illustrated above.



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