Asegurarse de que todas las nuevas tecnologías desplegadas en su empresa se asientan detrás de una capa de abstracción de algún tipo puede tener beneficios duraderos. He aquí algunos consejos para empezar a utilizar los microservicios.
Según Forrester Research, Jeffrey Hammond, una arquitectura de microservicios puede conducir a una mayor velocidad, mayor previsibilidad y mejor gestión del equipo.
Pregunte cuál ha sido el mayor logro de Amazon hasta la fecha, y probablemente escuchará cómo han revolucionado las compras en línea, o cómo se han convertido en un actor creíble en los medios de comunicación y el entretenimiento. Si usted habla con un tecnólogo, podrían mencionar el surgimiento de Amazon como una de las plataformas tecnológicas preeminentes. Aunque no hay nada nuevo o emocionante en las empresas que utilizan los Servicios Web de Amazon (AWS) como plataforma, considere por un momento lo que sucedería si viajara en el tiempo y se dijera a sí mismo que pronto llegaría a confiar en Amazon como socio de infraestructura crítica.
Lo que está de moda en ConsejoTecnologico.com
La información pública parece indicar que Amazon no se propuso realmente convertirse en un actor importante de la nube, y las primeras versiones de su plataforma se construyeron en última instancia para el consumo interno. A principios de la década de 2000, Amazon estableció una política conceptualmente simple, pero de largo alcance, que todos los proyectos de TI de la empresa necesitaban para proporcionar una interfaz estandarizada que separara el servicio de la tecnología subyacente, ya que su pila de TI había crecido hasta convertirse en lo que la empresa describió como un enorme «monolito» que se estaba volviendo casi imposible de mantener.
En lugar de crear interfaces personalizadas para un sistema de seguimiento de pedidos que tendrían que modificarse en caso de que se actualizara o cambiara el software de seguimiento de pedidos subyacente, el grupo que mantenía el sistema de seguimiento de pedidos publicaría un conjunto de API estándar (Interfaces de Programación de Aplicaciones) que documentaría cómo otras aplicaciones podrían solicitar y recibir datos de seguimiento de pedidos. Estas interfaces eran esencialmente normas, y no podían modificarse sin una comunicación adecuada a los usuarios, así como un calendario definido para cualquier cambio en las interfaces existentes.
Además, estas interfaces estandarizadas estarían diseñadas para llevar a cabo una tarea única y discreta, de ahí el «micro» en el microservicio. En el diseño de sistemas tradicionales, puede pasar datos a otra aplicación que luego realiza docenas de operaciones sobre esos datos, ocultando de manera efectiva lo que ocurrió a otra persona que podría desear utilizar el servicio.
VER: Montar la revolución DevOps (PDF gratuito) (informe especial de ZDNet/ConsejoTecnologico.com)
La magia de los microservicios
De lo que Amazon se dio cuenta rápidamente fue de que con todos sus sistemas que proporcionaban microservicios simples, comunes y estables, otras partes de la compañía y, en última instancia, el público en general, podían utilizar estos servicios para crear algo nuevo, y que los productos construidos con la tecnología interna de Amazon se liberaban de los caprichos de las actualizaciones de versiones, los cambios de sistema y las actualizaciones de código, ya que siempre podían depender de que un servicio produjera un resultado consistente, independientemente de la tecnología que se utilizara para proporcionar ese resultado.
Cómo empezar con los microservicios
Para unas pocas organizaciones, puede ser posible duplicar el movimiento de Amazon y esencialmente ordenar que todos los nuevos proyectos de software sean entregados a través de microservicios. Para el resto de nosotros, puede ser más fácil empezar de forma más sencilla. Probablemente el mejor lugar para empezar simplemente es cuando se adquieren nuevos programas o plataformas. Esto es generalmente simple cuando se compra software de nube como un servicio, ya que los proveedores entregan un conjunto de microservicios preconstruidos para interactuar con los datos y la lógica del negocio.
Identificar algunos casos de uso sencillo que muestren los beneficios de los microservicios. Por ejemplo, si implementa una plataforma de ventas basada en la nube, puede aprovechar los microservicios para capturar datos en su sitio web e introducirlos en el sistema de ventas. O bien, puede desarrollar rápidamente una aplicación móvil o basada en la web en un tiempo récord que realice una tarea específica y significativa y demuestre que los microservicios hacen que la TI sea más rápida y flexible. Cuando busque áreas para construir un caso de prueba de este tipo, busque usuarios empresariales con conocimientos técnicos que estén enterrados bajo hojas de cálculo, macros y bases de datos de Access que intenten esencialmente casar la información de varios servicios de su empresa. Si bien esto puede parecer que está creando más trabajo para la TI, en última instancia, la TI debe mantener y asegurar el microservicio, mientras que los usuarios crean aplicaciones de ese servicio.
VER: Guía del líder de TI para el desarrollo ágil (Tech Pro Research)
Cómo evitar las posibles trampas
A nivel superficial, es fácil transmitir los beneficios de los microservicios. Sin embargo, a medida que comienza a planificar una transición a los microservicios, la propuesta puede resultar desalentadora. Incluso las organizaciones pequeñas tienen cientos o miles de componentes de aplicación que podrían estar disponibles a través de un microservicio.
Identificar los servicios de TI clave que potencian múltiples aplicaciones y priorizarlos para los microservicios.
Una compañía naviera podría comenzar por crear microservicios de estado de pedidos, de la misma manera que un minorista podría comenzar con servicios de inventario. También puede ser tentador crear el microservicio perfecto para cada aplicación, que se acomode a cada escenario y permutación potencial. Este enfoque es una receta para retrasar los despliegues y la sobrecomplicación. Tratar de mantener lo «micro» en microservicios haciendo que cada uno de ellos realice una tarea discreta. Siempre puede aumentar varios servicios para realizar funciones más complejas, del mismo modo que puede ampliar la funcionalidad en versiones futuras.
Para cada servicio, publique un conjunto de especificaciones que se actualicen de forma continua.
Una biblioteca completa de microservicios que no son compartidos o no están bien documentados no sirve de mucho. Recuerde que un beneficio clave de los microservicios es que se pueden construir nuevas aplicaciones sin proyectos de TI complejos y sin aprobaciones, por lo que mantener sus servicios actualizados y documentados es fundamental para obtener el beneficio de estos servicios.
Permitir la propiedad de los microservicios.
También puede haber cierta resistencia por parte de los propietarios de los diversos servicios que, en última instancia, estarán disponibles a través de una arquitectura de microservicios. Con los servicios abiertos, los equipos individuales renuncian a parte de su papel de «guardián», que puede parecer amenazador. Asegurarse de que se comunica que el alcance de su control permanece intacto, preservando la integridad de lo que sucede detrás del microservicio, y que la organización en general puede beneficiarse rápidamente de su trabajo en lugar de tener que esperar a que se produzcan interfaces complejas y puntuales.
Boletín Lo Mejor de la Semana
Nuestros editores destacan los artículos, galerías y videos de ConsejoTecnologico.com que no puede perderse para mantenerse al día con las últimas noticias, innovaciones y consejos de TI. viernes
mismo
Ver también: