Introducción Con la creciente demanda de servicios en línea para las empresas, la infraestructura moderna como Cloud Native, Containers, Kubernetes y Service Mesh se ha convertido en la opción de facto para que las empresas adopten e implementen las soluciones. Al adoptar la infraestructura de software moderna para nuevos servicios de aplicaciones o migrar aplicaciones heredadas a la nube, la arquitectura de software moderna juega un papel importante en la definición de cómo adoptar la infraestructura moderna para la empresa. ¿Qué es la arquitectura de software? No existe una definición correcta definida para referirse a lo que es Arquitectura de Software. Muchos expertos de la industria tienen sus propias definiciones de arquitectura de software. En Simple “La Arquitectura es un conjunto de Estructura o Estructuras de Software”. El software consta de sistemas centrales, subsistemas y componentes y una estructura es un conjunto de componentes y sus relaciones. ¿En qué debe consistir una Buena Arquitectura de Software? La arquitectura de software no es solo para definir los componentes y sus relaciones, sino que hay mucho más para agregar, como tener una hoja de ruta del estado objetivo, tomar decisiones estratégicas, adoptar el estilo/patrón de arquitectura correcto, identificar las tecnologías correctas para construir la aplicación o los servicios de software, aplicando las características de la arquitectura. Además, comprender los riesgos y los requisitos no funcionales, y lo más importante es documentarlos y comunicarlos a las partes interesadas. Una arquitectura de software sirve como una visión modelo para los equipos de desarrollo que definirán los requisitos comerciales y sus expectativas del sistema. La Arquitectura de Software es un proceso en continua evolución que se comprime con patrones de diseño arquitectónico y decisiones técnicas/estratégicas. Al construir una arquitectura efectiva, podemos identificar los riesgos de diseño y mitigarlos temprano. Una buena arquitectura de software es adoptar el estilo de arquitectura correcto y definir sus características de arquitectura que ayudarán a mantener la calidad del software a lo largo de su vida útil. Características de la arquitectura Cualquier arquitectura exitosa depende de qué tan bien definamos las Características de la Arquitectura. Hay muchos atributos de calidad del sistema que podemos discutir, pero para mí, las siguientes características de la arquitectura constituyen una base sólida para que la arquitectura de software moderna desarrolle un producto exitoso. https://en.wikipedia.org/wiki/List_of_system_quality_attributes 1. Comprensibilidad: Al definir la estructura de la arquitectura, nuestro objetivo no debe ser solo hacer una estructura de arquitectura de software efectiva. Pero debe ser capaz de comunicarse fácilmente, ser entendido rápidamente por los equipos de desarrollo y las partes interesadas, al mismo tiempo que debe cumplir con los requisitos comerciales. Cuando un nuevo desarrollador se une al equipo del producto, debería poder comprender la arquitectura del software con una breve introducción. Consideraciones para la comprensibilidad: Comprenda a sus partes interesadas qué requiere cada equipo de la aplicación. Comprender las fortalezas y debilidades de los equipos de desarrollo. 2. Facilidad de uso y aprendizaje: Lograr la Usabilidad de un producto de software depende de una serie de factores, como los usuarios objetivo, la experiencia UX y la facilidad de uso de las funciones del Producto. Necesitamos considerar qué es exactamente lo que quieren los usuarios y qué estamos proporcionando a los usuarios. Además, debemos comprender cómo los usuarios objetivo pretenden utilizar el producto o la aplicación de software. Las funciones proporcionadas por el producto/aplicación de software deben cumplir con el Usuario dentro del contexto y estas funciones deben ser claramente visibles para el usuario. El éxito de un producto depende de qué tan bien los usuarios utilicen la aplicación o el producto de Software y qué tan fácil pueda aprender el usuario las nuevas características de la aplicación/producto. Además, en la decisión de la arquitectura de adoptar nuevas tecnologías o marcos, el arquitecto debe ser consciente de lo fácil que es aprender o adoptar la nueva tecnología o marco rápidamente por parte del desarrollador. Consideraciones para la usabilidad y la capacidad de aprendizaje: Sepa qué tipo de usuarios usarán la Aplicación, adopte las Pautas de Accesibilidad si es necesario. Todas las características de la aplicación deben ser fácilmente visibles y accesibles. Haga una buena investigación sobre la adopción de nuevas tecnologías y marcos. 3. Asegurabilidad: La Aplicación expuesta en la web siempre tiene un riesgo de amenazas cibernéticas, si la aplicación es accedida por usuarios no autorizados. La seguridad de las aplicaciones es responsable de detener o reducir las amenazas cibernéticas, las acciones accidentales, el robo de datos o la pérdida de información. Existen numerosas formas de proteger la aplicación, como la autenticación, la autorización, la auditoría y el cifrado de datos. La seguridad bien diseñada para una aplicación de software es restringir el acceso de los usuarios en función de la autenticación y la autorización, la capacidad de detectar y protegerse de los ataques DDoS, la prevención de la inyección SQL, garantizar que las contraseñas estén cifradas y protegidas según la política de contraseñas y asegurarse de que aplicación se comunica en protocolos seguros. Consideraciones para la seguridad: Qué mecanismo de autenticación adoptar y qué roles se deben otorgar a las diferentes funciones de la aplicación. Asegúrese de que la aplicación se comunique con protocolos seguros Todas las contraseñas deben estar encriptadas y protegidas. Diseño para detectar y proteger ataques DDoS e inyección SQL Cifrado de datos, confidencialidad e integridad Auditoría de las actividades del usuario en la aplicación 4. Confiabilidad y disponibilidad: Al diseñar la arquitectura de software, una de las características clave de la aplicación es la confiabilidad y disponibilidad. La confiabilidad es un atributo del sistema responsable de la capacidad de continuar operando bajo condiciones predefinidas. La mayoría de las veces, el sistema falla debido a la inaccesibilidad de componentes externos como bases de datos, aplicaciones externas y conexiones de red. La Disponibilidad de la Aplicación se calcula en base al Tiempo Total de Operación dividido por el Tiempo Total, esto se expresa en porcentaje como 99.9%, también se expresa en el número de 9s. Por ejemplo, si la disponibilidad de nuestra aplicación es del 99,9% (que son tres 9), entonces en un año tenemos un tiempo de inactividad de 8 horas y 45 minutos para nuestra aplicación. Además, debemos considerar si nuestra aplicación depende de otras aplicaciones, debemos considerar la disponibilidad de la aplicación dependiente. Calculadora de disponibilidad: https://uptime.is/99.9 Consideraciones de confiabilidad y disponibilidad: Cuando la Aplicación o el Servicio no está disponible. ¿Qué se requiere para recuperar la aplicación, ya sea automática o manual? ¿Cuánto tiempo podemos tomar el tiempo de inactividad? ¿Cumple con los SLA comerciales? Cómo la aplicación enviará notificaciones cuando ocurra una falla. ¿Cuál es el plan de resiliencia para la aplicación? 5. Interoperabilidad: La mayoría de los servicios de aplicaciones deben comunicarse con sistemas externos para proporcionar servicios completos. Una arquitectura de software bien diseñada facilita la interoperabilidad de la aplicación para comunicar e intercambiar los datos con sistemas externos o sistemas heredados. Es fácil diseñar la interoperabilidad entre interfaces externas bien diseñadas y sistemas de estandarización. Pero tendremos muchos desafíos con sistemas externos o sistemas heredados que son de mala calidad y carecen de estándares. Consideraciones para la interoperabilidad: Se deben considerar diferentes formatos de datos para interactuar con sistemas externos. Calidad de API y diferentes versiones de API Compatibilidad con versiones anteriores. Posibilidad de reconstruir con los estándares de la industria. 6. Comprobabilidad: Una industria estima que entre el 30 y el 40 por ciento del costo lo toma Testing. El papel del Arquitecto de Software para garantizar que diseñen cada componente puede ser comprobable. Una arquitectura comprobable debe mostrar claramente todas las interfaces, los límites de la aplicación y la integración entre los componentes. La capacidad de prueba es la capacidad de probar diferentes componentes y eventos de la aplicación. Deberíamos poder crear una secuencia de comandos para crear el entorno de prueba, por lo que permitirá a los desarrolladores y evaluadores reproducir rápidamente escenarios similares que ocurrieron en producción para que puedan identificar rápidamente el problema y proporcionar la corrección o solución. Consideraciones para la capacidad de prueba: Todos los requisitos comerciales y NFR deben ser consistentes y completamente comprobables. Asegúrese de que todos los entornos DEV, TEST, UAT y PRODUCTION sean similares. Todos los componentes deben ser comprobables e incluso con recursos limitados. Todos los puntos de integración de la aplicación deben ser comprobables. Capture los resultados de las pruebas para pruebas internas y externas. 7. Escalabilidad: Con el tiempo, el negocio crecerá y el número de usuarios de la aplicación crecerá de 1000 a 100000. Cuando la carga aumenta, la aplicación debería poder escalar sin afectar el rendimiento. Hay dos tipos de escalado, escalado vertical/escalado ascendente y escalado horizontal o escalado horizontal. El escalado vertical agrega más CPU/memoria/disco de hardware al servidor existente. El escalado horizontal consiste en dividir la carga y responder a las solicitudes agregando más servidores/instancias al clúster de servidores. Esto es más rentable ya que podemos comenzar con poco y agregar más cuando aumenta la carga en la aplicación. Consideraciones para la escalabilidad: Número total de usuarios durante las horas pico y las horas no pico La cantidad de datos se genera para escalar la base de datos o el almacenamiento La cantidad de operaciones intensivas de CPU, memoria o E/S necesarias para escalar Número de operaciones de concurrencia realizadas en la aplicación Funciones u operaciones de ejecución prolongada dentro de la aplicación 8. Rendimiento: El rendimiento de la aplicación es uno de los factores clave en la Arquitectura de Software. Esta característica se logra por lo bien que diseñamos otras características de la arquitectura, una de ellas es la escalabilidad, como se discutió anteriormente. El rendimiento es la capacidad de la aplicación para cumplir con los requisitos de tiempo, como la velocidad y la precisión. La puntuación de rendimiento generalmente se mide en rendimiento, latencia y capacidad. Rendimiento: Número de solicitudes ejecutadas dentro de determinado Latencia: Tiempo total necesario para responder a cada solicitud o una solicitud específica. Capacidad: Número de solicitudes manejadas mientras se cumple el rendimiento y la latencia. Consideraciones para la Ejecución: El escalado horizontal aumenta la cantidad de instancias, la memoria y el ancho de banda de la red Equilibrio de carga para enrutar las solicitudes a diferentes instancias disponibles Procesamiento Paralelo o Concurrencia Solución de almacenamiento en caché Particionamiento o replicación de datos 9. Agilidad: Las empresas y las partes interesadas continúan exigiendo cambios rápidos o innovación de la aplicación o el producto para cumplir con el tiempo de comercialización. Las prácticas ágiles se utilizan para satisfacer la demanda y ofrecer funciones para cumplir con el tiempo de comercialización. Pero la arquitectura subyacente siempre se pasa por alto. Para lograr agilidad en la arquitectura, debemos seguir la dirección de "Anticipación informada", la arquitectura no debe anticiparse en exceso y diseñar la aplicación, lo que retrasará la entrega de la aplicación y agregará una complejidad excesiva para que el desarrollador la construya. Al mismo tiempo, no debe prever las demandas futuras de la aplicación que correrán el riesgo de desarrollar funciones en ausencia de una guía de arquitectura. La agilidad de la arquitectura requiere anticipación "suficiente". Para lograr esta anticipación de la arquitectura "Justo lo suficiente" se debe "informar", existen varios métodos para informarse, como el análisis de dependencia, la acumulación de productos y la deuda técnica. Consideraciones para la agilidad: El desarrollo de la arquitectura debe seguir el modelo “Justo a tiempo”. Mantener un enfoque continuo en las características emergentes orientadas al cliente. Concéntrese en las historias de usuarios que, con el tiempo, pueden conducir a una mayor complejidad. Análisis de las partidas de Product Backlog y Deuda Técnica. 10. Observabilidad: Las aplicaciones y los servicios se desarrollan utilizando diferentes estilos de arquitectura, como microservicios, sin servidor y basados en eventos. Se implementan en infraestructuras modernas como la nube, la nube híbrida. Las Aplicaciones consumen estos servicios como funciones distribuidas a través de diferentes infraestructuras. Para mantener la estabilidad y el rendimiento de la aplicación, debemos observar y monitorear de cerca. El monitoreo se ha vuelto clave para mantener la salud de estos servicios. La observabilidad no es solo un nuevo término elegante para el monitoreo. La observabilidad agrega mucho más junto con información procesable junto con monitoreo como agregación de registros/análisis, Notificaciones. Consideraciones para la observabilidad: Gestión central de registros mediante instrumentación eficaz para recopilar telemetría, registros, eventos, métricas y seguimientos. Defina el contexto para las notificaciones cuando las cosas van mal. Para que DevOps pueda actuar rápidamente para resolver Tenga un panel de visualización para facilitar la comprensión y transmitir lo que sucede y por qué sucede. 11. Tolerancia a fallas: Al diseñar aplicaciones o servicios que comunicarán diferentes sistemas en diferentes infraestructuras y tienden a fallar parcial o totalmente debido a la latencia de la red, conexión rota o cualquier otra razón. En caso de estas fallas, el Arquitecto debe diseñar dónde la Aplicación o los Servicios deben continuar con su funcionamiento posiblemente a un nivel reducido en caso de falla. Hay dos tipos de tácticas que se pueden adoptar en tiempo de diseño y tiempo de ejecución. Durante el tiempo de diseño, podemos esperar qué valores de retorno se esperan de cada operación y asegurarnos de que no haya desbordamientos de búfer. En caso de falla en el tiempo de ejecución, debemos adoptar la segunda mejor acción a tomar en caso de falla para asegurarnos de que el sistema continúe funcionando. Consideraciones para la tolerancia a fallas: Detecte todas las fallas de tiempo de diseño y tiempo de ejecución de todos los componentes dentro de la aplicación y tome medidas correctivas. Definir acciones de recuperación en caso de falla total Adoptar acciones de prevención Pensamientos finales: Intenté este artículo para presentar mis pensamientos sobre cuáles deberían ser las características de la arquitectura de software moderna. Cada una de estas características merece una discusión más larga y también hay otras características que no se tocan. Todavía podemos debatir qué se considera una "buena arquitectura de software" para mí, las características principales establecidas en el artículo se consideran buena arquitectura. Todavía estoy abierto a sus pensamientos para la discusión y los debates. Referencias: https://martinfowler.com/architecture/ https://learning.oreilly.com/library/view/fundamentals-of-software/9781492043447/ https://learning.oreilly.com/library/view/software-architecture-in/9780132942799/
