This document discusses microservices and provides recommendations for developing microservice architectures. It begins by comparing experiences developing large and small systems. Microservices are then defined as independently deployable services that communicate via lightweight mechanisms like HTTP. Examples are provided of companies that pioneered microservices like Amazon and Netflix. The document concludes by recommending developers start small with microservices, focus on principles over specific technologies, and address challenges of distributed systems through monitoring, resilience patterns, and infrastructure support.

1. © Equal Experts UK Ltd 2015 1
Microservices
Scaling Development and Service
by Paulo Gaspar

2. © Equal Experts UK Ltd 2015 2
What are Microservices?

3. © Equal Experts UK Ltd 2015 3
Large(-ish) Systems
• Ever worked on one?
• Which roles did you play?
• How do you rate its…
• Knowledge sharing / communication?
• Pace of progress? New technology adoption?
• Ease of technical debt elimination?
• Accountability (not throwing issues over the wall)?
• Did your team feel they owned the project?

4. © Equal Experts UK Ltd 2015 4
Small Systems
• Ever worked on one?
• Which roles did you play?
• How do you rate its…
• Knowledge sharing / communication?
• Pace of progress? New technology adoption?
• Ease of technical debt elimination?
• Accountability (not throwing issues over the wall)?
• Did your team feel they owned the project?

5. © Equal Experts UK Ltd 2015 5
Fowler Description
§ The microservice architectural style is an approach to developing a single application as
a suite of small services, each running in its own process and communicating with
lightweight mechanisms, often an HTTP resource API. These services are built around
business capabilities and independently deployable by fully automated deployment
machinery. There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use different data storage
technologies.
http://martinfowler.com/articles/microservices.html

6. © Equal Experts UK Ltd 2015 6
MY OWN EXPERIENCE
(A cautionary tale?)

7. © Equal Experts UK Ltd 2015 7
The First Time®!
• Just because of Spring Boot
(and Spring Loaded!)
• We loved deployments!
• Naturally, services were split and kept being split by functionality
• We had different load requirements per service…
• We started everything by hand, with scripts
• We looked at Docker and several tools

8. © Equal Experts UK Ltd 2015 8
2nd, with an experienced team...
First impressions
• Very senior team
• Agile, TDD, Reactive, Scala, Pairing, Q&A, …
• So many services, and they run ok on my machine!
• Infrastructure restrictions on used technologies
• No management interference on technical decisions
• Management SUPPORTS technical issue prioritization!

9. © Equal Experts UK Ltd 2015 9
2nd, with an experienced team...
Second impressions
• Shocking: no Business Logic on Libraries!!!
• Distributed computing like issues
(error propagation, latencies…)
• Internal Open Source

10. © Equal Experts UK Ltd 2015 10
2nd, with an experienced team...
Second impressions
• Something tribal about the developer team, like:
• We would trigger a whole team impromptu meeting if we found a production problem
• And we would do the same to take a structural decision about code we were working on
• Devs would sometime work out of office hours,
but mostly monitoring!
• Devs reported a large part of the production issues
• A lot of importance was given to Devs feedback

11. © Equal Experts UK Ltd 2015 11
2nd, with an experienced team...
Contact with the other teams
• Infrastructure teams would send us people to help us and doctrine us on the hows and
whys of their systems
• We were supported into monitoring our services
• There was an ongoing effort to allow us to deploy our own services

12. © Equal Experts UK Ltd 2015 12
2nd, with an experienced team...
The Big Picture
• Did I tell you there were hundreds of developers on the whole project?
• Was the management behaviour Microservice related?
• Was the development team behaviour Microservice related?
• Was the infrastructure teams behaviour Microservice related?

13. © Equal Experts UK Ltd 2015 13
2nd, with an experienced team...
The Big Picture
Ownership
Accountability
Trust

14. © Equal Experts UK Ltd 2015 14
3rd time is a charm?
• Microservice wise, a less mature customer team
• Moving functionality from a large monolithic system to Microservices
• A colleague’s proposal:
• Before / instead of migrating, just break the old system into Microservices!

15. © Equal Experts UK Ltd 2015 15
WHAT DO OTHERS SAY?

16. © Equal Experts UK Ltd 2015 16
Development Scalability
on large applications
• Steeper learning curve
• Development tools and containers get overloaded
=> slower development
• Larger teams have higher communication costs / problems
• Must rebuild and redeploy everything for any small change
• Any change (functional or technologic) is harder and riskier
• Riskier and expensive changes happen less frequently!

17. © Equal Experts UK Ltd 2015 17
Development Scalability
on Microservices
• Services get developed and deployed independently
• Smaller, simpler code bases
• Easier to learn and faster to develop on
• Less dependency hell
• Faster + simpler build and deployment
• Easier to compose and to replace
• Smaller teams
• Less communication paths, lower communication costs
• Change is simpler and risks more isolated

18. © Equal Experts UK Ltd 2015 18
Is this SOA
• “Traditional SOA” was dominated by vendors and the technologies they promoted
(e.g.: some people thought that SOA had to be done with SOAP)
• Microservices grew from practical needs and concerns, with no vendor/technology ties
• SOA done right?

19. © Equal Experts UK Ltd 2015 19
Historic Big Players
• Amazon
• Amazon Cloud
• Amazon’s Two-Pizza Team Rule
http://blog.idonethis.com/two-pizza-team/
• Netflix
• http://netflix.github.io

20. © Equal Experts UK Ltd 2015 20
When you start
• Start small
• Learn the basics well and ASAP
• Just the essential principles you need for your scale
• …inclusive about REST, if you use it
• …and CQRS (Command Query Responsibility Segregation)
• Don’t be in a hurry to divide services
• Take your time to learn each piece you add
• Lear about the “new” types of error you are exposed to, like:
• Fallacies of distributed computing
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

21. © Equal Experts UK Ltd 2015 21
…remembering the falacies…
• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.

22. © Equal Experts UK Ltd 2015 22
When you start
• Brace for networking related problems
• Latency across a call stack
• Manage timeouts
• Cascading failures
• Circuit breakers, bulkheads, isolation
• Start monitoring
• Collect metrics
• Good logs and a log repository
• Tracing

23. © Equal Experts UK Ltd 2015 23
SOME STUDY REFERENCES…

24. © Equal Experts UK Ltd 2015 24
Reading material
• Building Microservices, by Sam Newman
(O’REILLY)
• http://microservices.io
• Netflix stuff
• http://netflix.github.io
• Distributed computing
(search about these topics)
• CAP Theorem (read the paper)
• Eventual Consistency (read the Dynamo DB paper)
• Idempotency
• Consensus
• Causality

25. © Equal Experts UK Ltd 2015 25
Microservice frameworks
• Dropwizard
http://www.dropwizard.io
• Spring Boot
http://projects.spring.io/spring-boot/
https://github.com/spring-projects/spring-loaded
https://spring.io/blog/2015/06/17/devtools-in-spring-boot-1-3
http://projects.spring.io/spring-hateoas/
• Play Framework
https://www.playframework.com
• Netflix Karyon
https://github.com/Netflix/karyon

26. © Equal Experts UK Ltd 2015 26
Monitoring
• Metrics
https://dropwizard.github.io/metrics/
• Grafana
http://grafana.org
• ELK – ElasticSearch, LogStash, Kibana
https://www.elastic.co/webinars/introduction-elk-stack
• Twitter Zipkin (tracing)
http://twitter.github.io/zipkin/

27. © Equal Experts UK Ltd 2015 27
Basic Resilience
• Netflix stuff
(discovery, client side LB, circuit breakers)
• http://netflix.github.io
• http://cloud.spring.io/spring-cloud-netflix/
• Spring Cloud
• http://cloud.spring.io/

28. © Equal Experts UK Ltd 2015 28
Databases and Datastores
• Service databases
(one instance/schema per service family)
• Separated report database (usually relational)
• Database variants
• Relational, document based, key-value, etc.
• Notable databases / data stores
• MongoDB, PostgreSQL, Redis, ElasticSearch
• http://projects.spring.io/spring-data/

29. © Equal Experts UK Ltd 2015 29
Messaging
• Sophisticated Routing
RabbitMQ
https://www.rabbitmq.com
• High volume
Apache Kafka
http://kafka.apache.org
https://github.com/spring-projects/spring-integration-kafka

30. © Equal Experts UK Ltd 2015 30
Others
• Swagger
(service description)
http://swagger.io
• NGINX
(networking infrastructure)
https://www.nginx.com
• Zookeeper
(consensus, presence, other coordination)
http://zookeeper.apache.org
• Docker
(virtualization)
https://www.docker.com
• DEIS
(Docker based PaaS)
http://deis.io

31. © Equal Experts UK Ltd 2015 31
CI and Delivery + Security
• There is so much to add about these themes!!!

32. © Equal Experts UK Ltd 2015 32
Thank you!