jueves, 24 de junio de 2010

La nube en números


Ser consultor de negocio de transformación tecnológica te permite tener contacto con responsables de departamentos IT muy variopintos. Conoces y clasificas sus puntos de vista dependiendo si es consumidor o suplidor de recursos IT, o si sus intereses son adscritos al dominio de los Data Centers, a la funcionalidad de los aplicativos o a la operación del negocio. Los directivos europeos piensan diferente a los americanos. Sus opiniones discrepan si su misión dentro de la empresa es cambiar para integrar y estandarizar o si, por el contrario, es mantener el estatus quo de la independencia organizativa. Todos los directivos defienden sus puntos de vista con argumentos inteligentes, bien pensados y en un marco lingüístico que deja a la audiencia con pocos recursos para debatir. Todos, a la hora de tomar decisiones económicas, se ven afectados por la irracionalidad humana, que la economía conductual intenta explicar.
El método matemático, por el contrario, no admite la posibilidad de interpretación. Si las variables de entrada de una ecuación, ingresadas por un humano son correctas (pueden ser erróneas por omisión, desconocimiento o con intención) el resultado debería ser sin apelación. Los números claros no toman partido.
Joe Weinman, líder del desarrollo estratégico de la cartera de servicios y tecnologías emergentes de AT&T propone un análisis matemático que ha titulado “Mathematical Proof of the Inevitability of Cloud Computing” para estudiar las condiciones donde las capacidades dedicadas (recursos propios), las capacidades bajo demanda (nube pública) o un híbrido de las dos opciones tiene más sentido desde un punto de vista de costes. En el modelo matemático solo se toma en cuenta los costes de mantener las soluciones activas o BAU (Business As Usual), demanda media, demanda máxima, y tiempos. El modelo matemático no toma en cuenta riesgos financieros, limitándolo pero a la vez simplificándolo para mejor entendimiento.
Los principios del análisis son:
Suposiciones: 1) solo se paga por lo que se usa, de las capacidades bajo demanda, y no se paga por lo no usado. Así, se igualan a cero cualquier costo de membresía, depósitos no reembolsables o reservaciones. 2) Los costos para la capacidad bajo demanda no dependen del tiempo de petición o de uso, siendo el mismo coste un lunes por la mañana o un viernes por la tarde; o el coste de una hora al día o de una hora al mes. 3) El coste unitario de las capacidades dedicadas, o bajo demanda, no depende de la cantidad de recursos solicitados, eliminando la posibilidad de descuentos por volumen adquirido o por baja utilización de recursos. 4) No hay más costes relevantes para el análisis. Esta suposición es la más difícil de cumplir porque la mayoría de soluciones actuales requieren una integración a las plataformas de la nube o costes de las infraestructuras como alquiler de anchos de banda, etc. 5) El tiempo de servir una demanda de recursos es igual a cero; o lo que es igual, el proveedor de recursos IT, dedicados o bajo demanda, debe ser capaz de servir todas las solicitudes sin poder diferirlas en el tiempo (suposición muy poco realista sobre todo en el modelo de capacidades dedicadas).
Como ya hemos dicho en Blogs anteriores, la demanda está en función del tiempo.
D(t), 0<=t<=T
La función de la demanda puede ser caracterizada por una media µ(D) y un pico máximo max(D). Weinman llama A a la media de la demanda y P al pico máximo de la misma (uso la misma terminología de Weinman para simplificar). También definimos el coste unitario de la capacidades dedicadas como C, y U como la prima sobre el coste de las capacidades bajo demanda. El coste de las capacidades bajo demanda es igual a C*U. La prima U existe solo cuando se usan las capacidades bajo demanda. Cuando no se usan los recursos bajo demanda contamos con un descuento del 100%.
Si U < 1 y como A <= P, entonces:
A * U * C * T <= P * U * C * T < P * 1 * C * T = P * C * T
Significa que la solución de capacidades bajo demanda cuesta menos que una solución de capacidades dedicadas diseñadas para una demanda máxima (P).
Si U = 1 y suponemos una demanda plana en el tiempo, A = P, entonces:
A * U * C * T = P * U * C * T = P * 1 * C * T = P * C * T
Indicando que la solución de capacidades bajo demanda cuesta igual a una solución de capacidades dedicadas diseñadas para una demanda máxima (P). Como sabemos este escenario es prácticamente imposible porque implicaría ser capaces de pronosticar sin error la demanda de recursos a corto, medio y largo plazo.
Si U=1 y A < P, entonces:
A * U * C * T < P * U * C * T =P * 1 * C * T = P * C * T
Se demuestra lo económico de la solución de capacidades bajo demanda sobre la solución de capacidades dedicadas diseñada para una demanda máxima (P).
Si 1 < U < ( P / A ), entonces:
A * U * C * T < A * (P / A) * C * T = P * C * T
Esto demuestra que mientras la demanda sea abrupta en el tiempo (con máximos muy altos y mínimos muy bajos) sigue siendo más económica la solución bajo demanda mientras que la prima de la solución bajo demanda se mantenga entre 1 y la relación entre el máximo y la media. La lógica es muy clara. Si necesitamos un coche durante todos los días de un año, lo lógico es comprar el coche digamos a 10 euros el días. Si lo necesitamos por solo unos días al año, lo lógico sería alquilarlo aunque sea a una tasa de 50 euros al día. Si lo necesitamos por unos minutos lo mejor es tomar un taxi aunque nos cobren miles de euros por día.
Por temas de tiempo, y porque pueden seguir leyendo las explicaciones en el Blog de Weinman, no vamos a demostrar matemáticamente la conveniencia económica, bajo ciertas condiciones, de las soluciones híbridas.
Podemos debatir si las suposiciones son válidas, si los escenarios son realistas o demasiado simplistas, pero tienen que estar de acuerdo de que los números y la lógica aritmética empleada nos hace pensar sobre la importancia de las soluciones basadas en la nube como parte de las plataformas actuales.

miércoles, 9 de junio de 2010

¿Por qué Netflix usa los servicios de nube computacional de su competidor más cercano?



Netflix es una de esas compañías que han tenido tanto éxito con su modelo de negocio en sus 13 años de existencia que se estudia en muchos casos en las escuelas de negocio de todo el mundo. Aunque no vamos a ahondar mucho en el tema, Netflix saca provecho de la “Long Tail Economy” para obtener beneficios, catapultarse como una de las mejores empresas en el sector y acabar con la competencia.

Para los que no la conozcan, Netflix es una empresa dedicada a entregar contenidos audiovisuales, por streaming o por correo convencional (DVD y Blu-ray), a sus más de 13 millones de suscriptores en los EEUU. El streaming de películas puede ser descargado desde una PS3, Xbox 360, Wii, PC, Mac o IPad. Solo en el envío de DVDs y Blu-Rays Netflix supera los mil millones de entregas en sus 50 centros de distribución. Netflix ha llegado a exponer, de manera online, 12.000 contenidos concurrentemente. Su capitalización en el mercado de valores Nasdaq (NASDAQ:NFLX) es de aproximadamente $5.740 M. Actualmente Netflix compite cara a cara con Amazon por el dominio de la distribución de contenidos off-line y online en EEUU.

Uno de los grandes éxitos de Netflix ha sido adelantarse a otros grandes distribuidores de audiovisuales, como Blockbuster, ofreciendo la casi ilimitada visualización de películas online a un precio fijo mensual asequible. Hace unos meses atrás leí un artículo del New York Times donde especifica como Netflix tomaba la decisión de mudar sus servicios a la nube de su “archi-enemigo” Amazon para disfrutar de los beneficios de Cloud Computing.

¿Cómo es posible que Netflix tome esta decisión? ¿Se habrán vuelto locos los directivos de Netflix? De acuerdo a un blog de James Hamilton, Vicepresidente de Amazon Web Service, Netflix muda todos sus servicios a la nube por la infraestructura elástica, porque paga por lo usado, por su simplicidad de implementar y mantener, por la diversidad geográfica de los datacenters y por las mejoras en el servicio de aplicación. Pero ¿por qué elige a Amazon, su competidor directo? Por la gran escala de la solución de Amazon, por lo madurez de la solución y por la comunidad de desarrollo (más de 400,000).

Lo que más me llamo la atención del post es que Netflix muda sus servicios a la nube para mejorar la disponibilidad de su solución y por la simplicidad de las operaciones en la nube. Pero si a la mayoría de directores de IT españoles que les pregunta si confían en los proveedores de nubes me comentan que no. ¿Será que sus empresas tienen servicios más importantes y críticos que Netflix?

lunes, 10 de mayo de 2010

Exprimiendo las nubes

Todos sabemos los beneficios operacionales de la nube; es flexible, los tiempos de desarrollo e implementación de software e infraestructura se reducen sustancialmente, es ubícua, etc… Pero ¿cómo medir y traducir todos esos beneficios operacionales en beneficios financieros para el CFO de nuestra compañía?, es decir, ¿cómo crear ROI de las ventajas de la nube?

Mark Skilton, @mskilton, Director Global de Capgemini y miembro del Cloud Business Artifacts Projects del The Open Group ha propuesto un modelo que transforma la curva de capacidad y utilización de recursos en medidas directas e indirectas que benefician el ROI del negocio. Skilton ha definido seis KPIs en total, de las cuales, según mi opinión, las primeras cuatro métricas están muy bien definidas, pero las dos últimas pueden ser mejoradas.

El modelo tradicional que todavía siguen muchos departamentos de telecomunicaciones de grandes empresas, es el de adquirir recursos computacionales dependiendo de los pronósticos de consumo que se hacen al comienzo de cada período. Si sumamos que estas previsiones de recursos son imprecisas, a que por lo general los recursos son utilizados de acuerdo a la temporada y a la imposibilidad de obtener los recursos de forma inmediata, (lean mi antiguo post) el modelo tradicional resulta un despilfarro económico y de recursos inexplicable bajo el modelo de la nube computacional.


Skilton propone que se usen las siguientes métricas para explicar los beneficios económicos de la nube:

Aceleración en la reducción de costes

El modelo de la nube permite que los costos de infraestructuras pasen de ser CAPEX a OPEX ya que la compañía adquiere un servicio y no necesita hacer una inversión inicial.

Adicionalmente el tiempo de adopción, desarrollo, prueba, implementación o inhibición de la tecnología es mucho más rápido que el del modelo tradicional.

Optimización del uso de la inversión

Cuando un Project Manager o Arquitecto IT diseña una solución, por lo general, no piensa en los costos de mantenimiento de su diseño. Lo importante es el cumplimiento de los tiempos, presupuesto y objetivos del proyecto. Mantener la solución es problema del departamento de operaciones. Si los costos de soporte son altos entrarán en otra partida y no del proyecto inicial.

En los servicios de la nube, el mantenimiento de la infraestructura es invisible para el usuario. Si se tiene que instalar un parche de seguridad en el sistema operativo de los servidores, ni el usuario ni la compañía cliente se entera de lo ocurrido.

Desde el punto de vista del ROI, el beneficio viene de la optimización de los costes en los activos adquiridos.

Aprovisionamiento rápido

La posibilidad de tener recursos computacionales en horas en vez de en semanas puede tener efectos muy importantes en el ROI de un proyecto. Si la solución diseñada es implementada rápidamente, los costes de RRHH disminuyen sustancialmente, los beneficios económicos son materializados con anterioridad, etc.

Incremento de márgenes

La nube computacional puede generar más dinero o mejorar el uso de las inversiones realizadas para así mejorar el ROI. ¿Cuántos ejemplos hay de PyMEs que pueden entrar en nuevos mercados o expandir sus líneas de negocio existentes gracias al bajo CAPEX y escalabilidad de la nube? ¿Acaso una transnacional no puede beneficiarse de las mismas características?

Uso dinámico de los recursos

A mi parecer este es el punto más débil del documento. De acuerdo con Skilton:

The impact of dynamic provisioning on the Cloud Computing ROI business case is that the façade of service management becomes more “digital”.”


“El impacto que el aprovisionamiento dinámico de la nube tiene sobre el ROI del modelo está en que el perfil de la gestión del servicio es más digital.”

Muy bien, pero ¿cómo traducimos eso en métricas financieras?

Menores riesgos y mejor cumplimiento de normas

Otro KPI un poco dudoso, seguro que por eso Skilton lo dejó para el final, es el de menores riesgos y mejor cumplimiento de normas. Según Skilton, como la compañía no consume potencia eléctrica al no poseer un Data Center propio, es problema del proveedor hacer su negocio más verde. Al tener menor riego, el IRR del proyecto se reduce siendo más fácil obtener beneficios del proyecto. Uh, pero, ¿acaso Nike no tiene responsabilidad cuando sus proveedores de calzado contratan a menores de edad en el sureste asiático?

Yo no veo una verdadera mejora de riesgos en este tema. Cada día las compañías son más conscientes de su responsabilidad sobre las actividades de sus proveedores. Además el marco legal de muchos países prohíbe que datos sensibles sean transferidos fuera de las oficinas de la compañía. Algo que tiene que ser considerado y puede afectar los proyectos de la nube.

martes, 4 de mayo de 2010

La economía de escala de Cloud Computing

Hace unos días, tuve la oportunidad de ver en vídeo la conferencia realizada por James Hamilton, Vicepresidente de Amazon Web Services, durante el MIX10. Durante la conferencia habló sobre la economía de escala de las compañías proveedoras de nubes computacionales, explicó a grandes rasgos el modelo de negocio de Amazon como proveedor de Cloud Computing, dio sus razones de porque los Data Center en la nube son más sostenibles desde un punto de vista ecológico y expuso sobre temas operacionales y de eficiencia que tienen que tomar en cuenta los proveedores de servicios computacionales y diseñadores de Data Centers. Yo, por mi parte, quiero utilizar la información que Hamilton obtuvo para resaltar los aspectos económicos y estratégicos más interesantes desde un punto de vista de negocio.

Según datos obtenidos por Hamilton en 2006, un poco antiguos a decir verdad, los grandes proveedores de servicios de Cloud Computing tienen costos inferiores a las PyMEs a la hora de construir sus Data Center. Bueno, dirán ustedes, pero eso no es algo difícil de imaginar, y tienen razón. Es fácil suponer que los proveedores de las compañías que proporcionan Cloud Computing, ofrecen grandes descuentos a sus clientes por los mega volúmenes de productos y servicios que consumen. Lo que me sorprendió es el rango de diferencia que existe entre las dos. En la gráfica anexa más abajo podrán ver la diferencia entre ambos costos.


La discrepancia de costos pueden llegar a significar factores de x7 en costos de networking, x6 en costos de almacenamiento y en casi x10 en costos de personal de administración. La gran eficiencia en recursos humanos conseguida por los proveedores de nubes se debe a la alta automatización de procesos de gestión de sus equipos. Automatización necesaria para gestionar miles de servidores a la vez. Como discutimos anteriormente, la diferencia de costos de almacenamiento y networking se deben a los descuentos que reciben los proveedores de nube por comprar grandes volúmenes.

La divergencia en los costos entre proveedores de nubes y PyMEs, hace posible que compañías como Amazon puedan ofrecer servicios de Data Center virtuales a sus clientes con descuentos y seguir siendo rentables.

Utilización de recursos del Data Center

Cualquier ingeniero de infraestructuras sabe de la infrautilización de los servidores de un Data Center. En mis tiempos de administrador de sistemas no era difícil encontrar servidores ocioso, con cargas de CPU inferior a 10% o hasta de 5%, durante la mayoría del tiempo. Por lo general, estos servidores soportaban aplicaciones que usaban los recursos computacionales según la temporada del año. Por ejemplo, siempre teníamos que vigilar los CPU de los servidores que soportaban las transacciones SAP en los cierres de periodo, cuando mis compañeros accedían a la aplicación y comenzaban a realizar los cálculos necesarios para obtener la información financiera requerida. La carga de los recursos de un servidor seria algo como lo que represento en la gráfica inferior.

Económicamente hablando, es una pérdida de recursos. Hemos comprado un servidor con una capacidad x, para amortizarlo durante tres años y solo usamos toda su capacidad 4 días al mes. Esto no es muy eficiente financieramente hablando.

Lo que hacen los proveedores de nubes es utilizar la virtualización de servidores y/o crear diferentes estancias de software (multitenancy) dentro del mismo hardware para ofrecer las prestaciones sobrantes a compañías con necesidades de cargas no correlacionadas, optimizando la utilización de sus recursos. Gráficamente seria:

Como pueden, ver la carga media de los recursos aumenta haciendo mucho más eficiente la utilización de los recursos adquiridos.

Ahora, ¿acaso las PyMEs no pueden virtualizar sus recursos computacionales y disfrutar de mejores cargas medias?. Pues si, si pueden, pero no al mismo nivelde un proveedor de nube. Las compañías medias tienen equipos inventariados por si le surge necesidades inmediatas y porque los proveedores de equipos no pueden entregar servidores en un plazo corto (por lo general de 4 a 6 semanas en España). Invierten capital en equipos ociosos y apagados por si a acaso son requeridos. El negocio de un proveedor de nube es vender recursos computacionales, por tanto lo mejor que puede hacer es encender y utilizar todos y cada uno de sus servidores.

¿Cómo hacen los proveedores de nube para saber cual es la correlación en la utilización de recursos demandados por sus clientes? Pienso que no lo saben. Proveen servicios con el hardware instalado hasta que la carga media llega a un límite superior y luego tiran de otro hardware.

Sostenibilidad Ecológica

Hamilton sostiene que los proveedores de nube son más eficientes en el consumo eléctrico de sus Data Center que una compañía media. Los grandes proveedores de nubes no solo diseñan sus Data Center para reducir costos, también tienen la oportunidad de involucrarse en el diseño de los servidores para reducir consumos y perdidas eléctricas innecesarias.

De acuerdo con Hamilton un Data Center bien diseñado tiene un PUE de 1,7, un Data Center excelente 1,5, pero normalmente los Data Centers tienen un PUE de 2. Esto quiere decir que en un Data Center medio, de cada 2W de potencia eléctrica suministrados, 1W llega a los servidores. El resto se disipa en perdidas o se consume en otras cargas no prioritarias.

Ahora bien una empresa tiene que ser eficiente a la hora de consumir energía por varias razones. La primera es el costo de la factura eléctrica. La segunda puede ser por razones estratégicas que no involucren el mercado, como la mala publicidad, presiones sociales, legislación local, ONG, etc. ¿Cuál es el PUE de vuestros Data Center?¿Cuál es el PUE de los Data Centers de vuestro proveedor de nube? O como Greenpeace denuncia en su articulo Make IT Green, ¿Cuáles son las fuentes energéticas de vuestros Data Center o de sus proveedores?

lunes, 26 de abril de 2010

Devops: cambiando el paradigma de desarrollo e implementación de software

La situación actual

Los modelos de gestión de desarrollo de aplicaciones que disponemos actualmente son inmanejables. Si alguna vez han tenido la posibilidad de trabajar en ambientes de desarrollo de aplicaciones, sabrán que los desarrolladores codifican su software esforzándose en satisfacer las necesidades del negocio y de los clientes de acuerdo a las especificaciones que le transmiten los analistas de negocio o managers en general. Por otra parte, el personal operativo tiene como objetivo principal garantizar la disponibilidad del servicio del cual dependen los ingresos de la compañía. Ambos grupos tienen objetivos diferentes, y podría decirse que hasta contradictorios. Los desarrolladores quieren mantener el software al día introduciendo cambios a la solución mientras que el personal operativo solo le interesa la estabilidad de la plataforma para que la aplicación funcione correctamente. Cuando los desarrolladores entregan su nuevo software a los operadores para comenzar el ciclo productivo de la aplicación, la trama esta servida. Si han tenido la fortuna de trabajar en desarrollo de software como yo, seguro que han escuchado frases como: “El nuevo parche no se ejecuta en nuestra plataforma”, “En el laboratorio de desarrollo la nueva aplicación funciona de maravilla”, “Esta nueva funcionalidad no puede ser instalada porque otro desarrollo activo lo impide”, “Porque vosotros, operadores, no mantienen el hardware al día”, “esta aplicación es un desastre y no hay servidor que la pueda soportar”, etc.

Tal como lo veo, los problemas se pueden resumir en los siguientes puntos:

Miedo al cambio

Cuando trabajé en un grupo de desarrolladores, temíamos que la plataforma fuese inestable y nos cohibíamos en cambiar la solución. Desconfiamos, y muchas veces con razón, de los desarrolladores y de sus desarrollos. Como tenemos miedo al cambio, recurrimos a procesos burocráticos para controlar y gestionarlos excesivamente rígidos. ¿Quién no ha sufrido durante una semana, o incluso más, para que el comité de cambios ITIL se reúna y discuta la vialidad de los cambios propuestos por los técnicos?

Inseguridad sobre los desarrollos creados

Nadie tiene garantías de que el nuevo código o sistema desarrollado funcione como lo esperamos en la plataforma productiva. ¿El servidor será capaz de soportar la carga actual del servicio? ¿Habrá algún código oculto que no valide la solución? Muchas veces no tenemos la respuesta a estas preguntas y nos empeñamos en seguir con la implementación.

Aislamiento

Los desarrolladores, una vez entregan su software a los operadores, se desentienden completamente de su implementación. Solo actúan si el problema es muy grave y apremiante. Por otro lado los operadores no involucran a los desarrolladores en sus decisiones sobre la plataforma, lo que hace que los desarrolladores pierdan contacto con la realidad de la plataforma productiva. Este comportamiento genera silos de conocimiento que no ayudan al desarrollo e implantación de las nuevas soluciones.

Que es Devops?

La palabra Devops, proviene de la unión de dos palabras anglosajonas “Developer” y “Operations”. Devops es un movimiento reciente (2009), tan reciente que no hay una entrada en Wikipedia sobre el mismo. Devops plantea solucionar los problemas a que nos enfrentamos constantemente en los ambientes de desarrollo y operación. Devops es un concepto paraguas que involucra cualquier intención de mejorar los procesos actuales de desarrollo de software, facilitando las interacciones entre desarrollo y operaciones. Es una propuesta bottom-up (las mejores que existen) de experimentados administradores de sistemas que saben que los desarrolladores, testers, managers, técnicos de redes y administradores de sistemas son parte de un equipo con un solo objetivo: proporcionar a los clientes un software competitivo, seguro y de gran calidad. Devops quiere ser el nuevo paradigma de desarrollo de aplicaciones cambiando el modelo actual, reactivo, centrado en procesos operacionales (ITIL es uno de ellos) a un nuevo modelo ágil y automatizado. Devops quiere alinear los objetivos de los desarrolladores y operadores para que ambos trabajen como equipo quitando barreras y alentando la comunicación.

Que tiene que ver Devops con la nube?

Como ya saben, en la nube la aplicación es rey. En el pasado, la unidad de despliegue en el Data Center era el servidor, con un OS especifico para una o varias aplicaciones, se conectaba a la red y se le asignaba una dirección IP. Antes la aplicación era secundaria. Ahora, y gracias a la virtualización, se crean servidores específicos para cada aplicación. Que importa si el sistema operativo es Linux o Windows, si puedo virtualizar servidores sobre el hardware que cumplan los requisitos de la aplicación.

Si la virtualización permite desarrollar servidores a la medida del software ¿no deberían los desarrolladores definir especificaciones para las maquinas donde se ejecutará el software? Es más, ¿estas especificaciones no podrían definirse de manera semiautomática y enviarlas instantáneamente al proveedor de nubes? ¿Acaso todo esto no implica una revolución en los perfiles del personal técnico de las compañías o de sus procesos de desarrollo de software?

Beneficios e inconvenientes que el nuevo paradigma traerá a los negocios

Los negocios se beneficiarán de Devops porque la nueva filosofía de desarrollo asiste a dos de las cualidades estratégicas más poderosas y deseadas por los negocios. La agilidad de negocio y el alineamiento IT. Devops alinea los objetivos del personal de desarrollo y operaciones con los objetivos del negocio. Las empresas se beneficiarán de esta nueva filosofía porque los equipos de desarrollo y operaciones estarán involucrados y facultados para obtener los mismos objetivos de la compañía.

Pero, ¿Cómo gestionar esta nueva filosofía de desarrollo? ¿Hay alguna metodología ya definida? El movimiento es muy reciente para tener parámetros bien definidos. Existen herramientas de gestión que ayudan a los managers y desarrolladores a la hora de agilizar el desarrollo. La familia de metodologías de desarrollo ágil de software ha intentado vencer la resistencia y burocracia de otros métodos, es más, la popularización de la misma es uno de los catalizadores que han hecho germinar el movimiento Devops. Lo que hace falta a esta metodología es saltar la brecha entre desarrollo y operaciones. El post de Robert Dempsey, uno de los padres del movimiento Devops, expresa exactamente esta idea. Aplicar este nuevo modelo significa cambiar la cultura y sistema de compensación de una empresa. Tarea que nunca es fácil pero necesaria si quiere beneficiarse del nuevo método de desarrollo e implementación.

Siendo manager o director ¿Cómo puedo comenzar a utilizar esta metodología?

Como manager de empresa IT, un primer paso, podría ser solicitar Devops, en vez de desarrolladores o administradores de sistemas. Este cambio de búsqueda deja claro que quieres gente comprometida con los objetivos de la empresa, capaces de ejercer múltiples funciones y la empresa es capaz de instruir a los empleados si requieren de alguna habilidad. Este primer paso puede ser el detonante del cambio de cultura de tu empresa IT. Un manager también debe de tomar en consideración qué cambios realizar en los parámetros de medición del performance de cada miembro del equipo. Lo que se cuantifica, influye e incentiva las conductas de los empleados. Comunica a los empleados qué parte fundamentan cumplen dentro del proceso de la empresa. El éxito de los individuos y grupos debe de ser medido de acuerdo al éxito de todo el ciclo de proceso e implementación.

Otro paso importante es unificar y automatizar los procesos. El método Devops analiza todo el ciclo desarrollo/implementación como uno solo. Procesos individuales pueden ser usados en cada fase, como desarrollo ágil de software en la fase de codificación o Visible Ops en la fase de operaciones, pero de manera que los dos procesos individuales puedan ser gestionado como uno solo.

Herramientas de control de versiones de software que permita compartir, documentar y mantener al día los desarrollos ya son disponibles y conocidas por todos; solo hace falta cambiar la mentalidad y permitir que todos los miembros involucrados en el ciclo de desarrollo y operación puedan leer y cambiar elementos si es necesario y de acuerdo a políticas de acceso. Actualmente existen grupos de trabajos creando herramientas que sirven para el desarrollo y operación de aplicaciones de forma unificada. Puppet, Chef o Cucumber Nagios son algunas de ellas. Frases como infraestructuras como código, modelos impulsados por automatización e implementación continua serán escuchadas dentro de poco en la jerga de los Devops.

Fuentes

Si desean saber más del movimiento Devops les aconsejo que accedan a los blogs, páginas web de los Devops, pero si desean estar al tanto de todo lo que pasa en el mundo Devops sigan a los gurús del tema en Twitter. Para finalizar les dejo una lista de fuentes:

DevopDays

http://www.devopsdays.org/

Patrick Debois Twitter: @patrickdebois

Damon EdwardsTwitter: @damonedwards

John AllspawTwitter: @allspaw

Lindsay HolmwoodTwitter: @auxesis

Andrew ShaferTwitter: @littleidea

Paul NasratTwitter: @nasrat

Mick PollardTwitter: @_lunix_

Robert Dempsey Twitter: @rdempsey

lunes, 19 de abril de 2010

El negocio y la nube


La nube ha revolucionado el mundo de las telecomunicaciones. La invención de la nube posiblemente es uno de los mayores avances en la historia de la computación. La idea general de Cloud Computing es conocida por un gran número de profesionales del negocio de los sistemas de información pero desconocen las implicaciones técnicas y económicas que la nube puede tener en sus negocios. Antes de plantearse el cambio de paradigma hay que entender las implicaciones del cambio y los beneficios/riesgos del nuevo modelo. Mientras que las tecnologías mejoran constantemente gracias a las grande inversiones en investigación y desarrollo, no se invierte lo suficiente en entender las implicaciones que Cloud Computing tiene en los negocios. El documento titulado Cloud Computing – The Business Perspective provee de un análisis SWOT de la industria de la nube que quisiera compartir con ustedes. En el documento, el Doctor S. Bandyopadhyay identifica algunos de los inconvenientes que pueden afectar a los usuarios de la nube y también realiza recomendaciones para los gestores de nubes.
El National Institut of Standards and Technology (NIST) ofrece una definición de Cloud Computing muy completa . De acuerdo con dicho instituto, Cloud Computing es un modelo de servicio IT que permite acceder, por medio de Internet, bajo demanda a un conjunto de recursos compartidos (redes, servidores, espacio de disco, aplicaciones y servicios) con poco esfuerzo o interacción con el proveedor. La definición del NIST también describe unas características esenciales, modelos de servicio y de despliegue de Cloud Computing.
Muchos gestores de TI no quieren implementar una nube porque les preocupa la falta de control directa sobre la infraestructura, o peor aun sobre la información soportada en la misma. Pero no solo este problema les genera ansiedad; la posibilidad de que los proveedores de Cloud Computing se encasillen en una tecnología propietaria que no permita migrar o cambiar de proveedor, la falta de QoS y disponibilidad garantizados y la posibilidad de un corte de servicio o perdida de datos por razones de malfuncionamiento, desastres naturales, o incluso ataques terroristas en las instalaciones del proveedor son las peores pesadillas de los agentes del sector empresarial.

Pero la nube no es tan negra como los directores temen. Cloud Computing ofrece una gran cantidad de beneficios como es la ubicuidad de los recursos, la indudable reducción de CAPEX en plataformas IT/IS, la reducción de barreras técnicas y económicas para Pymes, el incremento de la escalabilidad de las plataformas IT/IS, y la creación de nuevos servicios y aplicaciones que antes de la nube no eran posibles (como lo pueden ser Facebook, Dropbox, Gmail, Mint, etc).


Análisis SWOT

Fortalezas
• La nube permite de forma casi instantánea y bajo demanda escalar recursos computacionales. En industrias con requerimientos temporales esta ventaja puede ser invaluable.
• Actualmente las capacidades de los servidores y demás elementos TI están infrautilizados, lo que hace difícil justificar financieramente la adquisición de nuevo hardware. Cloud Computing ofrece una alternativa real a este problema.
• La posibilidad de pre-configurar servidores y maquinas virtuales según las políticas de TI de la empresa reducen los costos de gestión TI significantemente.

Debilidades
• La falta de garantías de QoS y disponibilidad genera desconfianza a la hora de migrar aplicaciones criticas a la nube. 99,95% de disponibilidad al año puede no ser suficiente para las aplicaciones ERP de McDonalds.

Oportunidades
• Cloud Computing puede ayudar a los países en vías de desarrollo a disfrutar los beneficios de las tecnologías de información.
• Las Pymes pueden beneficiarse de aplicaciones como ERP y CRM que de otra manera no podrían acceder por costes o inexperiencia técnica.
• La oportunidad de crear y configurar nuevas Mashups es inigualable.

Amenazas
• Aunque el articulo del Doctor S. Bandyopadhyay describe como oportunidad la reducción de CO2 gracias a los servicios de la nube, Greenpeace ha publicado un articulo titulado Make IT Green: Cloud computing and its contribution to climate change que critica el excesivo uso de energías no renovables en los Data Centers. Considero que la critica de una ONG de gran visibilidad, como Greenpeace, es una amenaza para las compañías que quieran utilizar el modelo de tecnología de información propuesto por la nube.
• Existe el riesgo, de que compañías incumbentes no permitan el desarrollo de la nueva tecnología disruptiva. Esta demostrado que la gente se resiste al cambio, y para bien o para mal los departamentos de TI de las empresas pueden tener reticencias a la hora de implementar la nube dentro de sus soluciones.
• La falta de estándares de la nube a forzado a la ISO crear el subcomité de Servicios y Plataformas de Aplicaciones Distribuidas (DAPS de sus siglas en inglés) . Existen un gran número de organizaciones privadas que buscan armonizar las soluciones de Cloud Computing pero el riesgo es cierto y persistente.
• La legislación vigente puede complicar la implementación de la nube. Leyes como la famosa Sarbanes-Oxley exige que datos sensibles sean físicamente accesibles puede implicar que un negocio falle a la hora de pasar una auditoria si tienen sus datos en la nube.

Recomendaciones
Quisiera terminar mi post con algunas de las recomendaciones para los negocios que quieran implementar las soluciones de la nube:
1. Elegir que aplicaciones pueden ser migradas a la nube. Aplicaciones de colaboración y ofimática son candidatas perfectas para penetrar la nube primero. Cuidado con aplicaciones legacy, aplicaciones desarrolladas in-house o alguna aplicación de terceros que puedan complicar su implementación en la nube.
2. Es fácil entender porque las Pymes deben comenzar a desplegar sus soluciones en la red. Los beneficios económicos y técnicos son muchos para resistir el cambio. A la hora de hablar de grandes empresas la recomendación no es tan sencilla. Si quieres que tu empresa mueva servicios a la nube ten en cuenta las implicaciones de los SLAs.
3. Los proveedores de nubes deben de considerar las necesidades e intereses de sus clientes en vez de desarrollar aplicaciones porque si.
4. Los proveedores de nubes deben de seguir invirtiendo tiempo y dinero para promover la interoperabilidad de sus propuestas. Los clientes de las nubes quieren saber que van poder migrar sus servicios en cualquier momento y con las más altas garantías de éxito.