Creación de aplicaciones basados en los 12 factores.

Una arquitectura de microservicio exitosa requiere un sólido desarrollo de aplicaciones y prácticas de DevOps. Uno de los resúmenes más sucintos de estas prácticas se puede encontrar en el manifiesto de la aplicación TwelveFactor de Heroku. Este documento proporciona 12 prácticas recomendadas que siempre debemos de tener en cuenta al crear microservicios.

1. Base de código: todo el código de la aplicación y la información de aprovisionamiento del servidor deben estar en control de versiones. Cada microservicio debe tener su propio repositorio de código independiente dentro de los sistemas de control de fuente. 
2. Dependencias: declara explícitamente las dependencias que usa tu aplicación mediante herramientas de compilación como Maven (Java). La dependencia de JAR de terceros debe declararse utilizando sus números de versión específicos. Esto permite que su microservicio siempre se compile utilizando la misma versión de bibliotecas.
3. Config: almacene la configuración de su aplicación (especialmente la configuración específica de su entorno) independientemente de su código. La configuración de su aplicación nunca debe estar en el mismo repositorio que su código fuente.
4. Servicios de respaldo: su microservicio a menudo se comunicará a través de una red con una base de datos o un sistema de mensajería. Cuando lo haga, debe asegurarse de que, en cualquier momento, pueda cambiar su implementación de la base de datos de un servicio administrado internamente a un servicio de terceros. 
5. Cree, publique, ejecute: mantenga las partes de la implementación de la aplicación, compiladas, publicadas y ejecutadas completamente separadas. Una vez que se crea el código, el desarrollador nunca debe realizar cambios en el código en tiempo de ejecución. Cualquier cambio debe volver al proceso de compilación y volver a implementarse. Un servicio construido es inmutable y no se puede cambiar.
6. Procesos: sus microservicios siempre deben ser sin estado. Se pueden eliminar y reemplazar en cualquier tiempo de espera sin temor a que una instancia de pérdida de un servicio provoque la pérdida de datos.
7. Enlace de puertos: un microservicio es completamente autónomo con el motor de tiempo de ejecución para el servicio empaquetado en el ejecutable del servicio. Debe ejecutar el servicio sin la necesidad de un servidor web o de aplicaciones separado. El servicio debe iniciarse por sí mismo en la línea de comando y se debe acceder a él inmediatamente a través de un puerto HTTP expuesto.
8. Simultaneidad: cuando necesite escalar, no confíe en un modelo de subprocesos dentro de un solo servicio. En su lugar, lance más instancias de microservicio y escale horizontalmente. Esto no excluye el uso de subprocesos dentro de su microservicio, pero no confíe en él como su único mecanismo para escalar. Escala horizontalmente, no hacia arriba.
9. Desechabilidad: los microservicios son desechables y se pueden iniciar y detener a pedido. El tiempo de inicio debe minimizarse y los procesos deben cerrarse correctamente cuando reciben una señal de interrupción del sistema operativo.
10. Paridad desarrollo / producción: minimice las brechas que existen entre todos los entornos en los que se ejecuta el servicio (incluido el escritorio del desarrollador). Un desarrollador debe usar la misma infraestructura localmente para el desarrollo del servicio en el que se ejecutará el servicio real. También significa que la cantidad de tiempo que se implementa un servicio entre entornos debe ser de horas, no de semanas. Tan pronto como se confirme el código, debe probarse y luego promoverse lo más rápido posible desde Dev hasta Prod.
11. Registros: los registros son una secuencia de eventos. A medida que se escriben los registros, deben poder transmitirse a herramientas, como Splunk (http://splunk.com) o Fluentd (http://fluentd.org), que recopilarán los registros y los escribirán en una ubicación central. El microservicio nunca debe preocuparse por la mecánica de cómo sucede esto y el desarrollador debe mirar visualmente los registros a través de STDOUT a medida que se escriben.
12. Procesos de administración: los desarrolladores a menudo tendrán que realizar tareas administrativas en sus servicios (migración o conversión de datos). Estas tareas nunca deben ser ad hoc y, en cambio, deben realizarse a través de scripts que se administran y mantienen a través del repositorio de código fuente. Estas secuencias de comandos deben ser repetibles y no cambiar (el código de la secuencia de comandos no se modifica para cada entorno) en cada entorno en el que se ejecutan.

Dejo link: https://12factor.net/

Cuando no usar Microservicios?

Creo que hay un post anterior similar, pero bueno, el publico se renueva :D

Tenemos 4 características de los microservicios que nos dejan inferir los escenarios que no estaría bueno usarlos :

Complejidad de la construcción de sistemas distribuidos: debido a que los microservicios están distribuidos y son pequeños, introducen un nivel de complejidad en las aplicaciones que no estaría en aplicaciones monolíticas. Las arquitecturas de microservicios requieren un alto grado de madurez operativa. No sé debe considerar el uso de microservicios a menos que la organización esté dispuesta a invertir en la automatización y el trabajo operativo (monitoreo, escalado) que una aplicación altamente distribuida necesita para tener éxito.

Expansión de servidores: uno de los modelos de implementación más comunes para microservicios es tener una instancia de microservicio implementada en un servidor. En una gran aplicación basada en microservicios, puede terminar con 50 a 100 servidores o contenedores (generalmente virtuales) que deben construirse y mantenerse solo en producción. Incluso con el menor costo de ejecutar estos servicios en la nube, la complejidad operativa de tener que administrar y monitorear estos servidores puede ser tremenda. 

Tipo de aplicación: los microservicios están orientados a la reutilización y son extremadamente útiles para crear aplicaciones de gran tamaño que deben ser altamente resilientes y escalables. Esta es una de las razones por las que tantas empresas basadas en la nube han adoptado microservicios. Si está construyendo aplicaciones pequeñas a nivel departamental o aplicaciones con una base de usuarios pequeña, la complejidad asociada con la construcción de un modelo distribuido como microservicios puede ser más costosa de lo que vale la pena.

Consistencia y transformaciones de datos: a medida que comienza a analizar los microservicios, debe pensar en los patrones de uso de datos de sus servicios y cómo los consumidores de servicios los usarán. Un microservicio envuelve y abstrae una pequeña cantidad de tablas y funciona bien como un mecanismo para realizar tareas "operativas" como crear, agregar y realizar consultas simples (no complejas) en una tienda.

Si sus aplicaciones necesitan realizar una agregación o transformación de datos complejos a través de múltiples fuentes de datos, la naturaleza distribuida de los microservicios dificultará este trabajo. Sus microservicios invariablemente asumirán demasiada responsabilidad y también pueden volverse vulnerables a problemas de rendimiento.

También tenga en cuenta que no existe un estándar para realizar transacciones entre microservicios. Si necesita la gestión de transacciones, deberá crear esa lógica. La mensajería introduce latencia en las actualizaciones de datos. Sus aplicaciones deben manejar la coherencia eventual donde las actualizaciones que se aplican a sus datos pueden no aparecer de inmediato.

[eBook] Continuous API Management, 2nd Edition

  Me llego este mail de la gente de NGINX y les comparto : 

EBOOK

The second edition of this O’Reilly eBook, sponsored by NGINX, provides maturity models for individual APIs and multi-API landscapes to help you invest the right human and company resources for the right maturity level at the right time. How do you balance the desire for agility and speed with the need for robust and scalable operations? Four API experts show software architects, program directors, and product owners how to maximize the value of their APIs by managing them as products through a continuous lifecycle. In this eBook you will learn: Which API decisions you need to govern How the continuous improvement model governs change throughout an API’s lifetime About the five stages of the complete API product lifecycle How to manage APIs published by your organization Download eBook

This email was sent by: NGINX, Part of F5 Insurgentes sur 601 piso 15, CDMX, Mexico | +52 55 2789 0323 | nginx.com ©2021 F5, Inc. All rights reserved. Policies | Privacy | Trademarks | Preference Center | Unsubscribe

Free Serverless App Development O'Reilly Book

 Me llego este mail de la gente de infoQ y O'Reilly y les comparto : 

December 2021

Sent on behalf of Cockroach Labs to InfoQ Industry Email Notice Subscribers

In this hands-on guide, developers will learn to build production-ready serverless apps and services on Google Cloud Run.

Download Book

The 10-chapter book includes tutorials for building and deploying a variety of serverless applications across Google Cloud. Ultimately, developers will learn how serverless development can dramatically simplify the building and scaling of applications. This guide, authored by Wietse Venema, covers: How to build serverless apps on Google Cloud Run How to use HTTP to create unique experiences for your users How identity and access management (IAM) work in serverless environments How to deploy applications across a variety of Google Cloud services CockroachDB is an official partner of Google Cloud Run and Google. Here's our solution to integrating CockroachDB with Google Cloud Run. Download it for free and start building! Cheers, The Cockroach Labs Team

You have received this email because you opted-in to the "InfoQ Industry Email Notices" box when you registered to InfoQ.com, where we send infrequent notices on behalf of our partners, user groups, conferences, etc. To unsubscribe to the InfoQ Industry Email Notices, please click the following link: Unsubscribe - - - C4Media Inc. (InfoQ.com), 2275 Lake Shore Boulevard West, Suite #325, Toronto, Ontario, Canada, M8V 3Y3

Pants, un sistema de construcción de software multilenguaje

Pants es un sistema de construcción de software escalable. Es útil para repositorios de código de todos los tamaños, pero es particularmente valioso para aquellos que contienen múltiples piezas distintas pero interdependientes.

Pants organiza las diversas herramientas y pasos que procesan su código fuente en software implementable, que incluyen:

• Resolución de dependencia
• Generación de código
• Verificación de tipos y compilación
• Pruebas
• Linting
• Formateo
• packaging
• Introspección del proyecto

Pants es similar a herramientas como make, ant, maven, gradle, sbt, bazel y otras. Su diseño se basa en ideas e inspiración de estas herramientas anteriores, al tiempo que optimiza la velocidad, la corrección y la ergonomía en los casos de uso del mundo real de hoy.

Lo que me llamo la atención es que soporta, Python, Shell, Docker, Go, Java y Scala. Esta bueno para equipos que tengan que trabajar con varios lenguajes y tecnología y pueden compilar con una sola herramienta.  

Dejo link: https://www.pantsbuild.org/

¿Cómo saber si sus microservicios tienen el tamaño correcto?

 ¿Cómo saber si sus microservicios tienen el tamaño correcto? 

Si un microservicio es demasiado grande, es probable que vea lo siguiente:

• Un servicio con demasiadas responsabilidades: el flujo general de la lógica empresarial en el servicio es complicado y parece estar imponiendo una gama demasiado diversa de reglas empresariales.
• El servicio administra datos en una gran cantidad de tablas: un microservicio es el sistema de registro de los datos que administra. Si se encuentra almacenando datos en varias tablas o llegando a tablas fuera de la base de datos inmediata. Un microservicio no debe poseer más de tres a cinco tablas. Si lo hace, es probable que su servicio tenga demasiada responsabilidad.
• Demasiados casos de prueba: los servicios pueden crecer en tamaño y responsabilidad con el tiempo. Si tiene un servicio que comenzó con una pequeña cantidad de casos de prueba y termina con cientos de casos de prueba unitarios y de integración, es posible que deba refactorizar.

¿Qué pasa con un microservicio que es demasiado pequeño?

• Los microservicios en una parte del dominio del problema se reproducen como conejos: si todo se convierte en un microservicio, componer la lógica empresarial a partir de los servicios se convierte en complejo y difícil porque la cantidad de servicios necesarios para realizar un trabajo crece enormemente. Un error común es cuando tiene docenas de microservicios en una aplicación y cada servicio interactúa con una sola tabla de base de datos.
• Los microservicios se convierten en una colección de servicios CRUD (Crear, Reemplazar, Actualizar, Eliminar) simples; los microservicios son una expresión de la lógica empresarial y no una capa de abstracción sobre sus fuentes de datos. Si sus microservicios no hacen nada más que lógica relacionada con CRUD, probablemente sean demasiado pequeño y falte algo.

Una arquitectura de microservicios debe desarrollarse con un proceso evolutivo en el que sepa que no obtendrá el diseño correcto la primera vez. Por eso es mejor comenzar con un primer conjunto de servicios siendo más detallado con las iteraciones. También es importante no ser dogmático con su diseño. Puede encontrarse con limitaciones físicas en sus servicios donde tendrá que crear un servicio de agregación que combine datos porque dos servicios separados serán demasiado grandes, o cuando no existan límites claros entre las líneas de dominio de un servicio.

Al final, hay que adoptar un enfoque pragmático, en lugar de perder el tiempo tratando de obtener un diseño perfecto.

¿Como diseñar la arquitectura de microservicios?

El trabajo del arquitecto es proporcionar el andamiaje contra el cual los desarrolladores construirán su código para que todas las piezas de la aplicación encajen.

Al construir una arquitectura de microservicios, el arquitecto de un proyecto se centra en tres tareas clave:

•   Descomposición el problema 
•   Establecer la granularidad del servicio
•   Definición de las interfaces de servicio

Descomposición el problema : Frente a la complejidad, la mayoría de las personas intenta dividir el problema en el que están trabajando en partes manejables. Hacen esto para no tener que tratar de encajar todos los detalles del problema en sus cabezas. En cambio, desglosan el problema de manera abstracta en algunas partes clave y luego buscan las relaciones que existen entre estas partes.

En una arquitectura de microservicios, el arquitecto divide el problema empresarial en fragmentos que representan dominios de actividad discretos. Estos fragmentos encapsulan las reglas comerciales y la lógica de datos asociada con una parte particular del dominio comercial.

Aunque desea que los microservicios encapsulen todas las reglas comerciales para realizar una sola transacción, esto no siempre es factible. A menudo, tendrá situaciones en las que necesitará grupos de microservicios que trabajen en diferentes partes del dominio empresarial para completar una transacción completa. Un arquitecto separa los límites de servicio de un conjunto de microservicios al observar dónde el dominio de datos no parece encajar.

Por ejemplo, un arquitecto puede mirar un flujo de negocios que se llevará a cabo mediante código y darse cuenta de que necesita información tanto del cliente como del producto. La presencia de dos dominios de datos discretos es una buena indicación de que hay varios microservicios en juego. La forma en que interactúan las dos partes diferentes de la transacción comercial generalmente se convierte en la interfaz de servicio para los microservicios.

Separar un dominio empresarial es una forma de arte más que una ciencia en blanco y negro. Se pueden utilizar las siguientes pautas para identificar y descomponer un problema empresarial en candidatos a microservicio:

1. Describe el problema empresarial y escucha los sustantivos que usas para describir el problema. El uso de los mismos sustantivos una y otra vez al describir el problema suele ser una indicación de un dominio empresarial central y una oportunidad para un microservicio. 
2. Presta atención a los verbos. Los verbos resaltan acciones y, a menudo, representan los contornos naturales del dominio de un problema. Si se encuentra diciendo "la transacción X necesita obtener datos de la cosa A y la cosa B", eso generalmente indica que hay varios servicios en juego. 
3. Busque la cohesión de datos. A medida que divide su problema comercial en partes discretas, busque piezas de datos que estén muy relacionadas entre sí. Si de repente, durante el curso de su conversación, está leyendo o actualizando datos que son radicalmente diferentes de los que ha estado discutiendo hasta ahora, es posible que tenga otro candidato de servicio. Los microservicios deben poseer completamente sus datos.

Establecer la granularidad del servicio : Una vez que tenga un modelo de datos simplificado, podemos comenzar el proceso de definir qué microservicios necesitará en la aplicación.

El objetivo es tomar estas piezas importantes de funcionalidad y extraerlas en unidades completamente autónomas que se pueden construir e implementar independientemente de cada una. Pero extraer servicios del modelo de datos implica más que volver a empaquetar el código en proyectos separados. También se trata de extraer las tablas de la base de datos real a las que acceden los servicios y permitir que solo cada servicio individual acceda a las tablas en su dominio específico. 

Después de haber dividido un dominio problemático en partes discretas, a menudo nos encontraremos  luchando para determinar si hemos logrado el nivel correcto de granularidad para los servicios. Un microservicio que sea demasiado burdo o detallado tendrá una serie de atributos reveladores.

Cuando crea una arquitectura de microservicio, la cuestión de la granularidad es importante, pero puede usar los siguientes conceptos para determinar la solución correcta:

• Es mejor comenzar ampliamente con microservicio y refactorizar a servicios más pequeños. Es fácil exagerar cuando comienza su viaje de microservicio y convierte todo en un microservicio. Pero descomponer el dominio del problema en pequeños servicios a menudo conduce a una complejidad prematura porque los microservicios se convierten en nada más que servicios de datos detallados.
• Concéntrese primero en cómo interactuarán sus servicios entre sí: esto ayudará a establecer las interfaces generales de su dominio de problemas. Es más fácil refactorizar de un grano demasiado grueso a un grano demasiado fino.
• Las responsabilidades del servicio cambiarán con el tiempo a medida que aumente su comprensión del dominio del problema. A menudo, un microservicio adquiere responsabilidades como una nueva aplicación se solicita funcionalidad. Lo que comienza como un único microservicio puede convertirse en varios servicios, con el microservicio original actuando como una orquestación.

Definición de las interfaces de servicio: La última parte se trata de definir cómo los microservicios en su aplicación se comunicarán entre sí. Al construir lógica de negocios con microservicios, las interfaces para los servicios deben ser intuitivas y los desarrolladores deben conocer el ritmo de cómo funcionan todos los servicios en la aplicación aprendiendo uno o dos de los servicios en la aplicación.

En general, las siguientes pautas se pueden utilizar para pensar en el diseño de la interfaz de servicio:

• Adopte la filosofía REST: el enfoque REST de los servicios es fundamentalmente la adopción de HTTP como el protocolo de invocación para los servicios y el uso de verbos HTTP estándar (GET, PUT, POST y DELETE). Modele sus comportamientos básicos en torno a estos verbos HTTP.
• Use URI para comunicar la intención: el URI que usa como end-points para el servicio debe describir los diferentes recursos en su dominio de problemas y proporcionar un mecanismo básico para las relaciones de recursos dentro de su dominio de problemas.
• Use JSON para sus solicitudes y respuestas: la notación de objetos JavaScript (en otras palabras, JSON) es un protocolo de serialización de datos extremadamente liviano y es mucho más fácil de consumir que XML.
• Utilice códigos de estado HTTP para comunicar los resultados: el protocolo HTTP tiene una gran cantidad de códigos de respuesta estándar para indicar el éxito o el fracaso de un servicio. Aprender estos códigos de estado y, lo que es más importante, utilícelos de forma coherente en todos sus servicios.

Todas las pautas básicas conducen a una sola cosa: hacer que sus interfaces de servicio sean fáciles de entender y consumibles. Quiere que un desarrollador se siente y observe las interfaces de servicio y comience a usarlas. Si un microservicio no es fácil de consumir, los desarrolladores harán todo lo posible para solucionarlo y subvertir la intención de la arquitectura.

Una guía práctica sobre cómo las herramientas de gestión del tráfico de Kubernetes pueden ayudarlo a resolver los desafíos de resiliencia, visibilidad y seguridad.

La gente a Nginx me mando esta guia y la comparto con ustedes.  

NEWSLETTER

A practical guide to how Kubernetes traffic management tools – including an Ingress controller and service mesh – can help you solve the challenges of resilience, visibility, and security that come with running Kubernetes in production. Download eBook

Fleet, el IDE de nueva generación de JetBrains

JetBrains Fleet es la respuesta de JetBrains a Visual Code. 

Construido desde cero, Fleet es el resultado de 20 años de experiencia en el desarrollo de IDEs. Utiliza el motor de procesamiento de código de IntelliJ, con una arquitectura de IDE distribuida y una interfaz de usuario totalmente renovada.

Fleet es un editor de texto rápido y ligero que permite navegar por el código y editarlo rápidamente cuando lo necesite. Se inicia en pocos segundos para que pueda empezar a trabajar al momento y puede transformarse fácilmente en un IDE, gracias al motor de procesamiento de código de IntelliJ, que se ejecuta de forma independiente al editor.

Fleet hereda lo que más gusta a los desarrolladores de los IDE basados en IntelliJ: la finalización contextualizada de código en el proyecto, la navegación a las definiciones y los usos, las comprobaciones de la calidad del código sobre la marcha y los arreglos rápidos.

La arquitectura de Fleet está diseñada para que sea compatible con varias configuraciones y flujos de trabajo. Puede ejecutar Fleet en su equipo directamente o trasladar algunos de los procesos —por ejemplo, el procesamiento del código— a la nube.

Fleet ofrece una experiencia multilenguaje y una asistencia inteligente para muchos lenguajes y tecnologías, que pronto se completará con nuevos complementos específicos. Gracias a los LSP, también podrá utilizar otros servicios de lenguajes en Fleet.

Fleet está diseñado para detectar de forma automática la configuración de su proyecto a partir del código fuente, aprovechando al máximo el valor que obtiene del motor inteligente de procesamiento de código, de manera que se reduce al mínimo la necesidad de configurar el proyecto en el IDE.

Fleet ofrece una experiencia de usuario familiar y coherente para los diferentes tipos de proyecto, de modo que solo utilizará un IDE, sin importar el conjunto de tecnologías que emplee o el tipo de proyecto en el que esté trabajando.

Para que tanto usted como su equipo empiecen a trabajar en sus proyectos todavía más rápido, Fleet puede aprovechar la potencia de los entornos de desarrollo de Space. Su proyecto y Fleet se ejecutarán en una máquina virtual preconfigurada de alto rendimiento que se «prepara» y está lista para usar en pocos segundos. Puede conectarse a un entorno de desarrollo con Fleet desde su equipo personal en unos pocos clics y deshacerse de este al terminar la tarea.

Dejo link: https://www.jetbrains.com/es-es/fleet/

Libros gratuitos

 

Download IT Guides!   JAXB Tutorial The first specification of JAXB was done in March 2003 and the work process is tracked in the Java Specification Request 31. In this specification request you can find a lot of...     JavaFX Programming Cookbook JavaFX 2.0 and later is implemented as a native Java library, and applications using JavaFX are written in native Java code. JavaFX Script has been scrapped by Oracle, but development is...     Java Servlet Tutorial A servlet can almost be thought of as an applet that runs on the server side-without a face. Java servlets make many Web applications possible. Java...     Groovy Programming Cookbook Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July, 2012. Since version 2, Groovy can also be compiled statically, offering type inference and performance very close to...

Por qué están teniendo éxito las arquitecturas de microservicios?

La historia del desarrollo de software está plagada de historias de grandes proyectos de desarrollo que, después de una inversión de millones de dólares y cientos de miles de horas de desarrollador de software, y con muchas de las mejores y más brillantes mentes de la industria trabajando en ellos, de alguna manera nunca lograron para entregar algo de valor a sus clientes y literalmente colapsó bajo su propia complejidad y peso.

Estos proyectos gigantescos tendían a seguir metodologías de desarrollo en cascada grandes y tradicionales que insistían en que todos los requisitos y el diseño de la aplicación se definieran al comienzo del proyecto. Se puso tanto énfasis en conseguir que todas las especificaciones del software fueran “correctas” que hubo poco margen para cumplir con los nuevos requisitos comerciales, o refactorizar y aprender de los errores cometidos en las primeras etapas de desarrollo.

Sin embargo, la realidad es que el desarrollo de software no es un proceso lineal de definición y ejecución, sino más bien evolutivo en el que se necesitan varias iteraciones de comunicación, aprendizaje y entrega al cliente antes de que el equipo de desarrollo realmente comprenda el problema. 

Para agravar los desafíos del uso de metodologías tradicionales, es que muchas veces la granularidad de los artefactos de software que se entregan estos proyectos: 

• Estrechamente acoplado: la invocación de la lógica empresarial se realiza a nivel del lenguaje de programación en lugar de a través de protocolos como SOAP and REST. Esto aumenta en gran medida la posibilidad de que incluso un pequeño cambio en un componente de la aplicación pueda romper otras partes de la aplicación e introducir nuevos errores.
• Fugas: la mayoría de las aplicaciones de software grandes administran diferentes tipos de datos. Por ejemplo, una aplicación de gestión de relaciones con el cliente (CRM) puede gestionar información sobre clientes, ventas y productos. En un modelo tradicional, estos datos se mantienen en el mismo modelo de datos y dentro del mismo almacén de datos. Aunque existen límites obvios entre los datos, con demasiada frecuencia resulta tentador salir de un dominio para acceder directamente a los datos que pertenecen a otro equipo. Este fácil acceso a los datos crea dependencias ocultas y permite que los detalles de implementación de las estructuras de datos internas de un componente se filtren a través de toda la aplicación. Incluso pequeños cambios en una sola tabla de base de datos pueden requerir un número significativo de cambios de código y pruebas de regresión en toda la aplicación.
• Monolítico: debido a que la mayoría de los componentes de una aplicación tradicional residen en una única base de código que se comparte entre varios equipos, cada vez que se realiza un cambio en el código, se debe volver a compilar la aplicación completa, volver a ejecutar durante un ciclo de prueba completo, y redistribuido. Incluso los pequeños cambios en el código base de la aplicación, ya sean nuevos requisitos del cliente o correcciones de errores, se vuelven costosos y requieren mucho tiempo, y los grandes cambios se vuelven casi imposible de hacer de manera oportuna.

Una arquitectura basada en microservicios adopta un enfoque diferente para brindar funcionalidad. Específicamente, las arquitecturas basadas en microservicios tienen estas características:

• Restringido: los microservicios tienen un único conjunto de responsabilidades y su alcance es limitado. Los microservicios adoptan la filosofía UNIX de que una aplicación no es más que una colección de servicios donde cada servicio hace una cosa y hace esa cosa realmente bien.
• Poco acoplado: una aplicación basada en microservicios es una colección de pequeños servicios que solo interactúan entre sí a través de una especificación y no de implementación. Cada microservicio tiene una interfaz bien definida, utilizando un protocolo de invocación no propietario (por ejemplo, HTTP y REST). Siempre que la interfaz del servicio no cambie, los propietarios del microservicio tienen más libertad para realizar modificaciones en el servicio que en una arquitectura de aplicación tradicional.
• Abstración: los microservicios poseen por completo sus estructuras y fuentes de datos. Los datos que pertenecen a un microservicio solo pueden ser modificados por ese servicio. El control de acceso a la base de datos que contiene los datos del microservicio se puede bloquear para permitir que solo el servicio acceda a ella.
• Independiente: cada microservicio en una aplicación de microservicio se puede compilar e implementar independientemente de los otros servicios utilizados en la aplicación. Esto significa que los cambios se pueden aislar y probar mucho más fácilmente que con una aplicación monolítica.

¿Por qué estos atributos de la arquitectura de microservicios son importantes para el desarrollo basado en la nube? Las aplicaciones basadas en la nube en general tienen :

• Una base de usuarios grande y diversa: los diferentes clientes desean funciones diferentes y no quieren tener que esperar un ciclo de lanzamiento de aplicaciones prolongado antes de poder comenzar a usar estas funciones. Los microservicios permiten que las características se entreguen rápidamente, porque cada servicio tiene un alcance pequeño y se accede a él a través de una interfaz bien definida.
• Requisitos de tiempo de actividad extremadamente altos: debido a la naturaleza descentralizada de los microservicios, las aplicaciones basadas en microservicios pueden aislar más fácilmente fallas y problemas apartes de una aplicación sin eliminar la aplicación completa. Esto reduce el tiempo de inactividad general de las aplicaciones y las hace más resistentes a los problemas.
• Requisitos de volumen desiguales: las aplicaciones tradicionales implementadas dentro de las cuatro paredes de un centro de datos corporativo generalmente tienen patrones de uso consistentes que emergen con el tiempo. Esto simplifica la planificación de la capacidad para este tipo de aplicaciones. Pero en una aplicación basada en la nube, un simple tweet en Twitter o una publicación en Slashdot puede impulsar la demanda de una aplicación basada en la nube por las nubes.

Debido a que las aplicaciones de microservicio se dividen en pequeños componentes que se pueden implementar de forma independiente entre sí, es mucho más fácil enfocarse en los componentes que están bajo carga y escalen esos componentes horizontalmente en varios servidores en una nube.

Aunque se necesita más que personal técnico para entregar una aplicación completa, creo que la base para el desarrollo exitoso de microservicios comienza con las perspectivas de tres roles críticos:

• El arquitecto: el trabajo del arquitecto es ver el panorama general y comprender cómo se puede descomponer una aplicación en microservicios individuales y cómo los microservicios interactuarán para ofrecer una solución.
• El desarrollador de software: el desarrollador de software escribe el código y comprende en detalle cómo funcionarán el lenguaje y los marcos de desarrollo del lenguaje.
• El ingeniero de DevOps: el ingeniero de DevOps aporta inteligencia sobre cómo se implementan y administran los servicios no solo en la producción, sino también en todos los los entornos de no producción. Las palabras clave del ingeniero de DevOps son coherencia y repetibilidad en todos los entornos.