Conceptos sobre Cloud Computing

El Cloud Computing tiene como objetivo la oferta de recursos y servicios - de negocios y de tecnología - en ambientes escalables, adaptables y flexibles. Es decir, "la Nube" sostiene la idea de que el almacenamiento y la administración de la información se manejen sobre Internet aprovechando la oportunidad de tener redes de servidores, centros de datos, servicios, etc. diseminados en la enorme extensión de la web.

A quiénes está dirigido?

Este modelo de prestación de servicios y tecnología ofrece una variedad tan amplia de productos y aplicaciones que puede ser usado tanto por grandes corporaciones, pequeñas y medianas empresas, instituciones educativas, entre otros, e incluso particulares.

Con esto se apunta a que cualquier tipo de usuario tenga acceso a una serie de servicios estandarizados para utilizar según sus necesidades, en forma totalmente flexible y pagando sólo por el consumo efectuado, ahorrando además en los costos de equipos, mantenimiento, actualización de los mismos, personal que los administre, licencias, espacio físico, etc..

De qué se trata

El modelo de Cloud Computing se afirma sobre 3 patas:

1. Software - Software as a Service (SaaS): la Nube ofrece una serie de aplicaciones del tipo "Software como Servicio" que los usuarios pueden consumir a través de Internet. Este concepto existe desde hace tiempo y se trata de cualquier servicio que se base en la web, como podría ser el webmail de Gmail o los típicos CRM, por ejemplo. En este caso el usuario consume los servicios que necesita y es el proveedor el encargado del desarrollo y mantenimiento. El cliente puede decidir en todo momento qué aplicaciones usar y qué tipo de servicio contratar. Algunos servicios pueden ser gratuitos (esto depende del proveedor) pero en el caso de aplicaciones pagas, el costo varía según el tiempo de uso, volumen de información, usuarios, tipo de servicio, etc..
2. Plataforma - Platform as a Service (PaaS): algunos describen a la "Plataforma como Servicio" como un modelo donde están dadas todas las condiciones que necesitan los desarrolladores para la construcción integral - testing, almacenamiento de datos y documentación, administración de versiones, backups, etc.- e instalación de sus aplicaciones o servicios web. Es decir, todas las herramientas necesarias para el desarrollo de software se encuentran alojadas en la web y el desarrollador accede a las mismas desde cualquier browser. Un ejemplo claro de PaaS puede ser el Google App Engine.
3. Infraestructura - Infraestructure as a Service (IaaS): la infraestructura como servicio se refiere a una forma de distribución del equipamiento pensada como servicio. O sea, existen proveedores de equipamiento en la Nube que prestan servicios de hardware o infraestructura, en general, en base a plataformas de virtualización. Cualquier usuario puede "alquilar" los servicios de CPU, RAM, Sistema Operativo, redes, Firewall y todo lo que necesite que mejor se adapte a sus necesidades en cada momento. El dueño de esa infraestructura es el proveedor de dicho servicio y él se encarga del mantenimiento, administración y buen funcionamiento de lo que ofrece.

Buenas y Malas

Dos de los principales beneficios del Cloud Computing son, sin duda alguna, la simplicidad y la baja inversión requerida para comenzar a trabajar. Y podemos también enumerar estas otras ventajas:

• Rápida implementación, en general los tiempos para empezar a usar cualquier servicio que se contrate son muy cortos
• Actualizaciones automáticas e independientes de los recursos propios, a cargo de los proveedores de los servicios. 
• Fácil integración con otro tipo de aplicaciones
• Menor riesgo ante "caídas" de los servicios
• Movilidad, por la posibilidad de acceder a los servicios desde cualquier punto y en cualquier momento
• Adaptable a necesidades estacionales de los distintos negocios
• Uso eficiente de la energía, que permite, por un lado, bajar costos que requiere el funcionamiento de una infraestrucutra propia, y por otro lado, reducir el desperdicio de la energía al contar con sistemas centralizados 

(Imagen tomada de http://www.zdnet.com/blog/hinchcliffe/eight-ways-that-cloud-computing-will-change-business/488)

Ahora bien, a pesar de los muchos beneficios que nos muestra este modelo no son pocos los que ponen el ojo en las desventajas y riesgos que puede acarrear:

• La disponibilidad y estabilidad del acceso a Internet sigue siendo un problema en algunas zonas
• Existe un riesgo de vulnerabilidad de la información al "sacarla" de las instalaciones propias y "entregarla" al proveedor elegido
• Los niveles de seguridad crecientes que deben implementarse pueden afectar la velocidad de respuesta a los requerimientos
• Asi como los proveedores de los servicios son los responsables de su mantenimiento y mejora continua, los usuarios de los mismos dependen absolutamente de ellos sin poder hacer nada en caso de interrupciones imprevistas de las prestaciones contratadas
• Muchos dudan sobre cómo afectará a la efectividad de los servicios expuestos el aumento de la cantidad de usuarios y el tráfico creciente
• Y el punto más debatido respecto del modelo de la Nube reside en la seguridad de la información. Hay quienes incluso recomiendan no confiar los datos más sensibles al universo del Cloud.

Aún así y dada la flexibilidad de esta plataforma siempre existe la opción de llevar un esquema mixto de trabajo entre cosas que pueden consumirse desde la nube sin mucho riesgo y otras - las más críticas - que puedan mantenerse en las propias instalaciones.

Artículos para recomendar:

Eight ways that cloud computing will change business

Cloud Computing (IV): Plataforma como servicio (PaaS)

Qué es SaaS 

Cloud Computing (III): Software como Servicio (SaaS)
Google ya encripta toda la informacion de cloud storage con AES de128 bits 

Twittear Seguir a @3p_ar

Leer más...

Por qué estimar con puntos y no con horas?

Cuando comenzamos a introducirnos en la práctica de Scrum muchos nos preguntamos por qué es mejor hacer las estimaciones basadas en puntos que hacerlas basadas en horas. No existe acaso una relación directa entre ambas medidas?


La gran mayoría de los expertos en el tema coinciden en que la respuesta a la segunda pregunta es NO.

Los puntos en Scrum son un reflejo del riesgo y la complejidad que cada miembro del equipo puede percibir sobre una historia, mientras que las horas asignadas a esa misma historia son una estimación absoluta, basada en forma casi exclusiva, en la experiencia previa.

La estimación con puntos es lo que usualmente se denomina "estimación relativa" y tiene como principal objetivo el agrupar cosas de similar medida en vez de darles a cada una una magnitud categórica y terminante.

Una de las ventajas de dimensionar las historias a través de puntaje es que nos permite mirarlas desde 3 ángulos distintos:

• complejidad
• esfuerzo
• duda - representada por las cosas que no sabemos si van a poder ser hechas o que no sabemos cómo van a ser encaradas porque incluyen factores con cierto grado de incertidumbre -

El medir una historia con puntos permite encarar un aspecto diferente de la estimación: cuando preguntamos "cuántas horas va a llevar una historia?" el número dado como respuesta está pensado, en la gran mayoría de los casos, sólo según la experiencia anterior. En cambio, el pensar una medida en puntos permite relativizar los 3 aspectos mencionados antes y compararlos contra las estimaciones hechas para otras historias dando la posibilidad de ajustar y afinar dichas estimaciones a cada paso. Estos ajustes son normales cuando recién comenzamos a usar esta forma de "medir".

Otro aspecto positivo es que esta técnica permite a todo el equipo estar involucrado. La decisión de qué valor darle a una tarea ya no depende exclusivamente de quien va a desarrollarla sino que todos los participantes deben aportar su punto de vista respecto de los 3 aspectos enumerados. Las distintas visiones  al estimar una historia permiten a los miembros entender cuestiones que podrían no ser tenidas en cuenta en forma individual.

Algunos opinan además que las estimaciones por puntos no llevan la "carga psicologica" que tiene la estimación por horas, con el impacto negativo que puede llegar a provocar en alguien que excede el tiempo previamente estimado para terminar una tarea.

Una forma sencilla de comenzar a pensar en puntos

Planning Poker cards

La forma de estimar es uno de los cambios más grandes al que tenemos que hacer frente cuando empezamos con la práctica de Scrum y puede ser muy frustrante no encontrar la manera de hacer ese "click" de dejar de pensar en "tiempo" para pasar a pensar en "puntaje".  Cuando comenzamos a implementar esta técnica en Tercer Planeta, alguien nos recomendó arrancar con estos pasos, y realmente nos fue muy útil:

1. Elegir un par de historias de nivel medio en complejidad, historias "conocidas" o "repetidas" en cualquier tipo de aplicación.
2. Asignarles puntos de las cartas (la serie de Fibonacci reflejada en las cartas de Planning Poker)
3. Estas historias elegidas pasan a ser entonces "historias de referencia" para puntuar el resto de las historias
4. Luego, asignar puntos al resto de las historias, basándonos en puntajes relativos a los puntos asignados a las "historias de referencia": las historias que parezcan más complejas o más grandes que las de referencia recibirán puntajes más altos.

Al final de la estimación se suman los puntos de las historias para tener una dimensión total del sprint. Después de completar un par de sprints se podrá tener una idea más certera de cuántos puntos puede hacer el equipo en cada iteración, lo que determina la "velocidad" de ese equipo.

A partir de esto las estimaciones por puntos se harán cada vez más naturales y se irá mejorando la técnica hasta llegar a dejar de pensar en el reloj al momento de medir las entregas en cada intervalo.


Para leer más:
Story points vs. development hours
Sobre Ratas, elefantes y timeboxing


Twittear Seguir a @3p_ar

Leer más...