El software del SIGLO XXI
La informática en la nube quiere ser el gran salto del software en el Siglo XXI. Todo lo que una empresa necesita "on demand" en pago por uso. Podemos competir con las grandes empresas y sus grandes soportes informáticos de manera barata y desde la nube. Microsoft, ORACLE, SAP, ya no tienen porque liderar los nuevos mercados que se abren a start-ups de todo tipo.
Está bien como teoría pero, años después del lanzamiento de Salesforce y docenas de competidores suyos, la informática distribuida sobre "la nube", lo mismo que el comercio electrónico desde la de Amazon, siguen siendo campo de acción de empresas relativamente pequeñas o soluciones puntuales para las grandes. Todavía hoy los grandes contratos y la facturación por software sigue estando en las licencias de las tres empresas citadas y un selectivo grupo de otra veintena de seguidores, más especializados, a nivel mundial.
La irrupción de Google en este mercado puede cambiar este "status quo" a favor de la computación en nube pero, de momento, las grandes empresas le piden "su nube" a SAP, Microsoft y a ORACLE.
The more things change....




pantulis dijo
Como desarrollador, a mi modo de ver Amazon es la solución más rápida para pasar a la nube. Y tiene la ventaja de que puedes hacerlo de manera progresiva: empezar usando S3 como almacenamiento infinito, luego contratando instancias EC2 como satélites que complementen a nuestra aplicación en un hosting tradicional y por último pasando a meterlo todo en la nube de Amazon (caso de éxito: meneame.net) e incorporar soluciones más avanzadas como balanceo de carga, VPNs, etc. Amazon además se mueve a gran velocidad y está permanentemente ampliado funcionalidades (desde alojar su nube en ubicaciones geográficas distintas, a acuerdos con Microsoft, Oracle para licenciar las aplicaciones y que corran en EC2...)
Desde el punto de vista del programador nada cambia (o cambia muy poco): se desarrolla la aplicación como si tuvieras un hosting tradicional basado en Linux o Windows. Como inconveniente, la arquitectura de la aplicación debe adaptarse a lo que supone "vivir en la nube" y por tanto los administradores de sistemas deben imaginar soluciones tanto de arquitectura como de despliegue para igualar las funcionalidades que son habituales en un hosting tradicional (afortunadamente la documentación de Amazon es magnífica y hay bastantes recursos en la red).
El servicio de computación en la nube de Google (AppEngine) es otro mundo. Por lo que he tenido oportunidad de probar uno tiene la sensacion de estar trabajando con tecnología alienígena. Se puede poner una aplicación en producción en cuestión de minutos ¡sin escribir un comando Unix! No hay que configurar máquinas, ni IPs, ni discos, ni bases de datos, sólo escribir nuestra aplicación y pulsar un botón. Este nivel de abstracción tiene un coste, sin embargo. Si bien se puentea en gran medida el trabajo del administrador de sistemas (tanto que podríamos dudar si sería necesario en una solución como AppEngine) el código de la aplicación se ve fuertemente afectado por la plataforma de Google y hay que desarrollar olvidándonos de las APIs de programación habituales y usando exclusivamente los servicios que Google pone a disposición del programador (que son razonablemente amplios y estan bien documentados, pero son los que son y no se pueden ampliar por nuestra parte) El modelo de datos de la aplicación también debe rediseñarse para funcionar en un sistema no basado en SQL, por lo que no sólo los datos de la aplicación quedarán dentro del DataStore de Google, sino que el propio diseño de la misma estará totalmente acoplado a Google. Como ventajas, que cualquier usuario de un servicio Google podrá usar nuestra aplicación sin necesidad de crearse una nueva cuenta y que tiene un tramo de coste gratuito que nos puede servir para hacer pequeñas aplicaciones de prueba.
En conclusión (y esto puede extenderse a cualquier proveedor de cloud computing) cada uno tendrá sus pros y contras, y conviene al menos conocer por encima su funcionamiento para poder adoptar en cada caso lo que mejor convenga.
5 Mayo 2010 | 10:55 AM