Microservices - the lean way

Microservices,
the lean way
Bruno Bossola
@bbossola
@bbossola, 22nd
October 2015

Hey mate, who are you?
● Developer since 1988
● XP Coach 2000+
● Co-founder and coordinator of JUG Torino
● Java Champion since 2005
● VP of Engineering @Workshare.com
@bbossola, 22nd
October 2015

@bbossola, 22nd
October 2015
Agenda
● Why microservices?
● What are microservices?
● Common antipatterns
● Some common issues
● MSNOS to the rescue!
● demo, demo, demo!

@bbossola, 22nd
October 2015
Why microservices?
● if you are asking this question you are probably living in this
world:
...The world of
the BLACK
MONOLITH!
why microservices?

@bbossola, 22nd
October 2015
Why avoid the monolith?
● the monolith usually provides HTML pages
– these days we want APIs and single page apps
● the monolith scares developers!
– the code base is massive
● the monolith is scary to deploy
– everytime you have to deploy everything!
– it's a stop-the-world moment
why microservices?

@bbossola, 22nd
October 2015
What's the issue here?
● the monolith code bloats your IDE
● it locks you into one language/platform
● adding a new API requires a congress
● on deploy the whole database may have to be migrated for a
very small change
● running the tests can take hours
● it's boring to develop on that s**t
why microservices?

@bbossola, 22nd
October 2015
Agenda
● demo, demo, demo

@bbossola, 22nd
October 2015
What are microservices?
● 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
what are microservices?

@bbossola, 22nd
October 2015
I want to add a file to a group...
groups:μs
UI:js-app
files:μs
buckets:μs
queues:μs
postman:μs
events:μs
notifications:μs
mixpanel
marketo
intercom
Amazon S3
sendgrid
Javascript
Ruby
Java
C
thumbs:μs

@bbossola, 22nd
October 2015
Microservices!

@bbossola, 22nd
October 2015
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

@bbossola, 22nd
October 2015
Cons!
● Lots of them!
● Every microservice is doing one thing, so a lot of
collaboration is required to perform a task
● Scaling requires considerable effort
● Frequent duplicated configuration
● Proxying for external apps is not easy
● management overhead (more moving parts)

@bbossola, 22nd
October 2015
Demo!
1. simple services (time and location)
2. complex services (groups and folders)
3. a nodejs live sample that shows some simple microservices
speaking to each other, p`art one (code available at
https://github.com/bbossola/microjs )

@bbossola, 22nd
October 2015
Common antipatterns
● disneyworld
● monolith database
● unknown caller
● hardcoded hell
● synchronous world
● babel tower
● monolith frontend
● early mornings
Common antipatterns
Stay tuned go get more!
bbossola.wordpress.com
● crapper

@bbossola, 22nd
October 2015
Disneyworld
● 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
Sorted!
Common antipatterns

@bbossola, 22nd
October 2015
Monolith database
● 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?
Sorted!
Common antipatterns

@bbossola, 22nd
October 2015
Unknown caller
● 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!)
WE
HAVE IT!
Common antipatterns

@bbossola, 22nd
October 2015
Harcoded hell
● 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
GETTING
THERE!
Common antipatterns

@bbossola, 22nd
October 2015
Synchronous world
● 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 asynchronism from the start
GETTING
THERE!
Common antipatterns

@bbossola, 22nd
October 2015
Babel Tower
● 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)
Sorted!
Common antipatterns

@bbossola, 22nd
October 2015
Monolith Frontend
● you have a big fat frontend system:
● 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
Common antipatterns
GETTING
THERE!

@bbossola, 22nd
October 2015
Early Mornings
● 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
Common antipatterns
GETTING
THERE!

@bbossola, 22nd
October 2015
Crapper
● 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
Sorted!
Common antipatterns

@bbossola, 22nd
October 2015
Demo!
Let's kick out some antipatterns! Any clue?
1. a nodejs live sample that shows some simple microservices
speaking to each other (code available at
https://github.com/bbossola/microjs )
Common antipatterns

@bbossola, 22nd
October 2015
What is the context?
● you use a microservice architecture
● microservice are distributed across the world
● each microservice provide different APIs
● several instances of the same microservices are available
● they need to talk to each other to fullfill a task
Some common issues

@bbossola, 22nd
October 2015
Problem #1: how do I find an API?
● I need to use an API exposed by another microservice:
how do I find the endpoint?
– I am the Session Tracking microservice and I need to
translate an IP to a geo location
– I heard that a Location microservice does this
– How do I know which endpoint I need to call?
● where is it?
● what's the nearest?
● what's the less loaded?
Some common issues

@bbossola, 22nd
October 2015
Issue #2: how do I expose my APIs?
● Hey, I am online and I want to publish my APIs to
everybody: how can I do that?
– I am a new service, I am a new instance of an existing service
– I am ready to receive calls!!
– How do the other microservices get to know about me? :(
Some common issues

@bbossola, 22nd
October 2015
Issue #3: how do I report issues?
● OMG I am not able to connect to my database
anymore!!!
– I need to alert the other microservices around that I cannot
accept calls at the moment!
– If they knew this, they could call another instance of me that
actually works...
– How do the other microservices get to know about me being
faulty?
Some common issues

@bbossola, 22nd
October 2015
Issue #4: how do I call from clients?
● I am a single page app / mobile app and I want to use
some backend APIs
– How can I make sure the APIs I want to use are proxied and
available on the web?
– How can I get load the best possible service instance to use?
– How can I avoid connecting to a “bad” API and be sure that I
will always use a working endpoint?
Some common issues

@bbossola, 22nd
October 2015
In an ideal world...
● new microservices APIs are automatically seen and used
by any other microservice
● unhealthy microservices do not receive calls
● the load is distributed trough advanced strategies (load,
location, availability...)
● there are no single point of failures
● add/remove of microservices is transparent
● “public” APIs are magically proxied to the web
Some common issues

@bbossola, 22nd
October 2015
Agenda
● demo, demo, demo!
msnos.io is open source! (MIT license)

@bbossola, 22nd
October 2015
MSNOS to the rescue!
● A network operating system for architectures based on
microservices
– self discovery
– communication
– load balancing
– routing
– web proxying
– ...and more :)
msnos to the rescue!

@bbossola, 22nd
October 2015
● A replacement for a deployment mechanism
– still your job to deploy and run a microservice
– docker does a good job I heard :)
● A replacement for any configuration
– still your job to configure enough to start
– it provides a shared key-value store tough :)
● An infinite scaling solution
– works well with a couple of hundreds
– we are not in the thousands (yet)
What is NOT

@bbossola, 22nd
October 2015
Why do we need this? [1/2]
● μservices should automatically discover themselves
– any service can find any api with zero effort
● μservices should be able to scale on demand
– work should be handled in a balanced manner
– you should be able to spinoff a new instance so that it can
transparently join the cloud and start working
● μservices should work across network boundaries
● the cloud of services should be deployable across two or more different
physical clouds

@bbossola, 22nd
October 2015
Why do we need this? [2/2]
●
μservices api should be exposed automagically to the external world
● μservices public APIs should be proxied transparently
● you should not need a VM for each microservice!
– we run 20 of them on one single machine
– you can also use an application server!
● language agnostic, please (Java, .NET, Ruby, JS)
– basic implementation should be easy and available

@bbossola, 22nd
October 2015
How do I use it? [1/2]
● msnos is a native library you link into your app
cloud = new Microcloud(params.uuid());
service = new Microservice(params.name());
service.join(cloud);
RestApi[] { apis = new RestApi[] {
new RestApi("/hello", URI_GREET, port),
new RestApi("/wassup", URI_WASSUP, port),
new RestApi("/checkme", URI_HEALTH, port).asHealthCheck(),
new RestApi("/msnos", URI_MSNOS, port, Type.MSNOS_HTTP),
};
service.publish(apis);
Declare and publish
your service APIs
Create a cloud, a service,
let the service join the cloud

@bbossola, 22nd
October 2015
What do I get?
● Out of the box fast HTTP reverse proxy
– fast, non blocking, based on Netty
– exposes your public APIs to the web
● Out of the box WWW gateway
– helps discovery across network boundaries
● A simple sms-style messaging system
● Free live visualization tool for monitoring and basic
management of your cloud
– available now at msnos.io

@bbossola, 22nd
October 2015
Demo!

@bbossola, 22nd
October 2015
Future
● Release 1.1 (1m)
– core, proxy, www gateway
● Native Ruby support 1.1 (2w)
● Support for Azure (4w)
● New distributed configuration service (2m)
● Native .NET support (1m) (yeah, still ongoing...)
● STUN protocol support - RFC 5389 (tbc)

@bbossola, 22nd
October 2015
Q&A
● Msnos code:
– https://github.com/workshare/ms-nos
– msnos.io
● Myself:
– https://about.me/bbossola / @bbossola
● Company
– https://www.workshare.com

@bbossola, 22nd
October 2015
Anticipated Q&A
●
Q. Why did you not release a final version yet?
● A. Because, even if we are using it in production, we still consider it not final and we
prefer to wait in order to release top-quality code
● Q. Why are you not using clear and elegant names in the JSON? It looks awful!
●
A. Because the maximum size of a datagram packet is usually 512 bytes: you may want
to be concise
● Q. Then why use JSON?
●
A. We will also use Hessian2 but at the moment we favour readability over bare
efficiency and we need a protocol that every language can understand (C#, Java, Ruby)

@bbossola, 22nd
October 2015
Anticipated Q&A
● Q. Why don't you simply use a dynamic DNS to manage discovery??
● A. One of my favourites :)
– a DNS entry does not provide us enough granularity, as we want to talk about
API endpoints, not machines names.
– clients will have poll for changes as there’s no push protocol for DNS
– any DNS suffer from propagation delays, non deterministic
– the routing will be effectively random, as there's no way for a DNS to
dynamically assess the status of an API endpoint
– aggressive DNS caching may take place by client libraries or even applications
at startup (i.e. Nginx / HAProxy) thus making ineffective anything done at the
DNS level

@bbossola, 22nd
October 2015
Anticipated Q&A
● Q. Why don't you use ${other-framework}?
● A. Well, there are different answer for each of them, and such frameworks are becoming more
popular by the minute! Anyway, some common issues we found so far:
– they do not have native API level granularity (i.e. Consul, Zookeper)
– they do not have a push model (i.e. Zookeper, dynamic DNS)
– they have a single point of failre and are not fully distributed (Smartstack)
– they are missing basic necessary routing mechanism (i.e. geolocation, session stickiness)
– they are not language agnostic or very difficult to code against (i.e. Zookeper)
– they are proprietary

@bbossola, 22nd
October 2015
Tech-stuff: features
● full messaging platform
– broadcast of messages
– point-to-point messages
– reliable messages
● self discovery of other services
● publish and locate an API in the cloud
● debug in the cloud
● automatic reverse proxying of public APIs
● sharing configuration within the cloud (wip)
● events publish/subscribe (future)

@bbossola, 22nd
October 2015
Extras :)

@bbossola, 22nd
October 2015
how routing works
WWW Gateway
UDP
Ring
HTTP
(polling)
Ring
Ring
HTTP
(direct)
UDP only
UDP + WWW
Microservices
UDP + HTTP +
WWW

@bbossola, 22nd
October 2015
how proxy works
HTTP
Proxy
RestAPI X
RestAPI Y
RestAPI Z

@bbossola, 22nd
October 2015
server:linux-eu-001
server:linux-eu-002
FATTY:Service
FATTYFATTY:Service
Microservices??

@bbossola, 22nd
October 2015
Microservices!
server:linux-eu-001
server:linux-eu-002
api:files
api:users
api:folders
api:groups
api:sessions
api:members
api:deals
api:tracking
api:notes
api:mobi
api:postman
api:pushy
api:cachey
api:pics
api:pools
api:loops
api:deals
api:seams
api:prints
api:receipts

Microservices - the lean way

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to Microservices - the lean way (20)

Recently uploaded (20)

Microservices - the lean way

Editor's Notes