Tecnologías para
MICROSERVICIOS
Dr. Pedro J. Molina
Fundador de
http://pjmolina.com
@pmolinam
¿Qué hago?
 Metadev
 Consultoría, Formación
 Cloud, Microservicios, Stack MEAN, CI
 Productos en Modelado y DSL
 Colaboro con Lemoncode
 Cursos y mater de frontend
 Ex:
 CTO, Director de I+D, Arquitecto de Software,
Desarrollador
¿Qué es un Microservicio?
 Estilo arquitectural
 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 claro y conocido.
http://martinfowler.com/articles/microservices.html
Sobre la importancia de aislar los microservicios:
Si la necesita,
cada microservicio tiene su propia capa de persistencia.
Aislados
Microservicios
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
¿Qué es un Microservicio?
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…
APIs agnósticas de lenguaje
1. CORBA >> C + IDL
2. SOA >> XML + SOAP + WDSL …
3. REST >> JSON + HTTP
Tipos MIME
 Declaran el tipo de codificación a
emplear
 Los más frecuentes:
 JSON application/json
 XML text/xml
 HTML text/html
 Texto plano text/plain
 CSV text/csv
GET /actors/42
Accept: text/xml
200 OK
Content-Type: text/xml
<actor id="42">
<name>Jessica</name>
<lastname>Alba</lastname>
<filmography
url= "/films/42" />
</actor>
REST
 REpresentational State Transfer
 Protocolo sin estado
 URIs únicas para cada recurso
 Semántica asociada a operaciones
 GET/PUT/POST/DELETE en HTTP
 Hipermedia (navegable)
GET /actors/42
Accept: application/json
200 OK
Content-Type: application/json
{ "id": 42
"name": "Jessica"
"lastname": "Alba"
"filmography": "/films/42"
}
Niveles REST
Richarson Maturity Model
 http://martinfowler.com/articles/richardsonMaturityModel.html
 Nivel 0. HTTP y nada mas (RPC bajo HTTP)
 Nivel 1. Recursos: GET /factura/217
 Nivel 2. Verbos y códigos de error HTTP POST /factura/ 201 Created
 Nivel 3. Controles Hipermedia <link rel=“lines”
uri=“/factura/217/lines”
/>
HATEOAS
 Hypertext As The Engine Of Application State
 API autodocumentadas, autoexplorables
 Clientes más inteligentes / dinámicos
HAL
Estándar de Hipermedia
en Recursos
HATEOAS
{
“id”: 1234
“name”: “Alicia”
“_links”: {
“self”: { “href”: “/article/10”},
“prev”: { “href”: “/article/9”},
“next”: { “href”: “/article/11”},
“action-delete”: {
“verb”: “DELETE”,
“href”: “/article/10”
}
}
}
http://stateless.co/hal_specification.html
Microservicios
 Microservicios = ¿SOA para Hipsters?
 Abanderados
 Netflix
 Amazon
 Thoughtworks
 Building Microservices
2015, Sam Newman
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, Posgress, 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://dotnetmalaga.herokuapp.com
demo / 1234
¡Sed buenos! }:-b
Repositorio de fuentes:
https://github.com/pjmolina/event-backend
Demo. Portal usando los servicios
https://dotnetmalaga2.herokuapp.com
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
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
Go Serverless: AWS Lambda
 http://nancyfx.org
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
Swagger
 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
Configuración
 Configuración como código (hard-coded json)
 Configuración en la base de datos
 Configuración por variables de entorno process.env.VAR1
 Configuración en Consul (centralizada)
Despliegue en Heroku
git remote add heroku https://git.heroku.com/app1.git
 Si conoces git, sabes desplegar en Heroku
 Configurar:
/Procfile
 Desplegar:
git push heroku master
web: node app/server.js
Despliegue en IBM Bluemix
 IBM Bluemix usa CloudFoundry
/manifest.yml
cf login
cf create-service mongodb 100 mydb-sancho
cf push myapp-quijote -m 1024M -b sdk-for-nodejs -t 180 -i 1
cf bind-service mydb-sancho myapp-quijote
cf scale myapp-quijote -i 1
---
applications:
- name: myapp-quijote
command: node app/server.js
Despliegue con Docker (1/2)
 Dockerfile
FROM node:latest
ENV NODE_ENV=production
WORKDIR /app
RUN npm install -g grunt-cli
ADD package.json /app/
RUN npm install
ADD . /app
RUN grunt release
ENV PORT=80
EXPOSE 80
ENTRYPOINT ["node", "/app/app/server.js"]
Despliegue con Docker (2/2)
 Build
 Run
docker build –t user/appName .
docker run --name db -d -P mongo:3.0
docker run user/appName –d –P --link db:db
dbapp
Despliegue con Docker Compose
db:
image: dockerfile/mongodb
ports:
- "27017"
app:
build: .
environment:
NODE_ENV: production
PORT: 80
SERVICE_NAME: app
links:
- "db:DB"
ports:
- "80"
lb:
image: jasonwyatt/nginx-loadbalancer
links:
- app
environment:
APP_PATH: "/"
ports:
- "80:80"
docker-compose.yml
Despliegue con Docker Compose
docker-compose up –d
docker-compose scale app=3
 ¡¡Arriba, arriba!!
db
app
lb app
app
#0
#1
#2
80
80 27017
Hivepod.io
Hivepod.io
https://www.hivepod.io
class SessionTalk
{
string Title;
string? Description;
Speaker Author;
}
class Speaker
{
string Name;
string Lastname;
}
Microservicios en MEAN: Contras
 JavaScript
 WAT Programming
 Se echa de menos Strongly-typing a lot  TypeScript ¡úsalo! Nada lo impide.
 Unit Test no son un capricho  mocha, chai, Jasmine, karma, istanbul, etc
 Versionado en NPM
 Falta de un SDK base estable (a la Java o .NET)
 Demasiadas baldosas en movimiento #npmgate (mejora sobre npm: yarn)
 Cambios que rompen compatibilidad que no respetan Semantic Versioning
 Front-end JS es una non-stop fiesta cada 6 meses
Microservicios en MEAN: Pros
 Stack muy portable
 Corre en Windows, Linux, Mac sin cambios
 La mayoría de los proveedores de nube lo soportan activamente
 Prototipado rápido
 Escalado horizontal muy sencillo
 ExpressJS es muy extensible
 Ligero: provisiona y levanta muy rápido comparado con Java o .NET
clásico
Frontend vs Backend
Pero monstruos al fin y al cabo…
Monstruos diferentes
Referencias
 Código de ejemplo
https://github.com/pjmolina/event-backend
 Podcast sobre Microservicios con “El Bruno”
https://elbruno.com/2016/05/27/podcast-introduccin-a-microservicios-con-pmolinam/
 Swagger  OpenAPIs https://openapis.org
 Hivepod https://www.hivepod.io
Tecnologías para microservicios

Tecnologías para microservicios

  • 2.
    Tecnologías para MICROSERVICIOS Dr. PedroJ. Molina Fundador de http://pjmolina.com @pmolinam
  • 3.
    ¿Qué hago?  Metadev Consultoría, Formación  Cloud, Microservicios, Stack MEAN, CI  Productos en Modelado y DSL  Colaboro con Lemoncode  Cursos y mater de frontend  Ex:  CTO, Director de I+D, Arquitecto de Software, Desarrollador
  • 4.
    ¿Qué es unMicroservicio?  Estilo arquitectural  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 claro y conocido. http://martinfowler.com/articles/microservices.html
  • 5.
    Sobre la importanciade aislar los microservicios: Si la necesita, cada microservicio tiene su propia capa de persistencia. Aislados
  • 6.
    Microservicios Ventajas  Componibles  Evoluciónrá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
  • 7.
    ¿Qué es unMicroservicio?
  • 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.
    APIs agnósticas delenguaje 1. CORBA >> C + IDL 2. SOA >> XML + SOAP + WDSL … 3. REST >> JSON + HTTP
  • 10.
    Tipos MIME  Declaranel tipo de codificación a emplear  Los más frecuentes:  JSON application/json  XML text/xml  HTML text/html  Texto plano text/plain  CSV text/csv GET /actors/42 Accept: text/xml 200 OK Content-Type: text/xml <actor id="42"> <name>Jessica</name> <lastname>Alba</lastname> <filmography url= "/films/42" /> </actor>
  • 11.
    REST  REpresentational StateTransfer  Protocolo sin estado  URIs únicas para cada recurso  Semántica asociada a operaciones  GET/PUT/POST/DELETE en HTTP  Hipermedia (navegable) GET /actors/42 Accept: application/json 200 OK Content-Type: application/json { "id": 42 "name": "Jessica" "lastname": "Alba" "filmography": "/films/42" }
  • 12.
    Niveles REST Richarson MaturityModel  http://martinfowler.com/articles/richardsonMaturityModel.html  Nivel 0. HTTP y nada mas (RPC bajo HTTP)  Nivel 1. Recursos: GET /factura/217  Nivel 2. Verbos y códigos de error HTTP POST /factura/ 201 Created  Nivel 3. Controles Hipermedia <link rel=“lines” uri=“/factura/217/lines” />
  • 13.
    HATEOAS  Hypertext AsThe Engine Of Application State  API autodocumentadas, autoexplorables  Clientes más inteligentes / dinámicos
  • 14.
    HAL Estándar de Hipermedia enRecursos HATEOAS { “id”: 1234 “name”: “Alicia” “_links”: { “self”: { “href”: “/article/10”}, “prev”: { “href”: “/article/9”}, “next”: { “href”: “/article/11”}, “action-delete”: { “verb”: “DELETE”, “href”: “/article/10” } } } http://stateless.co/hal_specification.html
  • 15.
    Microservicios  Microservicios =¿SOA para Hipsters?  Abanderados  Netflix  Amazon  Thoughtworks  Building Microservices 2015, Sam Newman
  • 16.
    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
  • 17.
    Persistencia  NoSQL  MongoDB,CouchDB, Dynamo, DocumentDB  RDBM  MySql, Posgress, Oracle, Sql Server  Key-Value Stores  Redis  Memcache  Colas  RabitMQ, ZeroMQ, AMZ SQS, Azure Queues  Blobs  Amazon S3  Azure Blobs
  • 18.
  • 19.
    Demo. Ejemplo Sitio enProducción: https://dotnetmalaga.herokuapp.com demo / 1234 ¡Sed buenos! }:-b Repositorio de fuentes: https://github.com/pjmolina/event-backend
  • 20.
    Demo. Portal usandolos servicios https://dotnetmalaga2.herokuapp.com
  • 21.
    MEAN Stack: Arquitectura ClientExpressJS BaucisJS Mongoose MongoDB HTTP req resource query/command data 401 | 403 AuthN/AuthZ middleware <req.user, res> Microservice
  • 22.
    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
  • 23.
    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()
  • 24.
    .NET Core +NancyFX  http://nancyfx.org public class SampleModule : Nancy.NancyModule { public SampleModule() { Get["/hello"] = _ => “hello world"; } } /helloreq res
  • 25.
    Go Serverless!  Códigosin preocuparse* por la infrastructura  Amazon Lambda Functions http://docs.aws.amazon.com/lambda  Google Cloud Functions  IBM OpenWhisk  Azure Functions
  • 26.
    Go Serverless: AWSLambda  http://nancyfx.org 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
  • 27.
    Swagger  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
  • 28.
    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
  • 29.
    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
  • 30.
  • 31.
  • 32.
  • 33.
  • 34.
    Configuración  Configuración comocódigo (hard-coded json)  Configuración en la base de datos  Configuración por variables de entorno process.env.VAR1  Configuración en Consul (centralizada)
  • 35.
    Despliegue en Heroku gitremote add heroku https://git.heroku.com/app1.git  Si conoces git, sabes desplegar en Heroku  Configurar: /Procfile  Desplegar: git push heroku master web: node app/server.js
  • 36.
    Despliegue en IBMBluemix  IBM Bluemix usa CloudFoundry /manifest.yml cf login cf create-service mongodb 100 mydb-sancho cf push myapp-quijote -m 1024M -b sdk-for-nodejs -t 180 -i 1 cf bind-service mydb-sancho myapp-quijote cf scale myapp-quijote -i 1 --- applications: - name: myapp-quijote command: node app/server.js
  • 37.
    Despliegue con Docker(1/2)  Dockerfile FROM node:latest ENV NODE_ENV=production WORKDIR /app RUN npm install -g grunt-cli ADD package.json /app/ RUN npm install ADD . /app RUN grunt release ENV PORT=80 EXPOSE 80 ENTRYPOINT ["node", "/app/app/server.js"]
  • 38.
    Despliegue con Docker(2/2)  Build  Run docker build –t user/appName . docker run --name db -d -P mongo:3.0 docker run user/appName –d –P --link db:db dbapp
  • 39.
    Despliegue con DockerCompose db: image: dockerfile/mongodb ports: - "27017" app: build: . environment: NODE_ENV: production PORT: 80 SERVICE_NAME: app links: - "db:DB" ports: - "80" lb: image: jasonwyatt/nginx-loadbalancer links: - app environment: APP_PATH: "/" ports: - "80:80" docker-compose.yml
  • 40.
    Despliegue con DockerCompose docker-compose up –d docker-compose scale app=3  ¡¡Arriba, arriba!! db app lb app app #0 #1 #2 80 80 27017
  • 41.
  • 42.
    Hivepod.io https://www.hivepod.io class SessionTalk { string Title; string?Description; Speaker Author; } class Speaker { string Name; string Lastname; }
  • 43.
    Microservicios en MEAN:Contras  JavaScript  WAT Programming  Se echa de menos Strongly-typing a lot  TypeScript ¡úsalo! Nada lo impide.  Unit Test no son un capricho  mocha, chai, Jasmine, karma, istanbul, etc  Versionado en NPM  Falta de un SDK base estable (a la Java o .NET)  Demasiadas baldosas en movimiento #npmgate (mejora sobre npm: yarn)  Cambios que rompen compatibilidad que no respetan Semantic Versioning  Front-end JS es una non-stop fiesta cada 6 meses
  • 44.
    Microservicios en MEAN:Pros  Stack muy portable  Corre en Windows, Linux, Mac sin cambios  La mayoría de los proveedores de nube lo soportan activamente  Prototipado rápido  Escalado horizontal muy sencillo  ExpressJS es muy extensible  Ligero: provisiona y levanta muy rápido comparado con Java o .NET clásico
  • 45.
    Frontend vs Backend Peromonstruos al fin y al cabo… Monstruos diferentes
  • 46.
    Referencias  Código deejemplo https://github.com/pjmolina/event-backend  Podcast sobre Microservicios con “El Bruno” https://elbruno.com/2016/05/27/podcast-introduccin-a-microservicios-con-pmolinam/  Swagger  OpenAPIs https://openapis.org  Hivepod https://www.hivepod.io