Crucial, en una palabra. Gracias a estos tipos de rollos de software moderno. Para entender cómo llegamos a ser importantes y lo que realmente hacemos, regresemos hace 20 años, los albores del desarrollo web.
Cada comienzo es simple. Las primeras aplicaciones web no fueron la excepción. Eran scripts CGI (primero Perl, luego PHP) que fueron ejecutados por el servidor web y lo que devolvieron fue devuelto al usuario. Los pioneros generalmente almacenaban datos en archivos simples, por ejemplo, Paul Graham promociona su ventaja competitiva sobre las tiendas web rivales del día en exactamente esa característica (o falta de ella, si lo prefiere). Pero a medida que la web mundial reunió a más y más usuarios, las aplicaciones respaldadas por bases de datos se vuelven estándar. Aún así, durante los primeros diez años, ni los datos ni la carga del servidor fueron un gran cuello de botella. La mayoría de las aplicaciones se ejecutaron en un entorno compartido, es decir, varias aplicaciones se ejecutaban en el mismo hardware físico, que alojaba servidores web y de bases de datos.
Luego, alrededor de 2006, se alcanzó un nuevo umbral. Ruby on Rails llegó a la escena y literalmente revolucionó la forma en que se desarrollaron las aplicaciones web. De repente, los despliegues diarios se convirtieron en un estándar. Rails vino con una herramienta muy conveniente, Capistrano, que hizo que tales implementaciones fueran una tarea tan fácil como disparar un solo comando: `cap deploy`. Aunque la configuración del servidor todavía la realizaban los administradores de sistemas tradicionales que generalmente se eliminaban a años luz de la programación, las recetas de Capistrano (esa es la jerga técnica para el código de automatización de implementación) se escribieron en el mismo idioma que la aplicación, Ruby. Así, la línea entre desarrolladores y administradores de sistemas comenzó a desdibujarse y nació algo nuevo: un desarrollador que entendía más que otros desarrolladores sobre la infraestructura.
- ¿Cuál es la mejor manera de escribir un CV para una pasantía de ingeniería de software?
- ¿Qué es mejor: ingeniería de software o ingeniería aeroespacial?
- ¿Por qué las personas que han estado programando durante años todavía hablan sobre la legibilidad del código?
- ¿Cuál es la diferencia entre desarrollo de productos, desarrollo de aplicaciones y desarrollo de software en TI?
- Quiero crear o hacer un prototipo para un proyecto de software que sea muy similar al proyecto de presa para el seguimiento de computadoras portátiles. Cuales son los pasos?
Luego vino la parte del palo de hockey de la curva de crecimiento exponencial con un orden de magnitud de más usuarios y toneladas de datos. El escalado, que hasta ahora era un problema solo para las compañías más grandes en el rango de Google o Amazon, golpeó a todos menos a los jugadores más pequeños. Los codificadores que sabían algo sobre infraestructura se encontraron pasando más y más tiempo adaptando las aplicaciones a las necesidades de servir a miles de usuarios simultáneos simultáneamente hasta el punto de que apenas aportaron nuevas características, solo mantuvieron todo el gran remolino de una base de datos (be relacional o no), caché en memoria, base de datos en memoria no persistente para cálculos rápidos, proxy inverso, cola de mensajes, trabajos en segundo plano y lo que no gira 24/7 🙂
Me sorprendió mucho después de tomar un año sabático de tres años en 2010 para volver a un entorno en el que DevOps era una necesidad a tiempo completo. Mi punto de vista puede estar sesgado desde el lado del desarrollador desde el lado del desarrollador, pero la importancia de esta posición difícilmente podría subestimarse. Si bien el trabajo del administrador de sistemas se puede externalizar fácilmente en la mayoría de los entornos, ya sea a una compañía diferente o a un departamento diferente en la misma compañía, DevOps es la cinta adhesiva y WD-40 entre los equipos de desarrollo y operaciones sin los cuales todas las aplicaciones web más simples de hoy no funcionará.
