En un mundo de interrupciones sin precedentes en el mercado, donde las barreras de entrada se están desmoronando y una gran experiencia de usuario significa más que un nombre de marca de cien años, los CEO esperan una conversación diferente con IT. CIOs y CTOs están tratando de cambiar el interlocutor de la conversación de un proveedor de IT a un socio de negocios. Una conversación de proveedores de IT (negocios esperando por IT) suena familiar: ‘¿cuándo estará lista la infraestructura, cuándo ofrecerá la capacidad X, cómo puede reducir mi presupuesto en Y ?’.
Por el contrario, una conversación de Business Partner (IT esperando a los negocios) suena muy diferente: ‘siéntete libre de empezar a construir lo que necesitas cuando lo necesites mediante el aprovisionamiento bajo demanda; aquí hay una nueva API (interfaz de programación de aplicaciones) de seguridad que puede aprovechar; aquí están los resultados de un piloto que corrimos; y por cierto, redujimos los costos en Y este mes’. Este último es iniciado por IT con un solo objetivo en mente: llevar los productos al mercado. Y la aceleración de la innovación y el desarrollo de productos depende de aumentar la velocidad de sus constructores.
Para que esto suceda, las IT deben centrarse en las tareas que diferencian el negocio y permiten a los constructores moverse más rápido. Las tareas de IT que no diferencian el negocio deben automatizarse y descargarse a una plataforma que proporcione la mayor cantidad de funcionalidad posible fuera de la caja. Este cambio de paradigma requiere una transformación, y a menudo es más sobre las personas y su organización que la tecnología subyacente. Para muchos de nuestros clientes este es un viaje de varios años, uno que comenzó mucho antes de que surgiera la nube – se den cuenta o no.
Era Pre-Virtualización
En la era anterior a la virtualización, la implementación de la infraestructura era manual. La infraestructura tomó meses para ser aprovisionada, almacenada, apilada, cableada, instalada y configurada. La mayoría de las aplicaciones eran monolíticas, con estrechas interdependencias y despliegue manual. Las guías de instalación y configuración corren comúnmente decenas, sino cientos de páginas. La eficiencia del centro de datos también fue un desafío. Con tales largos ciclos de aprovisionamiento, las empresas a menudo proporcionan un 25-40% más de lo que se necesitaba durante el pico de uso. Con tanta capacidad desperdiciada, las tasas de utilización eran a menudo inferiores al 10%. En este modelo, los equipos de desarrollo, infraestructura y operaciones operaban en silos, requiriendo semanas o meses de planificación para cada cambio. Las operaciones en sí se convirtieron en un desafío importante, ya que todo se gestionaba y operaba manualmente, con poca estandarización en los entornos.
Promesas de virtualización / nube privada
La virtualización y la nube privada prometieron una mejor manera. Ellos trataron de mejorar la eficiencia del servidor, reducir la huella de la infraestructura, permitir la automatización y los nuevos modelos de prestación de servicios y, lo que es más importante, llevar la agilidad a los negocios.
En realidad, aunque la virtualización del servidor tuvo impactos positivos en el consumo de energía y enfriamiento e incluso permitió a las organizaciones consolidar y / o racionalizar algunos centros de datos, muchos de los beneficios prometidos no se han alcanzado completamente. El tiempo de aprovisionamiento del servidor ha disminuido y los servidores a menudo se pueden convertir en minutos, pero la realidad es que el aprovisionamiento y la planificación de la capacidad no ha mejorado significativamente. Los constructores todavía se ven obligados a adquirir la capacidad requerida para el pico basado en los patrones de uso anticipados (y evasivos) de su producto. En algunos casos, los constructores deben duplicarlos para adaptarse a los escenarios de recuperación de desastres (DR o n-1). Casos de negocio para difundir esto a través de múltiples unidades de negocio se desarrollan 3-5 años para justificar el gasto de capital, y en la mayoría de los casos hemos encontrado que no terminan pagando.
Los equipos de infraestructura han comenzado a aprovechar la automatización que permite la virtualización, pero en su mayor parte esta capacidad no se ha extendido a los equipos de desarrollo. Los modelos de entrega ‘autoservicio’ siguen siendo en su mayoría manuales, a menudo requieren días o semanas de aprobaciones usando automatización limitada. Los cambios son difíciles ya que los equipos siguen operando en silos, y la orquestación de los cambios a través de estos silos a menudo viene con una gran cantidad de gastos administrativos burocráticos que rara vez se gestiona bien. En última instancia, muy poco se ha logrado en términos de velocidad del constructor. Los constructores siguen frustrados por la limitada automatización, lo que afecta su productividad. Todavía toma demasiado tiempo para hacer las cosas por el negocio.
La buena noticia es que las organizaciones que han tomado medidas para virtualizar sus entornos o perseguir una estrategia de nube privada son capaces de pasar a la siguiente fase de esta evolución a un ritmo más rápido que los clientes que aún no han hecho ese cambio. La virtualización no sólo simplifica la migración real de las máquinas virtuales, sino que también es un reflejo de la capacidad de una organización para transformar, adaptarse a las necesidades del negocio y mejorar su fuerza de trabajo de IT.
Viaje a la nube
Completar el cambio a la nube ayuda a los clientes a darse cuenta de las promesas incumplidas de la virtualización. El aprovisionamiento a la carta de recursos de red, computación, almacenamiento, base de datos y otros en un modelo de pago por uso proporciona agilidad sin precedentes y ayuda a acelerar la velocidad de los equipos de desarrollo. Pero incluso en la nube, esta transformación no es instantánea. Más bien, la velocidad de los equipos de desarrollo se acelera a medida que el cliente viaja a través de varias etapas de adopción.
Etapas de Adopción
Adopción de la nube – Proyectado a través de las etapas de migración
Durante las primeras tres etapas de adopción de la nube, donde las organizaciones 1) comienzan con unos cuantos proyectos para aprender los beneficios, 2) sientan las bases para la transformación organizacional a través de un equipo de centro de excelencia de nube (CCoE), y 3) ejecutan migraciones masivas, para empezar a ver la realización de varios factores clave que aceleran directamente la velocidad de sus constructores.
-
Infraestructura como código: a principios de la etapa del proyecto, los clientes pueden hacer ciertas cosas manualmente. Sin embargo, a medida que avanzan hacia las etapas de Fundación y Migración, embrazan la Infraestructura como Código. Esto significa que toda la infraestructura no es simplemente automatizada con scripts, sino que se desarrolla y mantiene como código (es decir, CloudFormation). Estas plantillas pueden reutilizarse para desplegar entornos completos y pilas en cuestión de minutos.
-
Cloud COE: el equipo Cloud COE desarrolla y mantiene las plantillas básicas de infraestructura, diseña arquitecturas de referencia, educa a los equipos de desarrollo y los ayuda a migrar aplicaciones a la nube. Los equipos de desarrollo aprovechan la infraestructura como tuberías de código y están comenzando a desarrollarlas también de integración continua para sus aplicaciones.
-
Adopción de los servicios de AWS: durante estas primeras etapas, vemos un alto grado de adopción de los servicios de base de AWS, incluyendo Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS) Service (S3), AWS Identity and Access Management (IAM), Servicio de administración de claves AWS (KMS), AWS CloudFormation y Amazon CloudWatch. Los clientes también están empezando a desacoplar sus aplicaciones monolíticas y aprovechar los servicios gestionados de AWS cuando es posible. El grado de adopción de los servicios de nivel superior en estas etapas normalmente depende de la estrategia de migración del cliente y qué porcentaje de aplicaciones es nativo de la nube y qué porcentaje se está reorganizando o refactorizado para aprovechar toda la amplitud de la plataforma AWS.
-
Seguridad: aunque la seguridad puede ser tradicionalmente un gran obstáculo para la agilidad, cuando se implementa adecuadamente en AWS, puede aportar un nivel de transparencia, auditabilidad y automatización mucho mayor de lo que se puede lograr en premisa.
Adopción de la Nube – Fase de Reinvención
No hay duda de que la velocidad de los equipos de desarrollo se mejora mucho cuando el cliente se mueve a través de las etapas iniciales de adopción. Pero en la mayoría de los casos, la oportunidad de optimizar no termina con la etapa de migración. Rara vez los clientes tienen la oportunidad o los recursos para volver a diseñar todas sus aplicaciones para que sean nativas de la nube como parte de la migración (vea Cloud-Native vs. Lift-and-Shift). Esto crea una oportunidad para la reinvención constante para acelerar aún más la velocidad del constructor. Volver a diseñar la arquitectura de las aplicaciones a menudo implica desacoplar y descomponer el monolito en servicios más pequeños con API, mientras que se maximiza la reutilización. Como parte de este proceso, los clientes buscan descargar las porciones indiferenciadas de la aplicación a la plataforma AWS y enfocarse en la lógica de negocio en su lugar.
Durante la fase de reinvención, las organizaciones suelen optar por servicios totalmente gestionados como Amazon Kinesis para la ingesta de datos, AWS Lambda para procesamiento en tiempo real, Amazon Aurora y Amazon DynamoDB para bases de datos relacionales y NoSQL y Amazon Redshift para almacenamiento de datos, para que los constructores puedan gastar la cantidad máxima de tiempo en los diferenciadores de negocios. Es poco probable que el desarrollo de la mejor solución de gestión de colas, mensajería o API sean los que ‘muevan la aguja’ para el negocio. Por el contrario, son los algoritmos, flujos de trabajo de negocios y análisis en tiempo real los que deslumbrarán a los clientes y ayudarán a hacer crecer el negocio.
En esta etapa, también vemos un esfuerzo más enfocado para transformar operaciones en un verdadero modelo de desarrollo de operaciones. El Cloud COE también se centra más en el desarrollo de arquitecturas de referencia, gobernabilidad y marcos de cumplimiento y permite al equipo de desarrollo más autonomía para desplegar infraestructura y aplicaciones a través de un canal unificado CI / CD. Y los equipos de seguridad están acelerando su velocidad al adoptar las metodologías de desarrollo de operaciones seguras y exponer las capacidades de seguridad a través de las API.
Con cualquier transformación, puede ser difícil saber cómo medir el éxito y mantener el objetivo final a la vista. Centrarse en la velocidad de los equipos de desarrollo proporciona un gran criterio para el éxito de la nube y puede ayudar a guiar sus decisiones a medida que se convierte en un socio de negocios y continúa evolucionando y reinventándose con AWS.
-
-
-
-
