msnos: a cool and cozy blanket for your microservices - bruno bossola - codemotion roma 2015

Bruno Bossola

MSNOS

a spontaneus network operating system for Microservice Architectures

bbossola@gmail.combruno.bossola@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@gmail.com

– @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)