Que tal amigas y amigos como están, regresando a los artículos el día de hoy platicaremos acerca de microservicios y partimos de que los microservicios no solo es poner aplicaciones o pedazos de aplicación sobre contenedores, una arquitectura de microservicios va mas allá, una arquitectura de microservicios es un enfoque para crear una aplicación de servidor como un conjunto de servicios pequeños, eso quiere decir que los microservicios están enfocados directamente al back-end. Esto no quiere decir que su lógica de diseño no pueda ser aplicada en otros contextos o ambientes pero la implementación en este caso es para aplicaciones de back-end.
Con microservicios cada servicio debe ejecutar su propio proceso y se comunica con otros procesos, esta comunicación puede ser síncrona o asíncrona. para poder mejorar la posibilidad de éxito de una arquitectura de microservicios hay que diseñar muy bien basándose en el dominio (reglas de negocio) y separados en contextos delimitados, ¿Te suenan estos términos?, ¡si!, estoy hablando de Domain Driven Design (DDD) pero no todo es DDD, recordemos que DDD es una arquitectura de software basada en arquitecturas limpias, tal como Clean Architecture o la arquitectura Hexagonal.
Pero ¿por que es importante una arquitectura de este estilo?, porque para estas arquitecturas el enfoque principal es enfocar la solución de software a las reglas de negocio y que estas mismas son lo mas importante de la solución de software y no tienen dependencia alguna, esta independencia disminuye el acoplamiento con otros componentes o librerías que son ajenos a las reglas del negocio y con esto mejoramos la escalabilidad, extensibilidad y mantenimiento de la solución de software, y esto, ¿Qué tiene que ver con microservicios?, bueno pues todo, ya que cuando estamos definiendo una arquitectura de nuestra aplicación casi el 99% de las veces uno de los principales atributos de calidad es escalabilidad, extensibilidad , mantenimiento de la solución, disponibilidad entre otros.
Esto lleva a otra pregunta clave al momento de decidir microservicios, ¿La solución de software es lo suficientemente grande para implementar microservicios?, ¿Son realmente necesarios?. Bien la respuesta a estas ultimas 2 preguntas depende directamente del problema a resolver pero solo como un parámetro podríamos hacer un pequeño análisis para definir algunas cuestiones:
Dominio
Aquí es analizar cuales son las reglas de negocio y que tan críticos son los procesos por ejemplo ¿que impacto tienen las reglas de negocio de la aplicación en la organización?, ¿es un impacto económico u operativo?, ¿que pasaría si alguna de las reglas de negocio no estuviera bien implementada?, si hubiera cambios operativos o de reglas ¿que tan facil deberia ser el intercambio o actualización de estas reglas?,¿son reglas de negocio cambiantes?, ¿Qué tan fragmentadas con las reglas de negocio en cuanto a contextos?, ¿Qué operación del negocio esta relacionada directamente con la aplicación?
una vez definidas y respondidas estas preguntas quizá podríamos subir al siguiente nivel en nuestro análisis.
Diseño de aplicación
Aquí ya podemos empezar a tocar temas de .NET, versiones de .NET, de preferencia versiones LTS para poder aguantar un poco las actualización o siempre mantenerse actualizados a la versión de .NET que este en este momento del diseño, patrones de desarrollo para reutilizar componentes, frameworks o librerías en .NET para no empezar todo desde cero, todo esto depende totalmente del arquitecto de software en la parte del diseño y la experiencia del equipo de desarrollo en la parte de implementación. Este diseño debe considerar la comunicación entre componentes ya sean microservicios o componentes desacoplados los cuales deben cumplir con el principio como tal de la arquitectura limpia que elijamos y de los microservicios que es la autonomía.
Un punto mas aquí que hay que mencionar son los atributos de calidad, es decir ¿Cuánta disponibilidad, escalabilidad, elasticidad quiero en la aplicación? ya que la respuesta a esta pregunta será base para definir la infraestructura que llevara nuestra solución de desarrollo de software
Infraestructura:
En este punto ya podemos pensar en protocolos de comunicación HTTP o AMQP, el sistema manejador de base de datos ya sea SQL Server, MySQL, Postgresql, también en un proveedor de nube como Azure y con ello poder usar algún servicio de contenedorizacion y administración de contenedores como Docker y Azure Kubernetes Services(AKS) y eso con preguntas como ¿Cuánto es el presupuesto?, ¿Qué tecnología se adapta a mis atributos de calidad en cuanto a escalabilidad, disponibilidad, etc.?, ¿Cuál es la experiencia del equipo de implementación para estos servicios?, ¿Es posible implementar DevOps para mejorar y dar calidad al proyecto de desarrollo?
Como ven creo yo son pocas preguntas pero créanme cuando les digo que derivado de las respuesta de estas preguntas saldrán más, estas preguntas son solo el comienzo para el diseño y creo que es fundamental empezar con estos cuestionamientos si queremos implementar una arquitectura de microservicios en nuestra solución, aquí te invito a compartir si tu llevaste algún plan o preguntas diferentes a que los compartas en los comentarios para poder ayudar a otros compañeros que están el el dilema de si implementar microservicios o no.
Déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece esta serie de artículos.
Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!
Top comments (0)