Anoche me fui a dormir leyendo el Well Architected Framework de AWS en el kindle. Tengo que reconocer que tengo una cantidad de notas tomadas como nunca lo hice con un libro. Me sorprende como muchos de los conceptos establecidos hoy se ponen en jaque día a día.
De los que más me sorprendió fue el énfasis que hacen una y otra vez en los equipos involucrados en los objetivos del negocio y en la participación de todos los miembros de los equipos para lograr grandes resultados. De verdad trataba de llevar a la realidad lo que veo todos los días versus lo que estaba en el kindle.
Si bien comparto la teoría de que para tener resultados todos los miembros del equipo tienen que entender los objetivos de negocio todavía no logro visualizarlo en la realidad Argentina y, por qué no, en la región.
Horas más tardes de que esto me quede dando vueltas me encontré en una reunión con un cliente que quería mover una carga de trabajo a AWS. Era una portal, una especie de intranet, donde se iban a publicar novedades para que los empleados de la empresa desde varios paíeses pudieran nutrirse de información relevante. Un reemplazo de un sharepoint si se quiere.
Pero a principios del año desde el negocio recibieron la directiva de comenzar a utilizar servicios nativos AWS junto con algunas cargas de trabajo y capacidad que tenían en unos hosts de VMC también en AWS. Si queres saber más sobre VMC podes leer acá o mirar acá.
Ante la necesidad y la directiva del negocio un cloud architect se puso a trabajar en un diseño súper interesante que contemplaba de muy buena manera los pilares del Well Architected Framework. Realmente estaba muy bien contemplando casi todos los pilares del Well Architected Framework.
Nos invitaron a una reunión para revisar ese diseño con servicios nativos para ser traducidos a lo que pudieramos hacer basados en lo que teníamos de VMC.
Esto fue lo que pasó en la reunión:
La gente de seguridad informática comenzó a decir que no podían permitir salir a producción algo con NSX-T como seguridad ya que no había sido homologado en la nube. Para el caso los servicios de seguridad de AWS tampoco habían sido validados. Necesitaban 6 meses para hacerlo en cualquiera de los dos casos.
La gente de monitoreo indicó que como esas instancias de VMC no tenían monitoreo por vROPS no iban a poder salir a producción tampoco.
Pero lo más interesante fue una persona que se sumó 30 minutos tarde, por que el jefe de su jefe no había podido asistir a la reunión, y como su jefe tampoco pudo tuvo que venir él. 30 minutos tarde lo primero que hizo fue preguntar de que se trata la reunión.
Me quería ir.
Estaba en una reunión que supuestamente era estratégica para el negocio y los que participaban de la misma en lugar de pensar cómo podían sacar a producción lo que el negocio necesitaba se estaban mirando el culo. Ni hablar del que llegó 30 minutos tarde, estaba en disney.
Me podes decir que esto mismo pasa hoy sin estar pensando en moverte a la nube lo cual sería cierto. Pero en este caso puntual o se tiene el compromiso de todo el mundo o no vas a ningún lado.
La burocracia del on-prem en la nube puede significar, no sacar un servicio a la calle, una factura descabellada o simplemente un expuesto de seguridad que deje el negocio cerrado.
Pero lo más preocupante es la falta de interés por cumplir con el objetivo de negocio. Si no están todos los equipos integrados para resolver el problema y se ponen de acuerdo en llegar al objetivo el camino a la nube puede tener unos cuantos golpes.
Golpearse contra algo en el espacio no debe estar tan bueno.
Sin importar si van a ir por VMware Cloud on AWS o cualquier otro servicio de cloud les recomiendo que lean el Well Architected Framework. No se trata solo de arquitectura, se trata de arquitectura, de operaciones, de visión y estrategia. Lo resuelven en unas horas pero les recomiendo leerlo de corrido y despés volver a leerlo y tomar notas.
Fue lo mejor que me pasó en el último tiempo, tira por el piso muchos conceptos que hoy tenemos como ley en el on-prem.
Buen fin de semana.
Deja un comentario