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