Neo y Cloud Foundry: ¿esto qué es?

En la entrada anterior hablaba de Neo y Cloud Foundry y me comprometí  a explicar la diferencia entre ambos conceptos. Para ello empezaré haciendo algo de historia…

Desde que apareció SAP Cloud Platform, hace ya más de 5 años, la plataforma ha evolucionado «un poquito»… de entrada, el nombre, al principio era SAP HANA Cloud Platform, pero decidieron quitar el «HANA» del nombre porque llevaba a equívocos y podría parecer que era imprescindible tener HANA para poder utilizar la plataforma.

También al principio, se hablaba del producto como «un todo»: IaaS, PaaS y SaaS. Es decir, infraestructura, plataforma y servicios, todo ello alojado y gestionado por SAP.

Después se fue evolucionando más al concepto puro de plataforma de servicios y se empezó a hablar de un concepto clave: los microservicios.

Los microservicios nos permiten «trocear» nuestras aplicaciones en componentes autónomos e independientes entre sí, pero que pueden interactuar entre ellos. Lo que nos permite, en un momento dado, modificar uno de esos microservicios, sin que tenga porque verse afectada el resto de la aplicación.

Javier Garzás os los explica mucho mejor en este artículo: ¿Qué es eso de los microservicios?

Existe una metodología para desarrollar este tipo de aplicaciones, conocida como los 12 factores, que básicamente lo que recogen es que si desarrollas de una manera determinada, tu aplicación se podrá ejecutar sobre cualquier infraestructura y entorno de ejecución… evidentemente, que cumpla con ciertas normas.

Tú sólo tienes que preocuparte de desarrollar, en el/los lenguaje/s que prefieras y al desplegar la aplicación, el sistema se encargará del resto.

Y es aquí donde aparece Cloud Foundry, que es una plataforma, de código abierto, que nos permite alojar nuestras aplicaciones utilizando contenedores e interconectar los mismos.

¿Y Neo qué es? Neo era el entorno inicial de SAP Cloud Platform, alojado en centros de datos de SAP, con una arquitectura propia y unos entornos de ejecución establecidos: HANA XS, HTML5 y Java.

El hecho de adherirse a Cloud Foundry, lleva implícito un cambio a nivel de infraestructura: nuestras aplicaciones deben ser capaces de alojarse en cualquier infraestructura cloud. Por eso, a día de hoy, cuando nos abrimos una cuenta de SAP Cloud Platform, en el entorno Cloud Foundry, podemos elegir en qué proveedor: Amazon Web Services, Azure o Google Platform.

¿Y SAP? SAP sigue dando infraestructura a todas las cuentas del entorno Neo. ¿Por qué? Bueno, pues porque hay clientes que eligieron esa opción y porque todavía hay algunos servicios de la plataforma que no existen en Cloud Foundry. De hecho, algunos existen en los 2, otros sólo en Neo y otros sólo en Cloud Foundry.

La lógica te dice que todo evolucionará a Cloud Foundry, por lo que habría que ir viendo de qué va esto, ¿no?

¿Cómo? Ufff… eso ya es un poco largo de contar. Te aconsejo que te mires algunos de los cursos que hay en openSAP y te apuntes al curso CP100, donde te podrás llevar una idea general de todo esto.

De todas formas, a día de hoy, no hay que elegir pastilla roja o pastilla azul, conviven ambos entornos y puedes elegir lo mejor de cada uno. Eso sí, deberías ponerte las pilas para que no se te atragante la pastilla… 😉

Trabajar por horas: ¿me lo estás diciendo en serio?

Esta semana se celebró el Día Internacional de los Trabajadores, en el que se conmemora, entre otras cosas, la lucha de una serie de sindicalistas por establecer la jornada laboral de 8 horas… que algunos ya firmaríamos, lo de las 8 horas, digo 😉

Eso fue a finales del siglo XIX, estamos en el siglo XXI (por si alguno no se ha dado cuenta) y me da que algunas cosas han cambiado en el mundo del trabajo desde entonces (y lo que está por venir), pero hay gente que sigue con la misma cantinela: la patronal es mala, el trabajador siempre tiene la razón y tópicos parecidos…

Y mientras tanto, que si unas subvenciones para formación por aquí, que si unos becarios sin cobrar por allá… vamos, que nadie puede hablar y nada es blanco ni negro, pero volvamos al tema de las horas, que me desvío.

Entiendo que si trabajas en una cadena de montaje de una fábrica es fundamental que estés en tu puesto a la hora que te corresponde, ya que cualquier pequeño retraso tiene un gran impacto en la cadena de producción, pero, ¿realmente crees que se puede llevar una gestión del tiempo parecida en los llamados «trabajadores del conocimiento»?

Algunos, sí lo creen. De hecho, hace unos años (sí, siglo XXI) viví un amago de poner tornos en una empresa con la que colaboraba, en la que a su vez se fomentaba el teletrabajo… Como no llegó a suceder, desconozco si la idea era poner un torno en la casa de cada uno de los trabajadores, la verdad… 😉

El argumento era que había algunos que se aprovechaban de la flexibilidad que había y que era la forma de tenerlos controlados. Algo que no entendía muy bien, porque sin necesidad de ningún tipo de sistema se sabía quiénes eran y no se tomaban medidas.

Probablemente, si se hubiera puesto en marcha la propuesta se les habría identificado fácilmente: se habrían puesto en cola 5 minutos antes de la hora de salida para fichar a «la hora» 😉

Pero este tema de las horas es algo que está muy arraigado dentro del sector de la consultoría y los proyectos de software, partiendo de la base de que muchos de las ofertas se basan en horas.

Es curioso porque a veces alguien que no sabe exactamente qué quiere hacer ni cómo hacerlo, te pide una oferta y te dice: «Esto son 2.400 horas». Sin hablar del factor precio (esa «risa» viene luego), no sabes cómo ha llegado a esa cifra: si son 2.400 personas trabajando 1 hora; si es una persona trabajando 24 horas al día, durante 100 días, fines de semana incluidos…

Eso por el lado del que te pide la oferta, pero es que tú redactándola haces lo mismo: 100 horas de jefe de proyecto, 300 de consultor y 2.000 de programador. Y cuando ganemos, ¡ya veremos cómo lo hacemos!

Esto, si hablamos de proyectos cerrados (en serio, ¿en el siglo XXI?), porque si hablamos de asistencias técnicas y lo único que contamos son las horas, resulta que se premia la «inefectividad»: cuanto más tarde en terminar, más facturo.

Todo muy lógico, ¿no? Pues así estamos y parece que es complicado cambiarlo, aunque creo que al menos hay que intentarlo y aprender a medir otras cosas como el trabajo completado y/o el valor aportado.

Y todo esto no es idea mía (yo simplemente la comparto, en ambos sentidos), sino del gran Javier Garzás, experto en agilidad, gestión de proyectos y equipos y brillante ponente, entre otras muchas cosas. Si no le conocéis, mal; si le conocéis, puede que le hayáis oído hablar de esos términos. Para todos, obligatorio perder 10 minutos de vuestra vida en escuchar el podcast que va en este artículo: Podcast: la absurda gestión por horas.

¡Viva el sentido común! 😉