Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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...
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
▫︎Promuev...
INTEGRACIÓN CONTÍNUA (CI)
5
▫︎Práctica de desarrollo
▫︎Devs suben código a un
servidor de control de
versiones varias vece...
ENTREGA CONTINUA (CD)
6
▫︎Prácticas diseñadas
para asegurar que el
software puede ser
desplegado en
producción de
manera s...
DESPLIEGUE CONTÍNUO
7
▫︎Más allá de la entrega contínua
▫︎Cada cambio que pasa por el proceso se
despliega automáticamente...
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
a...
AUTOMATIZACIÓN DE INFRAESTRUCTURAS
10
▫︎Creación de procesos
automáticos que
configuran servidores y
servicios.
▫︎Reduce fa...
EQUIPOS PEQUEÑOS Y AUTÓNOMOS
11
▫︎You build it you run it!
▫︎La responsabilidad de
mantener el software en
producción se c...
ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
▫︎Patrón de diseño en el que múltiples
servicios colaboran para proveer ciertas
c...
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óst...
HERRAMIENTAS QUE LOS HACEN POSIBLES
▫︎Entrega Continua
▫︎Automatización de infraestructuras
▫︎Virtualización por demanda
▫...
BENEFICIOS - FLEXIBILIDAD TECNOLÓGICA
18
▫︎La herramienta correcta
para el trabajo
▫︎Impulsa la innovación
con riesgos mín...
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.
▫︎Microserv...
BENEFICIOS - DISTRIBUCIÓN DE RESPONSABILIDADES
▫︎División de servicios entre equipos más
pequeños
▫︎Evita posibles conflict...
BENEFICIOS - REUSABILIDAD DE FUNCIONALIDADES
23
▫︎Un servicio puede ser
usado por múltiples
clientes.
http://expertintegra...
BENEFICIOS - FACILIDAD DE REEMPLAZO
▫︎Al ser pequeños son más fácil de eliminar,
juntar o separar.
▫︎No existe el apego em...
RIESGOS
▫︎Mantenibilidad de la infraestructura
▫︎Acciones: automatizar la creación de nuevos microservicios.
▫︎Rendimiento...
RIESGOS
▫︎Monitoreo y logging
▫︎Acciones: centralizar los logs (Logstash). Uso de métricas y herramientas de
consulta de e...
¿POR QUÉ NO USAR LIBRERÍAS?
▫︎Aportan reusabilidad y acceso a la misma
funcionalidad desde varios sitios.
▫︎Pero:
▫︎Tienen...
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...
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 ...
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 a...
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: ...
DEFINICIÓN DE ESTÁNDARES MÍNIMOS
▫︎Interfaces
▫︎ 1 o 2 tecnologías
soportadas
▫︎ ¿Cómo manejamos
paginación?
▫︎ Versionami...
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/...
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,
i...
BROWN-FIELD PROJECT
▫︎Separa estos contextos en paquetes y trata
de analizar las dependencias a nivel de
código. Si existe...
Mi Sistema
BROWN-FIELD PROJECT
▫︎Elige el contexto que
más se va a
beneficiar si lo
separas (distribución
de trabajo, carga...
BROWN-FIELD PROJECT
▫︎Elimina la integración a nivel de Bases de
datos (usa llamadas a servicios en vez de
llamadas a BD)....
YOU MUST BE THIS TALL TO DO MICROSERVICES
▫︎ Madurez técnica (TDD, o
por lo menos alta
cobertura de tests en
todos los niv...
MAS INFO
▫︎Divide y Vencerás
53
@mariascandella
mgomez@thoughtworks.com
GRACIAS
maria-gomez.me
Upcoming SlideShare
Loading in …5
×

Divide y Vencerás: introducción a los Microservicios

5,523 views

Published on

Actualmente está muy de moda los términos SOA, descentralización de servicios, microservicios... pero, ¿qué significan realmente?

En esta charla intentaremos aclarar estas dudas además de explicar como podemos utilizar los nuevos paradigmas y diseños arquitectónicos para crear aplicaciones sencillas de construir, escalables y que sigan cumpliendo los requerimientos del negocio.

Esta charla se presentó por primera vez en el evento ComparTI/Tech Stage en las oficinas de Thoughtworks Quito en Enero de 2015. http://info.thoughtworks.com/ComparTI-Quito-Enero_Registration-Page.html

Published in: Technology

Divide y Vencerás: introducción a los Microservicios

  1. 1. 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
  2. 2. ¿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
  3. 3. CONCEPTOS 3
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. ARQUITECTURA EVOLUTIVA 8 t Arquitectura Esperada Realidad t Tradicional Agile http://about.me/faustodelatog
  9. 9. VIRTUALIZACIÓN EN DEMANDA 9 ▫︎Capacidad de crear nuevas máquinas virtuales de manera automática. ▫︎Reduce los tiempos de aprovisionamiento de nuevos servidores
  10. 10. 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.
  11. 11. 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
  12. 12. 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
  13. 13. ARQUITECTURA ORIENTADA A SERVICIOS (SOA) 13 Web services SOAP ESB
  14. 14. MICROSERVICIOS 14
  15. 15. ¿QUÉ SON? ▫︎Implementación de SOA 15
  16. 16. 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
  17. 17. HERRAMIENTAS QUE LOS HACEN POSIBLES ▫︎Entrega Continua ▫︎Automatización de infraestructuras ▫︎Virtualización por demanda ▫︎Equipos pequeños y autónomos 17
  18. 18. BENEFICIOS - FLEXIBILIDAD TECNOLÓGICA 18 ▫︎La herramienta correcta para el trabajo ▫︎Impulsa la innovación con riesgos mínimos
  19. 19. BENEFICIOS - ESCALABILIDAD 19 Monolíticas Micro Servicios http://about.me/faustodelatog
  20. 20. BENEFICIOS - ESCALABILIDAD 20 https://flic.kr/p/aDZvrM
  21. 21. 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
  22. 22. 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
  23. 23. BENEFICIOS - REUSABILIDAD DE FUNCIONALIDADES 23 ▫︎Un servicio puede ser usado por múltiples clientes. http://expertintegratedsystemsblog.com/wp-content/uploads/2014/06/LEGO.jpg
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. ¿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
  28. 28. MANOS A LA OBRA 28
  29. 29. PAPEL DEL ARQUITECTO 29
  30. 30. PAPEL DEL ARQUITECTO TOWN PLANNER 30
  31. 31. PAPEL DEL ARQUITECTO TOWN PLANNER ▫︎No hace planos sino que traza líneas que ayudan a delimitar zonas. 31 https://flic.kr/p/ofKn1e
  32. 32. PAPEL DEL ARQUITECTO TOWN PLANNER ▫︎Pasa tiempo con el equipo, entiende sus desafíos y discute las ideas con ellos. 32
  33. 33. PAPEL DEL ARQUITECTO CITY PLANNER ▫︎Se asegura de que las funcionalidades implementadas son las adecuadas y agregan valor al cliente. 33
  34. 34. PAPEL DEL ARQUITECTO CITY PLANNER ▫︎Se adapta a los cambios (tanto del negocio como técnicos) 34
  35. 35. ¿CÓMO EMPIEZO? 35
  36. 36. 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].
  37. 37. DEFINICIÓN DE ESTÁNDARES MÍNIMOS ▫︎Monitoreo ▫︎ Estado de los servicios ▫︎ Tiempos de respuesta ▫︎ …. 37
  38. 38. DEFINICIÓN DE ESTÁNDARES MÍNIMOS ▫︎Microcontainers para ayudar al desarrollo ▫︎ JVM: Dropwizard ▫︎ Ruby: Sinatra ▫︎ .NET: Nancy 38
  39. 39. DEFINICIÓN DE ESTÁNDARES MÍNIMOS ▫︎Interfaces ▫︎ 1 o 2 tecnologías soportadas ▫︎ ¿Cómo manejamos paginación? ▫︎ Versionamiento de servicios 39
  40. 40. DEFINICIÓN DE ESTÁNDARES MÍNIMOS ▫︎Deuda técnica ▫︎ ¿Cómo la manejamos y la damos seguimiento? ▫︎ ¿Cómo la socializamos? 40
  41. 41. DEFINICIÓN DE ESTÁNDARES MÍNIMOS 41
  42. 42. 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
  43. 43. ENTREGA CONTINUA 43
  44. 44. ENTREGA CONTINUA 44
  45. 45. GREENFIELD PROJECT 45 https://flic.kr/p/eZC6ps
  46. 46. GREENFIELD PROJECT ▫︎Empieza con un servicio hasta que el sistema evolucione y te “pida” que lo extraigas a otro. 46
  47. 47. BROWNFIELD PROJECT 47 https://flic.kr/p/4dMsJW
  48. 48. Mi Sistema BROWN-FIELD PROJECT ▫︎Empieza por identificar los diferentes contextos que existen en la organización (ventas, inventario, clientes….) 48 Ventas Productos Clientes
  49. 49. BROWN-FIELD PROJECT ▫︎Separa estos contextos en paquetes y trata de analizar las dependencias a nivel de código. Si existen, elimínalas. 49
  50. 50. 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
  51. 51. 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].
  52. 52. 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
  53. 53. MAS INFO ▫︎Divide y Vencerás 53
  54. 54. @mariascandella mgomez@thoughtworks.com GRACIAS maria-gomez.me

×