Lessons learnt from designing and developing with a Microservices Architecture - a talk I presented at GOTO Amsterdam 2015

1. Things I wish I'd known before I started
with Microservices
1
GOTO Amsterdam - June 18, 2015

2. Who are we?
2
Steve Judd - Lead Consultant
Tareq Abedrabbo - CTO
OpenCredo - an Open Source software consultancy

3. Things I wish I'd known before I started with
Microservices
What?
Why?
How?
3
Agenda

4. What’s the story morning glory?
4
“Gotta have a definition, right?”

5. • It is an architecture choice, not a design pattern
• Independently deployable software components
(services)
• Stateless, loosely coupled, resilient
• Communicate via explicit, published APIs
• Each service fulfils a single business capability
• Automated testing and deployment is essential
5
WHAT

6. So, what’s the big deal?
6
Go on, convince me….

7. • Encourages:
★ loose-coupling
★ separation of concerns
★ single responsibility principle
★ domain-driven design
• Good fit with Agile development practices
• Well-suited to a containerised infrastructure
7
WHY

8. 8
And are Microservices really the new black?
Monoliths: friend or foe?

9. 9
Monoliths
• Familiar & well-
understood
• Easy to develop, build &
deploy
• Consequences of
changing domain design
are localised
• Limited scaling choices
• Long-term commitment to
tech stack (technology
lock-in)
Microservices
• Flexible scaling options
• Enables independence in
development and
deployment
• Reduces technology lock-in
• Better fault tolerance
• Build/deploy/execution
infrastructure is complex
(automation a must)
• Getting the domain (service)
boundaries right can be
difficult
WHY

10. 10
Monoliths
• Familiar & well-
understood
• Easy to develop, build &
deploy
• Consequences of
changing domain design
are localised
• Limited scaling choices
• Long-term commitment to
tech stack (technology
lock-in)
Microservices
• Flexible scaling options
• Enables independence in
development and
deployment
• Reduces technology lock-in
• Better fault tolerance
• Build/deploy/execution
infrastructure is complex
(automation a must)
• Getting the domain (service)
boundaries right can be
difficult
WHY

11. 11
Monoliths
• Familiar & well-
understood
• Easy to develop, build &
deploy
• Consequences of
changing domain design
are localised
• Limited scaling choices
• Long-term commitment to
tech stack (technology
lock-in)
Microservices
• Flexible scaling options
• Enables independence in
development and
deployment
• Reduces technology lock-in
• Better fault tolerance
• Build/deploy/execution
infrastructure is complex
(automation a must)
• Getting the domain (service)
boundaries right can be
difficult
WHY

12. The importance of contracts
12
“Until the contract is agreed, nothing is real”

13. • Design your API contracts first
• Communicate them well
• Use tools to document them, e.g
• apidocjs (http://apidocjs.com/)
• swagger (http://swagger.io)
• spring-restdocs (https://github.com/spring-projects/spring-restdocs)
• Be mindful of the impact of changing an API
13
HOW

14. • If you don’t specify your contract, you end up with an
implicit one anyway
• Use the power of resources (HTTP and REST)
• Location
• Uniform interface
• Status codes
• Representations
14
HOW

15. Does size matter?
15
Provide as many APIs and Services as you need but no more

16. • Size - what really matters is quality not quantity
• Services should be decoupled conceptually so that
they can evolve independently
• Services should be decoupled technically so that they
can be managed independently
• What do I do, practically?
• Co-locate services, but avoid implicit dependancies
though shared common objects
• Separate services but avoid sharing (domain) libraries
16
HOW

17. • Don’t stress about how many APIs or Services
• Do stress about designing an appropriate domain models
for your services
• Don’t separate your services based on technical
boundaries
• Do separate your services based on self-contained
functions
17
HOW

18. Separating the men from the boys
18
What does a good microservice look like?

19. • Logging & monitoring
✤ Centralised collection
✤ Many more moving parts
• How the services are managed
• External configuration
• Handling failure
• Inter-process communication
✤ Message serialisation/deserialisation
✤ Network overhead
19
HOW

20. And finally….
20

21. 1. Specify your contracts first AND communicate them
2. Design for scale: infrastructure, processes, services
3. You’ll need to pay the Distributed Service Tax
4. Everything is a Service (aka eat your own dogfood)
5. Invest in tooling and automation
21
Final takeaways

22. Thank you, any questions?
http://www.opencredo.com/blog
@OpenCredo
@cyberbliss
@tareq_abedrabbo

23. Environmental concerns
23
“Infrastructure is much more important than
architecture”

24. • Allowing more than one service direct access to the same
database
• Delaying or ignoring the introduction of good DevOps
practices
• Infrastructure management of instances and containers is
a challenge
• Performance
24
HOW