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?
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?
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.
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.
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.”
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.
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.
Utilización de recursos del Data Center
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.
Como pueden, ver la carga media de los recursos aumenta haciendo mucho más eficiente la utilización de los recursos adquiridos.
Sostenibilidad Ecológica
lunes, 26 de abril de 2010
Devops: cambiando el paradigma de desarrollo e implementación de software
La situación actual
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.
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.
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?
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.
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.
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:
Damon Edwards
Twitter: @damonedwards
John Allspaw
Twitter: @allspaw
Lindsay Holmwood
Twitter: @auxesis
Andrew Shafer
Twitter: @littleidea
Paul Nasrat
Twitter: @nasrat
Mick Pollard
Twitter: @_lunix_
Robert Dempsey Twitter: @rdempsey