Embed Size (px)
Citation preview
Microservices, the lean wayBruno Bossola (JUG Torino)
AMSTERDAM 11-12 MAY 2016
`
Microservices, the lean way
...now with 100% more llamas!
AMSTERDAM 11-12 MAY 2016
l
● 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
.NET
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
● your tests can take hours to run
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
● your tests can take hours to run
● your db migrations are HUGE and
scary
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
● your tests can take hours to run
● your db migrations are HUGE and scary
● you always scale EVERYTHING
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
● your tests can take hours to run
● your db migrations are HUGE and scary
● you always scale EVERYTHING
● you have a single BIG team
Are you living with a monolith?
@bbossola
Why microservices?
J2EERuby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
● your tests can take hours to run
● your db migrations are HUGE and scary
● you always scale EVERYTHING
● you have a single BIG team
● you are generating HTML pages
(no, well... really?)
Are you living with a monolith?
@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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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
● 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!
What are microservices?
@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)
What are microservices?
@bbossola
In the meantime, at Workshare...
What are microservices?
@bbossola
Demo!
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
● Why microservices?● What are microservices?● Common antipatterns● How do we work with microservices?
@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
Demo!
ROME 18-19 MARCH 2016
All pictures belongto their respective authors
➢ 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
● Why microservices?● What are microservices?● Common antipatterns● How do we work with microservices?
@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
How do we work with microservices?
● 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
How do we work with microservices?
● 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
How do we work with microservices?
● 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!
ROME 18-19 MARCH 2016
[email protected]@bbossola
https://bbossola.wordpress.comhttps://github.com/bbossola
All pictures belongto their respective authors
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!
