Archivo de la categoría: Wetcom

Docker en la empresa

En una semana dos clientes nos pidieron reuniones para hablar de containers y de docker en particular.

Con las reuniones ya realizadas tengo algunos puntos que me gustaría compartir con ustedes en una serie de posts aquí, en linkedin.
Para estas reuniones me preparé como para cualquier reunión que hago con el nombre de wetcom encima.

A estas reuniones uno va mas a escuchar que a proponer inicialmente, pero algo dentro mío me decía que tenía que volver a revisar todo una vez mas.

Luego de hacer el ejercicio una vez más quedó claro que a estas reuniones, sobre contenedores, no iba a ir solo a escuchar.

Después de trabajar con tecnologías de vmware durante los últimos 10 años uno se acostumbra a ciertas cosas. Bajar la vara de las funciones básicas que ofrecen las tecnologías de virtualización actuales no es una opción.

Después de esto, estaba dispuesto a escuchar cualquier cosa que el cliente estuviera dispuesto a contar.Incluso estando seguro de estar seguro del mensaje que quería llevar a la mesa aún había dudas.

Básicamente esto se debía a que quienes nos están comenzando a llamar para hablar de contenedores no son los mismos interlocutores de siempre.

Una vez explicado mi punto de vista, ya les digo cuál es, todo el mundo se unió en una única línea de visión sobre el tema.

Mi punto de vista, ahí va.

Si uno mira el sitio web de Wetcom lo único que va a encontrar relacionado a contenedores es un post que escribí sobre mi visita al vmworld del año pasado.

Nada mas, no hay otra cosa.

De ninguna manera alguien que no conozca lo que venimos haciendo nos llamaría para hablar de docker.

Las dos reuniones que tuvimos fueron con clientes de larga data.

Ellos consultaron si trabajamos con docker. No lo promocionamos activamente.
Vengo trabajando con alta disponibilidad, balanceo de carga automático, tolerancia a fallos hace tanto tiempo que no estoy dispuesto a bajar ese estándar.
Eso no se negocia.

Mucho menos para un cliente de wetcom, donde nos eligen justamente para hacer que sus entornos estén disponibles las 24 horas del día los 7 días de la semana.

Es decir, no me quiero involucrar, en el análisis o implementación de una nueva tecnología que no pueda cumplir con esto.

Docker es una tecnología excelente. Por momentos me hace acordar a cuando empezábamos con las primeras reuniones para implementar vmware.

Pero todavía le falta resolver algunos puntos de disponibilidad y balanceo de carga importantes. Los que conocen docker me dirán que si un containers deja de responder lo matamos y lanzamos otro.

Eso es cierto.

El problema es que no todas las aplicaciones que quieren subir ahí arriba están preparadas para eso. Su arquitectura, su ADN las hace ver como una aplicación legacy.

No me sirve docker para eso.

Sobre todo que quieren mover docker directamente a producción, lo cual se entiende.

¿Para qué podríamos poner docker si en el final de la cadena no lo llevamos a producción?.

Es por esto que recomiendo y voy a seguir recomendando montar contenedores sobre vmware. Al menos hasta que los linux que usamos como motor de docker me puedan ofrecer un nivel de disponibilidad y balanceo de carga aceptables.

Hace 10 años no hubiese dudado en montarlos sobre un linux sin alta disponibilidad. Hoy no, y no es porque me haya aburguesado. La tecnología avanzó mucho y además me gusta dormir de noche.

Las reuniones fueron bien, muy bien hay buenas intenciones de avanzar con la tecnología. Pero por sobre todas las cosas que se habló de intenciones, lo único que quedó firme fue que los niveles de disponibilidad no se negocian.

Y está bien.

¿A quién van a llamar cuando todo deje de funcionar? A la gente que maneja la infraestructura señores.

¿Te interesa saber más de docker?, tengamos una charla, veo ahí una tecnología con futuro. ¿Trabajas en infraestructura?, no me dejes solo. Hagamos que los contenedores lleguen a buen puerto.

Nos leemos…

SDN VMware NSX – ¿Quién va a administrar tus redes?

Si cuando surgió la virtualización de servidores generó grandes dudas a la hora de tomar la decisión de implementarlo el caso de la virtualización de redes es similar.

Algunos de los motivos son similares a los de hace unos 10 años atrás pero creo que el más importante hoy en día es la definición de quién se hará cargo de la gestión de las redes una vez implementado.

Ver también: Desafíos de la virtualizacion de redes con vmware nsx

El día de hoy estoy terminando un entrenamiento oficial de VMware para poder cumplir con las obligaciones de competencias con el fabricante.  Es un entrenamiento en línea por lo que hay participantes de varios países trabajando sobre laboratorios.

Para poder estar bien parados para el curso de administración VMware tiene los siguientes requerimientos:

  • Administrador con experiencia en Windows y Linux
  • Conocimientos de VMware SDDC
  • Conocimientos a nivel DCA-DCV
  • Recomendado conocimientos nivel CCNA

Cómo pueden ver los conocimientos necesarios para el entrenamiento parecen bastante simples de cumplir siempre y cuando los asistentes cuenten con algunos años de experiencia en la materia.

Me llamó la atención en algunos casos el tipo de preguntas que se hicieron al instructor.

Mejor dicho, el nivel de preguntas que se hicieron. En algunos casos se demostró un amplio conocimiento tanto en redes como en el producto, pero en otros se demostró un desconocimiento total del funcionamiento de un firewall, de un router o de un balanceador de carga.

Aquí es donde me preocupé ya que o bien los asistentes al entrenamiento  no cumplían con los requerimientos adecuados, y asistieron por obligación, o el nivel del mismo era demasiado elevado.

En la mayorías de los casos los temas discutidos en el entrenamiento podían haber sido muy bien comprendidos para cualquier persona con algunos años de experiencia dura en infraestructura de TI.

Otros casos, como el de VXLAN, creo que para los asistentes estaba un poco por arriba de sus conocimientos. Esto es lo preocupante.

Si bien para cada uno de los casos existió una introducción , o explicación, creo no fueron suficientes como para que alguien sin conocimientos pueda hacerse cargo de la operación de la tecnología luego de la finalización del entrenamiento.

Con esto no quiero decir que quienes vayan a operar esta tecnología VMWARE NSX SDNdeben tener una certificación de nivel de Cisco CCIE pero con el conocimiento básico de los 4 semestres de la academia de Cisco no son suficientes.

Creo que las certificaciones de redes de muchos fabricantes irán desapareciendo a medida que se vayan desarrollando los especialistas y la tecnología sea adoptada por las organizaciones.

Veo en el futuro un “reciclado de perfiles de TI” donde las fronteras entre las áreas se diluyen cada vez más forzando una integración de las mismas en un equipo de trabajo único.

Los profesionales de redes realizarán tareas de infraestructura y los profesionales de infraestructura realizarán tareas de relacionadas a las redes.

A largo plazo esto será positivo para quienes estén a cargo de definir y gestionar infraestructuras de TI complejas. Los pedidos no deberán cruzar diferentes equipos de trabajo y las cosas deberían de poder resolverse de forma mucho más eficiente.

Mientras tanto tendremos que seguir trabajando en desarrollar especialistas idóneos que puedan trabajar de forma completamente independiente de los conocimientos específicos de un fabricante de hardware de redes.

¿Ustedes que opinan?

Foto: Brent H.

Desafíos de la virtualizacion de redes con vmware nsx

Como cualquier tecnología que llega para patearle el tablero a los paradigmas existentes existen algunos desafíos que vmware NSX deberá sortear si quiere ganarse un lugar en los centros de cómputo. Vamos a hacer un recorrido sobre cada uno de ellos para entender mejor cual es la situación de la solución de SDN de VMware.

Ver también: Las redes en ambientes virtuales, ¿el fin de la resistencia del mundo físico?

Ganarle un lugar al área de redes

Para el caso del SDN (software defined Networking) el primer desafío que tiene es que q quien viene a patearle el tablero es un área que tiene las piezas pegadas al mismo con cemento de contacto.

Las redes fueron por años un punto gris donde la virtualización en general tenía un lugar muy particular dentro de las comunicaciones de las empresas.

Generalmente la gente de Networking se limitaba a brindarnos acceso a la red física existente, a asistirnos en caso de algún problema y realizar modificaciones requeridas para nuestra infraestructura virtual.

Con VMWare NSX esto cambia completamente.

No solamente nuestros requerimientos para la red física disminuyen ampliamente una vez obtenida nuestra red de transporte sino que ganamos un control total sobre cambios a futuro en los casos de las infraestructuras cien por ciento virtualizadas.

Para la gente de redes NSX se puede ver como una amenaza.

Desplazar fabricantes con dominio de mercado

Sin dar más vueltas estoy hablando de Cisco. Quien lanzó su propia solución de SDN la cual compite con NSX aún no se encuentra madura.

La gente de redes ama a Cisco. Tanto es así que lo defienden a uñas y dientes cuando se plantea cualquier otro fabricante alternativo.

Este amor a la marca tiene aristas muy marcadas:

  • Sus soluciones son confiables
  • Trayectoria
  • Respaldo de la marca

“Nadie puede equivocarse eligiendo Cisco”

En muchos casos es como un fusible para quien arma la arquitectura de la red de la organización. Si existe un problema con soluciones de Cisco todos están cubiertos de que no hay algo mejor en el mercado y cada uno se lava las manos.

Hablando en castellano, si alguien compra Cisco y hay un problema la respuesta siempre es “imaginate si hubiese comprado otra marca lo que podría haber sido”.

Esquema de licenciamiento 

El esquema de licenciamiento de VMware para NSX es inclusivo desde el punto de vista de hypervisores soportados. Es decir, no estamos limitado a utilizar NSX únicamente con vpshere como hypervisor.

El problema es que el costo de las licencias por procesador es elevado para la media de las empresas, al menos latinoamericanas.

Históricamente VMware tuvo varias idas y vueltas con sus esquemas de licenciamiento por CPU físico, por cantidad de cores por procesador, por VRAM.  Personalmente espero algunos anuncios durante el vmware vmworld  2014 donde se presenten algunas alternativas de licenciamiento que permita a empresas medianas incorporar la tecnología a sus centros de cómputos.

Desafíos del cambio de tecnología

Los recursos humanos que operarán NSX deberán entrenarse en la nueva tecnología no cabe duda. Aquí es donde deberá plantearse en cada empresa una estrategia de integración completa del área de redes con el área de infraestructura.

En la mayoría de las empresas las áreas funcionan de forma independiente y para lograr la adopción de esta tecnología se deberán fusionar bajo un único mando para tener éxito. Quienes operaban el ambiente virtual deberán aprender cosas de redes y quienes operaban redes deberán aprender a trabajar sobre infraestructuras virtuales.

Formación de los partners de vmware

Como comentaba en la charla del último vforum en Wetcom estamos trabajando con NSX desde versiones Beta del producto. Esto nos permitió estar a la vanguardia de la tecnología y hoy en día poder ofrecer servicios profesionales sobre la solución.

A menos que los canales tradicionales de vmware, quienes generalmente también venden Hardware (servidores), aprendan de networking las implementaciones de NSX naufragarán.

Durante casi 2 años desde la compra de Nicira se prohibió a los partners hablar de la tecnología con clientes. Esto se debía a que tradicionalmente el fuerte de estos últimos era la infraestructura y no las redes.

En el caso de Wetcom venimos trabajando desde versiones Beta del producto lo cual nos permite estar hoy en día listos para asistir a nuestros clientes en la adopción de SDN en ambientes virtuales basados en VMware.

Casos testigos

Esto más que un desafío es un pedido a grito de quienes están analizando NSX para sus centros de cómputo. La pregunta “¿quién tiene implementado esto en el país?” se escucha en cada reunión a la que asistimos.

Los early adopters ya están trabajando en pruebas de concepto e incluso en implementaciones de esta tecnología por lo que preguntas como esta encontrarán respuesta en los próximos meses.

Lo importante creo no es quien lo tiene implementado sino el beneficio que puede proveer al negocio y, por que no, convertirse en un early adopter uno mismo.

Conclusión

Como toda tecnología o paradigma nuevo NSX tiene algunas barreras que romper. Es responsabilidad de la marca transmitirle confianza a los clientes como así también es responsabilidad del partner conocer sus limitaciones y no embarcar a un cliente en un viaje sin garantías.

Es cuestión de tiempo para ver como de a poco las empresas de telecomunicaciones comenzarán a adoptar la tecnología y posteriormente lo harán el resto siempre y cuando los casos testigos comiencen a florecer con buenos resultados.

Resumen de posts sobre vmware site recovery manager

Siguiendo con la idea del post anterior donde revisé algunos de los mejores posts sobre licenciamiento de productos de vmware en este caso voy a cubrir algunos posts relacionados con la recuperación de desastres para ambientes virtuales y más especificamente sobre vmware site recovery manager.


srm y stretched clustersSite recovery manager  y stretched clusters, cuando elegir uno, otro o ambos

En este post, que en realidad no es un post, es el video de la charla que dimos junto a Pablo Scheri en el vmware virtualization forum 2013 en Buenos Aires.

En el mismo discutimos cuales son las alternativas para el uso de vmware site recovery manager y clusters extendidos, cuando uno, cuando el otro y en que casos pueden trabajar en conjunto.

Creo que la charla fue muy buena por lo que vale la pena tomarse un rato para mirarla entera.


recuperacion de desastres con srm y viewPodcast S02E02 – Disaster recovery con vmware SRM y view

En este post, que tampoco es un post sino un podcast, cubrimos los beneficios de trabajar con vmware site recovery manager como herramienta de automatización de procesos de recuperación de desastres.

Aprovechando el momento discutimos también la posibilidad de incluir vmware view dentro del esquema de recuperaciones con el fin de simplificar el acceso a los puestos de trabajo a los usuarios durante un período de crisis.

Es un podcast que vale la pena escuchar.


rto rpo drp vmware srmRecuperación de desastres en ambientes virtuales

La idea de este post es mostrar los escenarios y conceptos generales dentro del marco de un proceso de planificación de recuperación de desastres.

También se ven los beneficios de poder trabajar con vmware por la simpleza de los procesos de recuperación.


vmware srm topologyRecuperación de desastres con vmware site recovery manager 5

En este artículo cubrimos los beneficios de trabajar específicamente con vmware site recovery manager 5 y sus nuevas funcionalidades y los requerimientos de las mismas como así también los escenarios donde se podrían aplicar cada una de las funcionalidades.

Un muy buen post como introducción a SRM 5


licencias site recovery managervmware srm – cuando 76 vms pueden ser muchas

Vuelvo con este artículo que ya les había presentado en el post sobre licenciamiento de vmware. En este caso el artículo describe el esquema de licenciamiento de vmware site recovery manager y los diferentes tipos de versiones de productos.

Aquí se ve claramente lo que vmware considera como una pequeña empresa y cuando comienzan a ser una empresa mediana. El modelo de licenciamiento lo deja bien claro.

 


Espero les sirva! Nicolás Solop

Wetcom Virtualization Podcast S02E2- Recuperación de desastres con SRM y View (Spanish)

Volvimos a transmitir en vivo y en el segundo episodio de la segunda temporada hablamos de como llevar adelante un proyecto de recuperación de desastres con tecnologías VMware SRM y VMware View

Participantes:
Diego Quintana (@daquintana)
Nicolás Solop (@nsolop)
Ariel Mónaco (@ariel_monaco)
Pablo Scheri (@pabloscheri)

Para escuchar el podcast pueden visitar Podcast S02E02: Disaster recovery con Vmware SRM y view

Si lo prefiere puede suscribirse a iTunes en Wetcom Group | Expertos en virtualización y Cloud Computing

Y por último para descargar el archivo en formato mp3 Podcast S02E02: Disaster Recovery con VMware SRM y View

Todos nuestros podcasts son transmitidos y grabados en vivo por medio de spreaker.com por lo que no tenemos forma de editar el contenido de los mismos!

Wetcom Virtualization Podcast S02E01- Cloud Desktops (Spanish)

Si volvimos a transmitir en vivo nuestros podcasts sobre tecnología y virtualización!. En el primer episodio de la segunda temporada hablamos de como llevar los desktops tradicionales a ambientes virtuales de forma simple y sin dolores de cabeza!

Participantes:

Diego Quintana (@daquintana)
Nicolás Solop (@nsolop)
Ariel Mónaco (@ariel_monaco)
Pablo Scheri (@pabloscheri)

Para escuchar el podcast pueden visitar Podcast S02E01: Cloud Desktops – Nuestra alianza con Microsoft

Si lo prefiere puede suscribirse a iTunes en Wetcom Group | Expertos en virtualización y Cloud Computing

Y por último para descargar el archivo en formato mp3 Podcast S02E01: Cloud Desktops – Nuestra alianza con Microsoft

Todos nuestros podcasts son transmitidos y grabados en vivo por medio de spreaker.com por lo que no tenemos forma de editar el contenido de los mismos!

Nicolás Solop

VMware View como soporte para planes anti pandemia

Escribí un nuevo post en el blog de tecnologías de virtualización de servidores y Desktops de Wetcom Group. En este nuevo artículo hablo sobre los beneficios de la virtualización de puestos de trabajo como soporte para la implementación de planes antipandémicos.

En el mismo aclaro sobre algunos puntos técnicos como así también de metodología que pueden ayudar a las empresas a implementar este tipo de soluciones de forma simple y eficiente simplificando los tediosos procesos de diseño, prueba y en el peor de los casos la puesta en marcha de los mismos.

El artículo lo pueden encontrar en:

VDI – Virtual Desktop Infrastructure como soporte de planes pandemicos

Espero sea de su agrado la lectura.

Nicolás Solop

VMware vExpert

LinkedinXingTwitter

Podcast de Kukudrulu sobre virtualizacion con vExperts Hispanos

Hace unas semanas tuve la suerte de participar en un podcast de los amigos de Kukudrulu donde discutimos sobre la situación actual y el futuro de la virtualización de servidores y desktops, sobre almacenamiento y demás cosas como redes que a todos nosotros nos gustan.

Tengo que reconocer que pasé un momento genial junto a un grupo de profesionales de primera división. A las personas que estén interesadas en escuchar lo que salió de la charla pueden escucharlo más abajo:

Los participantes de la charla fuimos:

Juan Manuel Rey, vExpert 2011 de Madrid. Experto en UNIX y vSphere de HP Spain.
Twitter: @jreypo

José Luis Gómez. vExpert 2011 de Sevilla. Experto en vSphere y Xen. Trabaja en NEC. Es sevillano y desde hace muy poquito vive en Madrid.

Twitter: @pipoe2h

Blog: http://blog.e2h.net

Diego Quintana. vExpert 2011 de Buenos Aires. CEO de Wetcom.
Twitter: @daquintana
Nicolás Solop. vExpert 2011 de Buenos Aires. Co-Founder de Wetcom.
Twitter: @nsolop
Pablo Scheri desde Buenos Aires. trabaja en Wetcom como consultor y especialista técnico para proyectos de vmware.
Twitter: @pabloscheri
Josep Ros. vExpert 2011 de Sabadell. Director General de Ncora. Vive en Torredembarra.
Skype: @josepros
Blog: http://www.josepros.com

Nicolás Solop

VMware vExpert

LinkedinXingTwitter

Recuperacion de desastres en ambientes VMware – escenarios y conceptos

Escribí un nuevo post en el blog de tecnología de Wetcom Group sobre escenarios de recuperación de desastres en ambientes virtuales VMware junto con los conceptos básicos de recuperación de desastres como RPO y RTO.

En el post Recuperación de desastres en ambientes virtuales VMware – escenarios y conceptos generales explico los diferentes niveles de RTO y RPO para los escenarios de respaldo y recuperación, replicación a demanda y orquestación con VMware Site Recovery manager.

Cada uno de estos escenarios posee niveles diferentes de RPO y RTO lo que se traduce en diferentes niveles de presupuesto para cada uno de ellos. Elegir la mejor opción para cada empresa debe ser el resultado de un relevamiento de requerimientos de negocio.

Espero que sea de su interés.

Nicolás Solop

VMware vExpert

LinkedinXingTwitter

Wetcom virtualization podcast #3 | Conversiones P2V

Pablo Scheri, Diego Quintana y Nicolas Solop hablan sobre los desafíos de las conversiones de físico a virtual o P2V.

Las conversiones P2V deben ser planificadas con antelación siguiendo con la ejecución de tareas previas a la migración con el objetivo de lograr un resultado exitoso. Escucha a nuestros expertos debatir sobre los diferentes enfoces que una conversión de físico a virtual requieren.

Si quiere escuchar el tercer podcast puede hacerlo siguiendo el siguiente enlace Conversiones P2V y el nuevo VMware Converter 5.0

O bien, si lo prefiere, descargarlo desde iTunes en Wetcom Group | Expertos en virtualizacion y cloud computing

Pueden descargar el archivo en formato MP3 siguiendo este enlace: Conversiones P2V y VMware Converter 5.0

Todos nuestros podcasts son transmitidos y grabados en vivo por lo que no tenemos forma de editarlos 😉

Nicolás Solop

VMware vExpert

LinkedinXingTwitter