Jan 01, 1970
1,513 lecturas
Diseño de microservicios con propósito
por John Vester2022/06/30
Demasiado Largo; Para Leer
La creación de microservicios con un propósito siempre debe ser un objetivo. Descubra cómo Render Blueprints puede ofrecer una estrategia de microservicios reproducible.Company Mentioned
Las palabras de moda no son algo que esperaba cuando comencé mi carrera. En aquellos días, la mayoría de las noticias sobre tecnología llegaban en publicaciones semanales en papel como InformationWeek y Network World. Recuerdo haber pensado para mis adentros: "Hombre, están usando estas mismas palabras una y otra vez cada semana".
Eso se tradujo en personas que usaban palabras de moda... todo el tiempo. En aquel entonces, mis dos palabras de moda favoritas eran las referencias a Internet como la "red mundial" y la "autopista de la información". Siempre me pregunté si habría una súper autopista en algún momento.
Sin embargo, recientemente, noté que las palabras de moda se usan como marcadores de posición donde no tienen mucho sentido. Términos como microservicios, arquitectura basada en eventos, IA y ML se usan en contextos que me llevan a concluir que muchas personas no los entienden del todo. Yo tampoco me esperaba esto…
Imagina esta simple conversación relacionada con una pregunta mal entendida:
Persona #1: ¿A qué hora sale tu vuelo?
Persona #2: A finales de este año.
Si bien la Persona n.º 2 proporciona una respuesta que no es incorrecta, la respuesta realmente no aporta ningún valor a la consulta de la Persona n.º 1.
En esa misma línea, la búsqueda para migrar a microservicios ha enfrentado desafíos similares. La mayoría de las veces, he trabajado con clientes y corporaciones cuyo diseño de "microservicio" dio como resultado un único monoservicio. Básicamente, se reemplazó una aplicación monolítica con una API RESTful realmente grande.
Para esta publicación, pensé que sería divertido analizar un ejemplo de cómo crear un diseño de microservicio orientado a un propósito... de la manera correcta.
El diseño de microservicios orientado al propósito
Un microservicio orientado a un propósito es un servicio que puede valerse por sí mismo y puede incluir un almacén de persistencia dedicado cuando sea necesario. Al estar orientado a un propósito, el microservicio proporcionará un conjunto específico de información y será el sistema de registro de los datos que se rigen dentro de las API asociadas.
Al adoptar el enfoque de microservicio orientado a un propósito, los usuarios pueden agregar nodos adicionales y reducir los nodos existentes para satisfacer las necesidades de la API en ese momento.
Por ejemplo, un microservicio orientado a un propósito centrado en un aspecto de los impuestos sobre la renta puede experimentar el mayor uso durante la primera parte del año y requerir menos instancias en ejecución en la segunda mitad.
Centrémonos en la creación de un diseño de microservicio orientado a un propósito usando un ejemplo muy simple.
Creación de un microservicio basado en Docker
los
Se rumorea que la familia imperial de la dinastía Qing se basó en esta misma cuadrícula para la selección de género de los hijos, que fueron favorecidos por el trabajo y el dinero que podían proporcionar a sus familias, así como por continuar con el linaje familiar.
A continuación se muestra una ilustración de la cuadrícula del predictor de género chino:
Como ejemplo, una madre de 18 años que concibió un hijo en enero tendría un bebé femenino.
Para esta publicación, crearemos un microservicio orientado a un propósito que devuelva una predicción de género basada en los mismos criterios. La carga útil resultante para el ejemplo anterior aparecería como se muestra a continuación:
{ "month": 1, "age": 18, "gender": "female", "errorMessage": null }
El microservicio utilizará Java y Spring Boot y empleará un Dockerfile de varias etapas para compilar el servicio y crear una imagen de Docker que pueda alojar las API de predicción de nacimiento.
El código para el servicio se puede encontrar en GitLab en la siguiente dirección:
Creación de un patrón reproducible usando planos de renderizado
He escrito sobre la plataforma __ Render __ en las siguientes publicaciones:
Para mis instancias personales que se ejecutan en Render, he usado el lenguaje de programación Go, sitios estáticos y una instancia de Postgres. Esta vez, escribí el servicio en Java/Spring Boot. Si bien aún no existe soporte nativo para Java, la plataforma Render incluye soporte para cualquier cosa que se ejecute en un contenedor Docker.
Dado que el servicio de predicción de nacimientos incluye un Dockerfile de varias etapas, quería ver lo fácil que es implementar un servicio basado en Docker en la plataforma Render. Sin embargo, noté la
¿Qué es un Blueprint?
Un Blueprint es la implementación de Render de Infraestructura como código (IaC). IaC también es algo que agrupo en un concepto más amplio llamado "* como código". Las organizaciones que necesitan administrar una implementación de varios servicios o que tienen servicios que requieren muchas opciones pueden definir su infraestructura de Render (servicios, bases de datos y grupos de entornos) como código en un archivo render.yaml.
Usando el modelo de renderizado
Basándose en el ejemplo de Blueprint proporcionado
services: - type: web name: restful-api-spring-boot env: docker region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443
A partir de ahí, personalicé los datos YAML para el servicio de predicción de nacimientos para actualizar la propiedad de nombre y agregar una propiedad de repositorio, como se indica a continuación:
services: - type: web name: birth-predictor env: docker repo: https://gitlab.com/johnjvester/birth-predictor region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443
Esta información se almacenó en la raíz del repositorio birth-predictor , en un archivo llamado render.yaml . Después de confirmar y fusionar este cambio, el servicio estaba listo para implementarse en la plataforma Render.
Desde el Tablero de procesamiento, seleccioné Nuevo | Opción de plano :
Luego, seleccioné el repositorio de predictores de nacimiento, que conecté a mi cuenta de GitLab usando las instrucciones encontradas
Como estaba usando un Blueprint, todo lo que tenía que hacer era proporcionar un nombre de grupo de servicios para mi nuevo servicio:
Después de presionar el botón Aplicar , comenzó el proceso de implementación:
Unos minutos más tarde, el servicio se implementó sin ningún problema:
Predictor de nacimiento en acción
Con el servicio de predicción de nacimiento en ejecución, puedo emitir el siguiente comando cURL para obtener una nueva predicción:
curl --location --request POST 'https://birth-predictor.onrender.com/predict' \ --header 'Content-Type: application/json' \ --data-raw '{ "conceptionMonth" : 11, "conceptionAge" : 43 }'
La carga de respuesta resultante se ve así:
{ "month": 11, "age": 43, "gender": "male", "errorMessage": null }
Esta información simplemente coincide con el mes de la concepción y la edad de mi esposa en el momento en que nuestro hijo (Finny) fue concebido. ¡En agosto de 2017 llegó!
Al igual que lo hicieron durante la dinastía Qing, pudimos confiar en el Predictor de género chino para pronosticar con éxito el sexo de nuestro hijo.
Conclusión
Desde 2021, he estado tratando de vivir de acuerdo con la siguiente declaración de misión, que creo que puede aplicarse a cualquier profesional de TI:
“Concentre su tiempo en ofrecer características/funcionalidades que amplíen el valor de su propiedad intelectual. Aproveche los marcos, productos y servicios para todo lo demás”.
-J. Vester
La especificación Blueprints de Render se adhiere a mi declaración de misión al permitir que los equipos de funciones y servicios se concentren en cumplir con los objetivos y metas establecidos, sin preocuparse por nada relacionado con DevOps.
Una vez que el servicio, el componente o la aplicación están listos, los equipos simplemente deben incluir el archivo render.yaml en la raíz de su repositorio y luego crear un nuevo servicio en la plataforma Render usando la opción Blueprint. En el futuro, cualquier actualización del repositorio conectado se implementará automáticamente minutos después de enviar el código a la rama indicada.
La plataforma Render vive con una mentalidad Zero DevOps, que es evidente en el origen del concepto Blueprint. Los desarrolladores de funciones y servicios quieren, y deben, centrarse en ofrecer actualizaciones y funcionalidades que brinden el máximo valor a sus partes interesadas. Render realmente entiende esta realidad.
Estoy seguro de que las palabras de moda siempre serán parte del espacio tecnológico. Sin embargo, comprender y adoptar la verdadera intención detrás de esas palabras de moda es algo que espero que los tecnólogos busquen.
Si está interesado en el código fuente de esta publicación, puede encontrarlo en GitLab en la siguiente dirección:
¡Que tengas un gran día!
L O A D I N G
. . . comments & more!
. . . comments & more!
