Archivos para 23 marzo 2011

La seguridad en la Computación en la Nube

He oído que uno de los tópicos más recurrentes cuando se habla sobre el “Cloud Computing” es el tema de la seguridad. Se dice que las aplicaciones en la Nube son más riesgosas y susceptibles de ataques informáticos de diversos tipos. Además se tiene la impresión de que al estar hospedadas en servidores externos a la empresa, los datos corren más riesgos de ser perdidos o robados; y que, por ende, una Nube privada es más recomendable que las aplicaciones en la Nube Pública. Todo esto me recuerda los albores de Internet cuando se decía que pagar con tarjeta de crédito en Internet era un riesgo mayúsculo y sin embargo el porcentaje de robos o fraudes de información al pagar en línea con tarjeta, en el peor de los casos, no son mayores que los realizados fuera de línea.

No me malinterpreten. No digo que no debamos tener cuidado. Debemos tener mucho cuidado de dónde comprar en Internet de la misma manera que una empresa debe tener cuidado de qué proveedores de aplicaciones Software-as-a-Service contrata. Pero una vez salvado este punto yo me atrevo a decir que los riesgos son menores a los riesgos que tradicionalmente se tienen con las aplicaciones instaladas “in-house” de la misma manera que nuestra tarjeta no corre más riesgos al pagar en línea de los que tomamos al pagar con ella en un restaurant.

Yo creo que el problema es de percepción. Se tiene la percepción de que al no tener el control de la infraestructura de nuestra aplicación (Hardware y Software), esta corre más riesgos. Nos sentimos más seguros de poder “ver y tocar” los equipos o las aplicaciones en cualquier momento. Es decir, caminar hacia el cuarto de hardware y entonces ver que están ahí y revisar en el equipo mismo que los procesos de las aplicaciones están ejecutándose adecuadamente; como si el hecho de poder ver los equipos pudiera, por arte de magia, crear mecanismos más seguros en nuestra infraestructura. En síntesis, queremos tener el control total de ello.

Pienso que este es un punto de vista un poco inocente. En realidad, con los servicios en la Nube de hoy día (de Infraestructura -IaaS- , Plataformas -PaaS- y Aplicaciones -SaaS- ) es difícil que nuestro departamento de TI llegue a tener el grado de especialización y la tecnología de avanzada (state-of-the-art) que estos servicios tienen (salvo quizá para algunas grandes empresas que sí cuentan con recursos para lograrlo). Me refiero, por ejemplo, a servicios de respaldo de datos, seguridad de los equipos, confidencialidad, datacenters, personal especializado, y hoy día hasta seguridad de las redes con tecnologías como la de VPN. Los Service Level Agreement (SLA), ó Acuerdos de Nivel de Servicios, son muy ventajosos para las empresas clientes; se ofrece mantener sus activos funcionando 365x24x7, nivel de servicio que sería difícil igualar por un departamento interno.

Realmente el tema de la seguridad se relaciona más con el diseño de toda la Arquitectura de nuestras soluciones informáticas y todos los elementos relacionadas (redes, equipos, aplicaciones de negocio, middleware, etc.). La seguridad no mejora si usamos una Nube privada por sobre la Nube pública sino que la seguridad únicamente mejora si nuestra arquitectura (ya sea pública o privada) está mejor diseñada e implementada. Y me atrevo a decir que en una gran mayoría de casos, la nube pública será más segura que la privada para desplegar soluciones de Cloud Computing.

Lo anterior se vuelve aún más crítico cuando aunamos dos elementos más: el hecho de que normalmente será mucho más barato el contratar servicios bajo demanda en la Nube pública (infraestructura, plataformas de desarrollo, aplicaciones de negocio, etc.) que comprar equipos o licencias de software, y además asignar a nuestro personal (o subcontratar) para desarrollar y mantener nuestra propia nube privada. Es decir, el factor económico es un factor adicional a favor de la Nube pública. Y finalmente, la Nube pública nos pone en contacto directo para poder aprovechar un enorme gama de recursos (servicios, software, herramientas, APIs, etc.) que son accedidos únicamente desde una plataforma de Nube pública. Hoy día prácticamente todo se accesa vía REST APIs y las aplicaciones de negocios interactúan “fácilmente” unas con otras en la Nube.

En fin, yo recomiendo olvidarnos un poco de nuestros prejuicios de no tener el control, y de querer “ver y sentir” en nuestra propias instalaciones a nuestros activos de TI, para, en cambio, iniciar un proceso de experimentación y exploración de los servicios de la Nube pública y aplicaciones Software-as-a-Service (SaaS) en ella. De hecho, un buen servicio de Nube pública en ocasiones provee mecanismos de control y monitoreo mucho más sofisticados de los que internamente podríamos mantener. Pienso que el tiempo, como en el caso de los pagos con tarjeta, acabará por darnos la razón.

, , , , , ,

Deja un comentario

Monetización en aplicaciones para móviles

En un anterior post intenté definir, de manera muy breve e introductoria, a qué me estoy refiriendo cuando hablo de aplicaciones para móviles (o celulares). Al final, comentaba que me parecía importante distinguirlas de las aplicaciones Web accedidas vía móviles debido a que el modelo de ingresos (o modelo de entrega del servicio) así como la tecnología subyacente podrían ser distintos.Monetizacion de aplicaciones para moviles

Entonces, voy a comentar un poco sobre el modelo de ingresos, también llamado el modelo de monetización. Es decir, la manera en cómo se accede a la aplicación y cómo se usa esta; y de acuerdo a ello, cómo podría el creador obtener un beneficio económico de ella. Cabe aclarar que una Mobile App no necesariamente siempre tiene la intención de sacar un beneficio económico. Tal es el caso de las mobile apps empresariales construidas internamente dentro de la organización (o externamente, pero para la organización) para apoyar las operaciones de la empresa. En este caso el beneficio es para la empresa que creó, o que contrató el desarrollo de, la mobile app.

Sin embargo, voy a centrarme en el caso de que el creador o empresa proveedora de la aplicación sí intenta obtener ganancias de su desarrollo. Quizá lo más importante de mencionar es que cuando una empresa desarrolladora crea una aplicación móvil su éxito depende básicamente de su uso masivo ya que su precio es bastante bajo. Sólo un uso masivo podría justificar la inversión en desarrollo de una mobile app.

Los modelos de ingresos básicos (no son excluyentes por lo que podrían mezclarse) son:

1. Suscripción o membresía. Es decir, el usuario de la aplicación móvil la obtiene y la instala en su celular o tableta pero para poder hacer uso de las capacidades completas del app tendrá que suscribir una membresía pagando una cuota periódica al proveedor del app. En ocasiones el modelo de suscripción tiene variantes donde no se paga cada cierto tiempo sino basado en cuotas de uso (megabytes de disco, transferencia de datos; uso de procesador; horas de uso; etc.) pero donde el modelo básico es el mismo: pago periódico o eventual vía suscripción.

2. Comisión por transacción. Es decir, cuando el usuario al usar el app realiza una transacción monetaria (un pago o transferencia). El app puede automáticamente descontar de una cuenta de débito que el cliente mantenga, un pequeño porcentaje a manera de comisión. Lógicamente es prácticamente obligatorio que la empresa desarrolladora del app realice alguna especie de convenio con los procesadores financieros de pagos (tarjetas, bancos, etc.) para que esto sea viable.

Estos dos primeros modelos han sido poco explorados en el ámbito de las mobile apps aunque son ya ampliamente conocidos en los servicios en la Nube. En cambio, en el ámbito puro de las mobile apps hay dos modelos que resaltan. Uno de ellos, basado en publicidad, que es bastante conocido también; y el de compra de la aplicación, que en el caso de las mobile apps resulta llamativo porque es un modelo muy basado en escala (descarga masiva del app).

3. En el caso del modelo de publicidad lo usual es que la aplicación móvil puede ser descargada desde Internet e instalada en el dispostivo móvil (celular o tableta); luego, la aplicación es usada de manera gratuita pero dentro de la aplicación aparecerán de vez en cuando algunos anuncios publicitarios. Son precisamente estos anuncios los que mantienen el desarrollo del app vía el pago que los anunciantes hacen a la empresa o persona que desarrolló el app.

Una variante del modelo es cuando el creador del app ofrece la opción al usuario de que quite los anuncios (Ads) de su aplicación vía un pago, ya sea de cuota única o periódica. De esa manera, el creador del app mantiene una mezcla de ingresos entre publicitarios y de pago de los usuarios.

Este modelo es bastante prometedor en el mundo de las aplicaciones móviles y, como modelo de ingresos, es bien conocido en el ámbito de los servicios que muchos sitios Web ofrecen hoy día. Simplemente que se hereda al mundo de las mobile apps.

4. Vendiendo la aplicación móvil por un precio bajo. Este cuarto modelo de ingresos es el que personalmente me resulta más llamativo, así que ahondaré en detalle en él en un siguiente post. En este momento simplemente mencionar que el modelo funciona porque la aplicación puede ser descargada desde Internet, a un precio muy bajo (típicamente entre 1 y 5 dólares) de manera masiva y a escala mundial. Siendo así, el creador del app sólo tiene que ponerla en Internet y esperar a que el efecto de Longtail haga su labor; es decir, que poco a poco el app vaya generándole ingresos desde unos pocos dólares hasta cantidades ya nada despreciables. Esto lo comentaré en un post posterior.

Y ahora, ¿alguna idea de cómo rentabilizar o monetizar esa aplicación para móviles que estás ideando? Good luck..!

, , , , , , ,

2 comentarios

Administración de contenido Web y TYPO3

Cuando uno piensa en desarrollar el sitio Web de su organización o empresa, uno tiende a pensar en un sitio visualmente muy atractivo. Efectivamente el atractivo del sitio Web es sumamente importante. Después de todo, al principio “se entra por los ojos”. Y si logramos que el visitante de nuestro sitio Web sienta a éste como un sitio atractivo, elegante, fácil de navegar, moderno y consistente en su arquitectura de información, ya habremos ganado la mitad de la batalla: el usuario se quedará en nuestro sitio Web porque le resultó bonito e interesante. Vende nuestra organización o empresa. Hasta aquí es como un bonito brochure publicitario en línea. Esto es importante y debemos valorarlo en su justa medida. Además es un requisito indispensable de un buen sitio Web.

Sin embargo, esa primera batalla puede posteriormente irse perdiendo si el usuario otro día regresa al sitio Web y ve exactamente lo mismo. Y si luego regresa una vez más y ve exactamente la misma información, empezará el desencanto. Es posible que ya no regrese porque ya conoce el sitio Web y no necesita estar viéndolo dado que la información siempre es la misma. Es entonces cuando debemos pasar el segundo nivel: convertir nuestros sitio Web no sólo en una herramienta de publicidad en línea sino también en una herramienta de comunicación constante e interactiva con nuestro público o mercado meta.

Antes de seguir con la idea de este post, debemos hacer una importantísima aclaración. Es con respecto a la expectativa que inicialmente tenga la organización o empresa sobre su sitio Web. Porque puede ocurrir que a la empresa lo que le interese es precisamente la publicidad pero no le interese mucho o no tiene el tiempo o recursos para que su sitio Web también sea una herramienta de comunicación. Si este es el caso, lo más recomendable es que la empresa piense en un proyecto de diseño de su sitio Web. De la misma manera como piensa cuando diseña su brochure físico, sus banners, o sus vallas publicitarias. Es un trabajo básicamente de Diseño; aún en el caso de que haya cierta interactividad (formularios de contactos o similares, por ejemplo), el trabajo es de Diseño y de Publicidad.

Si la empresa realmente quiere, o más bien si está en posibilidades de administrar una herramienta de comunicación (dado que casi siempre querrá pero no siempre podrá) es entonces cuando el proyecto se convierte de una iniciativa de diseño/publicidad a un proyecto de desarrollo de un sistema de información. Es cuando un diseñador y un publicista aunque necesarios, no son suficientes. Deben apoyarse entonces por conocimiento informático que implemente el sistema de comunicación. Y muy posiblemente deba también incorporar comunicadores, mercadólogos, periodistas, gestores de información, o especialistas temáticos (uno o más) que sean las personas que posteriormente administrarán de manera permanente la nueva herramienta de comunicación que será el sitio Web.

Hoy día, sin embargo, ya existen muchos sistemas de administración de contenido Web (CMS, por sus siglas en inglés de Content Management System) que aceleran muchísimo y estandarizan el proceso de implementación del sistema de comunicación Web. Permiten de manera sencilla, desde el punto de vista informático, desplegar un sitio Web con capacidades completas de administrar su contenido por parte de usuarios no informáticos ni diseñadores. Es el comunicador o especialista temático el que administra directamente la información de tal manera que el sitio Web esté permanentemente actualizado.

Aunque hay cientos de CMS, dentro de los más usados están WordPress, Joomla y Drupal, por ejemplo. WordPress surgió originalmente como una herramienta de creación y administración de blogs. De hecho, este blog Cloud.Mobile.Social está administrado en WordPress (lo considero excelente como herramienta de blogs). Sin embargo WordPress también ya se usa para administrar sitios Web completos. Joomla y Drupal son también muy populares. No obstante en este blog trataremos de impulsar uno de los CMS más completos y con una ingeniería bastante sólida y avanzada. Se trata de TYPO3.

TYPO3 (www.typo3.org) es un CMS enfocado en la implementación de sitios Web empresariales y organizacionales complejos; donde existan muchas capacidades requeridas en cuanto administración de contenido por parte de la organización. Es altamente flexible, poderoso y con una amplia comunidad basada principalmente en Europa y particularmente en Alemania. Está basado en el lenguaje de programación PHP. Cuando uno explora en detalle TYPO3 difícilmente habrá alguna funcionalidad o característica que no pueda realizarse. Se tiene un mundo de posibilidades en cuanto administración de contenido y características similares o complementarias. Me atrevería a decir que si algo se puede hacer en otro CMS (WordPress, Joomla, Drupal, etc.) también se podrá hacer en TYPO3.

La crítica constante que se le hace a TYPO3 es su complejidad, tanto para el Web Developer, como para el Administrador de Contenido. Sin embargo, esto es solo parcialmente cierto. En el caso del administrador de contenido, con una buena capacitación en el aprovechamiento de la herramienta se puede subsanar gran parte de esta “complejidad”. Pero es necesaria un entrenamiento sólido enfocándose en lograr “química” entre TYPO3 y el usuario administrador de contenido; y esa “química” se logra cuando el administrador entiende y aprovecha las capacidades únicas que TYPO3 le ofrece. Lamentablemente para TYPO3 existe, al menos en Latinoamérica, una gran masa de usuarios que ya conocen otros CMS como WordPress o Joomla lo que los hace sentir en ocasiones más cómodos con estos. Sin embargo, en casi todos los comparativos detallados TYPO3 saldrá ganando.

En cuanto al Developer o configurador de TYPO3 (típicamente alguien del área de informática) efectivamente los conceptos usados en TYPO3 hacen que su curva de aprendizaje sea más larga que aprender WordPress o Joomla. Y no cualquier programador tiene el tiempo suficiente hoy día como para afrontar el tiempo que tiene esta curva de aprendizaje TYPO3. Pero para aquellos que toman el reto con persistencia y dedicación, al final del proceso habrá no sólo muchas satisfacciones sino también se abren muchas posibilidades para el desarrollo de sitios empresariales complejos y portales Web de gama alta.

Personalmente, y tocando más el tema de computación en la Nube, aplicaciones móviles y sociales, puedo ver TYPO3 como la herramienta central bajo la cual pueden confluir las diversas iniciativas o proyectos Web de una empresa, empezando lógicamente, por su sitio Web.

, , , ,

Deja un comentario

Facebook y su protocolo Open Graph

Imagen de logotipo del Open Graph ProtocolEs imposible no sorprenderse con la capacidad de innovación que Facebook ha tenido desde su creación. Día con día aparecen nuevas funcionalidades, aplicaciones y novedades acerca del uso y aprovechamiento de esta famosa red social. Hoy día ya no solo las personas incrementan el número de usuarios de esta red, sino también las empresas y organizaciones están haciendo un uso masivo de las capacidades que Facebook les ofrece.

Una de las más recientes capacidades que Facebook está ofreciendo al mundo se ha vuelto posible gracias al protocolo Open Graph. Este es un mecanismo abierto y estándar que Facebook ha creado para que cualquier sitio Web pueda integrarse a esta red social como un objeto más de dicha red. En términos simples, esto posibilita que los sitios Web puedan obtener gran parte de las capacidades y características que tienen las Páginas Facebook (Facebook Pages), incluyendo la más importante de todas, quizá, que es el poder enviar mensajes Facebook (actualizaciones ó updates en la terminología Facebook) al grupo de personas que indicaron que les gusta el sitio Web.

Por ejemplo, supongamos que al sitio Web de nuestra organización lo integramos mediante este método a la red social Facebook; es decir, le incorporamos las características técnicas que nos dicta el Open Graph Protocol. Al hacerlo así, cualquier persona que visita nuestro sitio Web podrá clickear o pulsar el ya famoso botón “Like” o “Me gusta” de Facebook, lo cual creará una asociación automática entre el sitio Web y el usuario que pulsó el botón. A partir de ahí, el usuario recibirá los “updates” del sitio Web de Facebook directamente en su muro. De esa manera, la organización podrá mantener enterados a sus usuarios visitantes en todo momento del acontecer de dicha organización. Las posibilidades de mercadeo y socialización son infinitas usando adecuadamente esta capacidad.

Dicho de otro modo, el sitio Web se convierte en un objeto más de la red Facebook; tal como lo es una página Facebook creada enteramente en la red social.

Desde el punto de vista técnico, lo que Open Graph requiere para integrarse en el sitio Web es una serie de etiquetas (tags; ó metatags, para ser específicos) que el creador de cada sitio debe colocar en el código html de su sitio Web y que le indicarán a Facebook cómo quiere que se maneje, se conceptualice y se use dicho sitio Web. Eso, y colocando el botón de “Like” en los espacios adecuados del sitio Web es lo único que se requiere para integrar su sitio Web a Facebook.

Actualmente, Facebook ha definido una serie de “tipos” de Objetos que pueden ser definidos dentro del sitio Web y “etiquetados” con cada tipo de objeto. De esta manera, existen objetos de tipo “negocios” (empresas, hoteles, bares, etc.), “grupos” (causas, equipos deportivos, etc.), “organizaciones” (ONGs, gobierno, universidades, etc.), entre varios otros. Asimismo, existen los objetos de tipo “Sitio Web”, “Blog”, y “Artículo”. Con todas estas categorías, los administradores de cada sitio Web puede colocar el tipo de objeto que se muestra relacionado con el botón de “Like” (por ejemplo). Y así, Facebook no sólo le da al sitio Web las capacidades de socialización automática que ya de por sí ofrece a las Facebook Pages sino que también logra categorizar adecuadamente toda la información que se integra en la Red Social (en su Open Graph).

Lo anterior, a mi entender, es uno de los mejores ejemplos prácticos y útiles de manera masiva del concepto de Web Semántica. Porque cuando uno busque, por ejemplo, por la frase “Lo que el viento se llevó”, Facebook podrá saber si entrega los resultados de una película (marcada como de tipo “movie”) o si entrega la última noticia sobre el huracán que pasó en la localidad. ¿Será que por fin podremos empenzar a hacer un uso masivo de la Web 3.0 o Semántica? En los próximos años, Facebook podría darnos esta respuesta vía el éxito o fracaso de su iniciativa del Open Graph Protocol.

Para los developers Facebook que quieran explorar desde ya esta capacidad de Facebook, les recomiendo visitar el sitio Web del protocolo Open Graph y la excelente presentación de Facebook donde se explican algunas de las decisiones de diseño de este protocolo.

, , , , , , ,

Deja un comentario