The document outlines essential insights about adopting microservices architecture, emphasizing its benefits such as loose coupling, separation of concerns, and resilience through independently deployable components. It contrasts microservices with monolithic architecture, highlighting scalability, fault tolerance, and the importance of well-defined API contracts. Key takeaways include the necessity of investing in automation, design for scale, and managing the complexity of infrastructure.

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