La idea de construir aplicaciones usando servicios ha sido siempre atractiva. ¿Por qué hacer un código desde cero cuando puede montar múltiples aplicaciones que usan o aprovechan los mismos servicios a través de APIs estándares? Mientras esos servicios estén bien aprovisionados, debería ser capaz de disfrutar enormes economías de escala.
En el pasado, los intentos de implementar esta noción colapsaron bajo el peso de la manipulación excesiva (particularmente las tendencias CORBA y SOA). Pero uno de los aspectos más interesantes de los micro servicios -básicamente pequeños programas accesibles desde API y programas de un solo uso- es que su utilidad ha sido un fenómeno popular orientado a los desarrolladores.
Para un gran ejemplo de la arquitectura de micro servicios en acción, revisé esta publicación en un blog hecha en el 2014 por Stefan Borsje, CTO y con fundador de Karma, que vende dispositivos de punto de acceso Wi-Fi a los consumidores. Según Borsje, su equipo de desarrollo se metió en el tema de micro servicios mientras desarrollaba su tienda online:
“Comenzamos con una gran aplicación en la parte de atrás y separamos pedacitos cuando esta tuvo sentido. … Con solo seguir adelante y construir la aplicación, nos familiarizamos con el problema que estábamos tratando de resolver, y mientras más nos familiarizábamos con él, más obvio se volvía que necesitábamos límites entre los aspectos de las aplicaciones. Cada vez que nos encontrábamos con algo que claramente parecía que debía ser una pieza separada, lo convertíamos en un servicio”, señaló Borsje.
El ejecutivo continuó señalando que al principio, estas piezas eran relativamente grandes, pero como con otras historias de micro servicios, han descubierto que esas piezas pueden ser más y más pequeñas.
Por ejemplo, la aplicación monolítica originalmente tenía un componente “tienda”, que el equipo de Borsje convirtió en procesamiento y realización de pedidos y seguimiento de servicios. Incluso la parte delantera de cara al público ha sido separada y convertida en servicios. Aislar funciones granulares en servicios independientes se ha traducido en un gran aumento en la productividad, señaló Borsje, en parte porque los desarrolladores no necesitan quedarse con todas las dependencias de una aplicación monolítica en sus cabezas mientras trabajan.
Para Karma, el problema más grande que han tenido con los micro servicios ha sido probarlos. Así es como Borsje lo planteó: “Las acciones y los resultados eventuales están tan lejos el uno del otro que es difícil ver las causa y el efecto exacto. Un problema puede brotar de una cadena, pero ¿en qué parte de la cadena nos fue mal?”.
Martin Fowler, el legendario co-autor del ágil manifiesto que escribió la explicación de micro servicios favorita de todos el pasado marzo, seguida por una presentación en noviembre que describió un enfoque multicapas a la hora de probar los micro servicios, abogó – evidentemente- por la unidad de pruebas de servicios individuales, pero reconoció que es inadecuado o insuficiente para determinar si el sistema completo está funcionando como debería. Él amablemente expuso una serie de estrategias de prueba de integración, componente, contrato y end-to-end que deberían ayudar a los desarrolladores a envolver sus cabezas alrededor de los problemas más grandes, y graves de los micro servicios.
Otro problema: Usted no siempre puede predecir qué micro servicios pueden, bajo ciertas circunstancias, ser abrumados por la demanda. Estoy seguro que esa es una de las razones por la cual Karma implementó su plataforma de comercio electrónico en AWS (Amazon Web Services), donde el autoescalado puede ayudar a asegurar que ningún servicio se convierta en un cuello de botella, añadiendo caballos de fuerza donde sea necesario. Tenga en cuenta que Netflix, el niño en el cartel de los micro servicios, también usa AWS -en otras palabras, los micro servicios y la nube van de la mano. Teóricamente, podría construir su propia nube autoescalable usando VMware u OpenStack, pero la dificultad de hacerlo es una de las razones por las cuales la nube privada está ganando.
Otra tecnología más reciente subyacente a los micro servicios es Docker, una tecnología para empacar aplicaciones y desplegarlas en contenedores Linux. Como resultado, los micro servicios y Docker son un ajuste perfecto -una de las razones por la cual todas las nubes públicas grandes e importantes ahora apoyan a Docker.
Obviamente nadie está diciendo que los micro servicios pueden resolver todos los problemas; pero la arquitectura de micro servicios puede tener éxito donde todos los demás enfoques basados en servicios fallaron, por lo que está subiendo y ganando popularidad rápidamente. Los desarrolladores determinan los tipos de servicios y su granularidad, y a medida que la tendencia se expande a empresas más grandes, los equipos pueden decidir qué servicios are best of breed para toda la organización.
Ese tipo de ad hoc build-out hubiera sido imposible de construir con la infraestructura del pasado. Igualmente importante, los desarrolladores ahora son mucho mejores colaborando, con un cambio en la cultura que se presta para crear una arquitectura de software de manera orgánica, en vez de seguir los edictos pasados de moda.
De lo que estoy escuchando, en muchas compañías, los desarrolladores ya están haciendo uso de la arquitectura de los micro servicios sin importar si los directivos la conocen o no. Con la infraestructura de nube correcta, ya sea pública o privada, la arquitectura de micro servicios no solo puede aumentar la productividad del desarrollador, sino también permitir el desarrollo de nuevas aplicaciones que construirlas hace algún tiempo hubiera sido totalmente inútil.
Eric Knorr, InfoWorld EE.UU.
