Microserviceswithout the hype

Definition of Microservices

• SOA without the vendors

• + Lessons learned after 10+ years:

– REST >> SOAP

– Simplicity

– Higher granularity -> Micro

SOA Principles – Still valid

• High decoupling:– Service has its own lifecycle

• Allows releasing often with fewer changes with lower risk

• Rolling upgrades

• Canaries

– Isolation• Communication through well defined interfaces, usually

remote

• Share nothing, service owns its persistence schema

– Stateless• Clients maintain state for the flow

SOA Principles - Lessons Learned

• SOAP model is too rigid, REST is extensible

• Clients everywhere: HTML, devices, M2M, IoT

• Backwards compatibility is a must, usually we do not own clients

• Design the interface upfront, aim for consensus with client developers if feasible

• Refactor or rebuild the service, the smaller the service the cheaper to refactor/rebuild. Just keep the interfaces untouched

SOA Principles - Lessons Learned II• Resource versioning when backwards compatibility is not possible,

adds lots of complexity, code forking• HTTP as standard: Load Balancers, Proxies, Firewalls. Still more

communication mechanisms are required, mostly intra-dc: Kafka, RabbitMQ, Akka cluster, etc

• Remote interfaces promote better isolation than local interfaces.• Enhances team autonomy, easier to experiment new technologies

in smaller services that can be rewritten if necessary. REST interfaces are quite agnostic of implementation technology

• Strong Functional and Regression Testing – more exposed interfaces mean that more effort is required to assess the services data and behavior is correct

• Integration tests are costly – lots of integration points to test, system is complex so having a working integration environment is difficult and costly.

Micro, nano or pico??

• Service granularity depends on several factors:

– Organizational: Conway’s Law

– Latency: The more granular, the more latency we add, more so in the high percentiles

– Release policy

– Integration testing

Risks and caveats• Services too small:

– Risk of becoming orphaned, no team maintaining it– Chattiness, client needs to talk to multiple services for a given

functionality

• Too coarse:– more changes in each release– More difficult to refactor

• Backwards compatibility is expensive• Somewhat chaotic systems and organization, difficult to have the

whole picture, less standarized and more distributed• Complex systems design as everything is distributed• Complex debugging as a transaction usually flows through several

services

Related Topics• Continuous Delivery – Microservices are deployed often, CD

is almost a requirement to deploy as often as microservicesrequire

• Chaos Monkey – Resilience importance is more relevant because of the number of components involved in a flow/transaction

• Eventual consistency – CAP is usually balanced towards AP, availability and partition tolerance are more important than immediate consistency

• Immutable deployments – new containers are created that package the new version, traffic is progressively directed to this newly created cluster. Rollback is trivial

• Service discovery – configuration is difficult, many integration configuration points difficult to operate manually