Micro vsnano
Servicios
Pedro J. Molina
https://pjmolina.com
@pmolinamhttps://metadev.pro
μ n
Pedro J. Molina
@pmolinam
Agenda
 Micro-servicios
 Nano-servicios
 Casos de uso
Conclusiones
Microservicios (1/3)
Estilo arquitectural para desarrollo de Software
Aplicaciones complejas compuestas por
pequeños servicios, independientes y
autónomos que se comunican usando APIs
agnósticas de lenguaje.
Altamente desacoplados, enfocados en tareas
pequeñas. ¿Cómo de pequeño?
Dueño (onwership) claro y conocido.
http://martinfowler.com/articles/microservices.html
Microservicios (2/3)
 Ventajas
 Componibles
 Evolución rápida
 Stack adecuado al trabajo
 Aislamiento ante fallos
 Despliegues rápidos
 Mejor disponibilidad
 Contras
 Latencia (en composición)
 Correlación de eventos (trazas)
 Heterogeneidad
 Volumen en despliegue  requiere automatización
http://es.slideshare.net/stonse/pros-and-cons-of-a-microservices-architecture-talk-at-aws-reinvent
Microservicios (3/3)
 Microservicios = SOA para Hipsters
 Abanderados
 Netflix
 Amazon
 Building Microservices
2015, Sam Newman
Sobre la importancia de aislar los microservicios:
Si la necesita,
cada microservicio tiene su propia capa de persistencia.
Aislados
Microservicio Disrupción Empresarial
Ley de Conway
“Las organizaciones que diseñan sistemas están limitadas a producir diseños que
copian las estructuras de comunicación de esas organizaciones”.
Melvin Conway, 1968
Inversión  Disrupción
 Startups centradas en Transformación Digital que disrupcionan un mercado
 Aprovechan la agilidad de los microservicios para iterar y pivotar más rápido descubriendo y
asentando nuevos procesos más óptimos
 Uber, Netflix, Amazon…
Stacks para Microservicios
NodeJS
 Express + Baucis
 SenecaJS
 FeatherJS
 Serverless: Claudia
Java
 Jersey
 Dropwizard
 Spring / Spring Boot
 Play
 SparkJava
 http://www.gajotres.net/best-available-java-restful-
micro-frameworks/
.NET Core
 NancyFx
 WebAPI
 https://docs.microsoft.com/en-
us/dotnet/articles/csharp/tutorials/microservices
Go
 go-kit/kit
 micro/go-micro
 goa.design
 coding/kite
 Serverless: Sparta, Apex, Gordon
Persistencia
 NoSQL
 MongoDB, CouchDB, Dynamo, DocumentDB
 RDBM
 MySql, Postgress, Oracle, Sql Server
 Key-Value Stores
 Redis
 Memcache
 Colas
 RabitMQ, ZeroMQ, AMZ SQS, Azure Queues
 Blobs
 Amazon S3
 Azure Blobs
Stack MEAN Dev
Local
:27001
Local
:5000
-
Navegador
Nube
db
:27001
app
:80
-
Navegador
Producción
cluster
:27001
app :80
-
Navegador
lb: 443
Demo. Ejemplo
Sitio en Producción:
https://openapi3.herokuapp.com
demo / demo
¡Sed buenos! }:-b
Repositorio de fuentes:
https://github.com/pjmolina/event-backend
MEAN Stack: Arquitectura
Client ExpressJS BaucisJS Mongoose MongoDB
HTTP req
resource
query/command
data
401 | 403
AuthN/AuthZ
middleware
<req.user, res>
Microservice
NodeJS + Express JS
 http://expressjs.com
var express = require('express');
var app = express();
app.get('/hello', function(req, res) {
res.status(200).send('hello world');
});
/helloreq res
Express Middleware
 CORS
 AuthN  PassportJS
 AuthZ
 Etc.
app.all('*', function(req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Headers", "X-Requested-With, Content-Type");
res.header("Access-Control-Allow-Methods", "OPTIONS,GET,POST,PUT,DELETE");
next();
});
*req
res
next()
.NET Core + NancyFX
 http://nancyfx.org
public class SampleModule : Nancy.NancyModule
{
public SampleModule()
{
Get["/hello"] = _ => “hello world";
}
}
/helloreq res
OpenAPI
 OpenAPI Initiative https://openapis.org
 Descripción de Servicios / APIs
 Documenta el API
 Facilita su uso por desarrolladores
 Herramientas
 Contract first
 Documentar APIs existents
 Generación de Proxies, Skeletons, SDKs nativos
 Integración con Herramientas de API Management
Escalabilidad
 Clusters de MongoDB
 Sesión persistida en MongoDB
 connect-mongo
 Balanceador de carga (nginx, haproxy,
etc.)
 Opciones:
 Gestionalo tu según necesidades: IaaS
 PaaS (como Heroku)
 Serverless
Carga
 Sistema en producción
 Backends para aplicaciones móviles Android e iOS + portal web
 80.000 peticiones diarias en ventana de 4 horas
 Promedio = 333 ppm, aprox 6 pps 100-200ms
 Picos de 1000 ppm, aprox 17 pps
 En 2 instancias 1x 1Gb RAM en Heroku
 por 100 $/mes + 18 $/mes de mLab
Registro y descubrimiento
Consul
Monitorización
newRelic
Monitorización
Prometheus
Logs
papertrail
Go Serverless!
 Código sin preocuparse* por la infrastructura
 Amazon Lambda Functions http://docs.aws.amazon.com/lambda
 Google Cloud Functions
 IBM OpenWhisk
 Azure Functions
Nano-servicio
 ¿¡Microservicio más pequeño hecho en Valencia!?
Nano-servicio
 Servicios muy, muy pequeños. Altamente escalables.
 Diseñados para poder ser desplegados en plataformas serverless y
poder aprovechar un escalado totalmente elástico.
 Requieren de una infrastructura eficiente que pueda alojar una
multitud de nanoservicios
 Plataformas:
 Amazon Lambda Functions
 Google Cloud Functions
 Azure Cloud Funtions
 IBM OpenWisk
Nano-servicios: plataformas y librerías
 Plataformas:
 Amazon Lambda Functions
 Google Cloud Functions
 Azure Cloud Funtions
 IBM OpenWisk
 Librerías
 Serverless.com (ASW Lambda)
 ClaudiaJS (AWS Lambda)
exports.handler = function(event, context) {
switch (event.operation) {
case 'ping': context.succeed('pong'); return;
case 'getSample':
event.customArgs = ["rose:", "/tmp/rose.png"];
im.convert(event.customArgs, function(err, output) {
if (err) context.fail(err);
else {
var resultImgBase64 = new Buffer(
fs.readFileSync("/tmp/rose.png"))
.toString('base64');
try { fs.unlinkSync("/tmp/rose.png");} catch (e) {}
context.succeed(resultImgBase64);
}
});
break;
default:
return context.fail(new Error('Unrecognized operation "' +
event.operation + '"'));
}
};
Ejemplo: AWS Lambda
Ejemplo Serverless. Analíticas móviles
Amazon
Route 53
Amazon
S3
AWS
Lambda
Lambda
function
Amazon
DynamoDB
Amazon API
Gateway*
Casos de uso
Microservicios
 Frontera: Bounded Context bien definidos (DDD)
 Necesidad de escalado o evolución de negocio en cada Bounded Context a
diferentes velocidades o desconocida
 Equipos diferenciados: cada uno responsable de su microservicio
Nanoservicios
 Frontera: funcionalidad muy, muy pequeña
 Funcionalidad que requiera una escalabilidad o disponibilidad muy alta
 Servicio de login / Servicio de log / diagnostico
 A menudo considerados anti-patrón: cuando el coste de desplegarlos es mayor
que su utilidad
Preguntas
y tal vez… respuestas
@pmolinam

Micro vs Nano (servicios)

  • 1.
    Micro vsnano Servicios Pedro J.Molina https://pjmolina.com @pmolinamhttps://metadev.pro μ n
  • 2.
  • 3.
  • 4.
    Microservicios (1/3) Estilo arquitecturalpara desarrollo de Software Aplicaciones complejas compuestas por pequeños servicios, independientes y autónomos que se comunican usando APIs agnósticas de lenguaje. Altamente desacoplados, enfocados en tareas pequeñas. ¿Cómo de pequeño? Dueño (onwership) claro y conocido. http://martinfowler.com/articles/microservices.html
  • 5.
    Microservicios (2/3)  Ventajas Componibles  Evolución rápida  Stack adecuado al trabajo  Aislamiento ante fallos  Despliegues rápidos  Mejor disponibilidad  Contras  Latencia (en composición)  Correlación de eventos (trazas)  Heterogeneidad  Volumen en despliegue  requiere automatización http://es.slideshare.net/stonse/pros-and-cons-of-a-microservices-architecture-talk-at-aws-reinvent
  • 6.
    Microservicios (3/3)  Microservicios= SOA para Hipsters  Abanderados  Netflix  Amazon  Building Microservices 2015, Sam Newman
  • 7.
    Sobre la importanciade aislar los microservicios: Si la necesita, cada microservicio tiene su propia capa de persistencia. Aislados
  • 8.
    Microservicio Disrupción Empresarial Leyde Conway “Las organizaciones que diseñan sistemas están limitadas a producir diseños que copian las estructuras de comunicación de esas organizaciones”. Melvin Conway, 1968 Inversión  Disrupción  Startups centradas en Transformación Digital que disrupcionan un mercado  Aprovechan la agilidad de los microservicios para iterar y pivotar más rápido descubriendo y asentando nuevos procesos más óptimos  Uber, Netflix, Amazon…
  • 9.
    Stacks para Microservicios NodeJS Express + Baucis  SenecaJS  FeatherJS  Serverless: Claudia Java  Jersey  Dropwizard  Spring / Spring Boot  Play  SparkJava  http://www.gajotres.net/best-available-java-restful- micro-frameworks/ .NET Core  NancyFx  WebAPI  https://docs.microsoft.com/en- us/dotnet/articles/csharp/tutorials/microservices Go  go-kit/kit  micro/go-micro  goa.design  coding/kite  Serverless: Sparta, Apex, Gordon
  • 10.
    Persistencia  NoSQL  MongoDB,CouchDB, Dynamo, DocumentDB  RDBM  MySql, Postgress, Oracle, Sql Server  Key-Value Stores  Redis  Memcache  Colas  RabitMQ, ZeroMQ, AMZ SQS, Azure Queues  Blobs  Amazon S3  Azure Blobs
  • 11.
  • 12.
    Demo. Ejemplo Sitio enProducción: https://openapi3.herokuapp.com demo / demo ¡Sed buenos! }:-b Repositorio de fuentes: https://github.com/pjmolina/event-backend
  • 13.
    MEAN Stack: Arquitectura ClientExpressJS BaucisJS Mongoose MongoDB HTTP req resource query/command data 401 | 403 AuthN/AuthZ middleware <req.user, res> Microservice
  • 14.
    NodeJS + ExpressJS  http://expressjs.com var express = require('express'); var app = express(); app.get('/hello', function(req, res) { res.status(200).send('hello world'); }); /helloreq res
  • 15.
    Express Middleware  CORS AuthN  PassportJS  AuthZ  Etc. app.all('*', function(req, res, next) { res.header("Access-Control-Allow-Origin", "*"); res.header("Access-Control-Allow-Headers", "X-Requested-With, Content-Type"); res.header("Access-Control-Allow-Methods", "OPTIONS,GET,POST,PUT,DELETE"); next(); }); *req res next()
  • 16.
    .NET Core +NancyFX  http://nancyfx.org public class SampleModule : Nancy.NancyModule { public SampleModule() { Get["/hello"] = _ => “hello world"; } } /helloreq res
  • 17.
    OpenAPI  OpenAPI Initiativehttps://openapis.org  Descripción de Servicios / APIs  Documenta el API  Facilita su uso por desarrolladores  Herramientas  Contract first  Documentar APIs existents  Generación de Proxies, Skeletons, SDKs nativos  Integración con Herramientas de API Management
  • 18.
    Escalabilidad  Clusters deMongoDB  Sesión persistida en MongoDB  connect-mongo  Balanceador de carga (nginx, haproxy, etc.)  Opciones:  Gestionalo tu según necesidades: IaaS  PaaS (como Heroku)  Serverless
  • 19.
    Carga  Sistema enproducción  Backends para aplicaciones móviles Android e iOS + portal web  80.000 peticiones diarias en ventana de 4 horas  Promedio = 333 ppm, aprox 6 pps 100-200ms  Picos de 1000 ppm, aprox 17 pps  En 2 instancias 1x 1Gb RAM en Heroku  por 100 $/mes + 18 $/mes de mLab
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
    Go Serverless!  Códigosin preocuparse* por la infrastructura  Amazon Lambda Functions http://docs.aws.amazon.com/lambda  Google Cloud Functions  IBM OpenWhisk  Azure Functions
  • 25.
    Nano-servicio  ¿¡Microservicio máspequeño hecho en Valencia!?
  • 26.
    Nano-servicio  Servicios muy,muy pequeños. Altamente escalables.  Diseñados para poder ser desplegados en plataformas serverless y poder aprovechar un escalado totalmente elástico.  Requieren de una infrastructura eficiente que pueda alojar una multitud de nanoservicios  Plataformas:  Amazon Lambda Functions  Google Cloud Functions  Azure Cloud Funtions  IBM OpenWisk
  • 27.
    Nano-servicios: plataformas ylibrerías  Plataformas:  Amazon Lambda Functions  Google Cloud Functions  Azure Cloud Funtions  IBM OpenWisk  Librerías  Serverless.com (ASW Lambda)  ClaudiaJS (AWS Lambda)
  • 28.
    exports.handler = function(event,context) { switch (event.operation) { case 'ping': context.succeed('pong'); return; case 'getSample': event.customArgs = ["rose:", "/tmp/rose.png"]; im.convert(event.customArgs, function(err, output) { if (err) context.fail(err); else { var resultImgBase64 = new Buffer( fs.readFileSync("/tmp/rose.png")) .toString('base64'); try { fs.unlinkSync("/tmp/rose.png");} catch (e) {} context.succeed(resultImgBase64); } }); break; default: return context.fail(new Error('Unrecognized operation "' + event.operation + '"')); } }; Ejemplo: AWS Lambda
  • 29.
    Ejemplo Serverless. Analíticasmóviles Amazon Route 53 Amazon S3 AWS Lambda Lambda function Amazon DynamoDB Amazon API Gateway*
  • 30.
    Casos de uso Microservicios Frontera: Bounded Context bien definidos (DDD)  Necesidad de escalado o evolución de negocio en cada Bounded Context a diferentes velocidades o desconocida  Equipos diferenciados: cada uno responsable de su microservicio Nanoservicios  Frontera: funcionalidad muy, muy pequeña  Funcionalidad que requiera una escalabilidad o disponibilidad muy alta  Servicio de login / Servicio de log / diagnostico  A menudo considerados anti-patrón: cuando el coste de desplegarlos es mayor que su utilidad
  • 31.
    Preguntas y tal vez…respuestas @pmolinam