La NUBE está en la Tierra

 

Resulta tentador llamar a las cosas por otro nombre si con esto conseguimos atraer público y vender nuestros productos. Algunas veces un ligero cambio, otro enfoque, y una dosis de marketing es suficiente para tener un “Algo 3.0”.

La tecnología se adapta muy bien a estos temas y el consumidor también. Adquirir lo último siempre está de moda.

Para el usuario final el hecho de tener sus datos en “la nube” resulta “cool” aunque no sepamos donde, ni quien los puede ver o utilizar, pero están, o deberían estar, cuando los solicitamos.

El “cloud” es un servicio que se presta desde hace mucho tiempo, si desde hace mucho, pasaron por ser un Host o CPD, donde ya se empezaban a compartir recursos como el almacenamiento, procesamiento la seguridad, a un Grid o Grill a Housing o Virtual Private Server (VPS), Hosting o Clouding ¿os suena? Al final los que están detrás son siempre los mismos, multinacionales del sector o las consultoras boutique, como decía una amigo, que se reinventan para volver a vender lo mismo adaptado a los nuevos avances tecnológicos.

Y no me parece mal, dicho sea de paso, y sin dudarlo es el futuro, pero resulta irónico que te intenten vender de nuevo el mismo concepto (aunque con matices).

Por buscar una definición de “nube” sirva esta del NIST:

• “The National Institute of Standards and Technology (NIST) is an agency of the U.S. Department of Commerce that defines and sets standards for any emerging technology. NIST defines cloud computing as a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the data centers that provide those services. According to NIST, this cloud model promotes availability and is comprised of five essential characteristics, three service models, and four deployment models.”

Para una empresa las dudas sobre la seguridad, disponibilidad, accesibilidad, etc resultan inquietantes y es lógico empezar a hacerse preguntas sobre este tipo de servicio. Y en cuantas más preguntas se hacen, más se parecen las respuestas a lo que ya sabemos o a lo que tenemos.

En época de crisis tenemos que ser imaginativos y si además nuestro producto ayuda a abaratar costes, porque es cierto que esta tecnología ayuda, aprovechemos el tirón y coloquemos nuestro nuevo concepto. Este parece ser el discurso.

¿Qué aporta la nube fuera de los avances técnicos de los últimos tiempos?

¿Hablamos de escalabilidad? Compartir recursos, administración de volumetrías y accesos, balanceo de carga, sistema híbridos, virtualizaciones dinámicas de recursos y espacio. No es nuevo aunque quieran cambiar la siglas, SaaS, PaaS , IaaS o algunas características: On-demand self-service, Broad network access, Resource pooling, rapid elasticity, measured service, ya presentes desde hace tiempo en otras soluciones.

¿Y por qué en este momento?

Está claro que en los últimos años se han abaratado los costes de almacenamiento, de las líneas de datos, de la electrónica de red, hasta el coste de los técnicos.Todo esto junto con nuevas aplicaciones de seguridad y la creciente necesidad de movilidad hace que este tipo de producto sea más apetecible y necesario.

Que podamos gestionar de forma más independiente nuestras infraestructuras y las adaptemos dinámicamente a la demanda de nuestro negocio es fundamental para ser competitivos. Podemos conseguirlo con la externalización de estructuras de TI. Esta es una solución, pero no perdamos de vista que “la nube” se encuentra en la Tierra junto con nuestro proveedor de siempre, busquemos primeras marcas y proveedores de referencia. (Azure puede ser una buena solución, por su diversidad en la oferta y recorrido hasta la fecha, aunque tenemos otras también interesantes).

Quizás pueda adelantar, sino lo está ya, que en un futuro inmediato nuestros datos (fotos, documentos, el vídeo de la boda, etc) se almacenarán en el espacio profundo tipo “DEEP DATA NETWORK 3.0”, en un servidor que nos circunvale en la estratosfera o en un clúster en Marte :)

 

Sensibilidad al cambio de alcance en ingeniería de software.

Gestionar un cambio de alcance en un proyecto suele ser, en algunos casos, más o mucho más complejo de lo que el cliente podría imaginar. 

Si hablamos de ingeniera de software parece que la sensibilidad por parte del cliente respecto al cambio  en el alcance del proyecto suele ser escasa o incluso nula. ¿Por qué? 

Sin embargo, si observamos otros ámbitos de la ingeniería, parece que este tema está superado. Por ejemplo, en una obra civil, si estamos construyendo un puente entre dos montañas y  ya tenemos los cimientos asentados,  es difícil que nos pidan mover el puente  400 metros a la derecha.  Parece existir una conciencia general sobre la dimensión del nuevo trabajo a realizar y del sobrecoste que supondrá.  Será porque se ve el hormigón, el perímetro de la obra delimitado, el despliegue de accesos a la zona de trabajo, las medidas de seguridad implantadas.

Sin llegar a este extremo, en otros proyectos como en la construcción de una casa, si ya estamos levantando los tabiques ¿sería lógico que nos pidieran reorientar la entrada principal? ¿Accedería el propietario a abrir una nueva fachada y a reorganiza la distribución de su casa?

Sin demasiados conocimientos sobre arquitectura el cliente es perfectamente consciente de lo que está pidiendo y de sus consecuencias. Puede “verlo”. 

En ocasiones,  en el desarrollo de software, nos solicitan  cambios que afectan a la arquitectura del proyecto (sus cimientos), hasta el punto de necesitar rediseñar los “from” (fachadas), la seguridad, los accesos, los modelos de datos o incluso la tecnología a utilizar.  

Sin embargo el cliente no siempre percibe la dimensión del cambio. No sólo piensa  que se puede hacer de forma rápida sino que el coste o es bajo o no tiene mayor  impacto. ¿Qué es lo que no ven?

Pasar de una arquitectura centralizada a distribuida, modular la funcionalidad, migrar a otro lenguaje o adaptarse a nuevas normativas bancarias en tiempo récord no parece un problema si se trata de algo “abstracto”, de código, de elementos  que residen  en nuestro “Cloud” tan de actualidad  en estos momentos. 

Al igual que en otras ingenierías es necesario levantar nuevos planos (volver a definir),  someterlos a aprobación, presentar un calendario, desarrollar (construir), realizar pruebas técnicas y funcionales, certificar, buscar nuevos perfiles si procede, etc.  

En definitiva volver a pasar por un procedimiento exigente y exhaustivo que garantiza que se entiende el nuevo alcance y la calidad de la entrega. 

Hace años se hablaba de líneas de código para valorar un cambio. Podíamos medir si el impacto era de veinte o treinta mil líneas, por utilizar un tangible, pero aun así era discutible.

De igual forma  ocurre con las  horas de esfuerzo. ¿Podemos explicar al cliente el impacto de una modificación en un modelo de datos, en una API o una DDL?  Sin cierto nivel de conocimiento previo  sobre la materia es difícil valorar el alcance de la propuesta. 

Es más fácil medir el cambio cuando se ve afectada el área de hardware, la que se puede ver, como ocurre si ampliamos nuestros entornos Host, Clúster, TELCO, etc.

En definitiva,  gestionar un cambio de alcance en una aplicación de software requerirá de un esfuerzo extra por parte de sus responsables que deberán transmitir de forma clara y sencilla, sin tecnicismos, lo que supone los cambios y de un ejercicio de imaginación  por parte del cliente, para entender lo que está  al otro lado de su pantalla.