An Introduction to Microservices

An Introduction to Microservices

Ad van der Veer [email protected]

About me

Actually a ‘Strategic Product Designer’

About me

But spend the other 50% on programming backend services

About me

But most importantly: my Graduation Project at the Delft University of Technology

Contents

Microservices: • What is it? • Why should you use it? • Why shouldn’t you use it? • How should you use it? • What’s next?

So, what the Freck is it?

Our Example: Magento ( 8,511,815 lines of code )

Breaking it up

Small? Logical?

“Write services that do one thing and do it well. Write services to work together. Write services to handle RESTful http, because that is a universal interface.”

Small? Logical?

“For us, a service is micro if we can rewrite it in 2 weeks or less”

Breaking up Magento

System

Products

Customers

EAV

Sales

Get /products/21 POST /transactions

How is this different from SOA?

- Less specs (WS-*) - Focus on being small - Fit with Agile - JSON > XML - ??

Why should you use it? (The 5 most popular PRO’s)

1. The Right Tool for the Job

System

Products

Customers

EAV

Sales

Get /products/21 POST /transactions

2. Division of Labor(before)

2. Division of Labor (after)

Get /products/21 POST /transactions

3. Cognitive Scaling (before)

3. Cognitive Scaling (after)

Get /products/21 POST /transactions

4. Limited blast radius

4. Limited blast radius

Get /products/21 POST /transactions

5. Defer Decisions

System

Products

Customers Analytics

?

Sales

Get /count

Why shouldn’t you use it? (The 5 most popular CON’s)

1. DevOps Mentality is a Must

Get /products/21 POST /transactions

2. Complexity movement

Get /products/21 POST /transactions

3. Polyglot and Shared libraries

System

Products

Customers Sales

Get /products/21 POST /transactions

4. (Integration) Testing

Sytem

Products

Sales

5. interface Management

Products

How should you use it?

‘Separation of Concerns’

At the process level: - Instances: services - interfaces: RESTful

endpoints

API Gateway

Products

Customers Sales

API Gateway: Authentication&Routing

System

HTTP (REST)

Products

Customers Sales

API Gateway: Authentication&Routing

HTTP

HTTP

HTTP

HTTP

System

Message Queue (MQ)

Products

Customers Sales

API Gateway: Authentication&Routing

HTTP

HTTP

HTTP

HTTP

HTTP HTTP

System

How to Transitioning from A Monolith?

Piece by piece: “Whenever a big new feature change came along, we asked ourselves? Can we split this into a seperate microservice?”

Sales

HTTP

Tools and Technologies (step by step)

Step1 : Write something Tools& Techs: - JAVA - Go - .Net - Node.js … Standard(s)?: Simple to run (separate) processes

Step 2: Test it Tools& Techs: - REST Clients (Paw, Postman) - Language specific

test/mock frameworks

Standard(s)?: Ad hoc testing

Step 3: Commit it Tools& Techs: - GitHub - BitBucket - Launchpad - In-house hosting Standard(s)?: Support many repo’s, easy to use (GitHub?)

Step 4: Encapsulate it Tools& Techs: - Docker - (platform specific

process encapsulation)

Standard(s): Docker

Step 5: Wire it up

Tools& Techs: - Docker based:

- (google) Kubernetes - (openshift) GearD - (spotify) Helios - Many more…

- DNS service disco - Immutable:

- Terraform & Packer Standard(s): None, very much in flux, also check: http://www.mindmeister.com/389671722/docker-ecosystem

Step 6: Keeping Track Tools& Techs: - ELK stack - Nagios - Statsd/Graphite - … Standard(s): Whatever your company is comfortable with and has support for your poly glot env

And check out..

What’s Next?

1: Docker will lead development

2: Cloud providers will create convenient services (e.i lock-ins)

3: Development tools are needed for (contract) testing and isolation

Products

Customers Sales

API Gateway: Authentication&Routing

HTTP

HTTP

HTTP

HTTP

HTTP HTTP

System

Thank you! please check out: