Things I wish I'd known before I started with Microservices GOTO - - PowerPoint PPT Presentation

things i wish i d known before i started with
SMART_READER_LITE
LIVE PREVIEW

Things I wish I'd known before I started with Microservices GOTO - - PowerPoint PPT Presentation

Things I wish I'd known before I started with Microservices GOTO Amsterdam - June 18, 2015 1 Who are we? Steve Judd - Lead Consultant Tareq Abedrabbo - CTO OpenCredo - an Open Source software consultancy 2 Agenda Things I wish I'd known


slide-1
SLIDE 1

Things I wish I'd known before I started with Microservices

1

GOTO Amsterdam - June 18, 2015

slide-2
SLIDE 2

Who are we?

2

Steve Judd - Lead Consultant Tareq Abedrabbo - CTO OpenCredo - an Open Source software consultancy

slide-3
SLIDE 3

Things I wish I'd known before I started with Microservices

What? Why? How?

3

Agenda

slide-4
SLIDE 4

What’s the story morning glory?

4

“Gotta have a definition, right?”

slide-5
SLIDE 5
  • 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

So, what’s the big deal?

6

Go on, convince me….

slide-7
SLIDE 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

slide-8
SLIDE 8

8

And are Microservices really the new black?

Monoliths: friend or foe?

slide-9
SLIDE 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

slide-10
SLIDE 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

slide-11
SLIDE 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

slide-12
SLIDE 12

The importance of contracts

12

“Until the contract is agreed, nothing is real”

slide-13
SLIDE 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

slide-14
SLIDE 14
  • 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

Does size matter?

15

Provide as many APIs and Services as you need but no more

slide-16
SLIDE 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

slide-17
SLIDE 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

slide-18
SLIDE 18

Separating the men from the boys

18

What does a good microservice look like?

slide-19
SLIDE 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

slide-20
SLIDE 20

And finally….

20

slide-21
SLIDE 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

slide-22
SLIDE 22

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