Table of Contents
Equipo de Apiumhub ha entrevistado a Mark Richards – pontente en GSAS, Profesor en Apium Academy, un experimentado arquitecto de software que participa en la arquitectura, diseño e implementación de arquitecturas de microservicios, arquitecturas orientadas a servicios y sistemas distribuidos en una variedad de tecnologías. Ha estado en la industria del software desde 1983 y tiene una experiencia y conocimientos significativos en la aplicación, integración y arquitectura empresarial. Mark es el fundador de DeveloperToArchitect.com, un sitio web gratuito dedicado a ayudar a los desarrolladores en el camino para convertirse en un arquitecto de software. Es autor de numerosos libros y vídeos técnicos, entre los que se incluyen Fundamentals of Software Architecture, Software Architecture Fundamentals Video Serie y varios libros y vídeos sobre microservicios y mensajería empresarial. Además de la consultoría práctica, Mark es también un conferenciante y formador, habiendo hablado en cientos de conferencias y grupos de usuarios en todo el mundo sobre una variedad de temas técnicos relacionados con la empresa. Aquí Mark comparte sus recomendaciones sobre arquitectura de software:
Recomendaciones sobre arquitectura de software
¿Qué es la arquitectura de software para ti?
Mi visión de la arquitectura de software es que está compuesta de dos aspectos: la arquitectura de software como estructura, y la arquitectura de software como proceso. Dentro del aspecto estructural de la arquitectura de software hay 4 dimensiones: características de la arquitectura, componentes de la arquitectura, estilos de la arquitectura, y decisiones de la arquitectura. Todas estas 4 dimensiones son necesarias para formar el aspecto estructural de cualquier sistema. El aspecto de proceso de la arquitectura de software incluye tanto técnicas como habilidades soft – negociación, facilitación y liderazgo.
¿Cuáles son las tres principales habilidades soft que crees que necesitan los arquitectos de software?
Las 3 principales habilidades soft para cualquier arquitecto de software son la negociación, la facilitación y el liderazgo. La negociación es una habilidad requerida como arquitecto porque casi todas las decisiones que tomes como arquitecto serán desafiadas. Tus decisiones serán cuestionadas por otros arquitectos que piensan que tienen un enfoque mejor que el tuyo; tus decisiones serán cuestionadas por las partes interesadas de la empresa porque piensan que tu decisión tarda demasiado en implementarse o es demasiado costosa o no está alineada con los objetivos de la empresa; y finalmente, tus decisiones serán cuestionadas por los equipos de desarrollo que creen que tienen una solución mejor. Todo esto requiere que un arquitecto entienda el clima político de la empresa y cómo navegar por la política para conseguir que sus decisiones sean aprobadas y aceptadas.
La facilitación es otra habilidad de software necesaria como arquitecto de software. Los arquitectos no sólo colaboran con los equipos de desarrollo, sino que también colaboran estrechamente con los diversos interesados de la empresa para entender los impulsores de la empresa, explicar las características importantes de la arquitectura, describir las soluciones arquitectónicas, etc. Todas estas reuniones y encuentros requieren un agudo sentido de facilitación y liderazgo dentro de estas reuniones para mantener las cosas en el camino correcto.
Por último, el liderazgo es otra habilidad soft importante porque un arquitecto es responsable de dirigir y guiar a un equipo de desarrollo a través de la implementación de una arquitectura. Están ahí como guía, mentor, entrenador y facilitador para asegurarse de que el equipo va por buen camino y funciona tan bien como una máquina bien engrasada, y para estar ahí cuando el equipo necesita aclaraciones o tiene preguntas y preocupaciones sobre la arquitectura.
¿Cuáles son las tres principales responsabilidades de un arquitecto de software dentro de la empresa?
Las tres principales responsabilidades de un arquitecto de software son las siguientes:
1) Comprender las necesidades comerciales e identificar las características de la arquitectura subyacente que se requieren de un sistema.
2) Tomar decisiones sobre la arquitectura, justificar esas decisiones y comunicarlas de manera efectiva.
3) Dirigir y guiar los equipos de desarrollo y promover la colaboración entre la arquitectura de software y el desarrollo de software.
¿Cuáles son los atributos clave de la arquitectura de software?
Aunque hay literalmente cientos de características arquitectónicas posibles, algunas comunes incluyen cosas como el rendimiento, la capacidad de respuesta, la disponibilidad, la tolerancia a los fallos, la agilidad, la fiabilidad, la seguridad, la interoperabilidad, la escalabilidad, la elasticidad, la integridad de los datos y la viabilidad. Sin embargo, es fundamental comprender que no hay atributos de la arquitectura de software que sean comunes a un sistema determinado. Cada sistema, y más concretamente cada parte de un sistema, tiene sus propias características de arquitectura («enfermedades») basadas en lo que es importante para el negocio de ese sistema en particular. Simplemente no se puede decir «cada sistema debería centrarse en el rendimiento» cuando de hecho el rendimiento puede no ser una preocupación.
Sin embargo, hay algunas características comunes de la arquitectura implícita que son inherentes a cualquier sistema dado – esos atributos que están implícitos. Estas características implícitas comunes incluyen la viabilidad, la seguridad, la fiabilidad y la capacidad de mantenimiento. Estas características implícitas se hacen explícitas cuando son lo suficientemente importantes como para ser críticas para el éxito del sistema. Por ejemplo, considera la sostenibilidad. Este atributo sigue siendo una característica implícita hasta que se obtiene una necesidad comercial como, por ejemplo, un tiempo de comercialización muy rápido. En este caso, la velocidad a la que se despliegan las nuevas características o la corrección de errores es crítica para el éxito de la aplicación, y por lo tanto la mantenibilidad se convierte en una característica impulsora (o explícita) en lugar de una implícita.
¿Cuál es tu opinión sobre la Innovación vs. Pragmatismo?
El segundo mejor consejo que recibí cuando me convertí en arquitecto fue que debía seguir siendo pragmático, pero visionario. Pragmático se define como «tratar las cosas de forma sensata y realista de una manera que se basa en consideraciones prácticas más que teóricas», mientras que ser visionario se define como «pensar o planificar el futuro con imaginación o sabiduría». Ambas cosas son necesarias como arquitecto de software, y la búsqueda de un equilibrio entre ellas, aunque difícil, es una de las claves para ser un arquitecto de software exitoso y eficaz.
¿Qué opinas sobre el rendimiento y la capacidad de respuesta?
Mientras que ambos están relacionados con la rapidez de un sistema, la respuesta y el rendimiento significan dos cosas diferentes. La capacidad de respuesta se refiere a la rapidez con que la retroalimentación o la respuesta llega al usuario final, mientras que el rendimiento se refiere a la rapidez con que un sistema puede procesar la información.
Para ilustrar la diferencia, supongamos que un usuario desea publicar un comentario en un sitio web sobre un producto o servicio determinado, lo que tarda 3 segundos en procesarse. Suponiendo una latencia de red de 50ms para llegar al servicio, el uso de protocolos de comunicación síncronos (como REST) daría como resultado un tiempo de respuesta de 3100ms (3000ms para la publicación del comentario, 100ms en latencia de ida y vuelta). Sin embargo, esa misma solicitud utilizando un protocolo asincrónico como el de la mensajería sólo tardaría 25ms (25ms para publicar en una cola, y luego el control se devuelve al usuario). Aún así, se necesitarían otros 3025ms para publicar el comentario, pero el usuario no está esperando a que se publique el comentario. Este es un buen ejemplo de capacidad de respuesta, porque no se ha hecho nada para solucionar los problemas de rendimiento relacionados con el servicio de comentarios. La contrapartida de este escenario, por supuesto, es el manejo de errores.
¿Cuáles son tus expectativas con respecto a los eventos de arquitectura de software, crees que en 2021 todo será online?
Mi expectativa (y esperanza) es que volvamos a las conferencias presenciales desde mediados a finales de 2021. Mientras que las conferencias online proporcionan algunos de los objetivos de transferencia de conocimiento de las conferencias, falta mucho en términos de redes, colaboración cara a cara e interacción humana. Echo de menos esa parte como ponente, y asumo que los asistentes también están hambrientos de ese aspecto de la experiencia de la conferencia.
¿Qué tendencias de arquitectura de software has notado este año?
Una tendencia de la arquitectura de software que he notado este año es el movimiento hacia entornos de código bajo/no código. Creo que la razón de esta tendencia es la necesidad de que las empresas respondan más rápido a los cambios en el mercado, y escribir y probar el código simplemente lleva demasiado tiempo. Sin embargo, hay muchos aspectos negativos en esta tendencia, incluyendo lo que se llama «la última trampa del 10%». Los entornos de bajo código/sin código son buenos para conseguir que el 90% llegue allí muy rápidamente, pero el último 10% de esfuerzo es lo que mata a la mayoría de estas iniciativas, principalmente debido a necesidades específicas de usuarios o funcionalidades que no son soportadas por el entorno de bajo código/sin código.
También he notado una tendencia este año (¡por fin!) con las empresas que ponen más énfasis en la arquitectura como parte de las actividades diarias del proceso de desarrollo en lugar de una actividad singular que se hace al principio de un proyecto. Las empresas se están dando cuenta de los beneficios de la arquitectura evolutiva e incremental, permitiendo que la arquitectura inicial tome forma durante la implementación donde los detalles se entienden y se realizan mejor. Esto requiere que la arquitectura sea flexible para acomodar ese cambio frecuente.
Por último, he notado una tendencia a la baja en esta ruptura hacia la adopción de microservicios puros. Cada vez más empresas parecen cuestionar el estilo de la arquitectura de los microservicios puros y en su lugar se están moviendo hacia arquitecturas más híbridas, combinando la arquitectura basada en servicios y los microservicios para formar contextos estrechamente delimitados sólo en las partes del sistema donde tiene sentido.
¿Crees que existen balas de plata en la arquitectura de software?
No lo creo. Neal Ford y yo acuñamos la «Primera Ley de la Arquitectura de Software» en nuestro reciente libro Fundamentals of Software Architecture que dice «Todo en la arquitectura de software es un intercambio». Por eso los arquitectos suelen responder a cada pregunta con un «depende». Dicho esto, creo que hay algunas prácticas esenciales dentro del aspecto del proceso de la arquitectura de software, tales como «siempre analizar los equilibrios», y «centrarse en el por qué en lugar del cómo».
¿Cuál es tu opinión sobre la elasticidad vs. escalabilidad?
Mientras que tanto la elasticidad como la escalabilidad se relacionan con el mantenimiento de un tiempo de respuesta consistente cuando las peticiones a un sistema aumentan, difieren desde el punto de vista de la arquitectura. La escalabilidad consiste en asegurar tiempos de respuesta consistentes y la capacidad de crecimiento sostenido de un sistema a lo largo del tiempo, mientras que la elasticidad consiste en ser capaz de manejar picos inmediatos en la carga de usuarios (como los sistemas de entradas a conciertos y sistemas de subasta como eBay). La elasticidad también tiene que ver con el MTTS, es decir, el tiempo medio de arranque. Cuanto más grande sea un servicio (o sistema), más lento será responder a un pico de usuarios o de solicitudes debido al tiempo que lleva iniciar instancias de servicio adicionales. Considere tres estilos de arquitectura básica – arquitectura monolítica (despliegue único), arquitectura basada en servicios y microservicios. Las arquitecturas monolíticas no se escalan bien, mientras que las basadas en servicios y microservicios sí lo hacen. Sin embargo, desde el punto de vista de la elasticidad, sólo los microservicios lo soportan bien debido a la naturaleza de propósito único y de grano fino de los servicios (el MTTS es muy bajo).
¿Podrías compartir tus ideas sobre los patrones de la arquitectura de software?
Cuando empecé a hablar públicamente de arquitecturas como la arquitectura monolítica en capas, los microservicios, la arquitectura basada en servicios, la arquitectura basada en eventos, la arquitectura basada en el espacio, la arquitectura de tuberías y la arquitectura de micronúcleos, me referí a estas cosas como patrones de arquitectura. Esto creó bastante confusión en la industria porque la gente se preguntaba «¿cómo se relacionan estos patrones con otros patrones como CQRS (Command Query Responsibility Segregation), el patrón Gateway, el patrón Adapter, el patrón Anti-Corruption Later, y así sucesivamente? Nunca tuve una buena respuesta, normalmente respondiendo que las arquitecturas de las que hablaba eran más patrones de «nivel superior». Hace varios años, empecé a acuñar cosas como microservicios, micronúcleo, impulsado por eventos, basado en el espacio, etc., como estilos de arquitectura para diferenciarlos de los patrones de arquitectura subyacentes.
Por lo tanto, un estilo de arquitectura describe la forma en que su sistema global está estructurado (como los microservicios, monolito en capas, etc.), mientras que los patrones de arquitectura son formas de describir ciertos y específicos aspectos arquitectónicos de esa estructura global. Por ejemplo, se puede aplicar el patrón de arquitectura CQRS a cualquier estilo arquitectónico – en otras palabras, no cambia la forma general de esa arquitectura. Lo mismo ocurre con cualquier otro patrón de arquitectura – cualquiera de ellos puede ser aplicado para describir mejor los detalles subyacentes del estilo de arquitectura global que está utilizando.
¿Qué recomendaciones sobre arquitectura de software le darías a las grandes compañías internacionales?
La recomendación número uno que daría a las grandes compañías internacionales en términos de arquitectura de software es asegurarse de identificar (y analizar continuamente) las características de la arquitectura («-ales») que se necesitan para ese sistema en particular. Simplemente no se puede crear una arquitectura exitosa y funcional a menos que se tengan las características de arquitectura correctas. ¿Es la escalabilidad su preocupación más importante? ¿Es el rendimiento, la integridad de los datos, la disponibilidad del sistema y la tolerancia a los fallos, o la seguridad? Cada estilo de arquitectura soporta su propio conjunto de características de arquitectura. Si la escalabilidad y la tolerancia a fallos son sus preocupaciones principales y tiene una aplicación monolítica tradicional en capas, eventualmente fallará, sin importar la funcionalidad de ese sistema.
Derivar las características de arquitectura requeridas de las necesidades del negocio es la clave. Si el negocio está pasando por adquisiciones importantes y te centras en el rendimiento, es probable que falle – la interoperabilidad, la extensibilidad y la escalabilidad son lo importante. Si el negocio requiere el menor tiempo posible de comercialización para que las nuevas características y las correcciones de errores puedan llegar a tus clientes de la manera más rápida posible y te puedas centrar en la escalabilidad, fracasarás – la agilidad es lo importante.
¿Qué recomendaciones sobre arquitectura de software darías a las startups ?
En cuanto a las startups y la arquitectura, mi recomendación es que centren sus esfuerzos de arquitectura en la extensibilidad, la adaptabilidad y el cambio (flexibilidad). Utilizando el diseño basado en el dominio, comienza con un monolito modular simple, luego mueve esos módulos a los servicios de dominio utilizando la arquitectura basada en el servicio, y luego mueve esos servicios de dominio que requieren más escalabilidad, rendimiento y agilidad a los microservicios si es necesario. Esta progresión evolutiva permite a las empresas de nueva creación sacar la funcionalidad rápidamente y luego evolucionar la arquitectura a medida que se aprende más sobre las necesidades y la dirección de la empresa.
¿Cuáles son los principales problemas de la arquitectura de software?
Uno de los principales problemas que veo en la arquitectura de software es la práctica continua de «poner el carro delante del caballo» – tomar decisiones y elecciones de arquitectura sin calificar las necesidades del negocio a través de las características de la arquitectura y someterse a un análisis de compensación adecuado y completo. Demasiadas veces nos «subimos al carro» de una tendencia, plataforma, producto o tecnología en particular sin analizar las compensaciones de esas elecciones. Por ejemplo, demasiadas empresas se suben a los microservicios sin analizar si los necesitan o no, o comienzan a adoptar la computación cuántica o la IA/ML sin comprender plenamente las implicaciones de esas áreas o incluso si las necesitan o no.
Tu viaje de arquitectura: ¿lecciones aprendidas?
Mis lecciones aprendidas:
1) Las habilidades sociales (habilidades de la gente) importan en la arquitectura de software – constituyen el 50% de ser un arquitecto de software efectivo.
2) Tener siempre en mente las limitaciones del proyecto y del negocio al crear y analizar la arquitectura de software (costo, tiempo, presupuesto, niveles de habilidad, etc.)
3) No te dejes atrapar por la publicidad como arquitecto de software: detente, analiza las compensaciones, estudia las tendencias y enfoca la nueva tecnología con precaución.
4) Concéntrate más en el «por qué» que en el «cómo» – esto es lo verdaderamente importante es la arquitectura de software
5) Difundir el conocimiento es más valioso que ser un contribuyente individual.
BIO y Contacto
Mark Richards
Arquitecto de software práctico
Consultor independiente
Fundador de DeveloperToArchitect.com
Twitter: @markrichardssa
LinkedIn: https://www.linkedin.com/in/markrichards3/
Email: [email protected]
Website: https://www.developertoarchitect.com/mark-richards.html
