Cómo la nube y los contenedores están impulsando la desagregación de los servicios de aplicação

• Las aplicações impulsan decisiones sobre todo, desde la ubicación hasta el formato de la infraestructura de entrega de soporte. El 55% de las organizaciones eligen una nube en función de las necesidades y requisitos de las aplicação . El 40% quiere poder elegir el formato adecuado para la aplicación. (Estado de la entrega de aplicação 2018)
• A medida que las arquitecturas de nube y microservicios se dividen y distribuyen aplicaciones, la infraestructura compartida se convierte en una carga en lugar de un beneficio, lo que aumenta los costos operativos y de capital. 
• El costo, la configuración y las actualizaciones son impulsores clave para respaldar arquitecturas por aplicación con servicios de aplicação por aplicación.
• Es necesario un enfoque por aplicación para los servicios de aplicação a fin de respaldar las aplicaciones y arquitecturas modernas.

En los últimos años hemos visto un esfuerzo concertado de los proveedores de la nube (Amazon, Microsoft, Google, etc.) para responder a la necesidad misma de las empresas de servicios de aplicação .

Hoy en día, en los mercados de la nube se puede encontrar una cantidad (y esta cifra está creciendo) de servicios de aplicação que abordan la seguridad (como los firewalls de aplicação web), así como el rendimiento (almacenamiento en caché) e incluso la gestión de identidad. Esto no es ninguna sorpresa. Las empresas dependen de un promedio de 16 servicios de aplicação diferentes para que sus aplicaciones sean más rápidas y seguras. Cada año ese número aumenta. Las empresas no van a sacrificarlos por la velocidad de la nube.

En ese sentido, los servicios de aplicação influyen tanto en los clientes como en los proveedores de la nube. Pero no es una calle de un solo sentido. La nube –y cada vez más los contenedores– también está teniendo un impacto significativo en los servicios de aplicação y en cómo se entregan.  

A medida que las organizaciones empresariales continúan invirtiendo en nubes privadas (locales) y experimentando con contenedores, descubren que el modelo tradicional de prestación de servicios de aplicação no siempre es adecuado.

Al igual que la mayor parte de la red, los servicios de aplicação se han entregado durante mucho tiempo a través de una plataforma (a menudo denominada Controlador de Entrega de Aplicação o ADC por sus siglas en inglés) respaldada por hardware escalable y confiable. Estos dispositivos fueron diseñados para alta disponibilidad y escalabilidad, capaces de soportar cientos de aplicações simultáneamente. La infraestructura compartida, ya sea de red o de aplicação , ha tenido desde hace mucho tiempo ventajas en términos de costos. Tenía sentido distribuir el capital y los gastos operativos entre múltiples aplicações .

Hasta que surgieron aplicaciones y arquitecturas donde antes no había.

Hay un número cada vez mayor de aplicaciones y arquitecturas que requieren un enfoque más afín a la aplicación. La moderna colección de microservicios, por ejemplo, exige una plataforma rápida, escalable y asequible en la que implementar servicios de aplicação para una sola aplicação.

Las plataformas de servicios compartidos no pueden satisfacer esa demanda como lo haría una plataforma diseñada específicamente para cada aplicación. Hay tres buenas razones para ello:

1. Costo. No sales a comprar una camioneta para doce pasajeros si eres la única persona que la usará. Todo ese espacio extra cuesta dinero extra por adelantado y para mantenerlo. En las situaciones adecuadas (y para las aplicações adecuadas) la infraestructura compartida reduce el costo por aplicação y tiene mucho sentido financiero y operativo. Pero si intentas dar soporte a una sola aplicação, solo sumarás gastos sin agregar valor.
2. Configuraciones. Las aplicaciones y arquitecturas modernas se desarrollan e implementan con actualizaciones frecuentes en mente. Si compartes una plataforma con otras ocho aplicaciones (que no siguen el mismo cronograma), es posible que se molesten un poco si algo sale mal y afecta sus aplicações. Sin mencionar que cuantas más configuraciones, y más grandes sean, más tiempo llevará leerlas y verificarlas cada vez que sea necesario recargarlas o modificarlas.
3. Actualizaciones. Cuando Bob quiere actualizar esa plataforma compartida y tú no, ¿quién gana? Si Bob gana -y eso rompe una aplicação nadie gana, ese es el que gana.  Las actualizaciones de la infraestructura compartida pueden ser una propuesta aterradora. También pueden generar tiempo adicional dedicado a actualizar o mejorar (o incluso migrar) las configuraciones a las versiones más nuevas, lo que nos lleva nuevamente al problema número uno y los costos que pueden acumularse.

Existe una necesidad (y una demanda) de una plataforma de servicios de aplicação diseñada específicamente para soportar una única aplicação. Al reducir la responsabilidad a una sola aplicação , se reduce el tamaño (y la complejidad) de la configuración, se limita el radio de explosión de una actualización fallida a una sola aplicación y se reduce el costo tanto de adquisición como de operación.

Debido a la nube, los contenedores y los microservicios. Debido a DevOps y la economía digital que impulsa a las organizaciones a entregar con mayor rapidez y frecuencia.

Las aplicações y las arquitecturas están cambiando. Los entornos están cambiando. Esto significa que los servicios de aplicação –y sus mecanismos de distribución– también deben cambiar.