Los últimos 5 años de mi carrera que han estado llenos de muchos desafíos, en particular he tenido la responsabilidad de liderar iniciativas de transformación que puedan traducirse en valor para clientes y socios de negocios, apoyado en nuevas tecnologías de la información. Creo que estamos en un momento como ningún otro, rico en diferentes tecnologías y con un panorama emergente muy muy interesante.
Si pienso por un momento en el propósito que ha tenido mi profesión los últimos 10 años, traigo a mi memoria como he estado expuesto a tratar de solucionar problemas con el estado del arte actual de la tecnología. Hace unos años discutíamos acerca de la rigidez de la infraestructura tradicional, en el año 2010 tuve la fortuna de empezar un cambio de arquitectura de centro de datos conocido como convergencia. Básicamente como muchos deben recordar, en su momento planteábamos la necesidad de simplificar la gestión del centro de datos con equipos que pudieran tener la capacidad de integrar mejor sus componentes. En su momento existían soluciones como vBlock (EMC-cisco-VMware) y FlexPod (NetApp-cisco-VMware) que empezaban a tener un espacio importante en la industria. Recuerdo y resalto la iniciativa de cisco de ingresar en el mercado de los servidores muy criticado en su momento, pero luego se convirtió en un jugador importante. Fue un camino que viví desde la consultoría e implementación de soluciones de convergencia.
Fueron unos buenos años simplificando la arquitectura en los centros de datos, No obstante, solo tuvieron que pasar algunos años hasta verme envuelto en un nuevo reto conocido como la hiperconvergencia. Tuve la fortuna de participar en un comité evaluador que buscaba construir una plataforma importante para un cliente y nuevamente fui retado a cambiar mis formas y perspectiva. Luego nuevamente la vida me dio un desafío y fue llevar a un importante cliente hacia el camino de la virtualización de sus aplicaciones de misión critica con estas nuevas tecnologías de hiperconvergencia, fue y es hoy interesante como detrás de estos retos tecnológicos existen problemáticas reales de muchas industrias que solucionamos, muchas veces no lo vemos. Estoy muy agradecido por haber estado expuesto a renovar mi forma de pensar, fueron bonitas experiencias que quise utilizar como apertura de este blog.
En 14 años de trabajo en Tecnologías de la información desde diferentes roles, he visto un poco de ese camino y como han surgido y han desaparecido muchas tecnologías. ¿Ahora te estarás preguntando hacia donde voy con estos planteamientos? Pues bien, la razón por la cual quise arrancar con una reflexión muy personal es porque hoy en día los CIO´s y CTO´s tienen la fortuna de tener en su mesa un ecosistema bastante rico de tecnologías que podrían ayudarle a solucionar múltiples problemas y desafíos de negocio. El reto creo yo más importante es ir tan rápido como el ecosistema tecnológico va hoy en día. Es interesante como el 50% de las compañías que están hoy apoyando la transformación tecnológica de muchas industrias, no existía hace 3 o 4 años. Esto es un reto para el CTO de la actualidad, quien se ve empujado y desafiado en empezar a navegar en el mundo de las tecnologías emergentes, tomando el valor de éstas para la solución de problemas reales de los negocios y tratando de experimentar nuevos métodos y formas.
Ahora como parte de una compañía de software soy bastante consiente que así como muchos clientes escuchan la forma en cómo VMware puede ayudarle a solucionar sus problemas, de la misma manera podría tener 5 o 6 proveedores con diferentes planteamientos y alternativas.
Siempre existirán razones de peso que llevan a muchos clientes a seleccionar un proveedor…su presente, su visión, su costo, entre muchas otras cosas, No obstante, la realidad actual es que la tecnología se ha vuelto más compleja que nunca.
Cuando digo compleja, quisiera referirme a las múltiples herramientas tecnologías que hoy en día son usadas para solucionar diferentes problemas, la exigencia de los nuevos modelos de negocio, la rapidez y agilidad con la que deben ir las industrias cada día aumenta más. No es una limitación tecnológica la que nos empuja hacia nuevas tecnologías, es el afán del negocio por ser relevante en un mercado bastante cambiante y lleno de nuevos desafíos y consumidores.
Ahora bien, centrando un poco este planteamiento en TI, desde hace unos años han surgido múltiples planteamientos, teorías, practicas, roles, herramientas, que prometen ser la solución de esta complejidad tecnológica. Muchos “Buzzword”: DevOps, CI/CD, Microservices, SRE, Agile, Cloud, Cloud Native, Event-Driven Architecture, Serverless, etc. Podría quedarme acá nombrando muchas más…
Por eso quise hacer un ejercicio simple de cual sería desde mi perspectiva la propuesta de VMware para poder ayudar a los clientes a simplificar su estrategia de TI enfocada en la agilidad, modernización y adopción de nuevas aplicaciones, centros de datos y nube. Para esto quisiera iniciar contando a modo de historia un relato con los 2 roles que principalmente están siendo los actores en este proceso. Trae café o agua, espero puedas tomarte los próximos 15 o 20 minutos para analizar, debatir, comentar, compartir o simplemente descubrir algo que quiero compartir contigo.
Developer: De acá en adelante su nombre será Charlie, Charlie se encuentra enfrentado a desafíos importantes de su compañía financiera. Su compañía necesita ofrecer nuevos productos y para esto le han pedido una modernización e inclusión de nuevas aplicaciones. La compañía cree que la tecnología no ha sido un habilitador de nuevos negocios, le han expresado que el secreto del éxito de otras entidades financieras ha sido la utilización de tecnologías en la nube y el atreverse a hacer las cosas de una manera diferente.
Operator: De acá en adelante su nombre será George, George tiene un reto importante y será apoyar todas las iniciativas que tiene Charlie, sin olvidar su responsabilidad principal la cual es mantener los servicios tecnológicos de la entidad disponibles. La compañía cree que George necesita entender que si no apoya el proceso definido por Charlie, es posible que tenga una reducción en su personal porque muchos de los nuevos servicios ya no estarán bajo su responsabilidad y que la compañía necesita garantizar el gobierno y la operación de sus servicios financieros.
Escenario 1: Comienza esta historia…
Developer: Charlie tiene el reto de mantener sus aplicaciones tradicionales, pero también necesita empezar a definir qué puede hacer con las nuevas aplicaciones cloud native el cree que los contenedores son en buena parte actores principales en el proceso que le va a ayudar a ser más eficiente y rápido. Tiene en su cabeza la idea de construir una plataforma de aplicaciones multinube.
Operator: George ha iniciado el análisis de múltiples plataformas de infraestructura que necesita considerar para poder ofrecer a Charlie sus servicios. George esta un poco preocupado por la variedad de componentes que tiene cada plataforma tecnológica, cada uno tiene soluciones y productos interesantes, pero en cada uno de ellos es diferentes en sus componentes y arquitectura.
Antes de empezar es importante tener algunas definiciones sobre los componentes relacionados en la gráfica del escenario 1:
| NET | Componentes y estructura para la organización de las redes, esta estructura garantiza que cada “cliente“ o tenant tenga su propia red lógica |
| STORAGE | Mecanismo utilizado por las diferentes plataformas para proveer almacenamiento. |
| SEC | Componentes y estructura para brindar a sus clientes componentes de seguridad. |
| Hipervisor | Cada proveedor tiene la mayor parte de su infraestructura de servicios corriendo sobre plataformas virtuales. Esto permite estandarizar y poder ganar flexibilidad en el aprovisionamiento de servicios. |
| MP/API/CM | Procesos Manuales y/o herramientas para automatizar la configuración de los servicios.
|
| CMP/UI | Interfaz de usuario mediante la cual se consumen los servicios. Esta interfaz de servicio podría incluir, costos y opciones para monitoreo y control.
|
| Traditional Apps | En ingeniería de software, una aplicación monolítica describe una aplicación de software de un solo nivel en la que la interfaz de usuario y el código de acceso a datos se combinan en un solo programa desde una única plataforma. La filosofía de diseño es que la aplicación es responsable no solo de una tarea en particular, sino que puede realizar cada paso necesario para completar una función en particular. Hoy en día, algunas aplicaciones de finanzas personales son monolíticas en el sentido de que ayudan al usuario a realizar una tarea completa, de extremo a extremo. |
| Cloud Native Tech | Las tecnologías nativas en la nube permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos, como nubes públicas, privadas e híbridas. Contenedores, Service Mesh, microservicios, infraestructura inmutable y API declarativas ejemplifican este enfoque.
Estas técnicas permiten sistemas de acoplamiento flexible que son resistentes, manejables y observables. Combinados con una robusta automatización, permiten que los ingenieros realicen cambios de alto impacto con frecuencia y de manera predecible con un esfuerzo mínimo. https://github.com/cncf/toc/blob/master/DEFINITION.md
|
Entendiendo un poco los componentes descritos en la Escenario 1, entramos en detalle de que quiere cada uno:
Developer: Charlie quisiera poder construir sus aplicaciones una única vez y que las mismas puedan ser portables. Eso simplifica el mantenimiento, el ciclo de vida, la integración de los diferentes equipos de desarrollo, pruebas y producción. Charlie quiere evitar a toda costa el mantenimiento de sus aplicaciones en diferentes plataformas. Charlie ha escuchado que debería empezar a usar herramientas para automatizar el despliegue y configuración de servicios. También esta iniciando un camino con aplicaciones cloud native las cuales hacen parte de su análisis.
Operator: George quiere tener la posibilidad de escoger la plataforma de infraestructura optima para el negocio, la cual le brinde disponibilidad, capacidad de crecimiento, simplificación de sus operaciones de día 2, adicionalmente que le permita la flexibilidad de moverse entre plataformas dependiendo de la conveniencia del negocio. Es decir, tener la libertad para poder escoger la plataforma sin que esto afecte a Charlie, incluso que el mismo Charlie no sepa en donde están sus aplicaciones. La decisión de escoger la plataforma va a depender de el momento, el caso de uso y la conveniencia para el negocio.
Escenario 2: Desafío Multinube – Mantenimiento, Construcción y convivencia de aplicaciones.
Developer: Charlie ha construido su aplicación tradicional monolítica, pero ha descubierto que la misma tiene que ser construida para cada plataforma, esto dado que cada proveedor cuenta con su propia arquitectura y componentes. Esto podría servirle para aplicaciones que siempre van a estar en un solo lugar, pero definitivamente no parece ser la solución que busca.
Operator: George por su parte es consiente que su equipo de trabajo hipotéticamente hablando, ahora tiene el desafío de entender el funcionamiento de cada plataforma que seleccionen de infraestructura. A su vez es responsable de integrar las mismas y de poder ofrecerle a Charlie la alternativa de poder mover las aplicaciones bajo ciertos escenarios entre diferentes ambientes. También necesita considerar los escenarios de recuperación de desastres donde cada plataforma debe entender quién será su destino de replicación y cómo se realizará el proceso. Al tener diferentes plataformas, el reto es mantener un BIA y un BCP consistente para el negocio, se hace un poco más desafiante.
Muchas compañías quieren aprovechar el potencial de lo que se conoce como estrategia multinube, sin embargo, algunas desconocen los desafíos de mantener el ciclo de vida de las aplicaciones, garantizando su portabilidad, integración, recuperación de desastres, entre otros aspectos. En adelante vamos a tratar de analizar estos temas, teniendo como premisa la simplificación tecnológica para el negocio.
Escenario 3: Un alivio de operación, pero….
Developer: Charlie ha construido su aplicación tradicional Monolítica y ha encontrado algunas opciones para centralizar el aprovisionamiento. Utilizar una plataforma de servicios de nube, le va a ayudar a tener un único punto de aprovisionamiento y control. También ha encontrado una manera de empezar a utilizar herramientas para gestión la configuración. Sin embargo, es consiente que, retomando el principio de arquitectura, esto no solucionaría su necesidad puntual. Poder construir la aplicación una única vez y que la misma pueda vivir sin hacer ninguna modificación desacoplando cualquier dependencia de la infraestructura.
Operator: George por su parte se encuentra un poco más tranquilo porque la plataforma de administración de nube le va a ayudar a estandarizar el catálogo de servicios para Charlie, sumado a que ahora va a tener control y gobierno de en dónde y cómo se han aprovisionado estos servicios. Es una opción muy interesante y la cual puede ser viable para algunos casos de uso de aplicaciones, sin embargo, no simplifica la curva de aprendizaje de múltiples plataformas, es decir la “plomería” por debajo sigue estando a cargo de su equipo.
Algunas compañías creen que el reto principal esta en el aprovisionamiento, en VMware creemos que es parte del proceso, pero no es lo más crítico. Hoy en día se pueden utilizar herramientas gratuitas para tal fin. La diferencia de la propuesta de un Cloud Management no solo radica en la posibilidad de desplegar en diferentes lugares, la misma debe incluir la consistencia en las operaciones, el gobierno y por supuesto en tener la visibilidad de todo lo que está ocurriendo.
Por supuesto otro punto importante es el ecosistema de integración. El Cloud management es el corazón de una plataforma de aprovisionamiento de infraestructura como servicio, con lo cual viene siendo un punto de abstracción de múltiples componentes físicos y estos deben ser considerados o construidos para ser gobernados por el Cloud Management. En ese sentido el Cloud Management seria lo que ve el usuario cuando quiere consumir un servicio y lo que el operador utiliza para gobernar y controlar los servicios publicados.
Escenario 4: ¿Infraestructura como Código, la solución a estos problemas?
Developer: Charlie es consciente de los retos que ahora tiene en el mantenimiento de sus aplicaciones y de manera proactiva ha estado analizando las alternativas que propone el mercado para simplificar esto. Ha llegado a analizar herramientas como Chef, Ansible Puppet que prometen ser facilitadores en el proceso de aprovisionamiento e instalación de componentes de software. También ha revisado Terraform, plataforma que propone un lenguaje estándar de programación de infraestructura mediante el cual independiente del ambiente, se logra un mayor nivel de estandarización con algunas capacidades adicionales. Charlie cada día quiere más independencia y control sobre el aprovisionamiento de sus aplicaciones y software. Sin embargo, es consciente que, retomando el principio de arquitectura, esto no solucionaría su necesidad puntual. Poder construir la aplicación una única vez y que la misma pueda vivir sin hacer ninguna modificación desacoplando cualquier dependencia de la infraestructura.
Operator: George por su parte tiene el reto de entender que herramienta de CM/IaC podrían utilizar para tratar de simplificar de alguna manera el paradigma de los ambientes multinube. Por otra parte, es consciente que para él lo más importante es simplificar la integración de los ambientes, gobernar y controlar. La decisión de en donde van a estar las aplicaciones no esta definida por limitaciones tecnológicas, la decisión es en función de negocio. Charlie no debe importarle en donde va a estar su aplicación.
En la actualidad existen múltiples maneras de aprovisionar infraestructura. Hace unos años estas herramientas usaban agentes, luego empezaron a trabajar sin ellos, a tal punto que hoy en día algunas de ellas han evolucionado a lo que se conoce como Infraestructura como Código (IaC). Creo que una de las más famosas es Terraform, incluso los proveedores de nube publica han desarrollado sus propias herramientas como el caso de AWS Cloud Formation.
Permíteme hacer un pequeño paréntesis en esta historia para explicar en muy alto nivel que hace Terraform y porque su propuesta es muy interesante.
Terraform cuenta con archivos de configuración que describen los componentes necesarios para ejecutar una sola aplicación o su centro de datos completo. Terraform genera un plan de ejecución que describe lo que hará para alcanzar el estado deseado y luego lo ejecuta para construir la infraestructura descrita. A medida que cambia la configuración, Terraform puede determinar qué ha cambiado y crear planes de ejecución incrementales que se pueden aplicar.
La infraestructura que Terraform puede administrar incluye componentes de bajo nivel, como instancias de cómputo, almacenamiento y redes, así como componentes de alto nivel como entradas de DNS, características de SaaS, etc.
Las características principales de Terraform son:
Infraestructura como código
La infraestructura se describe utilizando una sintaxis de configuración de alto nivel. Esto permite que un plano de su centro de datos sea versionado y tratado como lo haría con cualquier otro código. Además, la infraestructura puede ser compartida y reutilizada.
Planes de Ejecución
Terraform tiene un paso de “planificación” donde genera un plan de ejecución. El plan de ejecución muestra lo que hará Terraform cuando llame. Esto le permite evitar sorpresas cuando Terraform manipula la infraestructura.
Gráfico de recursos
Terraform crea un gráfico de todos sus recursos y paraleliza la creación y modificación de cualquier recurso no dependiente. Debido a esto, Terraform construye la infraestructura de la manera más eficiente posible, y los operadores obtienen información sobre las dependencias en su infraestructura.
Cambio de automatización
Los conjuntos de cambios complejos se pueden aplicar a su infraestructura con una mínima interacción humana. Con el plan de ejecución y el gráfico de recursos mencionados antes, usted sabe exactamente qué cambiará Terraform y en qué orden, evitando muchos posibles errores humanos.
Interesante, Terraform cuenta con un sitio publico donde comparte sus cloud providers https://www.terraform.io/docs/providers/index.html así como Terraform Module Registry https://registry.terraform.io/ en donde se pueden encontrar módulos de configuraciones de infraestructura común en diferentes plataformas.
Un ejemplo de un archivo de configuración de Terraform para la creación de una maquina en Azure y AWS lo vamos a ver a continuación:
Azure Creación de maquinas Linux y Windows:
AWS – Creación de maquinas Linux y Windows:
Cierro El paréntesis con una reflexión, Terraform es una herramienta muy buena para el aprovisionamiento de los ambientes, así como para el manejo de las configuraciones, los estados y los cambios en línea, No obstante, si observan, aunque existe un lenguaje y sintaxis común, los componentes y elementos de interacción de cada plataforma son diferentes. Si analizan con detalle https://registry.terraform.io/ verán que para cada cloud provider existen diferentes módulos que incluyen las instancias de computo, redes, seguridad, entre otros y todos son diferentes.
Por ejemplo, AWS cuenta con componentes como VPC, AMI, Instance_Type, etc. Azure tiene otras definiciones en sus componentes VNET, location, resource group, entre otros. Al final se tiene la flexibilidad del aprovisionamiento, pero de alguna manera se siguen manteniendo elementos que no son comunes en las diferentes plataformas y por ende el desafío planteado por Charlie no es solucionado en su totalidad.
En mi opinión Terraform soluciona varios aspectos relacionados con el aprovisionamiento y manejo de la infraestructura, pero no soluciona todos los retos de gestión, operación y gobierno que necesitan las compañías y en este caso George.
Escenario 5: ¿Qué hace VMware para ayudarle a Charlie y George?
Developer: Charlie ha estado un poco confundido con el nivel de abstracciones que el mercado le ofrece para solucionar sus desafíos de aprovisionamiento de aplicaciones y ha encontrado una opción interesante la cual le ofrece un nivel mayor de estandarización, cumpliendo con su necesidad de construir la aplicación tradicional monolítica una única vez y que la misma pueda vivir y moverse en diferentes proveedores de nube! ¡Boom!
Operator: George por su parte al tener ya unos años de experiencia operando una plataforma de virtualización on-prem, cuenta con un equipo de trabajo que entiende las tecnologías de virtualización y esta familiarizado con las soluciones de VMware, también con el concepto de centro de datos definido por software. Esto es básicamente la virtualización del cómputo, las redes, la seguridad, el almacenamiento y la gestión de servicios de infraestructura.
George encontró una opción en donde su misma plataforma on-premise amplía el espectro y se extiende sobre el mismo stack que lleva trabajando por años y ahora puede vivir en los principales proveedores de nube pública del mundo. ¡Boom! George encontró una forma de poder ofrecerle a Charlie la misma arquitectura, garantizando que puede: operar, gobernar y gestionar bajo los mismos componentes, sin tocar las aplicaciones y con la libertad de escoger donde quiera ejecutarlas, sin que Charlie se entere en donde estarán. ¡Boom!
He tenido múltiples conversaciones con CTO´s CIO´s el último año preguntándome acerca de por qué seguir considerando a VMware como un proveedor de confianza para el futuro, partiendo de la base que hoy en día en un par de clics y con una tarjeta de crédito acceden a los mejores servicios tecnológicos del mundo. Son conversaciones muy interesantes, No obstante, en mi opinión y acá podrían muchos de los que se han tomado la tarea de leer este blog, no estar muy de acuerdo conmigo, pero la principal barrera o desafío en la migración de las aplicaciones a la nube publica ha sido justamente lo que hemos venido relatando en este blog. La infraestructura heterogénea.
Conozco varias historias de clientes que tomaron meses en mover sus aplicaciones desde sus ambientes on-prem hacia la nube, incluso muchos de ellos después de algunos meses abortaron el proceso. ( Debo reconocer que los proveedores de nube publica han hecho sus mejores esfuerzos en intentar realizar estos procesos de migración de la manera más trasparente, en muchos casos usando los servicios profesionales necesarios y/o utilizando técnicas para convertir las máquinas virtuales hacia sus formatos en la nube publica, toda una aventura…), no quiero con esto que piensen que no estoy a favor de la utilización de los servicios de nube publica y mucho menos que no den los resultados que muchos clientes esperan, es posible y millones de casos lo soportan, sin embargo en la dinámica de los negocios la gran pregunta es
¿Es el beneficio tan alto para sustentar el tiempo?
¿Están considerados los riesgos y los cambios en el modelo de operación?
Estoy seguro de que existirán múltiples casos donde tenga sentido hacerlo.
VMware Cloud Foundation Overview
El punto final y con esto quiero cerrar, VMware ha llevado su estrategia de SDDC Software Defined DataCenter hacia los principales proveedores de nube publica, mucha gente se pregunta… ¿Para qué?… ¿Cuál es la razón principal…… Existen muchas, pero quisiera dejar algunas de las que considero son más importantes:
- Si una compañia tiene el stack de SDDC on-prem y logra construirlo con la misma consistencia en cualquier proveedor de nube publica, obtendrá de manera directa una plataforma de nube hibrida, que es la base de lo que VMware está construyendo hace algunos años con Cloud Foundation.
- Al tener el mismo stack, la seguridad es consistente, el almacenamiento en consistente, las operaciones son consistentes, las aplicaciones se construyen una única vez y se pueden mover de manera simple y sencilla con VMware HCX entre los diferentes ambientes del cliente y los diferentes proveedores de nube publica con el stack de VMware habilitado.
- El cliente va a poder aprovechar los beneficios de los servicios nativos de nube pública. En VMware creemos que AWS, IBM Cloud, OVH y todo el ecosistema de proveedores tiene servicios de valor agregado para el cliente. Esta arquitectura simplifica la integración y el consumo de muchos de los servicios nativos de nube hacia el stack de SDDC propuesto por VMware en las nubes públicas.
- Finalmente, servicios como AWS Outpost que básicamente son inversos a lo descrito hasta ahora. Es decir, proveedores como AWS van a ubicar el hardware on-prem con el stack nativo de AWS y el stack nativo de VMware. Esta arquitectura brinda una profunda integración, puesto que un cliente podría tener:
- Servicios on-prem nativos de AWS y VMware
- Servicios en datacenter públicos de AWS y servicios nativos de VMware.
- En el caso de VMC on AWS el cliente tendrá nuevos servicios e innovaciones que hemos desarrollado en conjunto con AWS como lo son:
- Elastic DRS
- DRaaS usando SRM
- Extensión del centro de datos usando las mismas herramientas de gestión, como lo son el vCenter server, vRealize Operations, vRealize Automation, entre otros.
- La verdadera libertad que provee VMware Cloud Foundation es la capacidad de seleccionar múltiples opciones de plataforma on-prem, múltiples proveedores de nube publica, con el único propósito de hacer tu vida más simple.
Durante esta historia, es probable que ahora Charlie y George tengan una compresión de los principales retos y desafíos que tienen por delante, por efectos de no hacer más largo este relato esta historia este el primer parte de una serie que he denominado “Navegando en la realidad del mundo multinube”. Esta historia no termina acá por qué mientras escribía estas líneas ha llegado un nuevo desafío en la mesa de Charlie y George del cual hablaremos en el siguiente capítulo. Kubernetes
“Es difícil prepararse para los cambios fundamentales, pero es posible si usted es un apasionado en su campo. Todos nosotros presenciaremos algunos cambios tecnológicos importantes a lo largo de nuestra vida, pero no es la cantidad de conocimiento en nuestras cabezas lo que nos hace profesionales y nos lleva a la cima, es la apertura de nuestras ideas y la capacidad de aceptar la metamorfosis”.
Autor:
