Las opciones técnicas están realizadas y asumidas por Equipo de características.
El Equipo de características debe actuar responsablemente para identificar las opciones que lo afectan exclusivamente y las elecciones que impactan a la organización.
Las opciones que exceden el alcance del Equipo de características (por ejemplo, licencia, lenguaje de programación infrecuente) deben validarse por la organización o por el proceso de convergencia entre pares .
La herramienta correcta para buen uso es una fuente de ahorro.
Una mala herramienta impuesta a todos es un riesgo. El uso indebido de una buena herramienta puede tener consecuencias muy dañinas **. Por ejemplo, los métodos ágiles mal utilizados son peligrosos.
herramientas debe ser cuestionado.
Excel a menudo es una opción racional pero no es una herramienta para hacer todo ** (CRM, ERP, Datamart, …)
Privilege Build para el negocio principal.
Considere Comprar para el resto, caso por caso.
Cuanto más una herramienta tenga una función de característica diferenciadora para la organización, más se pretende que se cree. El negocio principal debe permitir la especificidad y adaptarse rápidamente ya menudo. Algunos paquetes de software a veces se adaptan a esta necesidad.
Para el resto : SaaS, Open Source, Build o Owner se estudiarán caso por caso.
Aproveche al máximo el código abierto.
Las opciones alternativas deben ser compatibles.
Las soluciones propietarias son un riesgo para la organización que debe poder reanudar el mantenimiento si es necesario.
Hay pocas herramientas propietarias que no tienen alternativas de código abierto.
La organización se beneficia de la Comunidad de Código Abierto y puede devolver sus contribuciones.
Desarrollar servicios independientes y débilmente acoplados.
acoplamiento débil debe ser la norma.
Cada micro-servicio tiene una interfaz claramente definida.
Esta interfaz determina el enlace entre los micro servicios.
Domain Driven Design permite, especialmente con Contextos acotados , anticipar este problema.
Cada servicio tiene su propio ** sistema de almacenamiento de datos.
Un Data Store está destinado a ser acoplado solo con un solo micro-servicio.
El acceso a los datos de un micro-servicio a otro se hace exclusivamente a través de su interfaz.
Este diseño implica consistencia en el tiempo en toda la plataforma. Debe ser aprehendido en todos los niveles, incluido UX.
Cada micro-servicio debe tener un perímetro funcional razonable, que "cabe en la cabeza".
Un micro-servicio ofrece un número razonable de funciones.
No dude en cortar un micro-servicio cuando este empiece a crecer.
Un servicio de tamaño razonable permite considerar serenamente la reescritura , si surge la necesidad.
El Manifiesto reactivo abre el camino hacia el diseño de arquitecturas reactivas.
La programación sensible se centra en el flujo de datos y la propagación del cambio. Se basa en el patrón " Observer " al contrario del enfoque " Iterator ", más tradicional.
El Manifiesto reactivo establece los ejes fundamentales: disponibilidad y velocidad, resiliencia a las interrupciones, flexibilidad , elasticidad y orientación del mensaje.
los procesos asincrónicos favorecen desacoplamiento y escalabilidad a favor de rendimiento **.
El intercambio entre aplicaciones debe ser asincrónico primero.
Los intercambios asíncronos naturalmente permiten un acoplamiento débil , aislamiento y control de flujo ( contrapresión **).
la comunicación síncrona solo debe considerarse cuando la acción lo requiera.
El sistema de información debe estar orientado eventos.
Los procesos **** *de* procesos impulsados por eventos están naturalmente implementados de forma asincrónica.
La orientación del evento permite favorecer la implementación de enfoques tales como C ommand Q uery R sponsibility S egregation (CQRS) y Event Sourcing.
Privilege a agente de mensajería simple, robusto y poderoso a un "conducto inteligente".
ESB mostró límites : el mantenimiento escalable es crítico , tanto desde el punto de vista técnico como organizacional.
Los mensajes de Broker como Kafka ofrecen una solución simple , duradera y flexible.
Puntos finales inteligentes y Tuberías simples es una arquitectura que funciona a escala: es Internet.
La sincronización completa del sistema debe pensarse tan pronto esté diseñado.
Si la sincronización entre dos sistemas está garantizada por un flujo de eventos , la resincronización total de estos sistemas debe planificarse en el momento del diseño.
Una **** *auditoría de sincronización* automática (ejemplo: por ejemplos) permite medir y detectar posibles errores de sincronización.
La configuración de los servicios está centralizada, su descubrimiento está garantizada por un directorio.
La configuración de los micro-servicios está centralizada para todos los entornos.
Un directorio central garantiza descubrimiento dinámico de micro-servicios.
La escalabilidad global depende de este directorio **.
Los equipos especiales proporcionan un entorno ** de espacio aislado.
Los equipos especiales mantienen un entorno de recinto de seguridad (versión actual y próximo lanzamiento) para permitir que otros equipos amplíen.
En algunos casos no nominales, funciones pueden estar inhabilitados en el entorno de desarrollo.
¡Tu sistema se bloqueará!
Diseñarlo para que sea tolerante.
Tu sistema fallará, es inevitable. Debe estar diseñado para esto (Design For Failure).
Predecir redundancia en todos los niveles: hardware (red, disco, etc.), aplicaciones (instancias múltiples de aplicaciones), zonas geográficas, proveedores (ejemplo: AWS + OVH).
Proporcione kits de herramientas , no imponga marcos estrictos.
Atención a los componentes técnicos casas y transversal ! Son restrictivos, caros y difíciles de mantener.
aceleradores , juegos de herramientas , acumulaciones técnicas pueden ser agrupados , gratuitos Equipos destacados, evitando un enfoque dogmático.
Público, privado o híbrido, la nube (IaaS o PaaS) es el estándar para la producción.
Los servicios de PaaS son preferidos, simples y se escalan rápidamente.
Los servicios IaaS le permiten abordar casos que requieren una mayor flexibilidad pero requieren más trabajo operativo.
Una nube privada no es un entorno de virtualización tradicional, sino que se basa en hardware básico.
Los equipos especiales no administran la infraestructura, la organiza y la mantiene.
Los problemas de infraestructura no están dentro de Equipos destacados. La infraestructura debe proporcionarse y mantenerse mediante un servicio ** con funciones cruzadas.
Los contenedores brindan la flexibilidad necesaria para herramientas heterogéneas.
Los contenedores proporcionan la flexibilidad que necesitan los equipos de características para habilitar herramientas heterogéneas en un contexto homogéneo.
El uso de contenedores hace posible superar los problemas de entornos técnicos.
Los contenedores (ejemplo: Docker) hacen posible ser liberado de las diferencias de entorno.
El proceso de implementación debe ser agnóstico para el entorno.
Algunos componentes como las bases de datos no se deben implementar en contenedores. Su implementación aún está automatizada.
Las medidas deben estar centralizadas y accesibles para todos.
Las métricas son accesibles para todas las personas con diferentes niveles de granularidad: vista detallada de la función del equipo relevante, agregaciones para otros miembros de la organización.
El acceso a las métricas no implica el acceso a los datos de la unidad , debe controlarse para mantener la confidencialidad.
Todos los entornos están afectados.
la calidad del software es un factor clave.
las revisiones de los códigos son sistemáticas. Son dirigidos por miembros del Equipo de funciones u otros miembros de la organización, como parte de Continuous Improvement.
Eso no está siendo auditado sino su código : "¡Usted no es su código!".
El qualimetry puede ser parcialmente automatizado, pero nada supera al "nuevo ojo".
Pruebas automatizadas es un requisito previo no negociable para la implementación continua.
Pruebas automatizadas asegura calidad del producto a lo largo del tiempo.
Es un prerrequisito para la implementación continua, permite **** cambios *y* implementaciones frecuentes **.
¡El lanzamiento de la producción se convierte en un evento anecdótico !
Pruebas en todos los niveles : unidad, integración, funcional, resiliencia, rendimiento.
Las pruebas de integración y funcional son las más importantes garantizan la operación efectiva **.
Las pruebas de unidad son adecuadas para desarrollo.
las pruebas de rendimiento miden el rendimiento a lo largo del tiempo **.
Las pruebas de resiliencia ayudan a anticipar fallas.
Cover es el principal indicador objetivo de la calidad de la prueba.
La cobertura del código según las pruebas es una buena métrica de la calidad del código.
Esta es una condición necesaria pero no suficiente, la cobertura de una estrategia de prueba incorrecta puede ser alta sin garantizar la buena calidad del código.
La seguridad es un proceso , no debe tratarse en respuesta a los problemas.
expertos en seguridad pueden integrarse directamente en los equipos de características si es necesario.
expertos en seguridad están disponibles en la organización para auditoría , conocimiento y reenvío.