[et_pb_section fb_built=”1″ admin_label=”section” _builder_version=”4.5.0″][et_pb_row admin_label=”row” _builder_version=”4.5.0″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” width=”100%” module_alignment=”left”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text admin_label=”Text” _builder_version=”4.5.0″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”]

Microservicios : Las nuevas arquitecturas necesitan nuevas culturas.

Los microservicios son pequeñas aplicaciones responsables de hacer una cosa bien en la búsqueda de un objetivo común.

Esta definición resume las definiciones generales más populares de microservicios, y construidos e implementado correctamente, los microservicios realmente pueden hacer todas las cosas maravillosas que deben hacer. Desde el punto de vista arquitectónico y de procedimiento, los microservicios tienen una serie de ventajas significativas sobre los enfoques más monolíticos hacia el desarrollo de aplicaciones. Hay razones legítimas por las que todos miramos el éxito de compañías como Amazon y Netflix, y nos encontramos pensando: “¡Microservicios! ¡Eso debe ser!”

Sin embargo, esta definición flexible omite por completo una de las motivaciones clave detrás de los microservicios de construcción: permitir que los equipos entreguen funciones a la producción más rápido y con menos fricción. Los microservicios logran la máxima utilidad solo cuando existe la cultura de software correcta. Una organización que analice los microservicios también debería adoptar, y cumplir, grandes cambios culturales en la forma en que valora la productividad del desarrollador y del operador.

En un nivel alto, hay tres verdades difíciles que las organizaciones que consideran o implementan, los microservicios tendrán que considerar. Y, como era de esperar, cada verdad se centra en las personas y la cultura más que en herramientas o arquitectura.

No puede hacer microservicios bien a menos que sea una empresa motivada para atraer y retener un gran talento en nombre del crecimiento continuo. Se necesita de una determinación real para hacer crecer continuamente el negocio y una apreciación del papel que un buen talento de software puede desempeñar en eso.

No puede hacer microservicios bien en una cultura de declive con los empleados que están atrapados en el modo de supervivencia. Una cultura de supervivencia es un tipo de entorno que ahoga la flexibilidad y la toma de riesgos que se supone que brindan los microservicios, y expulsará activamente a sus empleados más talentosos. Los creadores de software con talento son personas que están ansiosas por experimentar y descubrir nuevas mejores prácticas, en lugar de aprender qué no hacer.

No  puede pensar en hacer microservicios bien si está “promocionando” a todos sus desarrolladores más talentosos en roles de administración. La arquitectura de microservicios fue diseñada y popularizada por compañías de hipercrecimiento que priorizan la ingeniería, lo que significa que los microservicios requieren personas talentosas y capacitadas que trabajen en ellos. Algunas de estas personas prosperarán, junto con su negocio, si les brinda oportunidades para avanzar en una carrera técnica en lugar de solo una pista de administración.

Las compañías que aceptan y abordan los problemas relacionados con el declive cultural y un lento ritmo de crecimiento tendrán mejores resultados cuando intenten que los microservicios tengan éxito. Este es el por qué.

En las empresas de alto crecimiento, las personas son el proceso.

El mito de los microservicios tiene una historia de origen que comienza con Amazon y Netflix. Estas son dos de las empresas más valiosas del mundo y, al mismo tiempo, de más rápido crecimiento, y su liderazgo en adoptar nuevas arquitecturas y modelos de infraestructura ayudó a enseñar al mundo lo que significa crear aplicaciones nativas de la nube. Pero cuando pensamos ahora en las motivaciones detrás de por qué Amazon y Netflix apuestan a lo grande en microservicios, comenzamos a ver una imagen más detallada de por qué tuvieron éxito con el cambio. Un factor importante, pero poco apreciado, es que los desarrolladores calificados prosperan en entornos con acoplamiento flexible y autonomía personal.

Una arquitectura centralizada inevitablemente emitirá algo así como  multas por exceso de velocidad cultural: los resultados de los defectos que se producen al intentar entregar características a tiempo en un proyecto de software monolítico. Los desarrolladores con talento intentarán evitarlos innovando y ofreciendo ideas a la administración que ayudarán a preservar su libertad, autonomía y velocidad. Los microservicios en Amazon y Netflix no formaban parte del plan de negocios. Fueron el resultado de que los ingenieros y operadores de software encontraron una manera de reducir el esfuerzo inútil y de construir y operar sus aplicaciones de manera que faciliten un ritmo de desarrollo más rápido y seguro, sin las multas por exceso de velocidad.

Para muchas personas, un contraejemplo muy relacionado con una empresa de software de alto crecimiento es Initech, el empleador ficticio en la clásica película de culto Enredos de oficina (1999)Los personajes centrales son los desarrolladores de software que están sofocados por la falta de libertad y autonomía. Están plagados de ansiedad y falta de cuidado porque están en modo de supervivencia, tratando de mantenerse empleados (o al menos entretenidos) en una empresa que valora mucho el proceso sobre los valores de las personas. Los consultores de gestión ingresan y se les pide que reduzcan los costos, lo que provoca un pánico en la fuerza laboral de la empresa que se siente obligada a justificar su existencia. En el mundo real, como en la película, ese tipo de situación generalmente no termina bien para el empleado o empleador.

Todos quieren libertad, eficiencia y control.

Sin embargo, los microservicios siempre han querido que sucediera, en parte porque las prácticas de software heredadas pueden contribuir a una cultura estancada. Los desarrolladores siempre han querido más libertad para automatizar la infraestructura sin necesidad de hablar con las operaciones, mientras que las operaciones siempre han querido más libertad para automatizar la administración de la infraestructura, principalmente para evitar interrupciones causadas por los desarrolladores que realizan cambios constantes. Estos deseos se derivan de las dificultades inherentes a la administración de la infraestructura compartida para una aplicación monolítica.

Cada cambio en este tipo de arquitecturas es un riesgo para la estabilidad del sistema. Cada barandilla es un impedimento para el cambio. Toe-stepping es una norma en esta cultura de software, donde la falta de cuidado por parte de una persona hace que otra persona venga el fin de semana para limpiar el desorden. Así que el deseo de algo como microservicios siempre estuvo ahí. La llegada de una infraestructura más barata y automatizada, gracias a las herramientas de código abierto y nativas de la nube, ha facilitado la implementación de microservicios, pero la dificultad y el gasto de cambiar la cultura sigue siendo el principal obstáculo.

Sin embargo, solo porque puede comenzar a activar microservicios en un clúster Kubernetes no significa que deba apresurarse a hacerlo. Lo que muchas empresas no se dan cuenta es que el tiempo y el esfuerzo dedicados a implementar, y posiblemente a fallar, a los microservicios podrían gastarse mejor en examinar primero las vías de producción y potencialmente prepararse para automatizar los procesos de implementación en una práctica repetible. Si toma semanas solo para que su primera línea de código se implemente en producción, entonces debería considerar la actualización de sus herramientas para utilizar prácticas como la entrega continua.

Desea hacer la vida más fácil y eficiente para sus equipos antes de introducir un nuevo tipo de complejidad en una arquitectura.

Intente imaginar el movimiento de un monolito de un millón de líneas a 500 microservicios. Es como si un Aeropuerto grande solo tuviera una toma de corriente  en cada sala de embarque, con decenas de miles de pasajeros que vagan por el vestíbulo con la esperanza de encontrarlo y usarlo. El aeropuerto rápidamente tendría que averiguar cómo pasar de 1 salida a al menos 10,000 salidas. Una opción sería comprar muchos cables de extensión y multiplicar el número de enchufes. Terminaría con cables que envuelven los pasillos como serpientes en un avión, todo arraigado desde un solo zócalo. Ningún aeropuerto haría esto, pero lo hacemos en software todo el tiempo.

O podría hacer lo correcto: derribar algunas paredes y volver a cablear el sistema para soportar más enchufes de pared. Hacer lo correcto requiere valor y requiere una mentalidad desde arriba que dice: “Está bien derribar algunos de estos muros si significa que hay menos personas que se tropiezan entre sí o que luchan por el control de una base de código única”.

 

Las nuevas arquitecturas necesitan nuevas culturas.

La transformación de la arquitectura de su software, ya sea a través de microservicios, funciones o lo que sea que se presente, requiere el tipo de cambio que solo resulta de un proceso orgánico enraizado en el apoyo a una cultura saludable. En este tipo de entorno, los microservicios pueden ser en realidad un multiplicador de fuerza. Ahora, tanto los desarrolladores como los operadores pueden salirse con la suya, lo que significa un equipo más feliz y más productivo y, en última instancia, un negocio digital más productivo.

Entonces, ¿cómo llegar allí? Aquí hay algunas cosas que puede comenzar a hacer para cambiar su cultura de software:

• Aliente a los empleados a resolver problemas incentivando nuevas soluciones y minimizando el riesgo de cometer errores.
• Refuerza la creatividad usando hackathons o algún otro tipo de ejercicio de pensamiento libre.
• Mejore la colaboración al experimentar con prácticas como la programación en pares.
• Establezca un sentido de comunidad y compromiso mediante el suministro abierto de algunas de sus herramientas internas y reuniones de alojamiento en su oficina.
• Demuestre a sus empleados que valora su talento organizando charlas de tecnología donde pueden compartir proyectos paralelos u otros intereses tecnológicos.
• Experimente con nuevas tecnologías y prácticas de software lanzando proyectos greenfield.
• Encuentre nuevas ideas y puntos de vista contratando a un equipo más diverso.

Si estás haciendo todas estas cosas con regularidad, entonces estás actuando como un negocio que está listo para microservicios, porque estás actuando como una compañía que quiere atraer y retener el talento que necesita para seguir creciendo.

Es importante recordar que los microservicios no son un destino. Los microservicios son solo una parte de un viaje más grande para un negocio digital que busca sobrevivir en un mundo dominado por el software. Y la actualización de su cultura importa tanto como la actualización de sus herramientas

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]