things i wish i'd known before i started with microservices - software circus 2015
TRANSCRIPT
Things I wish I'd known before I started with Microservices
1
Software Circus - Sept, 2015
Who are we?
2
Steve Judd - Lead ConsultantTareq Abedrabbo - CTO
OpenCredo - an Open Source software consultancy
3
Agenda
4
“Gotta have a definition, right?”
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
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
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
MonolithsPros… Cons…
Limited scalability options
Increased inertia
Technical stack lock-in
Slower release cycle
10
Flexible scaling
options
Enables
independence in
development and
deployment
Reduces technology
lock-in
Enforced
modularity
WHY
MicroservicesPros… 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)
The importance of contracts
11
“Until the contract is agreed, nothing is real”
1.Identify your domain model
2.Design your API contracts
3.Use tools to document them
12
HOW
4. Communicate them well
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
Apply resource oriented design
Externally (obvious e.g. http + JSON)
Internally (less obvious)
14
HOW
15
the developer starter pack
Introducing….
Categories of Service components:
16
Orchestration
CRUD
Utilities
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
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
What does a good microservice look like?
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
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
Thank you any questions?
http://www.opencredo.com/blog
@OpenCredo @cyberbliss @tareq_abedrabbo
Environmental concerns
24
“Infrastructure is much more important than architecture”
• 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
Does size matter?
26
Provide as many APIs and Services as you need but no more
• 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
• 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