Archivo de la categoría: Tecnologia

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

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.

La procrastinación de las grandes empresas

Se fue Windows XP y muchas grandes empresas recién ahora se enteraron. Parece que todos los esfuerzos de Microsoft para dar a conocer el fin de soporte de Windows XP hicieron mella en las grandes empresas. Analicemos un poco el motivo.

2 años anunciando el fin del soporte de Windows XP y fueron muy pocas las empresas que hicieron algo al respecto. Hoy les toca correr.

¿Porqué nadie hizo nada?, ¿porqué dejaron de lado un proyecto que afecta a todos los usuarios finales?.

Procrastinaron, y mucho.

El mismo día en que Microsoft retira el sistema operativo me encuentro analizando la viabilidad de 4 proyectos de migración a Windows 7 o Windows 8.

Es cierto que un proyecto de migración de sistemas operativos en los puestos de trabajo de los usuarios no es el proyecto más “sexy” que un gerente de tecnología quiera enfrentar.

No importa si la empresa tiene 300 o 3000 puestos de trabajo para migrar. Cualquier proyecto relacionado con usuarios finales es un proyecto sensible. Que deber hacerse con tiempo, bastante tiempo.

Principalmente creo que el motivo por el cual muchas empresas aún siguen, y seguirán por algún tiempo, estancadas en Windows XP es la falta de un plan estratégico de TI.

Este plan debe definir claramente cuales son los proyectos más importantes de la organización para los siguientes 3 a 5 años. Contando con este plan ningún gerente de TI se hubiese encontrado en esta situación.

Este plan no solamente tiene como objetivó listar los proyectos que se ejecutarán a futuro, sino que también permitirá ajustar los presupuestos anuales de TI.

Si tenemos un plan y un presupuesto asignado al mismo no veo el motivo por el cual no ejecutar los proyectos.

Además de no contar con el presupuesto adecuado el otro problema que existe es que ningún gerente de tecnología se siente tentado a encarar un proyecto de este estilo por iniciativa personal.

Gran parte de la decisión de Microsoft de acabar con el soporte de Windows XP se debe justamente a esto. Todo el mundo están muy conforme con el sistema operativo y no veía la necesidad de cambiarlo.

Mientras no les impusieran una obsolescencia programada nadie iba a tomar la iniciativa.

Las empresas deberán trabajar en un plan de obsolescencia tecnológica por fuera a lo que imponga el fabricante del software. De esta forma tendrá siempre el control de la situación.

Al día de hoy el principal problema no es que Windows XP se quede sin soporte, la interface de Windows 7 o Windows 8 distintas a las anteriores. Tampoco lo es el hardware incompatible.

El principal problema que las empresas deberán enfrentar para un correcto despliegue de los nuevos sistemas operativos son las aplicaciones que corren en los puestos de trabajo.

Ya sean los desarrollados por terceros o los desarrollados internamente. Es aquí donde el gran problema persiste. No declarar la obsolescencia de los aplicativos provoca que realizar una migración ordenada no tenga lugar en las organizaciones grandes.

Muy pocas empresas grandes dieron el paso necesario algunos años antes del fin del soporte del sistema operativo. Estas son las que hoy están ejecutando otro tipo de proyectos de forma organizada y controlada.

El resto tendrá algunos meses duros por delante. Esperemos que el resto haya aprendido la lección.

Foto: Procrastination

Buscando revisores para libro sobre Windows 7 y 8

¿Cómo están? Les escribo para informarles que está terminado el segundo borrador de mi primer libro relacionado a la planificación de proyectos de migración a Windows 7 y Windows 8.

El mismo tiene un enfoque de planificación minimizando el detalle técnico. Es por esto que el libro está dirigido a quienes deban planificar o ejecutar un proyecto de migración de Windows en los puestos de trabajo de los usuarios finales.

Es una excelente lectura para quienes no tienen experiencia en la ejecución de este tipo de proyectos pero también para quienes tienen algo de experiencia y pueden complementarla con algunas ideas presentadas en el libro.

Está pensado para ser publicado en plataformas digitales (kindle, barnes & noble, kobo, etc.) por lo que no es un libro muy extenso (70 páginas de word o 120 en kindle) y no debería tomar mucho tiempo en su lectura.

El índice del libro es el siguiente:

  • Sobre el libro y el autor
  • Capítulo 1 – Escenario inicial – Objetivos
  • Capítulo 2 – ¿Cómo debe ser el equipo de trabajo?
  • Capitulo 3 – ¿Cómo debe ser el nuevo puesto de trabajo?
  • Capitulo 4 – Planificación de la migración
  • Capitulo 5 – Plan de pruebas
  • Capítulo 6 – Capacitación a usuarios finales
  • Capitulo 7 – Ejecución de la migración
  • Capítulo 8 – Inventario y tratamiento de hardware en desuso
  • Capitulo 9 – Oportunidades
  • Capitulo 10 – Ejecución por etapas
  • Apendice A – Documentos de proyecto
  • Comentarios finales y agradecimientos

Quienes deseen acceder a una copia de revisión antes de su publicación de forma completamente gratuita pueden hacerlo con las siguientes condiciones:

  • Enviar feedback sobre el libro. Será utilizado para realizar ajustes finales antes de su publicación oficial. Esto es obligatorio ya que la idea es poder mejorar mi trabajo antes de publicarlo.
  • Dejar una revisión sobre el libro en amazon. Esto es completamente opcional y en caso de hacerlo pido que la misma sea completamente honesta.

Si tienes tiempo y estás por iniciar un proyecto de migración a Windows 7 o Windows 8 puede ser una excelente oportunidad para obtener buenas ideas!.

Si estás interesado por favor completa los siguientes datos para ponerme en contacto y enviarte las instrucciones para acceder al borrador:

Importante! – El programa de revisión está cerrado. Completar el formulario agregará su lista de correo para recibir notificaciones sobre futuros programas de revisión de otros libros.


Recibe tu copia de revisión

* indicates required



Gracias por colaborar!