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 TI. CIOs y CTOs están tratando de cambiar la conversación de un proveedor de
TI a un socio de negocios. Una conversación de proveedores de TI (negocios
esperando por TI) 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 socios de negocios (TI esperando a los
negocios) suena muy diferente: "siéntete libre de empezar a construir lo
que necesitas cuando lo necesites al proporcionarlo 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 ejecutamos; y, por
cierto, redujimos los costos en Y este mes". Este último es iniciado por
TI con un solo objetivo en mente: llevar los productos al mercado. La
aceleración de la innovación y el desarrollo de productos depende de aumentar
la velocidad de sus constructores.
Para
que esto suceda, el departamento de TI debe centrarse en las tareas que
diferencian el negocio y permiten a los constructores moverse más rápido. Las
tareas de TI 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 la
mayoría 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
de 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.
Estructura
de desarrollo de la era de pre-virtualización
Promesas
de virtualización / nube privada
La
virtualización y la nube privada prometieron un mejor camino. 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.
Estructura
de desarrollo de la era de virtualización
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 TI.
Viaje
hacia 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
Estructura
de desarrollo de adopción temprana de nubes
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, abrazan 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 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, auditable y automatizable 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.
+++
No hay comentarios:
Publicar un comentario