Codemotion Rome 2015 - Since two years in Workshare we moved to a microservices based architecture and it's proved to be challenging in several different ways. Traditional configuration based mechanisms failed because of the very dynamic nature of such architecture. At any point in time you should be able to deploy a new microservice, kill one, upgrade one, this while preserving things like load balancing and session affinity, and being sure at the same time that everything is healthy. Workshare built an open source library, msnos, that tries to address the problem on the three main platform used (ruby, java, .net)

1. Bruno Bossola
MSNOS
a spontaneus network operating system for
Microservice Architectures
bbossola@gmail.com
bruno.bossola@workshare.com
ROME 27-28 march 2015

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

3. Agenda
● What are microservices?
● Pros and cons
● MSNOS to the rescue!
● demo, demo, demo!
note: this project is not released officialy, eta 2w

4. 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
● micro means small, very!
– on the train going to the airport we currently
invented the term “picoservices” :)

5. Microservices?
server:linux-eu-001
server:linux-eu-002
CICCIO:Service
PASTICICCIO:Service

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

7. Microservices!

8. Demo!

9. Pros!
● highly cohesive, loosely coupled
● clean api contracts and SOC
● very easy to write and replace
● self-contained
● very easy to deploy
● small releases, less risky to deploy
● fashionable and trendy :)

10. Cons!
● Lots of them!
● As every microservice is doing one simple
thing, performing a task requires a lot of
collaboration
● Scaling requires considerable effort
● Frequent duplicated configuration
● Proxying for external apps is not easy
● management overhead (more moving parts)

11. MSNOS to the rescue!
● A network operating system for architectures
based on microservices
– self discovery
– communication
– load balancing
– routing
– sharing configuration
– proxying

12. What is NOT
● 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 configuration mechanism
tough :)
● An infinite scaling solution
– works well with a couple of hundreds
– we are not in the thousands (yet)

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

14. Why do we need this? [2/2]
● μservices api should be exposed automagically to the
external world
● μservices should automatically share application
configuration
● μservices are small: don't run a VM for each of them!
– we run 20 of them on one single machine
● language agnostic, please (Java, .NET, Ruby, JS)
– basic implementation should be easy and available

15. Architecture
Security
HTTP / UDP / SSP
agent self discovery
point to point / broadcast messaging
Core
Application
Inter application messaging
Microservices
services API routing and discovery
HTTP
helper
routing
overrides
load
balancing
HTTP
reverse proxy

16. Core layer
HTTP / UDP / SSP
Security
agent self discovery
services API routing and discovery
point to point / broadcast messaging
Core
Microservices
Application
Inter application messaging
HTTP
helper
routing
overrides
load
balancing
HTTP
reverse proxy

17. Core: basic concepts
● Cloud
– a set of agents capable to communicate with each other
● Agent
– a network aware entity capable to communicate with
others in the same cloud exchanging messages
● Ring
– a set of agents directly connected that can communicate
between them using broadcast, part of the same cloud
● Message
– a short content exchangeable between agents, either in
broadcast or point to point

18. Core: architecture
● provides basic messaging capabilities and security
● each agent can send “SMS” style messages to any other
agent or to the cloud
● messages can be reliable on a point to point
communication
● uses existing networking feats:
– UDP over a local network
– HTTP(s) using internet SAAS over distributed networks
– HTTP(s) and SSH using helpers over near-distance
networks

19. Core: use cases
● broadcast a message
● send a message to another agent
● reliably send a message
● discovery of new agents
● maintaining a list of agents in the cloud

20. Core: basic concepts
WWW Gateway
UDP
Ring
HTTP
(polling)
Ring
Ring
HTTP
(direct)
UDP only
UDP + WWW
Microservices
UDP + HTTP + WWW

21. Core: demo!

22. core: sample code
● This is the whole code used by the sample:
Cloud nimbus = new Cloud(params.uuid());
Agent self = new LocalAgent(params.name());
self.join(nimbus);
Create a cloud object
Create an agent and
make it join the cloud

23. μservices layer
HTTP / UDP / SSP
Security
agent self discovery
services API routing and discovery
point to point / broadcast messaging
HTTP
helper
routing
overrides
load
balancing
Core
Application
Inter application messaging
HTTP
reverse proxy
Microservices

24. basic concepts
● Microservice
– a small independent entity, based on an Agent,
that exposes APIs, capable to communicate with
others in the same cloud exchanging messages
● Microcloud
– an instance of Cloud that contains Microservices
rather than Agents
● RestAPI
– a representation of an API exposed by a
microservice

25. RestApi
● encapsulate a REST endpoint exposed by a
microservice
● has different types:
– public, exposed to anyone
● will be exposed by the proxy to the public
– private, exposed to the cloud only
– health, exposes an internal healthcheck
– msnos, exposes a receiving endpoint for msnos
messages

26. architecture
● μservice basic functionalities
– self discovery of other μservices
– self discovery and publishing of APIs
● μservice advanced functionalities
– API routing strategies
● by geolocation, by load, by priority, by styckiness...
– Embedded HTTP helper
● allows the microservice to receive core messages
directly
● supports sticky sessions
● Out of the box fast HTTP reverse proxy

27. use cases
● locate a service in the cloud
● locate an API in the cloud
● debug in the cloud
● sharing configuration within the cloud (wip)
● events publish/subscribe (future)

28. Fast HTTP Proxy
HTTP
Proxy
RestAPI X
RestAPI Y
RestAPI Z

29. μservices layer: demo!

30. μlayer: sample code
● This is the whole code used by the clients:
cloud = new Microcloud(new Cloud(params.uuid()));
uvvc = new Microservice(params.name());
usvc.join(cloud);
RestApi[] { apis = new RestApi[] {
new RestApi("sample", URI_GREET, port),
new RestApi("sample", URI_WASSUP, port),
new RestApi("sample", URI_HEALTH, port).asHealthCheck(),
new RestApi("sample", URI_MSNOS, port, Type.MSNOS_HTTP),
};
usvc.publish(apis);
Declare and publish
your service APIs
Create a cloud, a service,
let the service join the cloud

31. μlayer: sample code
● Whole code for the msnos endpoint (standard
Java 5 code):
public void handle(HttpExchange exchange) throws IOException {
Reader reader = new BufferedReader(...);
try {
Message message = serializer.fromReader(reader, Message.class);
cloud.process(message, Endpoint.Type.HTTP);
} finally {
reader.close();
}
exchange.sendResponseHeaders(200, 0);
exchange.getResponseBody().close();
}
Read a message from
the HTTP exchange,
hand it over to the cloud

32. μlayer: sample code
● This is the whole code used by the proxy
when subscribing to the cloud:
cloud = new Microcloud(new Cloud(params.uuid()));
self = new Microservice("Proxy");
self.join(cloud);
self.publish(new RestApi("/msnos", port, Type.MSNOS_HTTP));
Same story:
- create a cloud
- create a microservice and join the cloud
- publish his own API

33. Future
● Release 1.0 (2w)
– core, proxy, www gateway
● New efficient routing protocol (2w)
● Native Ruby support (1m)
● Completion of distributed configuration (1m)
● Native .NET support (2m)
● Support for Azure (2m)
● STUN protocol support - RFC 5389 (tbc)

34. Q&A
● Msnos code:
– https://github.com/workshare/ms-nos
● Myself:
– https://about.me/bbossola
– bbossola@gmail.com
– @bbossola
● Company
– https://www.workshare.com
We are hiring!!!

35. ROME 27-28 march 2015 – Bruno Bossola
Leave your feedback on Joind.in!
https://joind.in/event/view/3347

36. Anticipated Q&A
● Q. Why are you not simply using ${library}?
● A. Because (a) it does not exist or (b) it does not exist in a language
agnostic implementation
● 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)