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