Mi ruta hacia el VCDX – parte 1

Que tal gente, el día de hoy voy a comenzar con una serie de artículos donde compartiré todas las experiencias que viví a lo largo del proceso para convertirme en VCDX. Como pueden saber, el nivel máximo de certificación por parte de VMware es el VMware Certified Design Expert, para el cual existen distintas versiones que se mapean directamente a las distintas verticales de productos que VMware maneja, teniendo el VCDX-DCV o “Datacenter Virtualization”, VCDX-DT o “Desktop” y VCDX-Cloud. En mi caso en especifico el objetivo era obtener el VCDX-DCV, por lo que primero debí cumplir con las certificaciones VCAP-DCA y VCAP-DCD (cosa que tenía hace varios años) y después comenzar a pensar sobre mi proyecto.

El convertirme en VCDX siempre fue algo que consideré imposible o muy lejano para mi, desde los 19 años comencé a trabajar con tecnologías de VMware y a los 20 ya era VCP… Recuerdo haber cambiado de trabajo a un socio de VMware aquí en México, ahí fue cuando me enteré del VCDX, siempre me pareció tan difícil, tan inalcanzable pero increíblemente interesante y un excelente reto personal. En el momento que me convertí en Instructor de VMware el deseo de ir mas allá y obtener certificaciones avanzadas como los VCAPs se hizo mayor, en poco tiempo comenzando a trabajar en VMware ya había conseguido obtener ambos VCAPs para poder aplicar al VCDX… Pero faltaba algo aún MAS importante, un diseño, un proyecto que pudiera utilizar. Lamentablemente al ser instructor me asaltaron fuera del país y perdí mi respaldo y laptop en donde se fueron varios documentos de distintos proyectos (¿Que clase IDIOTA :) no respalda su información en la nube? ), logré conseguir algunos de los documentos con un ex compañero de trabajo pero aún faltaba mucha documentación por lo que comencé a dejar de lado la idea de aplicar para el VCDX.

No fue hasta hace mas o menos 7 meses que revisando el sistema interno de socialcast de VMware me dí cuenta que otra persona (Mi compañero y gran amigo Niran Even Chen VCDX#142)  tenía en mente el aplicar para VCDX, por lo que me puse en contacto con el. Lo interesante de esto es que ambos somos SEs (Systems Engineers) en VMware, por lo que no participamos activamente en servicios profesionales realizando arquitecturas (servicios de Plan & Design) y por ende la mejor opción era crear un diseño ficticio…

¿Que proyecto debo de utilizar?

La recomendación por parte de todos los VCDXes que existen hoy en día es utilizar un proyecto real, que demuestre tus capacidades como arquitecto (capacidad para traducir requerimientos de negocio hacia una solución), generalmente estos diseños deberán ser ajustados para cumplir al pie de la letra el blueprint de VCDX, muchas veces incluyendo información ficticia, agregando mayor cantidad de detalles o estructurándolo de tal manera que cumpla con el blueprint. Siempre escucharán que NO SE DEBE DE UTILIZAR DISEÑOS FICTICIOS, lo cual es totalmente comprensible debido a que los diseños ficticios son mas difíciles de defender, de ajustarlos al blueprint, etc. Créanme, cuando teníamos sesiones para revisar nuestro proyecto con distintos VCDX y personas que nos estuvieron apoyando y se enteraban que era ficticio lo primero que nos decían es “será difícil”, nos cansamos de escuchar que el porcentaje de personas que aplican con un proyecto ficticio y aprueban el VCDX es bajísimo, debido a que al estar trabajando directamente con el cliente como consultor se “vive” el proyecto, es decir, se tiene interacción con los distintos equipos y personas clave del proyecto, se conoce exactamente la situación y que es lo que el cliente quiere cumplir con el proyecto, en este caso los requerimientos y objetivos son provistos por el cliente no son inventados, los problemas internos son algo con lo que se lidia directamente lo cual termina haciendo que se conozca el proyecto al 100% cosa que es difícil de hacer con un diseño ficticio (¡Aunque si es posible!!)

En el caso de Niran y mío optamos por ir por un diseño ficticio, lo cual derivo en una serie de tareas que en conjunto definimos para poder tener un diseño defendible:

  • Crear la historia de cliente – Esto es bastante importante, cuando hablamos de un proyecto sabemos que existen muchos jugadores, problemas internos, objetivos corporativos, etc. En nuestro caso tomamos un cliente existente en México y en base a este creamos la “historia”. Esto es bastante importante debido a que después podremos justificar decisiones de arquitectura en base a temas que incluso no son de carácter técnico. Esta historia sentará las bases para la construcción completa del diseño, definición de requerimientos, limitantes y supuestos (Requirements, Constraints & Assumptions) que formaran parte de nuestro proyecto.
  • Definir o identificar Casos de uso y objetivos del cliente – Una vez que tengamos la historia del cliente debemos de saber específicamente cuales son los objetivos que el cliente quiere cumplir con este proyecto, un ejemplo podría ser “Proveer de acceso a una sesión de escritorio de manera remota”. En base a estos casos de uso y objetivos se irán construyendo los requerimientos, limitantes y riesgos que regirán nuestro diseño.
  • Definir o identificar requerimientos para el proyecto – Esto puede sonar bastante simple, pero deben de prestar mucha atención a cada uno de estos requerimientos debido a que en fases futuras pueden impactar al diseño. TIP: Seguir el “KISS principle” o “Keep It Simple Stupid”, no porque comprendamos y sepamos diseñar soluciones multi sitio con stretched clusters, o seamos masters en networking o en almacenamiento, quiere decir que debamos de realizar un proyecto demasiado complejo porque además de que va contra el principio de diseños simples y funcionales debemos de entender que los panelistas SABEN de lo que hablan, y si incluimos una tecnología en especifico o tomamos alguna decisión estas podrán ser objetivo de preguntas por parte de los panelistas (Créanme, sucede…). Ejemplos de requerimientos podrían ser “Proveer un nivel de disponibilidad de 99.999%” o “Reducir el espacio de datacenter consumido”.
  • Definir o identificar limitantes (“Constraints”) para el proyecto –  Las limitantes del proyecto dictarán lo que podemos y no podemos utilizar en el proyecto, en el caso de proyectos reales esto es algo que es bastante simple de obtener, pero en nuestro caso al estar creando un diseño ficticio tuvimos que decidir de manera inteligente estas limitantes y casi todas ellas fueron creadas a partir de la historia y los requerimientos. Aquí viene algo bastante importante, en muchos casos una limitante también impone un riesgo, y es algo que nosotros como arquitectos debemos de estar conscientes, documentarlo y tener un plan de mitigación para dicho riesgo.  Ejemplos de limitantes podrían ser: “El cliente tiene infraestructura existente y esta deberá ser utilizada como parte del proyecto”, “Se tiene un tope de presupuesto de $XXXX” o “Se tienen enlaces de 1Mbps entre las distintas sedes”.
  • Definir o identificar supuestos para el proyecto – Como en cualquier proyecto se tendrá una serie de supuestos que forman parte de nuestro diseño, los supuestos definen expectativas que tenemos como parte del proyecto que en dicho momento no pueden ser confirmadas. Muchas veces estos supuestos pueden ser considerados riesgos y deberán ser perfectamente documentados. Ejemplos de supuestos: “Se tiene suficiente ancho de banda para un correcto funcionamiento de las sesiones de usuario”, “El almacenamiento será configurado de tal manera que aporte los requerimientos y siga las mejores practicas del fabricante” (este ejemplo puede aplicar cuando se tiene almacenamiento existente y el equipo interno estará gestionando la entrega del mismo).
  • Definir o identificar Riesgos para el proyecto – Los riesgos generalmente surgen a partir de los requerimientos, limitantes y supuestos que forman parte del proyecto, pueden ser tanto técnicos como de negocio o procesos. Es IMPORTANTE documentarlos y proporcionar el plan de mitigación (nuevamente confíen en mi, los panelistas pondrán atención). Ejemplos de riesgos: “No se cuenta con una solución de backup”, “No se tiene un plan de DR”, “La aplicación X será diseñada por un tercero”, “por cuestiones de presupuesto se cuenta con el siguiente SPoF”.

Cuando Niran y yo fuimos capaces de tener la historia, y todos los requerimientos, supuestos y limitantes fue cuando en verdad comenzó nuestro trabajo de diseño, estén atentos a los siguientes artículos donde estaré compartiendo mas información.

5 comments on “Mi ruta hacia el VCDX – parte 1

  1. jonaquezada July 17, 2014 8:20 pm

    Felicitaciones por este gran logro

    Saludos

  2. prcerda July 18, 2014 8:54 am

    Felicitaciones!!! Muy buenos tips y espero seguir tus pasos el proximo año :)

  3. JSanchez July 18, 2014 3:04 pm

    Muchas Felicidades por este tan importante logro!!

  4. amalanco July 19, 2014 11:14 pm

    Muchas gracias!!, Patricio si te decides acá estamos para apoyar con el diseño :)

  5. Miguel Romero September 15, 2014 10:34 am

    Gracias por compartirlo, ya tengo el VCAP-DCD y voy por el DCA porque el objetivo es el VCDX en el 2015. Salu2.

Leave a Reply