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!

Source: https://habr.com/ru/post/438694/


All Articles