Logotipo

Post Actualizado en julio 25, 2013


Serpientes en la web, el desarrollo web apesta

Jacob Kaplan-Moss Una charla presentada en PyCon Argentina y PyCon Brazil, 2009. El desarrollo web apesta. Es verdad: el desarrollo web, en el peor de los casos, es difícil, repetitivo y aburrido. Las herramientas de las que disponemos son malas. Cuanto mucho, hacen el desarrollo web ligeramente menos doloroso, pero todavia nos falta mucho para hacer que […]

Jacob Kaplan-Moss

Una charla presentada en PyCon Argentina y PyCon Brazil, 2009.

El desarrollo web apesta.

Es verdad: el desarrollo web, en el peor de los casos, es difícil, repetitivo y aburrido. Las herramientas de las que disponemos son malas. Cuanto mucho, hacen el desarrollo web ligeramente menos doloroso, pero todavia nos falta mucho para hacer que el desarrollo web este bueno.

La historia de las herramientas para el desarrollo web es una historia de intentar dar solucion a este problema. Es una historia de preguntarse, “como podemos hacer que esto apeste menos?”. Es importante comprender esta historia, porque podemos mirar a las modas del pasado para predecir el futuro.

Eso es exactamente lo que planeo hacer. Quiero responder estas tres preguntas:

  • Qué apesta, ahora, acerca del desarrollo web?
  • Como vamos a arreglarlo?
  • Podemos arreglarlo con python?

Para hacerlo, voy a empezar con historia antigua.1

Una historia corta y opinada del desarrollo web

En el inicio, TBL inventó la Web, y era buena.

Me gusta considerar este tiempo como la “Edad de piedra” del desarrollo web, una era caracterizada por herramientas torpes y difíciles de usar. Escribiamos HTML, a mano, generalmente en un editor de texto. El concepto de páginas web dinámicas no existia: Si querias publicar mil historias online, escribias mil documentos .html.

Esto era desagradable. Obviamente.

Y llevo a una pregunta obvia: y qué si pudiéram os generar HTML programaticamente, como desde una base de datos o algo?

Y así nació CGI, y dió inicio a la edad de Bronce de la web. Teniamos herramientas, finalmente, para automatizar algunas de nuestras tareas repetitivas. Podiamos manejar entrada de datos por parte del usuario! Conectar páginas web con bases de datos! Generar contenido mediante plantillas!

Pero CGI apesta. Es horriblemente lento. Peor aún, incentiva un estilo de desarrollo increiblemente malo. O tenes docenas (cientos!) de programas .cgi, con toda clase de código repetitivo… o terminas con un único, gigantesco, monolítico go.cgi. CGI usualmente es escabrosamente difícil de mantener. El hecho de que la mayoria del CGI de esta era este escrito en Perl — o peor, C — no ayuda.

Entonces, nuevamente, la gente inteligente comenzó a hacer preguntas. Al principio, preguntamos, “como podemos hacer que CGI apeste menos?” Nótese que esta no es una pregunta muy complicada — no es replantearse como deberia funcionar el desarrollo web — pero aún así condujo a un gran salto hacia adelante: La primer generación de servidores de aplicaciones.

Estoy hablando aqui de cosas como mod_perl, mod_python, y especialmente PHP. PHP, que es esencialmente “CGI hecho bien”, ganó una predominancia abrumadora, y la edad de hierro de la web comenzó2.

Ahora, mencioné que las preguntas que llevaron a PHP no eran muy buenas preguntas, y por eso el salto no fue tan dramático. La edad de hierro es muy similar a la edad de Bronce: las herramientas se ven iguales, solo que usan tecnologia un poco mejor. Eso es, PHP sufre de la mayoria de los problemas de CGI, pero en un grado menor.

El problema mas grande, al menos en mi cabeza, con las primeras etapas del desarrollo web es que la forma de pensar esta orientada a páginas. Todo lo que hicimos en esos años tempranos fue cambian pagina.html por pagina.cgi por pagina.php. Todavia representabamos a los sitios web como una coleccion de páginas, escritas en una seguidilla de lenguajes que iba mejorando.

Entonces la revolución verdadera vino cuando empezamos a cuestionarnos esta suposición. “Y que pasaria si,” nos preguntamos “pudieramos pensar acerca de esto como aplicaciones, no páginas?”

Esta pregunta llevó directamente a la creación de Django, y a la revolución industrial: Frameworks Web.

Ahora, las revoluciones técnicas suceden orgánicamente. Tomemos la Imprenta: Aunque Gutenberg es acreditado por su invención, en realidad también fue descubierta por otros 2 inventores3 en europa alrededor de esa fecha. De hecho, es inexacto dar crédito a cualquiera de estos hombres por la invención de la imprenta: Material impreso que data del siglo VII fue encontrado en China y Korea4.

Como la imprenta, entonces, los frameworks existieron mucho antes que la cosecha actual (WebObjects por ejemplo). Como la revolución industrial, la revolución de los frameworks sucedió en muchos lugares, y de muchas maneras diferentes. No quiero pretender que Django fue el primer framework — o uno de los primeros — ni que Django nació de la nada. Django es, como los otros frameworks de nuestra época, un producto de esta era, y de estas preguntas acerca del desarrollo web.

 

Nota del editor

Buscas hosting de calidad?
asegura tu tranquilidad contratando tu plan de hospedaje con Okhosting.com , una empresa confiable y con experiencia en México, en todos nuestros servicios de alojamiento web ilimitado, gratis asesoría ayuda y orientación para principiantes y avanzados, compra tu dominio .MX y si aun no tienes sitio web utiliza nuestro programa para hacer paginas web en minutos,  te invitamos a conocer nuestros planes de alojamiento ahora con mas espacio y con mas funciones profesionales. OKhosting.com  todo lo necesario para estar en internet

 

La era industrial: Frameworks Web

Ahora nos encontramos a nosotros mismos en la era industrial, la era del Framework. Como estoy hablando mucho de frameworks, creo que vale la pena clarificar a lo que me refiero. Según lo veo, las caracteristicas principales de un framework web son las siguientes:

  • Operan a un nivel conceptual alto. En vez de pensar acerca de HTTP, HTML y “páginas” web, los frameworks nos permiten pensar y operar al nivel de “aplicacion web”. Esto significa menos código, y tambien nos permite ser mucho mas ambiciosos acerca de lo que estamos construyendo.

  • Los frameworks proveen bloques mucho mas grandes para construir aplicaciones.

    Me gusta utilizar la analogia de la construcción: tradicionalmente, la mayoria de las casas estan hechas de madera: Solo tenés que clavar un monton de maderas, una por vez, hasta que la casa finalmente aparece. Los materiales son simples: madera, clavos, pegamento, tejas, ladrillos. Tenes mucha flexibilidad, pero la construcción toma mucho tiempo.

    Hoy en dia hay otra opcion: casas prefabricadas. Aquí, la casa esta hecha de muchas secciones grandes en una fábrica, automaticamente en su mayor parte. Cada habitación, prefabricada, es cargada en un camión y la grua ensambla la casa en su sitio. La arquitectura esta mas restringida — tenes que armar la casa usando las opciones de habitaciones soportadas por la fábrica — pero podes estar mudandote a la casa nueva literalmente 30 dias despues de aceptar los planos finales.

  • Los frameworks alientan el desarrollo veloz. No es coincidencia que la Edad del Framework es también la edad del desarrollo Ágil. Ágil, XP, Scrum, etc. — los frameworks se lucen mas cuando son utilizados en un estilo de iteraciones rápidas.

  • Los buenos frameworks son software libre. I no creo que tenga que justificar este punto a esta audiencia en particular, así que es suficiente decir que no es accidental que no haya ningún framework privativo con muchos seguidores del que valga la pena hablar5.

  • Finalmente, los buenos frameworks hacen que el desarrollo sea divertido. La gente de negocios suele pensar que este es un requerimiento tonto. No lo es. La mejor parte del mundo de los frameworks web es nuestro sentido de la diversión: la diversión motiva, lleva a la experimentacion, y así a la innovación.

Que sigue?

Describí donde estamos, entoces… que sigue?

La mejor manera de predecir el futuro del desarrollo web, creo yo, es continuar preguntandonos la pregunta que llevó a todos los avances del pasado: que apesta, y como podemos arreglarlo?

Entonces: Que apesta acerca del desarrollo web?

Inter-operabilidad

Los frameworks web modernos apestan en la inter-operabilidad. Los frameworks son buenos. Pero inevitablemente nos encierran. El encierro es malo.

Es importante darse cuenta que la parte mas importante de inter-operabilidad es con el código del usuario, y francamente los frameworks web suelen ser malos en esto. Una verdad fundamental del software es que mientras crece y se vuelve mas maduro, también se vuelve mas específico de un dominio y menos genérico. Voy a hablar mas de esto en un momento; La parte importante por ahora es que los frameworks genericos deberian poder ceder el control a reemplazos mas específicos del dominio en la medida en que la pila de herramientas crece. La mayoria de los frameworks no hace esto.

Por supuesto, la mayoria de la gente piensa en la inter-operabilidad como inter-operabilidad entre múltiples frameworks. Nadie esta haciendolo muy bien aquí, pero desafortunadamente el mundo web de Python es peor que el promedio. Hay mucha fragmentación en la comunidad web, y francamente Django no esta ayudando. Eso es un bug en la comunidad de Django, y hay bugs similares en todo el mundo web Python. Necesitamos solucionarlos.

WSGI esta ayudando con esto; WSGI es lo mejor que le pudo pasar al desarrollo web en python. Pero no podemos dormirnos en los laureles: WSGI tiene problemas serios. Estan fuera de tema aquí, asi que simplemente voy a apuntarlos al Hablemos de WSGI de James Bennett y a decirles que estoy de acuerdo.

Tambien deberia mencionar Rack. Rack, en resumen, llegó cuando el mundo Ruby, enfrentando problemas similares a los que enfrentamos en pythonlandia, crearon un ‘web gateway’ inspirado en WSGI. Fue un exito rotundo: Rails 3 esta siendo reescrito en Rack. Rack es francamente un poco mejor que WSGI; Nosotros los pythonistas deberiamos estar avergonzados por eso.

El problema principal, sin embargo — el elefante en la habitación — es que los gateways apestan también. Los gateways no son APIs. Hay un limite — y es uno muy bajo — al nivel de inter-operabilidad que podes obtener si la unica interface de la que dispones es un gateway. Incluso si mejoraramos WSGI — y deberiamos — no nos va a llevar muy lejos.

Peor aún, herramientas como WSGI y Rack no sirver para ayudar la inter-operabilidad entre lenguajes. Realmente me gustaria escribir partes de mi aplicacion en Python, partes en Clojure, partes en Ruby, y hasta partes en Perl. Cosas como los proxies web, SOA, ROA, y las máquinas virtuales ayudan con esto, pero como los gateways no son APIs no podemos llegar muy lejos.

Esto va a ser un problema difícil de solucionar, aunque solo nos enfoquemos en Python. Tenemos un monton de comunidades separadas, todas formadas por voluntarios. Muy pocas personas tienen conocimiento superpuesto, pocos saben como navegar múltiples estandares de la comunidad, y todavia menos tienen el impetu para trabajar en inter-operabilidad. Casi nadie esta pensando en inter-operabilidad multi lenguaje.

Pero estas cosas son increiblemente importantes. Si django desaparece, estaré triste. Pero si python falla como un lenguaje web, voy a estar devastado.

Rich web applications

Estoy extremadamente excitado con HTML 5. De hecho, creo que podria ser lo mejor que le pasó a los frameworks web. Si las aplicaciones web realmente pueden reemplazar a las aplicaciones de escritorio, entonces los frameworks van a ser el lugar donde uno deberia estar, y python la rompe en este ámbito.

Ahora mismo, sin embargo, las herramientas que tenemos no son buenas para crear ‘rich internet applications’ La vanguardia actual es lamentable. Los dos enfoques que he visto parecen ser, o construir dos capas MVC en el cliente y en el servidor, y pegarlas de alguna manera, o inventar un framework muy rígido que corre en el backend con un front-end generado, como GWT o SproutCore. Ninguno de los dos enfoques me agrada mucho.

Por ejemplo, miren 280Slides. Es una pieza de tecnologia web asombrosa — el navegador realmente desaparece; es difícil decir que no estas en una aplicacion de escritorio nativa, es increible.

Sin embargo, los desarrolladores creyeron que 280Slides seria literalmente imposible de escribir usando cualquiera de las tecnologias web actuales. No solo construyeron su propio framework, Cappuccino; sino que inventaron un nuevo lenguaje Objective-J!. Si esto se hace moda, es preocupante.

Manejando complejidad (alias el problema del despliegue)

Es un hecho bien conocido que las aplicaciones web se estan volviendo mas complejas, y la lista de cosas que necesitas para desarrollar exitosamente, desplegar, y escalar una aplicacion web, se esta haciendo cada vez mas larga.

Resulta ser que escribir la aplicación es ahora la parte facil; manejar el resto de la pila de herramientas que necesitas para un despliegue exitoso puede ser realmente imposible. En otras palabras: ahora todos somos operadores

Hace un tiempo, Leonardo Lin recopiló esta lista de todas estas “otras cosas” de las que necesitas preocuparte luego de desarrollar tu aplicación:

  • Mediciones del API
  • Backups & Snapshots
  • Contadores
  • Herramientas de manejo de Cluster/Nubes
    • Instrumentación/Monitoreo(Ganglia, Nagios)
    • Contingencia.
    • Agregar/quitar nodos y hashing de nodos.
    • Auto-escalamiento para recursos en la nube.
  • Protección a CSRF/XSS
  • Retención/Archivado de datos
  • Herramientas de despliegue
    • Multiples Devs, Staging, Producción
    • Actualizacionens al modelo de datos
    • Hacer despliegues
    • Multiples versiones (betas selectivas)
    • Bucket testing
    • Deshacer despliegues
    • Manejo de Redes de distribución de contenidos
  • Almacenamiento distribuido
  • Almacenamiento distribuido de Logs, analisis
  • Graficado
  • HTTP Caching
  • Filtrado de entrada y salida
  • Memory Caching
  • Key Stores no relacionales
  • Rate Limiting
  • Almacenamiento relacional
  • Colas
  • Mensajeria en tiempo real (XMPP)
  • Busqueda
    • Por rangos
    • Geografica
  • Sharding
  • Smart Caching
    • dirty-table management

Si, un desarrollador web moderno realmente necesita entender estas cosas. puaj.

Las buenas noticias son que hay software libre para satisfacer todas estas necesidades. Las malas noticias son que estan todos inmaduros, piezas separadas sin conexiones unas con otras. Levantar la mitad de estas cosas e integrarlas es una tarea monumental.

Hay una gran oportunidad para python aquí. Python ha sido utilizado historicamente como un lenguaje de “pegamento”, aunque recientemente hemos intentado des-enfatizar ese aspecto. No es nada para avergonzarse: Python es un muy buen lenguaje de pegamento.

Python podria facilmente ser el pegamento que evita que toda esta pila se caiga.

Escala

El uso de internet esta creciendo explosivamente. Mundialmente se ha duplicado 2 veces desde el 2000… y la penetración mundias es de solo un 25%6. Este número solo va a seguir subiendo.

Mientras tanto, los sitios web estan volviendose mucho mas complejos. Piensen en el 2000 — podrian haberse imaginado un sitio como 208Slides en ese entonces?

El trafico esta creciendo, el usuario promedio esta gastando mas y mas tiempo en la web, y piensen en lo que va a suceder cuando la internet móvil explote.

Vamos a tener que aprender a lidiar con mas y mas trafico. Y los frameworks son malos en escalar.

Los frameworks son muy buenos en tareas genericas. Se supone que lo sean: abstraen las dificultades comunes. Pero mientras las aplicaciones crecen en escala, necesitan volverse mas y mas especificas a su dominio para poder lidiar con la escalada. Hay una correlación directa entre el tamaño de un sitio y que tan específico es.

Esto usualmente se descompone de la siguiente manera:

  • Desarrollas tu primer aplicación de juguete usando Framework X. (En el mundo Django esta parece ser un Blog — parece que al menos 75% de los desarrolladores de Django han construido su propio blog.) Esto usualmente sale muy bien.
  • Feliz y exitoso, desarrollas un producto con el framework, y lo lanzas. Esto usualmente va bien también — los sitios al punto de lanzamiento inicial son todavia muy similares entre si, y los frameworks son excelentes hasta aquí.
  • En la medida que tu sitio crece, comienza a hacerse un poco doloroso, y necesitas reemplazar algunas partes del framework con partes específicas del dominio. Esto usualmente no es muy malo: La mayoria de los frameworks, Django incluido, son suficientemente modulares que podes reemplazar las partes mas comunes, menos escalables.
  • Un dia te convertis en Twitter, y se te descarrilan los patos. Escencialmente terminas teniendo que tirar todo el framework a la basura para reescribir todo, desde cero, en formas muy muy especificas, solo para lidiar con las cantidades exuberantes de tráfico que tenés.

Los frameworks funcionan increíblemente bien para hacerte empezar rápido… y después fallan miserablemente cuando se enfrentan a las necesidades específicas de los sitios grandes.

Esta es una situación imposible para los desarrolladores de frameworks: Al optimizar para un comienzo rápido, enfocandonos en las necesidades comunes, estamos esencialmente garantizando la futura derrota. Recuerdan la controversia de “Rails no escala” es año pasado? Puedo garantizarles que solo es cuestión de tiempo hasta que haya una situación de “Django falló!”.

Los frameworks deberian desvanecerse agraciadamente en la medida que los reemplazas, parte por parte, con código específico del dominio. (A esto me referia antes, con que inter-operabilidad es tambien un problema de escalado.) Ahora mismo, no lo hacen.

Concurrencia

Por supuesto, si estas hablando de escalar, entonces necesitas hablar acerca de la concurrencia. Exacto, voy a hablar de ese tema. Voy a hablar del GIL. No se preocupen, no voy a quejarme ni insistir mucho.

Primero veamos un poco de microprocesadores, quieren?

Hoy dia, podés comprarte un Intel Nehalem, el mejor de la linea, por unos dos mil dolares. Tiene 2 hilos de hardware por core, y esta disponible en configuraciones de 8-cores. Esto significa 16 threads de hardware en un solo slot, así que podés armarte una máquina con 64 threads de hardware, (4 CPUs, 8 cores por CPU, 2 threads por core)

Por supuesto, si te querés poner serio podrias comprar algo como el UltraSPARC T2 (a.k.a. Niagara) de Sun. Este chip tiene 8 cores, 8 threads por core, y te dan 2 de ellos por máquina. Si, el futuro de está máquina esta en duda7, pero Sun ha estado liderando en el campo de la concurrencia por bastante tiempo. Es solo cuestion de tiempo hasta que Intel y AMD lo alcancen.

Obviamente la concurrencia va a ser un tema muy importante en el futuro. Ya lo es de hecho.

La mayor parte de mi razonamiento al respecto viene de Ted Leung. Yo respeto mucho a Ted, y me entristece decirles que Ted dice que estamos jodidos. Temo que estoy comenzando a estar de acuerdo. Hasta algun punto, la arquitectura de “shared-nothing” de la mayoria de las aplicaciones web significa que podemos hacer StartServers 128 para lidiar con 128 threads, pero mientras las aplicaciones crecen, terminas teniendo problemas con el “shared nothing”.

La mayoria de los lenguajes solo puede saturar un core realmente, y si solo podés usar un solo core estás en problemas.

Ahora, en el mundo de la concurrencia están pasando cosas muy interesantes hoy dia. Cosas copadas como Actors, STM, persistent data structures, dataflow, tuple spaces, y más. El ensayo A survey of concurrency constructs de Ted es una buena introducción a estos términos si no los han oido aún.

Desafortunadamente, casi todo este trabajo increible esta sucediendo en lenguajes relativamente obscuros como Scala, Erlang, Clojure o Haskell. Casi no hay movimiento hacia adelante por parte de la comunidad de Python. Si, ya se sobre Twisted, Kamelia, Eventlet, etc.; Estos son solo modificaciones a threads o concurrencia basada en IO; Hay muy pocas cosas nuevas sucediendo en python.

Y aunque algunas veces es considerado taboo decirlo, tenemos que ser honestos: Esto es parcialmente culpa del GIL. No esta claro si el GIL hace descartar digamos STM, pero casi ni importa: La existencia del GIL manda a todo el mundo interesado en concurrencia a buscar pasturas mas verdes.

Tengo esperanza en Unladen Swallow: el prospecto de quitar el GIL de Python es un primer paso prometedor. Sin embargo, lo unico que realmente obtenemos de eso son mejores threads, y los threads apestan como mecanismos de concurrencia. Quiero mis Actores!

Aquí es donde nosotros los tipos de la web necesitamos su ayuda. Operamos tanto tiempo en un alto nivel de abstracción que simplemente no estamos calificados para darnos cuenta como mejorar la concurrencia en python. Al menos, yo no lo estoy. Francamente casi ni entiendo los threads luego de una decada de usarlos, y no hay manera de que vaya a ser uno de los que implementen STM en Python.

Ayuda!!

Como conclusión, los invito a que imaginen el desarrollo web en el año 2020. No es un año arbitrario: es la últma llamada para HTML 5, por lo que tiene sentido pensar sobre cómo va a ser la web cuando HTML 5 esté maduro. Cuando finalmente estemos desarrollando el tipo de aplicaciones con las que estamos empezando a soñar hoy.

No estoy seguro si estaré o no usando Djano en el 2020. Espero que si, por supuesto, pero también podría ser que Django simplemente no pueda adaptarse a la nueva era de desarrollo web.

Sin embargo, si en 2020 no sigo usando Python voy a estar seriamente encabronado…

Joel nos dice que el buen software lleva 10 años, pienso que debemos empezar ahora mismo. Cómo podemos trabajar en hacer de Python el lenguaje elegido por los desarrolladores del 2020?

Primero, necesitamos mejor interoperabilidad. Un mejor WSGI — quizá WSGI 2? — va a ayudar, pero necesitamos mejor comunicación y mejores APIs que trabajen entre frameworks.

La comunidad Django necesita hacer un mejor trabajo en este sentido y estoy asumiendo la responsabilidad para que esto ocurra. Sigan quejándose conmigo sobre la falta de interoperabilidad de Django y yo voy a seguir trabajando para arreglarlo.

Pero mas que eso necesitamos verdaderos líderes en esto. Alguien que pueda mostrarnos el camino y pueda mantener un ojo mas macroscópico y no concentrado en un framework en particular.

Algún interoperador web Python BDFL quizás?

Necesitamos salir al frente de HTML 5. Hay una oportunidad enorme para que Python sea el lenguaje por excelencia para los back-end de las aplicaciones desarrolladas en HTML 5. Tenemos que empezar a pensar en esto ahora.

Ya hicimos una estupenda transición al dejar de pensar en “páginas web” para comenzar a pensar en “aplicaciones web”. Es tiempo de una nueva transición en la que empecemos a pensar sobre un “web site holístico” y toda la tecnología asociada a él. De nuevo, hay una enorme oportunidad para Python: puede ser lo que una de nuevo las herramientas necesarias para que el proceso de despliegue sea placentero nuevamente.

Sueño con un framework para el despliegue de herramientas, todo unido por Python, probablemente construido sobre WSGI 2.

Necesitamos pensar en la escala desde el día uno. Esto significa ser increíblemente escéptico de nuetro propio trabajo, preguntándonos contínuamente dónde es que va a fallar. Tenemos que planificar para el día en que nuestro framework deje de ser usado.

Y mierda que necesitamos mejor concurrencia.

Gracias.

Argentinean Spanish translation of Snakes on the Web.
Translated by Nubis, Gutes.

Blog, artículos y noticias