Todas las entradas de: nsolop

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.

El ruido del tren de OpenStack

Nadie quiere perderse el tren de la Tendencia OpenStack !. Cisco, VMware, Red Hat quieren una porción y, según ellos, cada uno es un gran contribuidor del proyecto. Ahora bien, ¿qué hay detrás de todo esto?.

Grandes corporaciones tradicionalmente ligadas al software propietario metiendo mano en un proyecto de código abierto.

Algunos por rebote como el caso de VMware que luego de comprar Nicira, hoy VMware NSX, la cual era contribuidora del proyecto OpenStack continúa invirtiendo. Lo que no queda claro es si lo hacen porque realmente quieren hacerlo o simplemente para mantener los compromisos asumidos por la empresa adquirida.

Cisco, un caso parecido. ¿Que hace una empresa asociada al mundo de las redes invirtiendo en el proyecto?. No solamente invierte sino que además lanzó su propia distribución. ¿Es por miedo a que VMware avance demasiado y deje afuera su solución de SDN  porque la primera profundiza aún más sus tecnologías?.

Red Hat es el caso más natural de todos estos. Una empresa que produce software de código abierto (no voy a discutir su estrategia comercial) está bien que se decida a invertir en una empresa con sus misma ideología (?).

De acuerdo a lo que mencionaron en el Red Hat Forum la semana pasada en Buenos Aires, ellos son el contribuidor número 1 del proyecto OpenStack. Si ellos lo dicen…

Que haya opciones es bueno para el cliente final. Hace que cada uno tome su tiempo en la decisión y mantiene los precios bajos.

Para poder usar la distribución de OpenStack desarrollada por VMware (VMware Integrated OpenStack o VIO), o la que podemos descargar del sitio de OpenStack, tenemos que utilizarla contra un servidor vCenter. Nada muy raro ya que para poder usar un ESXi desde fuera necesito tenerlos licenciados y si licencio un par de hosts también compro licencias de vCenter.

No hay nada libre de uso. Perdón, si lo hay. Uno puede usarlo siempre y cuando tenga licencias de vCenter.

Gracias, de nada.

Para poder usar algo de Red Hat necesitas las suscripción ( al final hablé del modelo comercial). Sin esto tampoco hay nada.  La realidad es que si voy a invertir dinero para usar una herramienta de despliegue rápido, o distribución de  OpenStack, (se llama Red  Hat RDO por si les interesa) tendría que justificar muy bien mi decisión de ir al software de código abierto a menos que en nuestra organización seamos pro-open source.

Es muy raro que una empresa decida moverse de soluciones sólidas como las de VMware a soluciones de software Open Source así por que si.

Los fundamentos de la iniciativa deberían ser no solamente por el costo sino también por funcionalidades o bien la capacidad de crearlas o modificarlas.

Si miramos los dos casos (dejo fuera a Cisco porque sino es muy largo) el único objetivo de su colaboración en estos proyectos es asegurarse que quienes adopten sus distribuciones utilicen sus tecnologías de virtualización como soporte principal.

¿Cuál es el motivo para que cada vez más empresas deciden “investigar” OpenStack?. Se escucha mucho y fue uno de los motivos principales de mi asistencia al vmworld de este año.

Si las funcionalidades no son analizadas y los  servicios/aplicaciones de estas empresas no están preparadas para correr sobre OpenStack ¿dónde está el tema?.

En los casos que relevé personalmente el principal motivo es el costo de las licencias que utilizan para sus servicios de IaaS. Ni por cerca pasa analizar OpenStack por sus funcionalidades ya que cuando estamos en una reunión para presentar de que se trata no llegaron a tomarse el trabajo de investigar qué es OpenStack. (para quienes quieran saber qué es OpenStack recomiendo leer el post introductorio de Pablo Scheri).

Esa es la realidad argentina y tal vez la realidad de muchos países de América Latina.

Son pocas las empresas de estos países que podrían beneficiarse de utilizar OpenStack. Y las que podrían están relacionadas al mundo de Internet (comercio electrónico e ISPs) donde se manejan “enormes” volúmenes de información o transacciones.

¿Cuántos gigantes de internet hay en América Latina?. Pocos, muy pocos.

Esto filtra  los requerimientos y funcionalidades que podrían ser adoptadas por las empresas que continúan teniendo sus servidores exchange dentro de sus propios centros de cómputos.

Es cierto que muchas empresas están “pensando” en armar sus nubes privadas y están creando sus roadmaps que les permitirán implementarlas. Si este roadmap incluye la transformación de sus aplicaciones y mover parte de sus servicios internos (correo electrónico, intranets, file servers, etc.) a la nube van por el buen camino.

Si estas logran convertir sus aplicaciones a una arquitectura aplicativa moderna pueden ser un buen candidato a OpenStack.

Desde mi óptica todo se reduce al costo del licenciamiento (suscripción en el caso de Red Hat) hoy en día. No hay nada más.

Está más que claro que la innovación tecnológica que OpenStack tiene bajo el brazo. Es importante y puede cambiar la forma en que las empresas adoptan tecnologías o cuanto las pueden explotar pero de momento el análisis es económico.

Este es el principal motivo por el cual las empresas “preguntan” por OpenStack. Y sumando al motivo que mueve a las empresas se cierra el círculo.

Todo es una cuestión de números, las compañías no quieren perder clientes que utilizaban sus tecnologías y las compañías quieren bajar sus costos. Habrá que encontrar un punto intermedio donde la ecuación cierre.

Tanto OpenStack como el concepto de SDN tienen grandes desafíos por delante y no son todos tecnológicos.

Hasta que las empresas no se decidan a innovar tecnológicamente el valor que OpenStack puede entregar no será analizado desde el punto de vista del bit y byte.

Y vos, ¿qué opinas al respecto?.

Foto: Jerry Huddleston

Tiempo o dinero, siempre hay que elegir

En el proceso de selección de una tecnología a implementar en una organización se encuentran varios pasos de filtro que permitirían a una empresa tomar la decisión que se ajuste a las necesidades reales de la misma.

Debido a cambios generacionales cada vez son más las organizaciones que analizan el software de código abierto incluso cuando sus presupuestos tranquilamente pueden cubrir los costos de adquisición e implementación de tecnologías de código cerrado.

Ver también: ¿Software de código abierto o cerrado?, una mirada a 5 años.

Históricamente las organizaciones con grandes presupuestos se inclinaban al software de código cerrado. Es más, para muchos es normal pensar que con una billetera abultada la decisión es simple y se descarta el software de código abierto.

Hoy cada vez son más las empresas que, incluso contando con el presupuesto, se inclinan a la libertad de poder “tocar” el código fuente de las aplicaciones o servicios que prestan a sus usuarios al final del día.

Este movimiento puede observarse mucho en ambientes estatales o gubernamentales pero poco a poco los privados también están inclinando la balanza.

Sin importar cual sea la decisión hay dos factores clave que hoy en día, dependiendo de la organización, tienen peso propio en la balanza.

Si, adivinaron Tiempo y dinero.

En opinión generalizada el software de código cerrado es más simple de implementar, requiere menos personas involucradas en el despliegue y se pueden obtener buenos resultados.

Esto nos da una menor inversión en tiempo pero en casi todos los casos hay que desembolsar algunos billetes. Ideal para empresas privadas que buscan minimizar la cantidad de personal involucrado en un proyecto pero que están dispuestos a invertir dinero.

Hay casos donde privados ponen al software open source como primera opción, pero son los menos y generalmente son empresas ligadas al mundo de los servicios de internet.

Por el otro lado el software open source requiere de mayor personal para implementarlo, generalmente con conocimientos específicos, pero que no requiere una inversión en dinero.

Es por esto que las organizaciones gubernamentales las cuales cuentan con una buena cantidad de personal y con tiempo disponible se inclinan más al software de código abierto.

La balanza donde de un lado tenemos tiempo y del otro dinero decide su rumbo de acuerdo a donde estemos trabajando.

Es por esto que no es trivial para las organizaciones tomar una decisión. Para los privados cuando las finanzas está bien no se discute pero cuando una crisis encuentra una brecha siempre se plantea la decisión del software de código abierto.

El problema es que por más que no se gaste dinero en la inversión inicial de compra del software el dinero se gastará en sueldos de quienes implementen la solución o en los servicios de una empresa que lo haga por nosotros.

Para algunos fundamentalistas, que cuentan con tiempo y dinero, la decisión de el software código cerrado no es una opción pero la realidad es que son los menos.

Es por esto que al momento de decidirse por el software open source no debe dejarse de lado el peso del tiempo de implementación que tomará la puesta en marcha del mismo.

No estoy buscando discutir sobre tener o no el respaldo de un fabricante ni de cuales son los pros y contras entre uno y otro.

Simplemente es comprender los desafíos que plantea el TCO de una solución de software.

Quienes me conocen saben que el software de código abierto es siempre de mi agrado, por las posibilidades que el mismo plantea e incluso por lo romántico de la idea.

Pero no por esto me ciego pensando que por no pagar licencias de software las cosas van a ser simples o directas. En muchos casos es todo lo opuesto y esto se traduce en dinero.

¿Y vos que pensás? ¿cómo es tu balanza de tiempo o dinero a la hora de elegir software?.

Foto: Time is Money

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.

La importancia del ingles en sistemas

Este es otro de los posts que tenía escrito en un blog orientado a quienes se iniciaban en el trabajo dentro del mundo de la tecnología…

Porque es importante saber hablar y leer en inglés cuando trabajamos en sistemas. Cuanto es suficiente para tener un nivel aceptable de inglés. Aquí las respuestas.

La importancia de saber ingles en sistemas

No importa en el país en que vivamos si trabajamos en sistemas hablar en inglés es una de las herramientas más importantes con las que podemos contar. La parte “técnica” de trabajar en sistemas se aprende fácil, y rápido.

Las razones de la importancia:

  • La mayor parte de la tecnología se desarrolla en países de habla inglesa.
  • La mayoría de la información y libros disponible está en inglés.
  • Certificar una tecnología requiere conocimientos del idioma.
  • La actualización de software se realiza primero para sistemas en inglés.

La tecnología proviene de países de habla inglesa

La mayor parte de la tecnología con la que trabajamos en sistemas día a día proviene en mayor medida de Estados Unidos, Canadá y en menor medida de países como Inglaterra o Israel.

Existen otros países desarrolladores de tecnología pero en la mayoría de los casos la casa matriz de las compañías es de habla inglesa por lo tanto la información, documentación y actualizaciones se hace en inglés.
Nos guste el idioma o no si trabajamos en TI lo vamos a tener que aprender.

La mayoría de la información y contenido está disponible en inglés

Buscar información sobre tecnología en castellano es una pérdida de tiempo. O bien no hay información disponible o está desactualizada. Intentar conseguir libros de tecnología actuales es nuestro idioma es imposible por lo tanto si queremos mantenernos actualizados tendremos que hablar inglés.

Si bien en los últimos años con el desarrollo de los blogs la información tecnológica en español comenzó a desarrollarse aún queda mucho camino por recorrer para estar al nivel de cantidad y calidad de lo que podemos encontrar en inglés.

Simplemente para graficar este punto pregunto cuantas veces buscaron un error específico cuyo mensaje estaba en español. En ese mismo ¿caso cuantas veces intentaron traducir el mensaje de error al inglés para poder encontrar mejores resultados?.

Para los puestos de trabajo es un dolor de cabeza pero para buscar información de errores en los logs de un servidor puede ser una misión imposible.

Rendir un examen de certificación
Para las tecnologías con mayor presencia en el mercado como puede ser Microsoft cuentan con versiones de los exámenes en castellano pero la verdad es que las traducciones que se hacen de estos exámenes son verdaderamente desastrosas.

Sentarse a rendir un examen y no entender en castellano lo que estamos leyendo desde mi punto de vista es peor que rendir en un idioma que no es mi idioma nativo.

A menos que tengamos un excelente nivel de conocimiento vamos a tener que preparar la certificación con manuales, vídeos y laboratorios que en su mayoría, como es obvio, estará en inglés.

Ya hablamos en el blog de la importancia de las certificaciones cuando trabajamos en sistemas. ¿Cómo vamos a preparar un examen si no entendemos lo que estamos leyendo?.

Vi mucha gente fallar en los exámenes no porque no supieran sobre la tecnología o porque no tuvieran experiencia sino simplemente porque no entendían lo que les estaban preguntando mientras lo rendían.

La actualización del software se realiza primero en inglés
El software que viene en castellano en algunos casos es una versión diferente que la que podemos encontrar en inglés.

Debido a que la base de software instalada en inglés es ampliamente superior que lo que podemos encontrar en otros idiomas al momento de desarrollo de una actualización, parche o respuesta de una vulnerabilidad siempre se prioriza el software en inglés y el resto de los idiomas tiene que esperar su turno.

En los últimos años esto cambió mucho con la implementación de los MUI (Multingual User Interface) donde las traducciones no se encuentran en una versión diferente del software sino que en una interface con el idioma especificado en el MUI pero aún quedan casos bien claros.

¿Que nivel de conocimiento es suficiente?

El nivel de conocimiento que necesitemos va a depender en mayor o menor medida del tipo de trabajo que estemos realizando en el momento de nuestra carrera. O a donde queramos llegar.

Por ejemplo si estamos preparando un examen de certificación tendremos que ser capaces de comprender claramente los objetivos de el examen. En este link están los objetivos y detalles de los requerimientos de la certificación A+ de Comptia.

¿Si no los entendemos como vamos a poder sentarnos a tomar un examen? Ahí la respuesta.

En muchos casos trabajamos en empresas que tienen casas matrices en otros países cuyo idioma no es el español ni el inglés pero las comunicaciones ya sean presenciales, por correo electrónico o telefónicas se llevan adelante en inglés.

Si estamos trabajando en una posición con responsabilidades nuestro inglés deberá tener matices de negocios y gestión cosa que el inglés puramente técnico no tiene. Esto es para otro post, es un animal completamente diferente.

A modo personal creo que dominar un idioma es una llave que abre puertas, muchas puertas. Uno nunca sabe cuando va tener que usar la herramienta del idioma. Tengo varias historias de personas conocidas que en momentos difíciles de su vida el inglés les facilitó las cosas. 

Foto: TOEFL Program

Excusas por las cuales no certificaste

Este es un post que escribí en otro blog que estoy dando de baja… prefiero consolidar todos mis pensamientos en un solo lugar por más que a muchas personas no estén tan de acuerdo!.

Ver también: La importancia del inglés al trabajar en tecnología

Este blog estaba orientado a los jóvenes en sus primeros años de trabajo en TI. Es por esto que en algunos casos encontrarán el contenido algo básico.

En los últimos 5 años tomé más de 100 entrevistas para diferentes puestos que teníamos abiertos en Wetcom. Algunas de las excusas por las que los aspirantes no certificaron y el porque ya no son creíbles.

Insisto con el tema de las certificaciones porque me ayudan a entender el compromiso que tiene la persona que se tomó el trabajo de tomarse algunos días para sentarse a estudiar o al menos a pensar como es un examen.

Así mismo  y como la mayoría de los exámenes son en inglés puedo tener alguna idea de cuanto maneja el idioma el candidato.

Tengo que aclarar que un par de certificaciones no son determinantes en una entrevista, pero suman y mucho.

Hagamos foco en las excusas y como pensar del otro lado.

  • No tuve tiempo para preparar los exámenes. Esta es la que más escuchamos en la mesa y déjenme decirles que es muy difícil de creer que alguien con 10 años de experiencia no tuvo 3 meses para preparar un examen. Tomate el tiempo para hacerlo en lugar de jugar Counter Strike.
  • La empresa no me paga los exámenes. Otra que en el ranking, dependiendo el puesto se lleva la delantera. Si la empresa no te paga los exámenes podés hacer un plan para certificar 1 o 2 al año. Con las certificaciones tu ingreso debería subir al mismo ritmo.
  • La empresa no me paga los entrenamientos. Quien los necesita hoy en día hay suficiente material disponible en internet para preparar una certificación que los entrenamientos no se justifican. Incluso gastar unos pesos en un libro para preparar una certificación no le rompen el bolsillo a nadie.
  • No tengo el laboratorio necesario. A menos que sea una certificación de redes donde se requiere un equipamiento especial, incluso hoy ya hay simuladores, desde que apareció la virtualización con una pc promedio de gamer se puede preparar un laboratorio más que digno para una certificación.
  • No necesito certificarme. Esta es de las que peor se ven del otro lado de la mesa y de las más difíciles de romper. Si son necesarias y mucho ya que dan crédito del conocimiento que tiene la persona que las posee.

Hablemos claro, que una persona tenga certificaciones no es garantía de que sea un excelente profesional o que pueda cumplir con las necesidades de un puesto, pero a la hora de elegir siempre me inclino por alguien que tomó la decisión de desafiarse a si mismo ante un examen.

Uno puede sentarse por semanas a estudiar o incluso conseguir las respuestas de los exámenes para prepararlos. Nuevamente no son garantía de nada pero suman peso en la balanza y deberían ser tenidos en cuenta a la hora de evaluar que hacer con el tiempo libre.

Foto: Abhishek Baxi

El diagnóstico acertado es la mitad de la cura

En algún lugar escuché la frase el diagnóstico acertado es la mitad de la cura. Hoy, luego de participar en un incidente con interrupción de servicio en un cliente pude comprobar que la frase no aplica sólo a la medicina.

Diagnosticar es un arte en sí mismo. En algunos casos contamos con herramientas o tecnologías que nos pueden ayudar a identificar un problema y en otros no contamos más que con nuestra experiencia y corazonadas.

Pero la realidad es que en la mayoría de los casos las detecciones de los problemas se lleva a cabo luego de la aparición de los primeros síntomas.

En casos extremos lo que vemos es el resultado de la extensión del problema de raíz que deriva en otra cosa. En estos casos Lo que vemos, el síntoma, hace que el diagnóstico sea mucho más complejo identificar que es lo que lo está produciendo.

Volviendo al ejemplo de la tecnología… Hoy llamó un cliente informándonos que algunas de sus máquinas virtuales dejaron de funcionar en el único host que tenían en el sitio.

Dentro del mundo de la virtualizacion con VMWare a primera vista uno puede pensar algunos puntos sobre los cuales trabajar.

Esto se debe a que, por eliminación, son muy pocos los aspectos que pueden afectar solo a algunas máquinas virtuales en un host.

Luego de un análisis preliminar, charlar con el administrador sobre cosas que podrían haber cambiado en el ambiente y que nos habilitaran el acceso VPN pasó una hora.

Resuelto el problema de la conectividad y comenzando con el análisis, ya que el diagnóstico lo teníamos comenzamos a trabajar en el problema.

House tenía razón, todos mienten.

En el momento nos llama otra persona del cliente para preguntarnos porque todavía no sabíamos que pasaba cuando era un problema tan grave. Caras de sorpresa por todos lados.

La persona que llamo inicialmente nunca dijo que era crítico ni que TODOS los sistemas estaba afectados.

Perdimos tiempo, mucho. Analizamos cosas que no tenían sentido para el problema real. Ya el síntoma no era una molestia, era algo mucho más grave que debíamos atender.

Si hubiésemos contado con la información correcta de buenas a primeras la respuesta al origen del problema hubiese sido identificada mucho más rápido.

Con el correr de las horas la primer persona que nos llamó nos “contó” que antes de llamarnos había cambiado un disco que se había roto. Más información que nos podría haber dado antes. De hecho el origen del problema fue ese disco local en el servidor.

Identificada la causa raíz del problema delineamos un plan de acción para volver a dar servicio cuanto antes y eliminar por completo la causa raíz del problema.

Todo esto demoró unas 8 horas, de las cuales más de la mitad estuvimos a ciegas por no contar con un panorama completo de lo que estaba pasando.

Se que los sistemas vuelven a dar servicios y que en la medicina hay casos en que la muerte es inevitable pero bien sirve como punto de partida de comparación.

En mis días de empleado de EDS, hoy HP, para detectar la causa raíz de un incidente utilizábamos un sistema de 5 pasos. Este sistema de 5 pasos es utilizado también en muchas industrias.

La misma se basaba en realizar la pregunta ¿porqué?  cinco veces indagando cada vez de forma más profunda hasta dar con la causa raíz del problema y luego trabajar en la eliminación de la misma.

En algunos casos es efectiva, si se cuenta con TODA la información necesaria, pero en otros se puede quedar corta. Esto se debe a que al llegar al final de la respuesta del quinto ¿porqué? uno puede detener el análisis ahí mismo y quedarse plantado en esa respuesta cuando en realidad puede llegar a existir un punto más profundo aún.

¿Estás de acuerdo en que el diagnóstico acertado es la mitad de la cura?. ¿Qué métodos de análisis de causa raíz utilizas diariamente?.

Foto: Ripoff Я E.R.

Dejar la cabeza en el headhunting

Vamos a hacer un poco de ruido con esto…

Uno de los principales problemas de las pymes tecnológicas Argentinas es encontrar personal especializado, formados y que además pueda pagarlos a fin de mes.

Si venimos trabajando hace un tiempo con una tecnología muy específica, como es el caso de vmware, brindando servicios profesionales de calidad tanto en el mundo corporativo como en el estatal habremos recorrido un largo camino de entrevistas laborales, algunas productivas y otras no tanto.

Con el correr de los años llegamos al punto donde prácticamente uno puede conocer los nombres de las personas que se postulan, a quien entrevistaste, a quien no y quienes simplemente no encajaban en la cultura de la empresa.

Trabajar en una pyme es completamente diferente a trabajar en el mundo de las grandes corporaciones. Las primeras tienen otras reglas que a algunas personas pueden gustarle y a otras no.

Volviendo al desafío de encontrar personal especializado para cubrir una posición con alto conocimiento técnico y más específicamente de consultoría muchas veces las ideas y las opciones se acaban.

Aquí es donde uno comienza el duro camino del headhunting.  Ya sea utilizando herramientas como linkedin haciendo el trabajo personalmente o bien contratando una consultora.

Si lo hace uno mismo simplemente contacta a la persona cuyo perfil le interesa y si lo hace por medio de una consultora de reclutamiento espera algunas semanas para recibir la primer tanda de candidatos.

El horror comienza cuando uno recibe los primeros curriculums enviados desde la reclutadora. No están ni cerca de lo que uno espera de una persona que incorporaría a trabajar en su empresa. Ida y vuelta, se le explica a la persona responsable del reclutamiento de la consultora como debe ser el perfil.

El problema es que esta persona no tiene ni un gramo del conocimiento técnico ni como evaluar al candidato desde un punto de vista de como los conocimientos de esta persona aplicarían al día a día de la empresa.

Uno termina haciendo el mismo trabajo que hacía antes pero pagando para que alguien le traiga los curriculums. Un negocio buenísimo, ¿no?.

Pero pasan las semanas y al pobre tipo de la consultora le pasa lo mismo que a uno. No encuentra a las personas, las que encuentra están 3 veces por arriba del presupuesto para la posición o simplemente “estaban escuchando las ofertas de mercado”.

Empiezan a contactar a los perfiles de acuerdo a lo que les indicaste inicialmente. Ahora el tipo de la consultora está en la misma posición pero sin conocer demasiado de la tecnología con la que se debe trabajar todos los días.

Seamos claros en algo, cuando uno va a buscar a una persona para que venga a trabajar a una empresa no está en la mejor posición para negociar algunos temas.

Frases como “vos me llamaste, vos me tenés que convencer de venir a trabajar acá” o “yo estoy cómodo donde estoy, tu oferta tiene que ser muy tentadora para que cambie” son un claro indicio de esto.

En algunos casos es totalmente evidente y en otros estos comentarios son tan sutiles que pasan desapercibidos. Sea cual sea el caso uno debe estar atento para poder leer estas cosas.

Entender que hay gente que puede querer venir a trabajar a tu empresa por lo que esta puede ofrecer, por el desafío, porque le gusta la tecnología con la que puede trabajar y por la forma de hacerlo. Pero también tenemos que vamos a encontrarnos con gente que simplemente quiere cambiar de trabajo sea por un sueldo mejor o bien por un cambio de posición.

Por las características de una pequeña y mediana empresa es clave que todas las personas que participan en la misma aporten y aporten fuerte en el día a día de trabajo.

En una empresa de 500 empleados que algunas personas no aporten demasiado no se nota mucho. En una pequeña empresa esto no es así en absoluto, se nota muy rápidamente quienes realmente tienen ganas de trabajar, ganas de hacer cosas para que la empresa funcione mejor.

Estas son las personas que uno debe buscar para trabajar en la empresa. Quienes crean en el proyecto son las que deben tener un espacio, una oportunidad.

Por medio del headhunting como método de reclutamiento se está dando una invitación a trabajar en la empresa a alguien que, tal vez, ni siquiera esté interesado en trabajar en la misma. Aquí es donde el riesgo aumenta demasiado.

Ya uno no solo está en desventaja en la negociación sino que además puede estar negociando con la persona equivocada. Al menos si la persona aplica a la posición está demostrando un interés claro de hacer un cambio y, si tenemos suerte, este puntualmente interesado en trabajar en nuestra empresa.

A modo de cierre… En base a experiencias anteriores, intento evitar completamente llegar al reclutamiento por medio del headhunting. Es preferible esperar un poco, incluso pedir recomendaciones de personas que ya estén trabajando en la empresa a incorporar a alguien que no quiere realmente trabajar en tu empresa.

Para quienes se pregunten ¿cómo darse cuenta si alguien está realmente interesado en trabajar en nuestra empresa? mi única respuesta es: los mejores resultados de reclutamiento que tuvimos fueron siempre de personas que nos contactaron para venir a trabajar con nosotros sin tener un aviso de empleo publicado.

Si el curriculum es bueno, los requerimientos son adecuados y sin solicitarlo demuestra interés en trabajar en la empresa ambas partes deben darse una oportunidad.

Foto: Rusty Antiwar Sculpture

Es la ejecución, no el plan

No hay forma de llevar a papel lo que tengo en la cabeza. Algunas ideas, algunas intenciones no hay forma de llevarlos a un documento. A no temerle a escribir.

Esto fue lo que pensé cuando comenté dentro del círculo de Wetcom que iba a escribir un libro sobre la práctica de migración de Windows de trabajo que creamos.

La duda apareció rápidamente cuando pensaba si alguna persona que trabajara en alguna empresa que compita con Wetcom en el tema accedía al libro.

¿Qué podía pasar?, ¿qué robarán la práctica entera?, ¿qué perdiéramos algunos negocios?.

Dudas. Y estas eran sólo algunas.

Ahora bien, supongamos por un momento que tuve un ataque de inspiración y pude escribir todo lo que sabemos sobre este tipo de proyectos.

Y esto le sumamos que la persona que lee el libro comprende de punta a punta lo que estoy explicando.

¿Puede llevar adelante un proyecto por sí mismo?. Si puede, pero hasta cierto punto.

Siempre existen variables que únicamente están en la cabeza de la persona que tiene experiencia y que sería realmente imposible llevarlas a papel en su totalidad. Por más buena voluntad que ponga en escribir siempre algo va a quedar q mitad de camino.

Por eso no hay que temer a mostrar lo que uno tiene.

Sino ¿para qué publicar un libro?, si a fin de cuentas cualquier persona puede comprar el libro en una librería y obtener el mismo conocimiento por 10 o 15 dólares. No vale la pena preocuparse.

Es por esto que cuando escribí el post consultando a quienes les gustaría participar como revisor del libro antes de su publicación no tuve ningún tipo de problemas a la hora de aceptar a una persona, que no conozco personalmente, pero que se de buenas a primeras que trabaja en una empresa que compite con Wetcom.

Sin ir más lejos esta persona fue la que más colaboró en la revisión del libro. La que más lo criticó, aportó para mejorarlo y se volvió a ofrecer como revisor una vez que los cambios hayan sido aplicados al libro.

Llevemos esto a un punto mucho más lejano. Cuantas empresas no hubiesen visto la luz por temor a presentar un plan de negocios a alguna persona/empresa como potencial inversor.

Si por tener miedo a “mostrar”  y que nos puedan robar la idea de lo que queremos hacer vamos a paralizarnos creo que tenemos un problema.

Coincido mucho en el artículo El inversor no lee el plan de negocios donde Santiago Bilinkis explica que no es “el documento” el que convence al inversor, es la persona, el equipo.

Supongamos que tengo la oportunidad de sentarme frente a un potencial cliente por una reunión referida al tema central del libro. Supongamos también que la gente que está en la mesa lo leyó y le gustó.

No por esto van a contratar nuestros servicios. Tengo que demostrar que, además de haber escrito el libro, conocemos lo que hacemos, tenemos el equipo adecuado y podemos ejecutar en tiempo y forma.

Algo simple para una persona con experiencia en el tema, algo complicado para quienes solo leyeron un texto.

Les dejo un saludo.

 

Foto: Dome Plan Drawing