Embed Size (px)
Citation preview
Q u i t o , E n e r o 2 0 1 5
DIVIDE Y VENCERÁSIntroducció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 EsperadaRealidad
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 6
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 - 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
working practices may differ, you may want a different set of practices in different places,as long as they both map to a common set of principles. A .NET team for example mighthave one set of practices, a Java team another, with a set of practices common to both.The principles should be the same for both though.
A Real-World ExampleIn Figure 2-1 we see a real-world example from a ThoughtWorks client, which showsthe interplay of Goals, Principles and Practices. The practices on the far right can havechanged fairly reguarly, whereas the principles have remained farily static for the lastcouple 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 ofcourse more detail behind each point here, but being able to articulate this in summaryform is very useful.
Figure 2-1. A real-world example of principles and practices
It makes sense to have documentation supporting some of these items. In the mainthough, I like the idea of having example code that you can look at, inspect, and run,which embodies these ideas. Even better, we can create tooling that does the right thingout of the box. We’ll discuss that more shortly.
A Principled Approach | 15
Newman, 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
▫︎ Empieza con un servicio hasta que el sistema evolucione y te “pida” que lo extraigas a otro.
46
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, weneed to stop the Finance code reaching into the LineItem table, as this table reallybelongs to the Catalog code, and we don’t want database integration happening onceCatalog and Finance are services in their own rights. The quickest way to do this is ratherthan having the code in Finance reach into the LineItem table, instead have expose thedata via an API call in the Catalog package that the Finance code can call. This API callwill be the forerunner of a call we will make over the wire, as we see in Figure 6-3.
Example: Breaking Foreign Key Relationships | 75
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 databasecalls to generate the report. This is correct. And the same thing will happen if these aretwo separate services too. Typically concerns around performance get raised. I have afairly easy answer to that - how fast does your system need to be? And how fast is itnow? If you can test its current performance and know what good performance lookslike, then you should feel confident in making a change. Sometimes making one thingslower in exchange for other things is the right thing to do, especially if slower is stillperfectly acceptable.
But what about the foreign key relationship? Well, we lose this all together. This becomesa constraint we need to now manage in our resulting services rather than in the databaselevel.
Example: Shared Static Data
76 | Chapter 6: Splitting The Monolith
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
GRACIASmaria-gomez.me
