Microservices, the lean way

transcript

Microservices, the lean wayBruno Bossola (JUG Torino)

AMSTERDAM 11-12 MAY 2016

...now with 100% more llamas!

AMSTERDAM 11-12 MAY 2016

● Developer since 1988● XP Coach 2000+● Co-founder and coordinator of JUG Torino ● Java Champion since 2005● VP of Engineering @Workshare.com

….and microservices addicted since 2013

Hey mate, who are you?

@bbossola

● Why microservices?● What are microservices?● Demo● Common antipatterns● Demo● How do we work with microservices?● Conclusions?

Agenda

@bbossola

● Why microservices?● What are microservices?● Common antipatterns● How do we work with

microservices?

Agenda

@bbossola

Why microservices?

J2EERuby on Rails

Are you living with a monolith?

@bbossola

Why microservices?

J2EERuby on Rails

● your IDE is bloated

@bbossola

Why microservices?

J2EERuby on Rails

● you are locked onto a language

@bbossola

Why microservices?

J2EERuby on Rails

● your tests can take hours to run

@bbossola

Why microservices?

J2EERuby on Rails

● your db migrations are HUGE and

@bbossola

Why microservices?

J2EERuby on Rails

● your db migrations are HUGE and scary

● you always scale EVERYTHING

@bbossola

Why microservices?

J2EERuby on Rails

● you have a single BIG team

@bbossola

Why microservices?

J2EERuby on Rails

● you have a single BIG team

● you are generating HTML pages

(no, well... really?)

@bbossola

● Would not be better if...

Why microservices?

@bbossola

● Would not be better if...– you can use an IDE. Or not :)

– you can choose your favourite programming language

– your integration tests run in minutes

– your db migrations are small and cosy

– you scale independently

– you have small teams, pizza size

– you work on green field projects every time

– you can choose cool technologies

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

– you can fail

Why microservices?

@bbossola

● Why microservices?● What are microservices?● Common antipatterns● How do we work with microservices?

Agenda

@bbossola

● independent (processes) communicating with each other using language-agnostic APIs

● small, highly decoupled and focus on doing a small task● can be written in any programming language

– we do use Ruby, C#. Java and Javascript

● micro means small, very!– we run 20 of them on one single machine

● deployed independently, run independently● each use its own database● each owned by a team

What are microservices?

@bbossola

● Pros!

– highly cohesive, loosely coupled

– clean api contracts and SOC– very easy to write and replace

– self-contained, very easy to deploy

– scaling can be very focused

– small releases, less risky to deploy– separate databases for separate migrations

– enabler to have many small teams● each team is in charge of some of them● QA and OPS can be embedded in the team● CX teams can be built around this!

@bbossola

● Cons!

– Lots of them!– Every microservice is doing one thing, so a lot

of collaboration is required to perform a task– Scaling may require considerable effort

– Frequent duplicated configuration – Proxying for external apps is not easy

– management overhead (more moving parts)

@bbossola

In the meantime, at Workshare...

@bbossola

ROME 18-19 MARCH 2016

All pictures belongto their respective authors

➢ simple WS services (time and location)

➢ complex WS services (groups and folders)

➢ a nodejs live sample that shows some simple microservices speaking to each other, part one (code available at https://github.com/bbossola/microjs )

@bbossola

● Disneyworld● Monolith Database● Unknown Caller● Hardcoded Hell● Synchronous World● Babel Tower● Monolith Frontend● Early Mornings● Crapper

Common antipatterns

Stay tuned go get more!bbossola.wordpress.com

@bbossola

● we are small, everything is nice, cosy and lovely– no healthchecks

– no metrics– no monitoring

● Solution– adopt a stack that implements these basic functionalities

– adopt (and connect!) one (or two) monitoring systems

– use a circuit breaker!

Antipatterns - Disneyworld

@bbossola

● your microservices uses a shared database– all your services are coupled

– migration hell awaits you

– cannot be released indipendently

● Solution– each server has his own database

– services talking trough API● do you really believe that mysql wire protocol is faster

than sockets?

Antipatterns - Monolith Database

@bbossola

● there's no identification in your comms:– a call does not contain any identification

– nobody knows who called

– diagnosing a malfunction become an endless marathon

● Solution– each server must inject a call id if missing

– each server must propagate the call id if present

– each server should log each call (with the id please!)

Antipatterns – Unkown Caller

@bbossola

● address of services are hardcoded– microservices directly know about each other

– only light indirection mechanisms are supported● configuration● DNS or naming trickery

● Solution– build your own simple discovery

mechanism– introduce a discovery mechanism

● eureka, zookeper, consul, and why not, msnos

Antipatterns - Harcoded Hell

@bbossola

● every call in your systems is synchronous– microservices wait for the final result

– every call can potentially hang forever

– one bad apple and your harvest is gone!

● Solution– respond 201 and location as much

as you can

– put queues on top of your receivers

– implement asynchronicity from the start

Antipatterns - Synchronous World

@bbossola

● using all sort of different lingos to talk– someone uses REST

– someone uses SOAP

– someone uses RMIP

– someone uses IIOP

● Solution– standardize protocols

● one sync protocol (i.e. REST over http)● one async protocol (i.e. pub/sub on Redis)

Antipatterns – Babel Tower

@bbossola

● you have a big fat frontend:– you have a single page application

– you have to deploy it in full for any upgrade

– you are using vertical "feature" teams

● Solution– split the app in small independent pieces

– make sure those are deployable independently

– assign the entire frontend to a separate team

Antipatterns – Monolith Frontend

@bbossola

● You have a scheduled deploy rhythm and...– you deploy services in the early morning (6am?)

– you wan to to avoid any disturbance to the world

– you have a wiki page that lists all the new services

● Solution– implement continuous deployment

– introduce necessary scaling in your microservices

– onboard devops help to normalize everything

Antipatterns – Early Mornings

@bbossola@bbossola

● “Our monolith code is crap, let's write microservices!”– your decided to move to microservices

– your code is still crap

– your microservices are difficult to change

● Solution– DO NOT discount proper design in

your code

– LOD, S.O.L.I.D., SOC, DRY, YAGNI must have a central place in your code

Antipatterns – Crapper

@bbossola

➢ let's kick some antipatterns!

➢ a nodejs live sample that shows some simple microservices speaking to each other (code available at https://github.com/bbossola/microjs)

@bbossola@bbossola

@bbossola

How do we work with microservices?

● How did we get there?– Replacing the monolith!

● by executive decision ● legacy code progressively replaced

with microservices● each new feature can now drive

a new microservice

– Moving to continuous delivery!● the business need to experiment, quickly!● we moved in small steps: from month, to weeks, to

days, to anytime!

@bbossola

● Teams!– each team owns some microservices

● development and QA● deployment procedures● maintenance

– each team is cross-functional● QA, DEV, DEVOPS● also Design in the future

– we follow the Spotify Model

@bbossola

● What about client applications?– the frontends must be modular

● each team controls a vertical “slice” of the system● allows independent deployments :)

– edge microservices are useful!● they aggregate calls● they minimize roundtrips● they optimize content

– a proxy layer is always needed!● not all APIs are public● signing may be used internally

@bbossola

● Some numbers!– 9 different products (web, mobile, desktop, server)

– 40+ microservices

– 28k unit tests (run in minutes)

– 3k end-to-end integration tests (run in 3 hours)

– up to 200 RPS on the busiest microservice

– up to 0.000001 RPS on the least used :)

– fastest response in 2 ms

– slowest response in 12 seconds (!)

@bbossola

Conclusions?

● Have it your way!

@bbossola

Thanks!

bbossola@gmail.com@bbossola

https://bbossola.wordpress.comhttps://github.com/bbossola

Why consider NodeJS?

● It's faaaaaaaaaast– marvellous V8 engine, compiles JS in native code

– non blocking I/O all over the place

● Has a small footprint– uses a tiny amount of CPU and memory compared to

traditional solutions

– can scale very easily trough clustering

● It's easy– Ecma6 is well, kind of Java :)

– it's single threaded: no concurrency at all!

– frontend developers can write backebd code (after training :)

@bbossola

Why consider NodeJS?

@bbossola

● keeps working under incredibly hard conditions!

...yep, it kept pumping!

Microservices, the lean way

Software