Q u i t o , E n e r o 2 0 1 5
DIVIDE Y VENCERÁS
Introducción a los microservicios
María Gómez Aguirre

¿QUIÉN SOY?
▫︎Generalist dev & Agile
coach
▫︎3 años en TW
▫︎6+ años desarrollo
web y móvil
▫︎Trabajado en UK,
India, USA y Ecuador
▫︎Múltiples proyectos
usando microservicios
2

CONCEPTOS
3

DOMAIN DRIVEN DESIGN
▫︎Patrón de diseño de
software que nos ayuda
a representar el mundo
real en forma de código
▫︎Promueve la
colaboración entre los
expertos en el giro de
negocio y el equipo
técnico
▫︎Basado en la evolución
iterativa del modelo
4

INTEGRACIÓN CONTÍNUA (CI)
5
▫︎Práctica de desarrollo
▫︎Devs suben código a un
servidor de control de
versiones varias veces al
día
▫︎Cada check-in inicia una
serie de trabajos para
asegurar la calidad y
funcionalidad del código
http://www.meranetworks.com/sites/default/files/styles/large/public/images/20122012025124.png

ENTREGA CONTINUA (CD)
6
▫︎Prácticas diseñadas
para asegurar que el
software puede ser
desplegado en
producción de
manera segura
▫︎Cada cambio en el
código se trata
como un candidato
potencial a salir a
producción
http://en.wikipedia.org/wiki/Continuous_delivery#mediaviewer/File:Continuous_Delivery_process_diagram.png

DESPLIEGUE CONTÍNUO
7
▫︎Más allá de la entrega contínua
▫︎Cada cambio que pasa por el proceso se
despliega automáticamente en producción
▫︎No es una práctica recomendada para todas
las empresas
https://puppetlabs.com/sites/default/files/Continuous_Delivery_Continuous_Deployment.jpg

ARQUITECTURA EVOLUTIVA
8
t
Arquitectura Esperada
Realidad
t
Tradicional
Agile
http://about.me/faustodelatog

VIRTUALIZACIÓN EN DEMANDA
9
▫︎Capacidad de crear
nuevas máquinas
virtuales de manera
automática.
▫︎Reduce los tiempos de
aprovisionamiento de
nuevos servidores

AUTOMATIZACIÓN DE INFRAESTRUCTURAS
10
▫︎Creación de procesos
automáticos que
configuran servidores y
servicios.
▫︎Reduce fallos ya que el
mismo script puede ser
usado para varios
ambientes.

EQUIPOS PEQUEÑOS Y AUTÓNOMOS
11
▫︎You build it you run it!
▫︎La responsabilidad de
mantener el software en
producción se comparte
entre equipos de dev e
infra.
▫︎Equipos pequeños son
responsables de ciertas
partes del código.
https://twitter.com/jesse_white/status/557606536076226560

ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
▫︎Patrón de diseño en el que múltiples
servicios colaboran para proveer ciertas
capacidades.
▫︎Un servicio es un proceso de sistema
operativo independiente.
▫︎Comunicaciones entre los servicios se
hacen a través de llamadas sobre la red.
12

ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
13
Web
services
SOAP
ESB

MICROSERVICIOS
14

¿QUÉ SON?
▫︎Implementación de SOA
15

CARACTERÍSTICAS
▫︎Pequeño, enfocado en hacer una sola cosa
▫︎Proceso independiente
▫︎Comunicación a través de API’s agnósticas
▫︎Altamente desacoplado
16

HERRAMIENTAS QUE LOS HACEN POSIBLES
▫︎Entrega Continua
▫︎Automatización de infraestructuras
▫︎Virtualización por demanda
▫︎Equipos pequeños y autónomos
17

BENEFICIOS - FLEXIBILIDAD TECNOLÓGICA
18
▫︎La herramienta correcta
para el trabajo
▫︎Impulsa la innovación
con riesgos mínimos

BENEFICIOS - ESCALABILIDAD
19
Monolíticas Micro Servicios
http://about.me/faustodelatog

BENEFICIOS - ESCALABILIDAD
20
https://flic.kr/p/aDZvrM

BENEFICIOS - FACILIDAD DE DESPLIEGUE
▫︎Monolíticas -> Un cambio requiere que toda la
aplicación se despliegue.
▫︎Microservicios -> Un cambio solo requiere el
despliegue del servicio afectado
▫︎Despliegues más rápidos y menos arriesgados
▫︎Reduce el tiempo de salida a producción (time
to market)
21

BENEFICIOS - DISTRIBUCIÓN DE RESPONSABILIDADES
▫︎División de servicios entre equipos más
pequeños
▫︎Evita posibles conflictos en el código
▫︎Promueve la productividad
22

BENEFICIOS - REUSABILIDAD DE FUNCIONALIDADES
23
▫︎Un servicio puede ser
usado por múltiples
clientes.
http://expertintegratedsystemsblog.com/wp-content/uploads/2014/06/LEGO.jpg

BENEFICIOS - FACILIDAD DE REEMPLAZO
▫︎Al ser pequeños son más fácil de eliminar,
juntar o separar.
▫︎No existe el apego emocional al código.
24

RIESGOS
▫︎Mantenibilidad de la infraestructura
▫︎Acciones: automatizar la creación de nuevos microservicios.
▫︎Rendimiento
▫︎Acciones: pruebas de rendimiento y revisión de procesos
▫︎Despliegue
▫︎Acciones: uso de los mismos scripts o procesos automáticos para
desplegar en todos los ambientes
25

RIESGOS
▫︎Monitoreo y logging
▫︎Acciones: centralizar los logs (Logstash). Uso de métricas y herramientas de
consulta de estado (New Relic).
▫︎Dependencias
▫︎Acciones: pruebas de contrato
26

¿POR QUÉ NO USAR LIBRERÍAS?
▫︎Aportan reusabilidad y acceso a la misma
funcionalidad desde varios sitios.
▫︎Pero:
▫︎Tienen que estar escritas en el mismo lenguaje o correr en la misma
plataforma
▫︎Un cambio en una librería significa un despliegue en todos sus clientes
▫︎Conclusión:
▫︎Son una buena opción para evitar duplicidad en el código, pero no
deberíamos basar la arquitectura en ellas.
27

MANOS A LA OBRA
28

PAPEL DEL ARQUITECTO
29

PAPEL DEL ARQUITECTO TOWN PLANNER
30

PAPEL DEL ARQUITECTO TOWN PLANNER
▫︎No hace planos sino que traza líneas que
ayudan a delimitar zonas.
31
https://flic.kr/p/ofKn1e

PAPEL DEL ARQUITECTO TOWN PLANNER
▫︎Pasa tiempo con el equipo, entiende sus
desafíos y discute las ideas con ellos.
32

PAPEL DEL ARQUITECTO CITY PLANNER
▫︎Se asegura de que las funcionalidades
implementadas son las adecuadas y
agregan valor al cliente.
33

PAPEL DEL ARQUITECTO CITY PLANNER
▫︎Se adapta a los cambios (tanto del negocio
como técnicos)
34

¿CÓMO EMPIEZO?
35

DEFINICIÓN DE PRINCIPIOS Y PRÁCTICAS
36
couple of years. This can be printed nicely on a singlesheet of paper and shared around,
and each idea is simple enough to be held in the average developer’s head. There is of
course more detail behind each point here, but being able to articulate this in summary
form is very useful.
Figure 2-1. A real-world example of principles and practicesNewman, S., Building Microservices, Available at: http://shop.oreilly.com/product/0636920033158.do [Accessed February 2, 2015].

DEFINICIÓN DE ESTÁNDARES MÍNIMOS
▫︎Monitoreo
▫︎ Estado de los servicios
▫︎ Tiempos de respuesta
▫︎ ….
37

DEFINICIÓN DE ESTÁNDARES MÍNIMOS
▫︎Microcontainers
para ayudar al
desarrollo
▫︎ JVM: Dropwizard
▫︎ Ruby: Sinatra
▫︎ .NET: Nancy
38

DEFINICIÓN DE ESTÁNDARES MÍNIMOS
▫︎Interfaces
▫︎ 1 o 2 tecnologías
soportadas
▫︎ ¿Cómo manejamos
paginación?
▫︎ Versionamiento de
servicios
39

DEFINICIÓN DE ESTÁNDARES MÍNIMOS
▫︎Deuda técnica
▫︎ ¿Cómo la manejamos y
la damos seguimiento?
▫︎ ¿Cómo la socializamos?
40

DEFINICIÓN DE ESTÁNDARES MÍNIMOS
41

DEFINICIÓN DE ESTÁNDARES MÍNIMOS
▫︎Pruebas de contrato
▫︎ Para integración con otros servicios
42
http://martinfowler.com/bliki/images/integrationContractTest/sketch.png

ENTREGA CONTINUA
43

ENTREGA CONTINUA
44

GREENFIELD PROJECT
45
https://flic.kr/p/eZC6ps

GREENFIELD PROJECT
▫︎Empieza con un servicio hasta que el
sistema evolucione y te “pida” que lo
extraigas a otro.
46

BROWNFIELD PROJECT
47
https://flic.kr/p/4dMsJW

Mi Sistema
BROWN-FIELD PROJECT
▫︎Empieza por
identificar los
diferentes contextos
que existen en la
organización (ventas,
inventario, clientes….)
48
Ventas
Productos
Clientes

BROWN-FIELD PROJECT
▫︎Separa estos contextos en paquetes y trata
de analizar las dependencias a nivel de
código. Si existen, elimínalas.
49

Mi Sistema
BROWN-FIELD PROJECT
▫︎Elige el contexto que
más se va a
beneficiar si lo
separas (distribución
de trabajo, carga,
tiempos de
respuesta,
tecnología…)
50
Ventas
Productos
Clientes

BROWN-FIELD PROJECT
▫︎Elimina la integración a nivel de Bases de
datos (usa llamadas a servicios en vez de
llamadas a BD).
51
Figure 6-2. Foreign-key relationship
So how do we fix things here? Well, we need to make a change in two places. Firstly, we
need to stop the Finance code reaching into the LineItem table, as this table really
belongs to the Catalog code, and we don’t want database integration happening once
CatalogandFinanceareservicesintheirownrights.Thequickestwaytodothisisrather
than having the code in Finance reach into the LineItem table, instead have expose the
data via an API call in the Catalog package that the Finance code can call. This API call
will be the forerunner of a call we will make over the wire, as we see in Figure 6-3.
Figure 6-3. Post removal of the foreign key relationship
At this point it becomes clear that we may well end up having to make two database
calls to generate the report. This is correct. And the same thing will happen if these are
two separate services too. Typically concerns around performance get raised. I have a
fairly easy answer to that - how fast does your system need to be? And how fast is it
now? If you can test its current performance and know what good performance looks
like, then you should feel confident in making a change. Sometimes making one thing
slower in exchange for other things is the right thing to do, especially if slower is still
perfectly acceptable.
Butwhatabouttheforeignkeyrelationship?Well,welosethisalltogether.Thisbecomes
a constraint we need to now manage in our resulting services rather than in the database
level.
Example: Shared Static Data
Newman, S., Building Microservices, Available at: http://shop.oreilly.com/product/0636920033158.do [Accessed February 2, 2015].

YOU MUST BE THIS TALL TO DO MICROSERVICES
▫︎ Madurez técnica (TDD, o
por lo menos alta
cobertura de tests en
todos los niveles).
▫︎ No separación Devs vs
Infraestructura (if you
build it you own it)
▫︎ Integración y entrega
continua como elementos
básicos.
52

MAS INFO
▫︎Divide y Vencerás
53

@mariascandella
mgomez@thoughtworks.com
GRACIAS
maria-gomez.me