Velocidad negativa: cómo elevar el límite de complejidad
Uno de los objetivos más comunes de una organización de ingeniería: ofrecer software de alta calidad rápidamente.
Echa un vistazo a la declaración de principios de tu director de sistemas informáticos o tecnología y escúchalos hablar. Lo más probable es que quieran alcanzar alguna permutación de este objetivo. Si bien es un objetivo habitual, hay un amplio espectro entre los equipos que alcanzan este nirvana y los equipos atrapados en el purgatorio de la entrega de software. Algunos equipos lanzan constantemente código nuevo a producción con poco impacto negativo en los clientes o pocos incidentes, mientras que otros tienen problemas con las publicaciones trimestrales.
Uno de los objetivos más comunes de una organización de ingeniería: ofrecer software de alta calidad rápidamente.
Echa un vistazo a la declaración de principios de tu director de sistemas informáticos o tecnología y escúchalos hablar. Lo más probable es que quieran alcanzar alguna permutación de este objetivo. Si bien es un objetivo habitual, hay un amplio espectro entre los equipos que alcanzan este nirvana y los equipos atrapados en el purgatorio de la entrega de software. Algunos equipos lanzan constantemente código nuevo a producción con poco impacto negativo en los clientes o pocos incidentes, mientras que otros tienen problemas con las publicaciones trimestrales.
¿Qué causa esta discrepancia en el rendimiento?
La complejidad en la entrega de software es la diferencia entre ofrecer software de alta calidad, rápido y... no hacerlo. Es la diferencia entre hacer sonar la campana de la victoria tras una publicación exitosa cada semana y un equipo de entrega de software desvinculado, frustrado porque meses de trabajo en la última publicación se han traducido en seis errores nuevos y una reversión.
Compara la calidad y la velocidad a la que las empresas emergentes lanzan nuevos productos y funciones con las de una organización grande y consolidada. Por ejemplo, en el sector financiero, las empresas emergentes de tecnología financiera han reducido la cuota de mercado de los grandes bancos consolidados durante la última década. Los grandes bancos suelen mencionar las injustas ventajas de las empresas emergentes de tecnología financiera, que operan con menos supervisión normativa y sin sistemas de aplicaciones monolíticos y tradicionales que mantener. Un equipo más pequeño permite una mayor agilidad y la capacidad de cambiar en función de las necesidades del cliente. Básicamente, las empresas de tecnología financiera no cuentan con la complejidad de los bancos consolidados, lo que les permite moverse más rápido y con menos riesgo. Aunque puede ralentizar a los equipos de software, la complejidad no siempre es negativa.
Material relacionado
Ten controlado todo el software
VER LA SOLUCIÓN
Gestiona tus componentes con Compass
La complejidad en la entrega de software
La complejidad puede ser algo bueno: es extremadamente gratificante resolver problemas complicados. Sirve de motivación para que los equipos estén a la altura del desafío, aborden problemas difíciles y den un vuelco al sector. Por el contrario, hay un punto en el que la complejidad ya no consiste en resolver un problema difícil y tiene un impacto negativo en los equipos de software.
La complejidad organizativa desempeña un papel clave en la reducción de la eficacia de los equipos de software. El diccionario Collins define la complejidad como "estado en el que muchas partes diferentes están conectadas o relacionadas entre sí de forma complicada". En términos prácticos, la complejidad organizativa es la suma de la información, las dependencias, los cambios, los demás equipos, las herramientas y las solicitudes que los equipos de software deben tener en cuenta cuando interactúan con el resto de la organización.
Los niveles más altos de complejidad organizativa naturalmente hacen que sea más difícil ofrecer software de alta calidad a gran velocidad, ya que los equipos dedican más tiempo a adaptarse a la organización que a resolver problemas complicados. Las organizaciones en crecimiento pronto descubren que los equipos de software alcanzan un límite de complejidad, es decir, la cantidad de complejidad que pueden gestionar antes de que afecte a la satisfacción laboral, y a la calidad y velocidad del software producido. Puede parecer lógico, entonces, que reducir la complejidad organizativa permita a los equipos centrarse en resolver problemas complicados y entregar el software más rápido y con mayor calidad. Veamos por qué no siempre es así.
Cómo saber si te estás acercando al límite de complejidad
Alcanzar el límite de complejidad puede parecer inevitable, pero hay algunos indicadores de que los equipos se están acercando a su límite. Antes que nada, debo decir que no existe una métrica absoluta que te indique cuán cerca estás del límite de complejidad, pero los siguientes indicadores pueden ayudarte a identificar en qué punto te encuentras.
El indicador más claro de que un equipo ha alcanzado el límite de complejidad es cuando dedica más tiempo a analizar la complejidad organizativa que a resolver los complicados problemas en los que debe centrarse. Las tendencias en las métricas de DORA sobre los plazos de los cambios (velocidad) y de la tasa de errores de cambios (calidad) muestran si los equipos pierden o ganan velocidad a lo largo del tiempo. Aunque hay otros factores que influyen en estas métricas, son un buen indicador de la eficacia de los equipos.
La satisfacción de los desarrolladores es otro indicador de la complejidad organizativa a la que se enfrentan los equipos de software. Más que ningún otro perfil de puesto, a los desarrolladores les encanta dedicar su tiempo a resolver problemas complicados y, al mismo tiempo, detestan las tareas innecesarias que se interponen en el camino. La baja satisfacción de los desarrolladores es un buen indicio de que la complejidad organizativa es un problema para tu equipo de software.
Best for managing microservices: Compass
Compass is an ideal server management tool. It simplifies handling microservices architectures by putting disconnected data about engineering work and teamwork together in one central, searchable location.
Compass' features include:
- Get full visibility into service details with relevant APIs, libraries, documentation, key health metrics, latest deployment activities, on-call schedules, and more.
- Document and track upstream and downstream dependencies and understand performance impact across teams and services.
- View all incidents, deployments, and other critical activities for a service and its dependencies in one place.
Best for CI/CD: Bitbucket Pipelines
CI/CD is an acronym for continuous integration and continuous deployment.
Bitbucket Pipelines is a CI tool that automates processes. It works right out of the box with Bitbucket, an Atlassian cloud-based version control system. It can use code to manage pipelines, letting users commit pipeline definitions and start builds fast. Bitbucket Pipelines also has CD features that allow you to deploy projects to live infrastructure.
Part of the CI/CD development process is to build microservices. Bitbucket Pipelines fosters efficiency by simplifying workflows and integrating with Bitbucket's cloud version control system.
Best for ITSM: Jira Service Management
Jira Service Management is an add-on for Jira Software, a microservices-based application that lets you control IT services, such as incident, problem, and change management. Jira Service Management’s ITSM features allow IT teams to provide excellent service. There are several reasons why that is the case:
- Flexibility: JSM's collaborative approach can help streamline service delivery processes.
- Automation: The automation suite can help automate recurring tasks.
- Integration: JSM integrates seamlessly with other Atlassian tools.
- Security: It encrypts all data in transit using TLS 1.2+.
- Scalability: JSM is an agile ITSM product that can scale up to the enterprise level.
Best for documentation: Confluence
Confluence is a collaborative documentation tool. It’s ideal for creating and sharing documentation, critical in microservices architectures. Confluence offers a wide range of Confluence templates for various setups, including those using Kubernetes and Docker, a microservices tool that helps developers build, deploy, and run containers.
Confluence templates include multiple features and apps to help you capture, distribute, and update your technical documentation. Also, with Confluence, you can centralize all your documentation in one place and grant access to users only to what they need.
Best for bug tracking: Jira Software
Jira Software excels at bug tracking and project management. It provides a platform to track, prioritize, and resolve bugs effectively through an easily navigable interface. Jira Software's bug-tracking features contribute significantly to successful microservices management. They also address the potential for software sprawl.
With Jira Service Management, Jira's capabilities extend to streamline IT service management, including incident, problem, and change management within microservices and monolithic architecture.
Best for monitoring and logging: Prometheus
Prometheus is an open-source tool developers use to manage microservices. It collects extensive metrics, including counters, gauges, histograms, and summaries, that comprehensively view the application's performance. Prometheus also assists in real-time troubleshooting by providing a comprehensive monitoring and alerting system that enables developers and IT teams to identify and resolve issues promptly.
Best for testing microservices APIs: Postman
The distributed nature of microservices architectures significantly hamper traditional testing methodologies. Testing the entire system becomes complex and time-consuming because each microservice is an independent component. This is where a specific microservices testing tool like Postman comes in handy.
Postman simplifies the process of testing microservices APIs. Developers love that it can automate testing, enabling faster and more accurate results.
Some of the ways Postman simplifies the process of testing microservices APIs include:
- Visual request builder: Postman's visual request builder makes it easy to construct HTTP requests without writing code.
- Request collections: Postman allows you to organize your API requests into collections, making it easy to group related requests and share them with other team members.
- Predefined tests: Postman provides a library of predefined tests that you can use to validate the responses from your API requests.
- Test scripts: Postman allows you to write test scripts using JavaScript, giving you more control over your tests and enabling you to automate complex testing scenarios.
Cómo saber si te estás acercando al límite de complejidad
Alcanzar el límite de complejidad puede parecer inevitable, pero hay algunos indicadores de que los equipos se están acercando a su límite. Antes que nada, debo decir que no existe una métrica absoluta que te indique cuán cerca estás del límite de complejidad, pero los siguientes indicadores pueden ayudarte a identificar en qué punto te encuentras.
El indicador más claro de que un equipo ha alcanzado el límite de complejidad es cuando dedica más tiempo a analizar la complejidad organizativa que a resolver los complicados problemas en los que debe centrarse. Las tendencias en las métricas de DORA sobre los plazos de los cambios (velocidad) y de la tasa de errores de cambios (calidad) muestran si los equipos pierden o ganan velocidad a lo largo del tiempo. Aunque hay otros factores que influyen en estas métricas, son un buen indicador de la eficacia de los equipos.
La satisfacción de los desarrolladores es otro indicador de la complejidad organizativa a la que se enfrentan los equipos de software. Más que ningún otro perfil de puesto, a los desarrolladores les encanta dedicar su tiempo a resolver problemas complicados y, al mismo tiempo, detestan las tareas innecesarias que se interponen en el camino. La baja satisfacción de los desarrolladores es un buen indicio de que la complejidad organizativa es un problema para tu equipo de software.
Elevar el límite de complejidad
Why is monitoring and testing important in microservices architecture?
Para volver a la eficacia de los equipos de software, las organizaciones deben elevar el límite de complejidad. Elevar el límite de complejidad significa aumentar la complejidad organizativa a la que puede enfrentarse cada equipo antes de que esto afecte a la satisfacción laboral, y a la calidad y la velocidad con las que el equipo lanza el software.
La ingeniería de plataformas es un concepto importante a la hora de elevar el límite de complejidad de una organización. Los equipos de ingeniería de plataformas sólidos se centran en reducir la carga cognitiva de los equipos de software al abstraer la complejidad organizativa de su trabajo diario. Cuando se implementa correctamente, la ingeniería de plataformas permite a los equipos reequilibrar la mayor parte del esfuerzo que dedican a resolver problemas complicados y dedicar menos tiempo a analizar la complejidad organizativa.
What are some common challenges in monitoring microservices?
Atlassian creó Compass, una plataforma de experiencia para desarrolladores, por esta misma razón. Compass ayuda a elevar el límite de complejidad al facilitar a los equipos de software el análisis de la complejidad organizativa a través del catálogo de componentes, las métricas y los cuadros de mandos para que puedan centrarse en crear una cultura de ingeniería sólida. El principal argumento es que la complejidad organizativa no se redujo en Atlassian; de hecho, siguió creciendo a medida que más y más miembros de la organización pasaban a una arquitectura de microservicios. Redujimos el tiempo que los equipos de software dedicaban a enfrentarse a esa complejidad, que es la diferencia entre llevar a cabo un proyecto de simplificación y elevar el límite de complejidad.
Atlassian tiene más de 10 000 empleados y más de 17 000 componentes de software, pero nuestros equipos de software funcionan en gran medida con la libertad de una empresa emergente, lanzando software de alta calidad rápidamente. ¿Nuestra clave del éxito? Elevar el límite de complejidad para mejorar la eficacia de los equipos de software.
Aquí tienes dos acciones para empezar a elevar tu límite de complejidad:
- Realiza un seguimiento y evalúa tus métricas de DORA. ¿Cómo van las métricas de DORA para tu equipo? Si aún no las estás controlando, las métricas de DORA se proporcionan listas para usar con Compass.
- Conoce y evalúa la satisfacción de los desarrolladores. ¿Cómo se sienten los desarrolladores de tus equipos de software? La mayoría de las organizaciones realizan encuestas de satisfacción de los empleados. Pide los resultados, desglosados por área funcional, para hacerte una idea de la satisfacción de los desarrolladores. Las preguntas clave incluyen valorar las siguientes afirmaciones:
- Me enorgullece hacer lanzamientos
- La cantidad de estrés en mi trabajo es manejable
- Soy consciente de cómo mi trabajo contribuye a los objetivos de la empresa
Como alternativa, Compass recopila esta información durante el ritual CheckOps, en el que los equipos comparten lo que piensan de la última semana e indican lo que podría haber ido mejor.
Para elevar el límite de complejidad se requiere una combinación de herramientas, procesos y rituales. Una plataforma de experiencia para desarrolladores como Compass puede ayudarte a conocer el estado del sistema, asignar las dependencias y crear rituales continuos, lo que ayuda a superar el límite de complejidad y a aprovechar el potencial de los equipos de entrega de software de tu organización.
Prueba Compass gratis hoy mismo.
What are some best practices for monitoring and testing microservices?
To test and monitor microservices effectively, use monitoring data, set the proper alert levels, automate tests, set up continuous integration and delivery pipelines, and regularly test their performance and security. These methods ensure that your platforms work reliably.
Join the Atlassian Community for more Microservices articles and discussions.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
Comunidad de Compass
Tutorial: Crear un componente
