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

1. Things I wish I'd known before I started
with Microservices
1
Software Circus - Sept, 2015

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

3. 3
Agenda

4. 4
“Gotta have a
definition,
right?”

5. It is an architecture choice; not a single
design/implementation pattern
Independently deployable software
components (services)
Stateless, loosely coupled, resilient
Communicate via explicit, published APIs
Single responsibility services
Mature and cloud friendly testing and
deployment pipeline
5
WHAT

6. 6

7. Enables....
easier component replacement
a more heterogenous tech stack
greater flexibility
Good fit with Agile development practices
Well-suited to a containerised
infrastructure
7
WHY

8. 8

9. 9
Familiar, simpler to
develop, build &
deploy
Simple to enforce
structure at the code
level
Consequences of design
change (e.g. domain)
are localised
Good as a sacrificial
architecture
WHY
Monoliths
Pros… Cons…
Limited scalability
options
Increased inertia
Technical stack
lock-in
Slower release
cycle

10. 10
Flexible scaling
options
Enables
independence in
development and
deployment
Reduces technology
lock-in
Enforced
modularity
WHY
Microservices
Pros… Cons…
Build/deploy/
execution
infrastructure is
complex (automation
a must)
Getting the domain
(service)
boundaries right
can be difficult
Comms between
components will be
slower (network
latency)

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

12. 1. Identify your domain model
2. Design your API contracts
3. Use tools to document them
12
HOW
4. Communicate them well

13. Use the power of resources
1. Identify relevant resources and focus on
service boundaries
2. Provide adequate representations
3. Use URIs to abstract resource locations
4. (Define a simple uniform interface)
5. Communicate outcome with (pre-existing)
status codes
13
HOW

14. Apply resource oriented design
Externally (obvious e.g. http + JSON)
Internally (less obvious)
14
HOW

15. 15
the developer starter pack
Introducing….

16. Categories of Service components:
16
Orchestration
CRUD
Utilities

17. Decide which application framework(s)
to use
➡ Start with ones that give you the
scaffolding for free, e.g.
✓ Spring Boot (Java)
✓ Flask (Python)
✓ Grape (Ruby)
✓ NodeJS (Javascript)
To Docker or not to Docker
17

18. Consider where to deploy/run your application
➡ Public clouds: provide container management for you
(lock in risk)
➡ Private clouds/data-centres: flexibility to roll
your own (more effort)
Refine your build/deploy toolchain
Automate:
➡ VM provisioning (Terraform)
➡ Configuration Management (Ansible, Salt...)
➡ External Configuration (Spring Cloud, Consul...)
➡ Service Discovery (Zookeeper, Consul...)
18

19. 19
What does a good microservice look like?

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

21. 21

22. 1. Treat contract design and communication as
first-class activities
2. Design for scale: infrastructure, teams,
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
(upfront!)
22
Final takeaways

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

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

25. • 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
25
HOW

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

27. • 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
27
HOW

28. • 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
28
HOW