Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

• It is an architecture • 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 • It’s a choice • It’s not the only one • Commitment is key 5 WHAT

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

• 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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

• 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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

• 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

Slide 17

Slide 17 text

• 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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

• 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

Slide 20

Slide 20 text

And finally…. 20

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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