Cómo ha cambiado el proceso de soporte del sitio en los últimos veinte años

El gurú de la tecnología de la información y director técnico de la revista Ars Technica Jason Marlin tiene más de veinte años de experiencia apoyando infraestructuras de información, y, en su opinión, mucho ha cambiado en esta área.

El juego Pit, que funcionaba como una puerta BBS. En esta captura de pantalla, Lee Hutchinson ataca a estos tipos. O ellos son él.

En la década de 1980, crecí como un verdadero nerd, no en el sentido inconformista, sino en el sentido de que siempre llevaba conmigo un número de cinco kilogramos de la revista Computer Shopper (sí, estas publicaciones eran realmente grandes). Me enganché al Bulletin Board Systems a la edad de diez años. No es sorprendente que al final resulte ser el director técnico del sitio, cubriendo temas de ciencia y tecnología.

Puedo establecer paralelos claros entre el trabajo de soporte de mi BBS (es decir, el trabajo del sysop) y la administración de la infraestructura web moderna. Marquemos estos paralelos en honor del vigésimo aniversario del sitio web de Ars. Este artículo no será una historia exhaustiva de sitios web, aquí describiré mi propia experiencia en la administración de sitios y cómo ha evolucionado en los últimos 20 años, así como cómo han cambiado las herramientas y el pensamiento.

CARGAR "*", 8, 1

Mi primera experiencia como sysop se obtuvo en el Commodore 128 (por supuesto, en modo de 64 bits), donde funcionaba el programa Color 64 de Greg Pfountz. Envié a Greg mi cheque (bueno, fue firmado por mi madre) y recibí un disquete de 5.25 "con una instrucción cosida a mano impresa en una impresora matricial, y luego comenzó.

El color 64 se veía increíble gracias a ASCII, pintado de acuerdo con el estándar ANSI, a diferencia de la mayoría de los otros programas BBS que producían texto banal incoloro. Color 64 hizo posible crear una experiencia de usuario. Ya no puedo recordar los nombres de mi BBS, pero garantizo que el tema principal estaba relacionado con dragones y / o kung fu. Me da un poco de vergüenza admitir que mi apodo era DragonMaster, pero solo confirmó los estereotipos asociados con los nerds.

Desafortunadamente, mi infraestructura de red consistía en una sola línea telefónica, lo que significaba que tenía que desconectar todos los dispositivos de llamada (es decir, un teléfono de disco montado en la pared) y trabajar entre 23 y 5 horas. También significaba poca interactividad de BBS. Con una sola línea y una sola unidad Commodore 1571, los usuarios no podían chatear entre ellos o descargar más de un juego a la vez.


Commodore 1670 todavía hace que el corazón lata más rápido

En mis sueños, en el futuro cercano, ejecuté el BBS real, algo así como el famoso Las Vegas Fear & Loathing, que a menudo visitaba. En mis sueños, había 10 líneas telefónicas para que los usuarios pudieran comunicarse entre sí en tiempo real y conectarse a 1200 módems, ¡no, ni siquiera 2400 baudios! Y en un disco duro mítico con un volumen de hasta 10 MB del sistema Lt. Kernal habría mantenido un sinfín de existencias de juegos.

Por desgracia, todo esto era inaccesible para mí, pero estaba claramente infectado con algún tipo de enfermedad nueva que alentaba un deseo inusual en una persona de crear lugares digitales en los que los usuarios pudieran reunirse

1990s

Seguí jugando con el software BBS, incluido un predecesor HTML muy interesante como Excalibur BBS . Eche un vistazo a los resultados de búsqueda de imágenes de Google para ver cómo este software se adelantó a su tiempo.

$: cd ~ / public_html

Conocí HTML por primera vez en la universidad a mediados de los 90; luego hice mi tarea y la subí al directorio de inicio público, y los maestros podían revisarlos en su tiempo libre usando los navegadores Netscape o Mosaic. Un excelente motivador en ese momento era 10 puntos extra por "usar tecnología".

Apache + Perl + XML + Hosting compartido

Una de las primeras "aplicaciones" reales que creé como desarrollador web fue el departamento de noticias de una empresa de telecomunicaciones. Todo esto funcionó en un paquete generalizado: Apache como servidor HTTP, Perl como lenguaje de servidor y una base de datos como archivo de texto. En ese momento, no estaba familiarizado con las bases de datos reales, pero sabía cómo escribir y analizar XML. Todo esto se alojó en una plataforma de colaboración increíblemente buena en la que podía escribir todas las reglas para el servidor en un archivo .htaccess. ¡Pronto supe que este archivo le daba demasiado poder a mis manos inexpertas!

El alojamiento colaborativo resolvió mis problemas, pero en ese momento los desarrolladores dependían de los administradores en todo lo relacionado con las versiones y extensiones de software. También tuvo que preocuparse por lo que están haciendo sus vecinos con los recursos compartidos, incluyendo todo tipo de cosas desagradables. Hackear una máquina podría comprometer cientos de sitios.

IIS, extensiones de FrontPage y acceso

Como resultado, la agencia donde trabajé ganó suficientes clientes para pagar su propio servidor. Para mi disgusto, resultó ser una máquina Windows que ejecutaba IIS (Internet Information Services). Este territorio era completamente desconocido para mí, pero después de lanzar el IDE de Frontpage, me sorprendió lo simple que Microsoft hizo las tareas generalmente difíciles de almacenar información verificada en la base de datos. (No, en serio, simplemente increíble). Como resultado, busqué el IDE gráfico perfecto, incluido un breve y frustrante desastre con Macromedia Dreamweaver. Pronto aprendí que las herramientas que crean código automáticamente suelen producir una gran cantidad de fideos, que solo esas mismas herramientas podrían desentrañar.

Administrar IIS en Windows NT 3.5 también parecía una tarea fácil y peligrosa para alguien con experiencia en Unix. Y al mismo tiempo, era una sensación de restricciones estrictas: ¿dónde estaban los archivos .conf en los que era posible realizar microajustes (y un desorden fenomenal)?

Este ensamblado se convirtió en mi plataforma por un tiempo, hicimos varios CMS por pedido para nuestros clientes, sin pensar en mantener una base de código común, soporte a largo plazo o control de versiones. Que horror

Principios de 2000 a partir de ColdFusion

Ahora entiendo el horror de la situación, pero realmente me gustó el entorno Allaire ColdFusion , y lo usé durante al menos cuatro años para crear aplicaciones y redes corporativas lo suficientemente grandes. Trabajó sobre la base de CFML (lenguaje de marcado ColdFusion). Parecía HTML, pero realizó consultas triviales a las bases de datos y su integración con tecnologías externas como Java Servlets o CORBA. ColdFusion tenía muchos oponentes, pero nunca fui partidario de una tecnología en particular, y simplemente elegí lo que me permitió completar la tarea más rápidamente.

Aparecen marcos web

La barrera de entrada muy baja de ColdFusion le ha valido la notoriedad de un lenguaje tonto que ha atraído a programadores de baja calidad a esta área, muy parecido a PHP. No puedo discutir esto, pero la ironía es que mi primer conocimiento de un buen marco web tuvo lugar en forma de Fusebox . Comenzó con un intento de organizar una aplicación usando nombres simples de archivos y convenciones del sistema de directorios. Parecía obvio, pero, como la mayoría de los desarrolladores web de la época, gravité hacia un enfoque en constante evolución para el diseño de la aplicación y luché con cosas que se separaron entre sí, como consultas de bases de datos y componentes de salida. Jugué con Struts , pero como era imposible usar Java en el trabajo principal, todavía no lo comprendía. Pero Fusebox me abrió los ojos a las plataformas con el paradigma MVC (controlador de vista de modelo) que va más allá de los límites de lenguajes específicos. Y eso fue muchos años antes de la aparición de esa demoledora presentación de 15 minutos de Ruby on Rails hecha por David Heinemeyer Hansson .

Hoy nunca consideraría crear una aplicación grande sin elegir un marco, y hoy tenemos muchas opciones interesantes. Para PHP, me gusta más Laravel .



Sí, entonces solo voló el techo.

Hospedaje web en clúster

Obtuve mi primera experiencia con un sitio web de alto tráfico en 2002. A medida que aumentaba el tráfico, también aumentaba la responsabilidad, así como la cantidad de llamadas en medio de la noche, exigiendo reiniciar el servidor. Y finalmente, decidí averiguar todo sobre el equilibrio de carga, el almacenamiento en caché y el alojamiento de clústeres. Esta fue otra revelación, porque abrió las posibilidades de escalado casi ilimitado.

Si una máquina se desconectaba, teníamos autos de seguridad para garantizar que todo funcionara. Teníamos análisis y métricas detalladas del clúster. La vida era hermosa, como mi sueño.

Auge de las máquinas virtuales: AWS, Vagrant

AWS (Amazon Web Services) apareció, al parecer, de la nada, y les dio a los desarrolladores exactamente lo que necesitábamos. También eliminaron a los intermediarios del alojamiento tradicional. No tuvimos que preguntar qué tecnologías se nos permitía usar; De repente todo fue posible. ¿Quieres intentar hacer una aplicación en Django o NodeJS? No hay problema Inicie un par de máquinas virtuales y listo. Todo esto se podría hacer con AWS: firewalls virtuales, equilibradores de carga, clústeres especiales para bases de datos, CDN (red de entrega de contenido) para recursos estáticos y casi todo lo que se pueda imaginar. Se convirtió en un centro de datos para la fabricación propia, y fue tanto una maldición como una bendición. Al agregar cada nuevo servicio, era necesario rastrearlo, y para que alguien supiera cómo aumentarlo después de que todo se rompe (y todo se rompe). Demasiado interesado en el desarrollador, fue muy fácil morder más de lo que podía masticar.

Lo que AWS hizo posible en la nube, Vagrant lo hizo posible en una máquina de producción. Vagrant nos dio acceso fácil y programable a varios proveedores de VM. Pude probar nuevos tipos de Linux y todo tipo de paquetes de software en un entorno que, cuando se trataba de la implementación, era muy fácil de recrear en la nube. Si algo salió mal durante la instalación, el comando de destrucción vagabundo más simple le permitió comenzar de nuevo desde la misma imagen. Esto hizo que el desarrollo fuera mucho más agradable que ejecutar servidores en un sistema operativo hogareño, o directamente usando VMWare o VirtualBox.

Década de 2010: de webmasters a DevOps

Reduzcamos la velocidad un poco y hablemos sobre cómo siempre odié el término webmaster.

Hombre: ¿Qué haces en la vida?
Yo: creo aplicaciones web geniales usando varios lenguajes de programación, y trabajo con la infraestructura ...
Hombre: Ahhh, entonces eres un WEBMASTER!

Quiero eliminar esta palabra desagradable del uso.

Además de asociar esta palabra con un cubo de juego de 20 lados, no describe en absoluto el papel que muchos de nosotros jugamos en la gestión de la programación y la infraestructura. Por lo tanto, realmente me gusta este cambio, durante la última década, a términos más respetados como DevOps . Los ingenieros de DevOps utilizan la programación para crear, administrar y documentar la infraestructura del mundo real.

Chef + ansible

Cuando comencé a trabajar en Ars Technica, queríamos poder agregar o eliminar fácilmente servidores web y servidores de bases de datos en un entorno virtualizado. Después de explorar varios enfoques, nos decidimos por Chef , que simplifica la gestión de la infraestructura a través de una jerarquía de analogías, principalmente relacionadas con la cocina (cuchillo, recetario, recetas, etc.). Habiendo estudiado cómo las propiedades de las variables, o "atributos", como se les llama aquí, surgen de los roles y se reducen a nodos separados, se vuelve muy simple administrar el software del servidor y las versiones desde una sola plataforma. Chef nos permitió dejar de hacer microgestión de servidores individuales en grupos y facilitó la tarea de actualización masiva.

Hoy, personalmente, prefiero trabajar con Ansible , un sistema basado en Python desarrollado por Redhat: es más fácil trabajar con él y es un poco menos frágil cuando se trabaja en organizaciones pequeñas. A diferencia de Chef, donde se requiere un servidor central, Ansible usa SSH desde la máquina host (en nuestro caso, desde nuestras computadoras portátiles desde las que estamos desarrollando), pero para las empresas más grandes todavía tiene un servidor, Tower. Ansible también le permite escribir la mayor parte de la configuración en YAML, lo que mejora enormemente su legibilidad.

Desde hace varios años, hemos alojado el ServerCentral Turing Group . Nos ayudan a elegir el equilibrio adecuado entre lo que somos buenos (escribir código y configurar VM) y lo que no podemos controlar por completo: estos son generadores diesel de seguridad, redes redundantes o copia de datos en tiempo real en un centro de datos diseñado para evitar fallas.

2019 en adelante

Siempre estaré nostálgico por esos días serenos de ingresar comandos manualmente para el módem, cuando en algún lugar del horizonte nos atrajeron las promesas hechas por Lawnmower Man o Hal 9000. Pero el momento actual también contiene enormes oportunidades para la próxima fase de la evolución de la infraestructura. Hay tantas herramientas prometedoras que planeamos poner en el negocio, por ejemplo, Docker Swarm o Kubernetes . Es sorprendente darse cuenta de lo lejos que hemos llegado y de cuánto más productivo puede ser el desarrollador de hoy en comparación con los viejos tiempos llenos del misterioso chirrido de BBS. Espero que observemos una abstracción cada vez mayor de la compleja tecnología multicapa requerida para una presencia web moderna.

¡Así que le deseamos éxito en los próximos 20 años!