Microservicios

Las ventajas de implementar una infraestructura basada en microservicios se han convertido en el eje central de la transformación digital para las empresas que buscan liderar el entorno empresarial actual. Los sistemas tradicionales conocidos como "monolíticos" —aquellos donde todo el software está amarrado en una sola pieza masiva y rígida— han quedado completamente obsoletos. Hoy en día, la agilidad operativa y la capacidad de adaptación ya no son consideradas un lujo o una ventaja competitiva opcional; son, en realidad, un requisito de supervivencia en cualquier sector económico. Las caídas del sistema, las lentitudes en los tiempos de carga durante picos de tráfico y los largos meses de espera para lanzar una simple actualización son problemas del pasado que las empresas modernas ya no pueden permitirse.

Microservicios

Microservicios es un enfoque de diseño de software que divide una aplicación en servicios pequeños, autónomos y orientados a capacidades concretas del negocio. Cada servicio puede desarrollar, probar, desplegar y escalar su funcionalidad con un grado elevado de independencia, siempre que mantenga contratos claros con los demás componentes. La idea no consiste en fragmentar el código por moda ni en crear decenas de aplicaciones diminutas, sino en reducir el acoplamiento, asignar responsabilidades comprensibles y permitir que los equipos evolucionen partes del sistema sin tener que publicar toda la plataforma al mismo tiempo.

¿Qué son los microservicios?

La consulta “que son los microservicios” suele responderse con una frase sencilla: son servicios independientes que colaboran mediante interfaces bien definidas. Sin embargo, la independencia técnica solo aporta valor cuando el límite coincide con una capacidad del negocio. Un servicio de pagos, por ejemplo, puede encargarse de autorizar cobros, registrar intentos, procesar devoluciones y emitir eventos relacionados con la transacción. Separar “crear pago”, “validar tarjeta” y “guardar pago” en tres servicios distintos no mejora necesariamente el diseño; puede generar más llamadas de red, más puntos de fallo y una operación difícil de mantener.

Un microservicio bien delimitado reúne lógica, datos y reglas que cambian por una razón común. Google Cloud describe cada microservicio como una unidad autocontenida, con código, datos y dependencias propios, centrada en una función específica de la aplicación. AWS también destaca el desarrollo y despliegue independientes como rasgos centrales del modelo.

Una forma práctica de evaluar el límite de un servicio es aplicar la prueba de las cuatro D: dominio, datos, dependencias y despliegue. El dominio debe representar una responsabilidad reconocible para el negocio; los datos deben tener un propietario claro; las dependencias no deberían obligar a coordinar cada cambio con varios equipos; y el despliegue tendría que poder realizarse sin publicar el sistema completo. Cuando una pieza falla en las cuatro dimensiones, suele tratarse de un módulo interno o de un fragmento arbitrario, no de un microservicio maduro.

También conviene distinguir autonomía de aislamiento absoluto. Los servicios necesitan comunicarse, compartir eventos y participar en procesos de negocio amplios. La autonomía significa que cada uno controla su implementación y su ciclo de vida, no que opere sin relación con el resto. Un pedido puede requerir inventario, pago y envío; la arquitectura debe coordinar esas capacidades sin convertirlas en una única unidad rígida.

Arquitectura microservicios

La expresión arquitectura microservicios abarca mucho más que contenedores y API REST. Una solución completa suele incluir servicios de negocio, mecanismos de descubrimiento, balanceo de carga, autenticación, mensajería, observabilidad, gestión de configuración, automatización de despliegues y políticas de resiliencia. Kubernetes puede gestionar cargas contenedorizadas, distribuir tráfico y mantener el estado deseado de los despliegues, pero no sustituye decisiones como la división del dominio, el contrato de las API o la propiedad de los datos.

La comunicación síncrona es adecuada cuando el consumidor necesita una respuesta inmediata. Consultar el precio vigente de un producto o validar una autorización son ejemplos habituales. HTTP y gRPC pueden resolver esos intercambios, aunque cada llamada añade latencia y crea una dependencia temporal: ambos servicios deben estar disponibles al mismo tiempo. Por esa razón, una cadena de seis o siete llamadas síncronas para completar una sola solicitud suele ser una señal de riesgo.

La comunicación asíncrona mediante eventos o colas reduce el acoplamiento temporal. Cuando el servicio de pedidos publica “PedidoCreado”, inventario puede reservar unidades, notificaciones puede enviar un correo y analítica puede registrar el evento sin bloquear la respuesta al cliente. El modelo exige tratar duplicados, reintentos, orden de mensajes e idempotencia. La mensajería no elimina la complejidad; la desplaza hacia reglas explícitas que deben diseñarse y observarse. AWS recoge la mensajería asíncrona como uno de los patrones de integración utilizados para desacoplar y escalar sistemas distribuidos.

El gobierno técnico tampoco debería convertirse en una prohibición absoluta de tecnologías. Permitir que cada equipo elija cualquier lenguaje, base de datos y protocolo puede generar una plataforma imposible de operar. Una política más equilibrada define un catálogo reducido de opciones compatibles, plantillas de servicio, requisitos mínimos de seguridad, telemetría obligatoria y contratos de integración. La libertad se conserva dentro de límites operables.

Arquitectura de microservicios frente al monolito

La arquitectura de microservicios no es superior al monolito en todos los escenarios. Un monolito modular puede ofrecer despliegues sencillos, transacciones locales, depuración directa y menor coste de infraestructura. Para una empresa que valida un producto nuevo, un equipo pequeño o un sistema con pocas variaciones de carga, esa opción suele ser más eficiente. Los microservicios empiezan a justificar su coste cuando existen dominios diferenciados, equipos que necesitan autonomía, ritmos de cambio distintos o componentes con necesidades de escalado muy desiguales.

La decisión correcta depende del coste total, no solo de la elegancia del diagrama. Un sistema distribuido añade latencia de red, fallos parciales, versiones de contratos, consistencia eventual y una superficie de seguridad más amplia. A cambio, puede permitir despliegues independientes, escalado selectivo y evolución tecnológica gradual. AWS y Google Cloud señalan la escalabilidad, la resiliencia, la flexibilidad y la velocidad de entrega entre los beneficios potenciales, pero esos beneficios dependen de una implementación disciplinada.

Una señal de alerta es el llamado monolito distribuido: muchos servicios que deben desplegarse juntos, consultan la misma base de datos y se llaman de forma circular. El número de repositorios puede haber aumentado, pero la autonomía no. Antes de dividir una aplicación, conviene mejorar la modularidad interna, definir límites de dominio y medir qué partes cambian o escalan de manera independiente.

Implementación de microservicios

La implementación de microservicios debería comenzar con un problema concreto. Migrar toda una aplicación de una sola vez multiplica riesgos y dificulta saber qué cambio produjo una mejora o una regresión. Una estrategia más segura consiste en extraer una capacidad con límites claros, tráfico medible y dependencias manejables. Notificaciones, generación de documentos o procesamiento de imágenes suelen ser candidatos más simples que pagos, identidad o conciliación financiera.

El primer paso es construir un mapa del dominio. Hay que identificar capacidades, reglas, actores, eventos y fuentes de datos. Después se analizan patrones de cambio: qué funciones se modifican juntas, cuáles tienen picos de carga propios y dónde se concentran los incidentes. Ese análisis evita dividir la aplicación según capas técnicas —interfaz, lógica y persistencia—, una práctica que suele mantener el acoplamiento.

El segundo paso es definir el contrato. Cada API necesita operaciones, esquemas, códigos de error, reglas de compatibilidad y política de versiones. Cada evento requiere nombre, significado, productor, consumidores previstos y estrategia de evolución. Un contrato no es solo documentación; es un compromiso operativo que debería validarse con pruebas automáticas.

El tercer paso es asignar la propiedad de los datos. Compartir una única base entre todos los servicios facilita el inicio, pero permite que un equipo altere tablas utilizadas por otros y elimina la autonomía. La separación no obliga a usar un motor distinto por servicio; significa que cada conjunto de datos tiene un propietario y que el acceso externo se realiza mediante contratos.

Cuando un proceso atraviesa varios servicios, patrones como saga, outbox transaccional e idempotencia ayudan a gestionar la consistencia sin depender de una transacción global. Por ejemplo, la creación de un pedido puede iniciar una reserva de inventario, una autorización de pago y una solicitud de envío. Si el pago falla, el proceso debe liberar el inventario mediante una acción compensatoria claramente definida.

El cuarto paso es automatizar la entrega. Cada servicio necesita integración continua, pruebas, análisis de seguridad, artefactos versionados, despliegue repetible y una estrategia de reversión. Las publicaciones canary o blue-green reducen el impacto de una versión defectuosa al exponerla primero a una parte del tráfico. Kubernetes ofrece objetos de Deployment y Service para actualizar cargas y proporcionar acceso estable a conjuntos cambiantes de pods.

El quinto paso es establecer criterios de salida. Un servicio no debería considerarse listo solo porque responde en desarrollo. Debe contar con paneles, alertas, límites de recursos, copias de seguridad cuando correspondan, documentación de soporte, responsable operativo y procedimientos para incidentes. La capacidad de operar forma parte del producto.

Una lista de comprobación previa al despliegue puede incluir los siguientes puntos:

• Contratos de API o eventos documentados y versionados.
• Pruebas unitarias, de integración y de contrato ejecutadas automáticamente.
• Tiempos de espera y políticas de reintento definidos.
• Métricas, logs y trazas distribuidas disponibles.
• Estrategia de reversión probada.
• Secretos gestionados fuera del código fuente.
• Límites de CPU y memoria configurados.
• Responsable técnico y operativo identificado.
• Procedimiento de recuperación documentado.
• Dependencias externas inventariadas.

La implementación también debe considerar la capacidad del equipo. Crear veinte servicios sin una plataforma común obliga a repetir configuración, seguridad, despliegues y observabilidad veinte veces. Una plataforma interna puede ofrecer plantillas, canalizaciones, gestión de secretos, telemetría y entornos estandarizados sin impedir que cada equipo controle su lógica de negocio.

Características de los microservicios que aportan valor real

Las características de los microservicios más relevantes no se miden por el tamaño del repositorio, sino por el comportamiento del sistema y de los equipos:

• Responsabilidad delimitada: el servicio representa una capacidad del negocio y evita mezclar reglas sin relación.
• Despliegue independiente: una nueva versión puede publicarse sin coordinar una liberación global.
• Propiedad clara: un equipo conoce el código, los datos, los indicadores y la operación del servicio.
• Contrato explícito: las interacciones se realizan mediante API o eventos versionados.
• Aislamiento de fallos: los errores se contienen mediante límites, tiempos de espera, reintentos controlados y degradación funcional.
• Escalado selectivo: se asignan recursos a la función que realmente los necesita.
• Observabilidad incorporada: métricas, trazas y registros permiten reconstruir el comportamiento de una solicitud distribuida.
• Automatización: pruebas, despliegue, configuración y recuperación reducen tareas manuales propensas a errores.

No todas esas propiedades aparecen al crear el primer servicio. La madurez se construye. Un equipo puede empezar con despliegue independiente y telemetría básica, y después mejorar resiliencia, seguridad y autoservicio. Lo importante es evitar que la cantidad de servicios crezca más rápido que la capacidad para operarlos.

El tamaño del servicio tampoco debe definirse por un número fijo de líneas de código. Un microservicio puede contener varios módulos internos si todos pertenecen a la misma capacidad. Dividirlo solo para hacerlo más pequeño puede aumentar la comunicación, la latencia y el trabajo operativo sin mejorar la comprensión del dominio.

La independencia tecnológica es otra característica frecuente, aunque no implica que cada servicio deba utilizar una tecnología distinta. La autonomía permite elegir una herramienta especializada cuando existe una necesidad verificable. Si todos los servicios tienen requisitos similares, compartir lenguaje, bibliotecas y prácticas puede reducir costes de soporte y facilitar la movilidad de los desarrolladores.

Ventajas de los microservicios y condiciones necesarias

Las ventajas de los microservicios se vuelven visibles cuando existe una relación directa entre arquitectura y necesidad empresarial. El escalado independiente, por ejemplo, es valioso en una tienda digital donde las consultas de catálogo reciben cien veces más tráfico que la administración de devoluciones. Escalar ambos componentes por igual desperdiciaría recursos. La separación permite asignar capacidad según la demanda real.

La autonomía de los equipos también puede reducir bloqueos. Un equipo responsable de envíos puede mejorar reglas de transportistas sin esperar la publicación del módulo de promociones. Sin embargo, esa autonomía requiere contratos estables, propiedad de extremo a extremo y una plataforma interna que simplifique tareas repetitivas. Sin esos elementos, la organización cambia reuniones de coordinación por incidentes de integración.

Otra ventaja es el aislamiento progresivo de fallos. Si el servicio de recomendaciones deja de responder, la tienda puede mostrar productos sin personalización en lugar de bloquear la compra. Ese comportamiento no ocurre automáticamente: deben definirse tiempos de espera, circuit breakers, valores alternativos y presupuestos de latencia. La resiliencia nace de decisiones de diseño y pruebas de fallo, no del simple hecho de usar servicios pequeños.

La velocidad de entrega puede mejorar cuando los equipos publican cambios pequeños y controlados. Un error en el servicio de notificaciones no obliga necesariamente a revertir cambios de catálogo o inventario. Esa separación reduce el alcance de una publicación, pero exige conocer las dependencias y mantener la compatibilidad entre versiones.

La diversidad tecnológica puede ser útil cuando una capacidad necesita herramientas especiales, pero debe aplicarse con moderación. Un motor de búsqueda puede requerir una tecnología distinta de la utilizada para la gestión de usuarios. Elegir cinco lenguajes para cinco servicios similares, en cambio, aumenta la carga de mantenimiento, seguridad y contratación sin crear una ventaja clara.

La reutilización también puede ser una ventaja cuando una capacidad ofrece un contrato estable para varios productos. Un servicio de identidad, documentos o cálculo fiscal puede atender diferentes aplicaciones. No obstante, convertir todos los servicios en componentes compartidos crea nuevas dependencias organizativas. La reutilización debe responder a necesidades reales, no a la intención de construir una plataforma universal desde el primer día.

Mejores prácticas de monitorización de microservicios

Las mejores prácticas de monitorización de microservicios parten de una diferencia esencial: monitorizar comprueba estados conocidos; observar permite investigar situaciones que no se anticiparon. En un sistema distribuido no basta con saber que la CPU está al 70 %. Hace falta relacionar la experiencia del usuario con los servicios, dependencias y cambios que participaron en cada solicitud.

OpenTelemetry define un marco abierto y neutral respecto al proveedor para generar, recopilar y exportar telemetría. Sus señales principales incluyen trazas, métricas y logs. Una traza distribuida registra el recorrido de una solicitud a través de varios servicios, mientras que las métricas resumen comportamientos y los logs aportan eventos detallados.

La monitorización debería comenzar con indicadores orientados al usuario:

Cada servicio necesita objetivos de nivel de servicio o SLO vinculados con una experiencia concreta. “El 99,9 % de las solicitudes de confirmación de pedido se completará correctamente en menos de 800 milisegundos durante una ventana de 30 días” es más útil que “la API debe ser rápida”. El SLO orienta alertas, capacidad y prioridades de ingeniería.

Las métricas técnicas deben relacionarse con métricas de negocio. Un servicio puede mostrar CPU, memoria y latencia normales mientras rechaza pedidos por una regla configurada incorrectamente. Medir pagos autorizados, reservas completadas, documentos generados o envíos aceptados permite identificar fallos que no aparecen como errores de infraestructura.

Las trazas requieren propagación de contexto. Un identificador común debe viajar entre servicios, colas y procesos asíncronos para reconstruir el recorrido completo. Los logs estructurados deberían incluir marca temporal, nivel, servicio, versión, entorno, trace ID, operación y campos de negocio no sensibles. La correlación entre logs, métricas y trazas reduce el tiempo dedicado a saltar entre herramientas. OpenTelemetry contempla precisamente la correlación del contexto distribuido entre esas señales.

También es necesario controlar la cardinalidad. Añadir identificadores de usuario, URL completas o valores únicos como etiquetas de métricas puede disparar el consumo de memoria y el coste del sistema de observabilidad. OpenTelemetry advierte que la cardinalidad crece con cada combinación de atributos y recomienda limitar atributos de alta variabilidad.

Las alertas deben indicar impacto y acción. Una alarma por cada excepción genera ruido; una alerta basada en consumo acelerado del presupuesto de error ayuda a priorizar incidentes reales. El panel operativo de un servicio debería mostrar versión desplegada, tasa de solicitudes, errores, latencia, saturación, dependencias externas y eventos recientes de despliegue.

Vincular cambios con degradaciones permite responder una pregunta decisiva: “¿Qué cambió antes de que comenzara el problema?”. Registrar despliegues, modificaciones de configuración, cambios de infraestructura y versiones de dependencias facilita la investigación. Una gráfica de latencia sin contexto temporal muestra el síntoma, pero no siempre orienta hacia la causa.

La propia canalización de observabilidad también necesita supervisión. Si el colector deja de exportar datos o las colas de telemetría se saturan, los equipos pueden interpretar la ausencia de información como ausencia de problemas. OpenTelemetry contempla señales internas para observar el estado de los procesadores, exportadores y componentes de la canalización.

Seguridad, datos y resiliencia en una arquitectura distribuida

La superficie de ataque aumenta cuando existen más identidades, endpoints y canales de comunicación. Cada servicio debe autenticarse, autorizar acciones y proteger secretos. El tráfico interno no debería considerarse confiable por defecto. Identidades de carga, cifrado en tránsito, rotación de credenciales y privilegios mínimos reducen el impacto de una intrusión.

Las API necesitan límites de consumo, validación de entradas y protección frente a solicitudes repetidas. Los eventos también deben validarse: un mensaje mal formado puede propagarse por varios consumidores. La seguridad del software incluye imágenes actualizadas, dependencias revisadas, análisis de vulnerabilidades y trazabilidad de artefactos desde el código hasta producción.

La propiedad de los datos debe quedar documentada. Si dos servicios pueden modificar la misma tabla, ninguno controla realmente sus reglas. El servicio propietario puede ofrecer una API de consulta, publicar eventos o proporcionar modelos de lectura específicos para otros consumidores. Duplicar ciertos datos para lectura puede ser aceptable si existe una fuente de verdad definida y un mecanismo de actualización verificable.

La consistencia eventual no significa aceptar información incorrecta de forma indefinida. Significa que el sistema reconoce un intervalo controlado durante el cual varios componentes pueden mostrar estados diferentes. Ese intervalo debe medirse y limitarse. Un pedido puede aparecer como “pendiente de pago” durante algunos segundos, pero no debería permanecer así durante horas sin alerta ni mecanismo de reconciliación.

La resiliencia requiere límites explícitos. Los reintentos sin control pueden multiplicar la carga sobre un servicio degradado. Cada llamada debería tener timeout, política de reintento con espera y jitter, y un máximo definido. Las operaciones que pueden repetirse necesitan idempotencia para evitar cobros duplicados, reservas múltiples o mensajes enviados varias veces.

Un circuit breaker puede detener temporalmente llamadas hacia una dependencia con fallos recurrentes. El bulkhead separa recursos para impedir que una función consuma todas las conexiones o hilos disponibles. Las colas absorben variaciones de carga, aunque necesitan límites, colas de mensajes fallidos y políticas de reprocesamiento. Ningún patrón sustituye las pruebas; cada mecanismo debe ensayarse bajo fallos controlados.

Ejemplo práctico: evolución de una plataforma de comercio electrónico

Imaginemos una tienda que comenzó como un monolito con catálogo, carrito, pedidos, pagos, inventario y notificaciones. El problema no es el tamaño del código, sino que las campañas promocionales elevan el tráfico del catálogo y obligan a escalar toda la aplicación. Además, los cambios de pagos requieren una publicación completa y aumentan el riesgo durante días de alta demanda.

Una extracción razonable podría empezar por notificaciones. Tiene límites claros, tolera procesamiento asíncrono y puede consumir eventos como “PedidoConfirmado” o “PagoRechazado”. Después podría separarse catálogo si sus necesidades de lectura y escalado son muy distintas. Pagos se extraería más tarde, cuando existan controles sólidos de seguridad, observabilidad e idempotencia.

El diseño evita crear un servicio por entidad. “Producto”, “precio” e “imagen” no necesitan ser tres microservicios solo porque ocupan tablas diferentes. Pueden formar parte de la capacidad de catálogo si cambian juntas y comparten reglas. La pregunta útil no es cuántos servicios debería tener la tienda, sino qué límites permiten cambiar, desplegar y operar cada capacidad con menor coordinación.

Supongamos que catálogo recibe 4.000 solicitudes por segundo durante una campaña, mientras que devoluciones recibe 20. Si ambas funciones permanecen dentro de una unidad indivisible, la infraestructura debe escalar el conjunto. Al separarlas, catálogo puede recibir más réplicas y una estrategia de caché específica, mientras devoluciones mantiene una capacidad estable.

El cambio también modifica la investigación de incidentes. En el monolito, una solicitud puede seguirse dentro de un único proceso. Tras la separación, una compra puede atravesar carrito, inventario, pedidos, pagos y notificaciones. Sin un trace ID compartido, el equipo tendría que buscar manualmente marcas de tiempo y datos del pedido en diferentes sistemas. La observabilidad distribuida deja de ser una mejora opcional y se convierte en una condición operativa.

Para medir el éxito se compararían indicadores antes y después: frecuencia de despliegue, tiempo desde el cambio hasta producción, tasa de fallos por cambio, tiempo de recuperación, coste de infraestructura, latencia de compra e incidentes asociados a dependencias. Una migración que aumenta despliegues pero duplica incidentes no puede considerarse una mejora completa.

También deben evaluarse efectos organizativos. Si el equipo de catálogo depende del equipo de plataforma para cada cambio menor, el servicio puede ser técnicamente independiente pero operativamente dependiente. La autonomía real requiere herramientas de autoservicio, límites de responsabilidad claros y soporte especializado para problemas de infraestructura.

¿Cómo evitar los errores más frecuentes?

El primer error es empezar por la infraestructura. Instalar Kubernetes, una malla de servicios y varias bases de datos no define los límites del negocio. La plataforma debería responder a necesidades de despliegue y operación identificadas, no sustituir el trabajo de modelado.

El segundo error es dividir demasiado pronto. Cuando el dominio todavía no se comprende, los límites cambian con frecuencia y obligan a modificar contratos, datos y dependencias. Mantener módulos internos durante una fase inicial permite aprender con menor coste.

El tercer error es compartir bases de datos sin reglas. Aunque resulte práctico durante una transición, debe existir un plan para eliminar escrituras cruzadas. Como mínimo, cada tabla necesita un propietario, los cambios de esquema deben ser compatibles y los consumidores externos no deberían depender de detalles internos.

El cuarto error es confundir reintentos con resiliencia. Repetir una solicitud tres veces puede empeorar una caída. Los reintentos deben limitarse a errores transitorios, incluir espera progresiva y respetar el presupuesto total de latencia.

El quinto error es medir únicamente infraestructura. Una CPU estable no garantiza que los clientes puedan pagar. Los paneles deben incluir operaciones de negocio, dependencia externa y experiencia del usuario.

El sexto error es crear servicios sin responsables. Un repositorio compartido por varios equipos suele acumular decisiones inconexas. Cada servicio necesita propiedad técnica, contacto operativo y prioridades visibles.

El séptimo error es publicar cambios incompatibles. El productor de una API o un evento debe mantener compatibilidad suficiente para que los consumidores actualicen sus versiones sin interrupciones. Las pruebas de contrato ayudan a detectar cambios que rompen integraciones antes de llegar a producción.

¿Cuándo no conviene adoptar microservicios?

No conviene adoptar microservicios cuando el dominio todavía cambia de forma impredecible, el equipo es pequeño, la automatización es limitada o la aplicación no presenta necesidades diferenciadas de escala y despliegue. Tampoco son una solución automática para código desordenado. Dividir un sistema mal modelado puede distribuir el desorden entre redes, colas y repositorios.

Un monolito modular permite separar responsabilidades dentro de un solo despliegue y conservar transacciones simples. Puede evolucionar hacia servicios cuando los límites estén comprobados por cambios reales, no por suposiciones. La modularidad es una inversión útil en ambos caminos, tal como reconoce el marco de arquitectura de Google Cloud al relacionarla con flexibilidad, resiliencia, escalabilidad y recuperación.

Una empresa con tres desarrolladores y una aplicación administrativa de tráfico moderado probablemente obtendrá más valor de un monolito bien estructurado, pruebas automatizadas y despliegues confiables. Introducir varios servicios, mensajería, descubrimiento, trazas y administración de secretos podría consumir más capacidad que las funciones del producto. La decisión más sólida combina contexto técnico, estructura organizativa y economía operativa. Los microservicios aportan valor cuando resuelven cuellos de botella concretos y el equipo puede asumir la complejidad distribuida. Una arquitectura sostenible no busca maximizar el número de servicios; busca minimizar el coste de cambiar el negocio sin perder seguridad, estabilidad ni capacidad de diagnóstico.