The document discusses microservices and provides an agenda for the presentation. The agenda includes discussing why use microservices, what microservices are, common antipatterns, and how to work with microservices. Examples of antipatterns that will be discussed include having a monolithic database shared across services, services with unknown callers due to lack of request IDs, hardcoded service addresses, synchronous communication between services, and using different communication protocols between services.

1. Microservices, the lean way
Bruno Bossola
(JUG Torino)
AMSTERDAM
11-12 MAY 2016

2. `
Microservices, the lean way
...now with 100% more llamas!
AMSTERDAM
11-12 MAY 2016

3. 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

4. ● Why microservices?
● What are microservices?
● Demo
● Common antipatterns
● Demo
● How do we work with microservices?
● Conclusions?
Agenda
@bbossola

5. ● Why microservices?
● What are microservices?
● Common antipatterns
● How do we work with
microservices?
Agenda
@bbossola

6. Why microservices?
J2EE
Ruby on Rails
.NET
Are you living with a monolith?
@bbossola

7. Why microservices?
J2EE
Ruby on Rails
.NET
● your IDE is bloated
Are you living with a monolith?
@bbossola

8. Why microservices?
J2EE
Ruby on Rails
.NET
● your IDE is bloated
● you are locked onto a language
Are you living with a monolith?
@bbossola

9. Why microservices?
J2EE
Ruby 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

10. Why microservices?
J2EE
Ruby 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

11. Why microservices?
J2EE
Ruby 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

12. Why microservices?
J2EE
Ruby 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

13. Why microservices?
J2EE
Ruby 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

14. ● Would not be better if...
Why microservices?
@bbossola

15. ● 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

16. ● 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

17. ● 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

18. ● 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

19. ● 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

20. ● 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

21. ● 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

22. ● 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

23. ● 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

24. ● Why microservices?
● What are microservices?
● Common antipatterns
● How do we work with microservices?
Agenda
@bbossola

25. ● 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

26. ● 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

27. ● 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

28. In the meantime, at Workshare...
What are microservices?
@bbossola

29. Demo!
ROME 18-19 MARCH
2016
All pictures belong
to 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

30. ● Why microservices?
● What are microservices?
● Common antipatterns
● How do we work with microservices?
@bbossola

31. ● 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

32. ● 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

33. ● 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

34. ● 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

35. ● 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

36. ● 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

37. ● 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

38. ● 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

39. ● 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

40. ● “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

41. Demo!
ROME 18-19 MARCH
2016
All pictures belong
to 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

42. ● Why microservices?
● What are microservices?
● Common antipatterns
● How do we work with microservices?
@bbossola

43. 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

44. 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

45. 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

46. 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

47. Conclusions?
●
Have it your way!
@bbossola

48. Thanks!
ROME 18-19 MARCH
2016
bbossola@gmail.com
@bbossola
https://bbossola.wordpress.com
https://github.com/bbossola
All pictures belong
to their respective authors

49. 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

50. Why consider NodeJS?
@bbossola
● keeps working under incredibly hard conditions!
...yep, it kept pumping!