En mis días de estudiante universitario (en los tiempos antiguos, cuando computábamos en tablas de piedra) nuestra plataforma informática principal era un mainframe. De hecho, la mayor parte de mis actividades de codificación ocurrieron en el mainframe de la universidad.
Quizá le sorprenda que la mayor parte de mis actividades de codificación no involucraran COBOL. La verdad es que la mayor parte era Pascal y lenguaje ensamblador. Sólo una vez me obligaron a codificar en COBOL, y eso fue porque tomé una clase para familiarizarme.
Años más tarde, como arquitecto de TI, la misma afirmación era cierta: Escribí código C/C++ y Java en AIX y entregué aplicaciones habilitadas para web en WebSphere en un mainframe .
Ya ves, los mainframes no son sinónimos de COBOL. De hecho, la última encuesta de mainframe de BMC descubrió que el 82% de los encuestados utilizan Java en sus entornos de mainframe. Y si esto le sorprendió, no se desespere, porque el 48 % de los encuestados utiliza prácticas Agile y DevOps en su entorno de mainframe.
Te dejaré recuperarte por un momento antes de continuar.
La verdad es que los mainframes tienen mala reputación en el ámbito informático. Se les considera dinosaurios, cuando la realidad es que proporcionan una fuente importante de poder computacional para muchas organizaciones. Potencia informática cuyo uso está creciendo. Considere la encuesta de BMC y descubrirá que durante el año pasado:
Estas cifras son importantes si tenemos en cuenta que más del 51% de los encuestados afirma que más de la mitad de sus datos residen en el mainframe. Lo importante de esto es que los datos tienen gravedad.
Permítanme decirlo nuevamente porque es realmente importante: los datos tienen gravedad.
Como lo señaló recientemente la Oficina del CTO de F5, nuestra capacidad para mover datos afecta prácticamente todo lo relacionado con TI y aplicações. Afecta dónde se implementan las aplicações , cómo están diseñadas y los servicios de aplicação que las protegen defendiendo las aplicações que acceden a ellas. A medida que aumentan los volúmenes de datos, el peso de esos datos comienza a atraer aplicações , al igual que la gravedad real y su relación con la masa. Ya sea en la nube, en entornos tradicionales o en el mainframe, la gravedad de los datos es un factor real a la hora de decidir dónde se implementan finalmente las aplicações .
Para ver evidencia de esto en acción, considere un estudio de Sapho que exploró las razones por las cuales las organizaciones no estaban adoptando la nube y, en cambio, estaban modernizando las aplicaciones locales. De hecho, más de la mitad (56%) dijo que las instalaciones locales no desaparecerían y que menos del 5% de su cartera de aplicação empresariales realizaría la migración a la nube.
Alguien está gritando ahora mismo que esto es una herejía técnica. Pero pensemos en las razones que hay detrás del rechazo a la idea de "todo en la nube, todo el tiempo". En primer lugar, se basa en la gravedad de los datos. Más de la mitad (58%) de los encuestados dijeron que las aplicaciones que tienen acceso a datos y sistemas críticos deben estar locales.
Ahora bien, si retrocedemos y analizamos la encuesta de BMC, notaremos que más de la mitad de las organizaciones ven cómo los volúmenes de datos en sus mainframes aumentan año tras año.
Porque son eficientes y, contrarios al mito popular, son compatibles con DevOps, Agile y los métodos informáticos modernos. Si puedo implementar aplicaciones basadas en web en AIX en un mainframe, puedes implementar microservicios en un entorno de Kubernetes en ellas.
Los mainframes son colecciones de recursos computacionales y están aquí para quedarse. La gravedad de los datos, especialmente en esta era de transformación digital , los mantendrá firmemente fijados al piso del centro de datos. Esto significa que la capacidad de modernizar aplicaciones y entornos a través de herramientas y servicios de aplicação integrados seguirá siendo fundamental en los próximos años.
Con el tiempo podremos mirar atrás y ver que los mainframes fueron en realidad más estratégicos que la nube, si podemos dejar de asociarlos con COBOL y reconocer que lo importante son los datos y las aplicaciones (el software), no el tipo de hardware en el que está implementado.