Llegamos a ustedes gracias a:



Reportajes y análisis

7 razones para cambiarse a los microservicios

Y 5 razones por las que podría no tener éxito

[06/07/2017] Los microservicios han estado provocando cierto movimiento entre las organizaciones de desarrollo de aplicaciones con visión a futuro, desde que el término fue acuñado por primera vez en el 2011. Pocos años después, los microservicios están a punto de volverse normal, así como afirma una encuesta reciente de Nginix, que señala que el 36% de las empresas encuestadas están usando microservicios, con otro 26% en fase de investigación. Pero ¿qué es exactamente la arquitectura de microservicios, y es adecuada para la cultura, las necesidades y las habilidades de su organización?

Aquí le echamos un vistazo a siete razones por las cuales debería considerar a los microservicios en su siguiente proyecto de desarrollo de aplicaciones, y cinco obstáculos que tendrá que derribar para tener éxito.

El caso de los microservicios

Una variante de la arquitectura orientada a servicios (SOA), los microservicios, son un estilo arquitectónico en el que las aplicaciones son descompuestas en servicios d. Con servicios detallados y protocolos ligeros, los microservicios ofrecen mayor modularidad, haciendo que las aplicaciones sean más fáciles de desarrollar, probar, implementar y, lo que es más importante, cambiar y mantener.

Sin duda su organización aún está sujeta a aplicaciones desarrolladas en la era monolítica, cuando las arquitecturas centralizadas de varios niveles eran utilizadas para crear aplicaciones enteras en una única base de código. Ese modelo de servicio al cliente era una excelente opción cuando las computadoras de escritorio gobernaban TI.

Pero con el aumento de los dispositivos móviles y la nube, los datos de back-end siempre deberían estar disponibles para una amplia gama de dispositivos, y esa arquitectura monolítica no va hacer que sea fácil, ya que cada vez que se haga un cambio, toda la aplicación tendrá que ser actualizada, abriéndole paso a posibles nuevos errores cada vez que intente añadir una característica o ajustarse a un nuevo contexto. Pero aún, como todo está vinculado a una sola base de código, no puede ampliar una función o servicio específico, sino la aplicación entera, lo que genera costos inmensamente más altos.

Con microservicios, su código se divide en servicios independientes que se ejecutan como procesos separados. El output de un servicio es utilizado como el input de otro en una orquestación de servicios independientes y comunicados. Los microservicios son especialmente útiles para los negocios que no tienen una idea preestablecida de la matriz de dispositivos que sus aplicaciones soportarán. Al ser agnóstico de dispositivos y plataformas, los microservicios permiten a las empresas desarrollar aplicaciones que proporcionen experiencias de usuario consistentes a lo largo de una amplia gama de plataformas que abarcan los entornos web, móviles, de la Internet de las cosas (IoT, por sus siglas en inglés), de monitoreo de actividad y wearables. Netflix, PayPal, Amazon, eBay, y Twitter son solo algunas de las empresas que usan microservicios.

Walmart Canada, por ejemplo, rediseñó su arquitectura de software a microservicios en el año 2012 (ver video). La empresa, que no había sido capaz de manejar los seis millones de vistas que estaba recibiendo por minuto, se dio cuenta de los resultados instantáneos con un aumento significativo en su tasa de conversión durante la noche. El tiempo de inactividad fue minimizado también, y la empresa fue capaz de reemplazar el costoso hardware por servidores virtuales x86 mucho más baratos, lo que se tradujo en un ahorro global de entre 20 y 50%.

https://www.youtube.com/watch?v=SPGCdziXlHU

Incluso si su organización no es del tamaño de Walmart o Amazon, lo microservicios puede proporcionar un gran valor. Aquí les dejamos algunos de los beneficios que su organización disfrutará si es que se cambia a microservicios.

Mayor resiliencia: Con los microservicios, toda su aplicación está descentralizada y desacoplada en servicios que actúan como entidades separadas. A diferencia de la arquitectura monolítica, donde una falla en el código afecta a más de un servicio o función, al usar microservicios hay un impacto mínimo de falla. Incluso cuando se desactiven varios sistemas para el mantenimiento, sus usuarios no se darán cuenta.

Escalabilidad mejorada: La escalabilidad es un aspecto clave de los microservicios. Dado que cada servicio es un componente independiente, puede escalar una sola función o servicio sin tener que escalar la aplicación completa. Los servicios cruciales para la empresa pueden ser implementados en varios servidores para aumentar la disponibilidad y el rendimiento sin impactar el desempeño de otros servicios.

La capacidad de usar la herramienta adecuada para la tarea correcta: Con los microservicios, no tiene la necesidad de estar atado a un solo proveedor, sino que tiene la flexibilidad de usar la herramienta correcta para la tarea adecuada. Cada servicio puede usar su propio lenguaje, infraestructura o servicios auxiliares, y seguir siendo capaz de comunicar fácilmente con los otros servicios en su aplicación.

Mayor rapidez de comercialización: Debido a que los microservicios funciona con servicios ligeramente acoplados, no necesita reescribir toda su base de código para añadir o modificar una función/característica. Solo realiza cambios en un servicio específico. Mediante el desarrollo de aplicaciones en incrementos menores que pueden ser probados e implementados de manera independiente, puede llevar su aplicación al mercado y comercializarla de una manera más rápida.

Una depuración y un mantenimiento más fácil: Los microservicios también facilita la depuración y la prueba de aplicaciones. Con módulos más pequeños pasando por un proceso de entrega y de prueba continuas, su capacidad de entregar aplicaciones libres de errores es mucho mejor.

Mejor ROI con un TCO reducido: Los microservicios también le permite optimizar recursos. Con los microservicios muchos equipos funcionan en servicios independientes, lo que le permite implementar más rápidamente y pivotar más fácilmente cuando lo necesite. El tiempo de desarrollo se reduce, y el código de sus equipos será más reutilizable. Al desacoplar los servicios, no tendrá que operar en máquinas caras. Las máquinas x86 básicas funcionarían muy bien. La mayor eficiencia de los microservicios no solo reduce los costos de infraestructura, sino que minimiza el tiempo de inactividad.

Entrega continua: A diferencia de las aplicaciones monolíticas, en las que los equipos dedicados trabajan en funciones discretas, tales como la interfaz del usuario, la base de datos, la lógica del servidor y las capas tecnológicas, los microservicios usan equipos multifuncionales para manejar todo el ciclo de vida de una aplicación, usando un modelo de entrega continua. Cuando los equipos de desarrolladores, de operaciones y de pruebas trabajan de manera simultánea en un solo servicio, las pruebas y la depuración se convierten en sencillas e instantáneas. Con este enfoque de desarrollo incremental, el código es continuamente desarrollado, probado e implementado, y puede usar el código de las bibliotecas existentes en lugar de reinventar la rueda.

Los microservicios no son para todas las empresas

Las empresas que han adoptado los microservicios se han dado cuenta de los beneficios significativos, y las organizaciones que ignoran este hecho pueden quedarse atrás. Pero, aunque los microservicios parecen prometedores, no todas las empresas pueden capitalizar en la arquitectura. Asegúrese de que su negocio sea capaz de manejarlo. Aquí hay algunas advertencias organizacionales.

Tendrá que estar equipado para el aprovisionamiento rápido y la implementación de la aplicación: Con el desarrollo incremental y la entrega continua, los microservicios mantienen a su organización alerta. El personal debería ser capaz de proporcionar recursos de manera instantánea para mantenerse al ritmo requerido para aprovechar al máximo a los microservicios. Si tarda días o meses en aprovisionar un servidor, se encontrará con graves problemas. De manera similar, debería ser capaz de implementar nuevos servicios o aplicaciones.

El monitoreo robusto es una necesidad: Debido a que cada servicio se basa en su propio idioma, plataforma y APIs, y usted estará orquestando varios equipos trabajando de manera simultánea en diferentes entidades de su proyecto de microservicios, necesita un monitoreo robusto para monitorear y administrar de manera eficaz y efectiva toda la infraestructura, ya que si no sabe cuándo un servicio falla o su máquina empeora, podría ser imposible localizar los problemas cuando surjan.

Debe adoptar la cultura devops: Para trabajar en equipos multifuncionales, su empresa debería incorporas la cultura y las prácticas de devops. En un entorno tradicional, los desarrolladores están enfocados en las características y en las funcionalidades, y el equipo de operaciones es responsable de los desafíos de producción. En devops, todos son responsables del aprovisionamiento de servicios -y de su fracaso.

Las pruebas pueden ser complejas: Con los microservicios las pruebas no son sencillas. Cada servicio tiene sus propias dependencias, algunas directas y otras transitivas. A medida que se agregan nuevas características, aparecerán nuevas dependencias. Controlar todo esto rápidamente se vuelve poco práctico. Además, a medida que aumenta el número de servicios, también lo hace la complejidad. Ya sea que se trate de errores de base de datos, latencia de red, problemas de almacenamiento en caché o indisponibilidad de servicios, su arquitectura de microservicios puede ser capaz de manejar un nivel razonable de errores. Por todo esto, la prueba de resiliencia y la inyección de fallas son una necesidad.

Necesita diseñar con el fracaso en mente: Diseñar para el fracaso es esencial. Debería estar preparado para manejar múltiples problemas de falla, tales como el tiempo de inactividad del sistema, un servicio lento y respuestas inesperadas. Aquí, el equilibrio de carga es importante, pero tener un plan B es otra opción importante. Cuando se produce una falla, el servicio problemático debe seguir ejecutándose en una funcionalidad degradada, sin que todo el sistema falle o se bloquee.