Demistifying micro services as evolution of SOA

1. Microservices
without the hype

2. Definition of Microservices
• SOA without the vendors
• + Lessons learned after 10+ years:
– REST >> SOAP
– Simplicity
– Higher granularity -> Micro

3. 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

4. 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

5. 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.

6. 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

7. 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

8. Related Topics
• Continuous Delivery – Microservices are deployed often, CD
is almost a requirement to deploy as often as microservices
require
• 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