[Theory] Software craftsmanship Part 2 - Microservices

Part 1 - Parallel vs united sequential vision
Part 2 - Microservices
Part 3 - Deployment pipeline
----------------------------

In the previous post I wrote about the importance of small independent projects. 

The most important rules for building micro or nano services are:

1) The service should be autonomous.
The service and the small team should follow the idea of Bounded Context. Some examples: Email sending, SMS sending, Logging, Order service, Best buy suggestion, Products review, Search, Login and registration.

2) The service should be independently deployable.

The team should be able to deploy its service whenever it is desired.The compatibility can be supported with the ideas that were discussed in the previous part. 

If, for example, email sending team decides to work with some logging library version 1.2.5, while others use fancy v.1.6.0, then they must go with their choice (v.1.2.5), even if it is a product of their own company. The team is responsible for fixing bugs and makes reasonable decisions, logging package v.1.6.0 might not be properly tested or has undesirable behaviour. 

Creating a microservice with some HTTP RPC API usually does not rise many questions. The different picture is with GUI.

UI monolith that calls some HTTP API endpoints breaks the second law. The idea about a team being able to deploy its service independently from others means that the service should contain everything it needs for properly functionality, including UI controls if it is required:

The website shell should be able to collect independent services from some registry. Notice that autonomy also means that each team should be able to apply different technologies for their services, even different UI technologies (React, Angular, Vue.js, pure HTML, bootstrap, jquery, pure js). Of course it is likely that UI will be done in one technology stack, nevertheless such possibility should exist. The same is true for other technologies (data storage type, runtime and programming language).

A new question appears: how is it possible to control such a mess of technologies? Plus companies need consistent design.

Contradiction
As a team we want to have consistent design across the website.

As a team we want freely modify different parts of the website.

One solution is to separate service and not combine them at all.

Solution (1)

Give each service its own microsite.

Take a look at bbc.co.uk, in addition to the main "news" site there are many sub sites: weather, education, radio, TV and others. Each sub site has its own design, purpose and can be implemented with its own technology stack and its own team.

Solution (2)

Create the UI shell service that will dynamically collect different UI parts from the services.

Today this is scarcely done, however there are some attempts:
1) Scout 24 and Thoughtworks blog post and video
2) Zalando blog post and video
3) Amazon website itself

And what is about design?
Follow strict guide rules for design, share common styles.

An excellent example of such implementation is Building a Visual Language at Aribnb.
Designers specified common guides for sizes, colours and forms. Besides, their teams reuse common blocks across different types of applications. Headers, subheaders and rows have a consistent style in the website, mobile applications and emails.