1. Micro vsnano
Servicios
Pedro J. Molina
https://pjmolina.com
@pmolinamhttps://metadev.pro
μ n

2. Pedro J. Molina
@pmolinam

3. Agenda
 Micro-servicios
 Nano-servicios
 Casos de uso
Conclusiones

4. 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

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 importancia de aislar los microservicios:
Si la necesita,
cada microservicio tiene su propia capa de persistencia.
Aislados

8. 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…

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. Stack MEAN Dev
Local
:27001
Local
:5000
-
Navegador
Nube
db
:27001
app
:80
-
Navegador
Producción
cluster
:27001
app :80
-
Navegador
lb: 443

12. Demo. Ejemplo
Sitio en Producción:
https://openapi3.herokuapp.com
demo / demo
¡Sed buenos! }:-b
Repositorio de fuentes:
https://github.com/pjmolina/event-backend

13. MEAN Stack: Arquitectura
Client ExpressJS BaucisJS Mongoose MongoDB
HTTP req
resource
query/command
data
401 | 403
AuthN/AuthZ
middleware
<req.user, res>
Microservice

14. 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

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 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

18. 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

19. 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

20. Registro y descubrimiento
Consul

21. Monitorización
newRelic

22. Monitorización
Prometheus

23. Logs
papertrail

24. 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

25. Nano-servicio
 ¿¡Microservicio más pequeñ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 y librerí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íticas mó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