Descargar como PDF, PPTX
![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].](https://image.slidesharecdn.com/microservicios-150220014715-conversion-gate01/85/Divide-y-Venceras-introduccion-a-los-Microservicios-36-320.jpg)
![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].](https://image.slidesharecdn.com/microservicios-150220014715-conversion-gate01/85/Divide-y-Venceras-introduccion-a-los-Microservicios-51-320.jpg)
Subido porThoughtworks
Divide y Vencerás: introducción a los Microservicios
El documento presenta una introducción a los microservicios, destacando conceptos como el diseño orientado a dominios, la entrega y despliegue continuo, y la arquitectura orientada a servicios. Se detallan los beneficios, como la escalabilidad y flexibilidad tecnológica, así como los riesgos asociados a su implementación. Además, se describe el papel del arquitecto en la evolución y mantenimiento de sistemas basados en microservicios.
Más contenido relacionado
![[El comercio]php zend framework (speech)](https://cdn.slidesharecdn.com/ss_thumbnails/elcomerciophpzendframeworkspeech-120330144536-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar a Divide y Vencerás: introducción a los Microservicios
Divide y Vencerás: introducción a los Microservicios
- 1. Q u it 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. ¿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.
- 4. DOMAIN DRIVEN DESIGN ▫︎Patrónde 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. INTEGRACIÓN CONTÍNUA (CI) 5 ▫︎Prácticade 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. ENTREGA CONTINUA (CD) 6 ▫︎Prácticasdiseñ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. 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.
- 9. VIRTUALIZACIÓN EN DEMANDA 9 ▫︎Capacidadde crear nuevas máquinas virtuales de manera automática. ▫︎Reduce los tiempos de aprovisionamiento de nuevos servidores
- 10. AUTOMATIZACIÓN DE INFRAESTRUCTURAS 10 ▫︎Creaciónde procesos automáticos que configuran servidores y servicios. ▫︎Reduce fallos ya que el mismo script puede ser usado para varios ambientes.
- 11. EQUIPOS PEQUEÑOS YAUTÓ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. ARQUITECTURA ORIENTADA ASERVICIOS (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. ARQUITECTURA ORIENTADA ASERVICIOS (SOA) 13 Web services SOAP ESB
- 14.
- 15.
- 16. CARACTERÍSTICAS ▫︎Pequeño, enfocado enhacer una sola cosa ▫︎Proceso independiente ▫︎Comunicación a través de API’s agnósticas ▫︎Altamente desacoplado 16
- 17. HERRAMIENTAS QUE LOSHACEN POSIBLES ▫︎Entrega Continua ▫︎Automatización de infraestructuras ▫︎Virtualización por demanda ▫︎Equipos pequeños y autónomos 17
- 18. BENEFICIOS - FLEXIBILIDADTECNOLÓGICA 18 ▫︎La herramienta correcta para el trabajo ▫︎Impulsa la innovación con riesgos mínimos
- 19. BENEFICIOS - ESCALABILIDAD 19 MonolíticasMicro Servicios http://about.me/faustodelatog
- 20.
- 21. BENEFICIOS - FACILIDADDE 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. BENEFICIOS - DISTRIBUCIÓNDE RESPONSABILIDADES ▫︎División de servicios entre equipos más pequeños ▫︎Evita posibles conflictos en el código ▫︎Promueve la productividad 22
- 23. BENEFICIOS - REUSABILIDADDE FUNCIONALIDADES 23 ▫︎Un servicio puede ser usado por múltiples clientes. http://expertintegratedsystemsblog.com/wp-content/uploads/2014/06/LEGO.jpg
- 24. BENEFICIOS - FACILIDADDE 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. RIESGOS ▫︎Mantenibilidad de lainfraestructura ▫︎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. 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. ¿POR QUÉ NOUSAR 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. MANOS A LAOBRA 28
- 29.
- 30. PAPEL DEL ARQUITECTOTOWN PLANNER 30
- 31. PAPEL DEL ARQUITECTOTOWN PLANNER ▫︎No hace planos sino que traza líneas que ayudan a delimitar zonas. 31 https://flic.kr/p/ofKn1e
- 32. PAPEL DEL ARQUITECTOTOWN PLANNER ▫︎Pasa tiempo con el equipo, entiende sus desafíos y discute las ideas con ellos. 32
- 33. PAPEL DEL ARQUITECTOCITY PLANNER ▫︎Se asegura de que las funcionalidades implementadas son las adecuadas y agregan valor al cliente. 33
- 34. PAPEL DEL ARQUITECTOCITY PLANNER ▫︎Se adapta a los cambios (tanto del negocio como técnicos) 34
- 35.
- 36. DEFINICIÓN DE PRINCIPIOSY 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. DEFINICIÓN DE ESTÁNDARESMÍNIMOS ▫︎Monitoreo ▫︎ Estado de los servicios ▫︎ Tiempos de respuesta ▫︎ …. 37
- 38. DEFINICIÓN DE ESTÁNDARESMÍNIMOS ▫︎Microcontainers para ayudar al desarrollo ▫︎ JVM: Dropwizard ▫︎ Ruby: Sinatra ▫︎ .NET: Nancy 38
- 39. DEFINICIÓN DE ESTÁNDARESMÍNIMOS ▫︎Interfaces ▫︎ 1 o 2 tecnologías soportadas ▫︎ ¿Cómo manejamos paginación? ▫︎ Versionamiento de servicios 39
- 40. DEFINICIÓN DE ESTÁNDARESMÍNIMOS ▫︎Deuda técnica ▫︎ ¿Cómo la manejamos y la damos seguimiento? ▫︎ ¿Cómo la socializamos? 40
- 41. DEFINICIÓN DE ESTÁNDARESMÍNIMOS 41
- 42. DEFINICIÓN DE ESTÁNDARESMÍNIMOS ▫︎Pruebas de contrato ▫︎ Para integración con otros servicios 42 http://martinfowler.com/bliki/images/integrationContractTest/sketch.png
- 43.
- 44.
- 45.
- 46. GREENFIELD PROJECT ▫︎Empieza conun servicio hasta que el sistema evolucione y te “pida” que lo extraigas a otro. 46
- 47.
- 48. Mi Sistema BROWN-FIELD PROJECT ▫︎Empiezapor identificar los diferentes contextos que existen en la organización (ventas, inventario, clientes….) 48 Ventas Productos Clientes
- 49. BROWN-FIELD PROJECT ▫︎Separa estoscontextos en paquetes y trata de analizar las dependencias a nivel de código. Si existen, elimínalas. 49
- 50. Mi Sistema BROWN-FIELD PROJECT ▫︎Eligeel 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. BROWN-FIELD PROJECT ▫︎Elimina laintegració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. YOU MUST BETHIS 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. MAS INFO ▫︎Divide yVencerás 53
- 54.