Bruno Bossola
MSNOS
a spontaneus network operating system for Microservice Architectures
[email protected]@workshare.com
ROME 27-28 march 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
Agenda
● What are microservices?● Pros and cons● MSNOS to the rescue!● demo, demo, demo!
note: this project is not released officialy, eta 2w
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” :)
Microservices?
server:linux-eu-001
server:linux-eu-002
CICCIO:Service
PASTICICCIO:Service
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!
Demo!
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 :)
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)
MSNOS to the rescue!
● A network operating system for architectures based on microservices– self discovery
– communication
– load balancing
– routing
– sharing configuration
– proxying
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)
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
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
Architecture
Security
HTTP / UDP / SSP
agent self discovery
point to point / broadcast messaging
Core
Application
Inter application messaging
Microservices
services API routing and discovery
HTTPhelper
routing overrides
loadbalancing
HTTPreverse proxy
Core layer
HTTP / UDP / SSP
Securityagent self discovery
services API routing and discovery
point to point / broadcast messaging
Core
Microservices
Application
Inter application messaging
HTTPhelper
routing overrides
loadbalancing
HTTPreverse proxy
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
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
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
Core: basic concepts
WWW Gateway
UDP
Ring
HTTP(polling)
Ring
Ring
HTTP(direct)
UDP only
UDP + WWW
Microservices
UDP + HTTP + WWW
Core: demo!
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
μservices layer
HTTP / UDP / SSP
Securityagent self discovery
services API routing and discovery
point to point / broadcast messaging
HTTPhelper
routing overrides
loadbalancing
Core
Application
Inter application messaging
HTTPreverse proxy
Microservices
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
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
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
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)
Fast HTTP Proxy
HTTPProxy
RestAPI X
RestAPI Y
RestAPI Z
μservices layer: demo!
μ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
μ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
μ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
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)
Q&A
● Msnos code:– https://github.com/workshare/ms-nos
● Myself:– https://about.me/bbossola
– @bbossola
● Company– https://www.workshare.com
We are hiring!!!
ROME 27-28 march 2015 – Bruno Bossola
Leave your feedback on Joind.in!https://joind.in/event/view/3347
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)