Closed alexfernandez closed 9 years ago
Esta charla es una versión de la que voy a dar en una conf, esta vez en primicia para MadridJS.
Muy bien, luce excelente
Suena genial, si no es antes de Abril no me la pierdo
Sounds interesting. Ahí estaré.
Mi voto por la charla +1
Cuando sera la conferencia en Madrid JS?
Visto que hay interés, podemos ponerla a finales de marzo.
:+1:
Me apunto. @alexfernandez, ¿has leído que @azaru no puede asistir si se hace en marzo? ¿Puede ponerse en abril?
Lo he leído, pero es complicado. Normalmente intentamos acomodar a ponentes y espacios, pero no podemos poner nuestra agenda en función de los asistentes porque sería una locura: imagina que la cambio por ese motivo, y alguien dice que no puede ir en abril y que prefiere marzo (o mayo): ¿qué hacemos en ese caso? :(
Además, en abril seguro que hay otra charla que también le interesa (la de HTML2 parece apasionante).
Me resulta tremendamente interesante. Por mi parte prefiero antes de abril, pero asistiría igualmente.
:+1:
i like it :+1:
Pinta estupenda :+1:
+1 por la charla.
+1
Decidir la arquitectura tiene que ser un asunto serio. ¿Dos, tres o más capas? ¿Qué base de datos usaremos: SQL, NoSQL o NewSQL? En muchas empresas hay departamentos enteros dedicados a decidir una arquitectura y luego refinarla hasta que sea perfecta. El caso es que no existe una arquitectura perfecta para todas las situaciones, y probablemente ni siquiera para una situación particular. El stack moderno tiene unos requisitos muy exigentes de funcionalidad, escalabilidad, y coste, que además están cambiando todo el rato. Así que, ¿cómo podemos esperar que una arquitectura rígida aguante en un entorno cambiante?
En MediaSmart Mobile tenemos que responder a muchos miles de peticiones por segundo bajo condiciones muy estrictas, aparte de añadir funcionalidades nuevas todo el tiempo para estar por delante de la competencia. Podríamos esperar que nuestra arquitectura aguante lo que le echemos; en lugar de eso le permitimos que evolucione según las condiciones y los requisitos nos lo piden. Nada es sagrado: ni las bases de datos (donde hemos hecho varias migraciones a gran escala en dos años) ni la configuración, ni siquiera el proveedor de cloud, intentamos mantener nuestras opciones abiertas a cualquier cambio que nos permita aumentar la escalabilidad o bajar los costes. La clave es mantener la arquitectura fluida, en lugar de casarnos con decisiones pasadas.
Ilustraremos los principios de la arquitectura fluida con ejemplos reales usando Node.js y JavaScript.
Bio Soy Alejandro Fernández, un desarrollador con 15+ años de experiencia (es decir, un viejales). Me gusta cacharrear, y desde que descubrí Node.js me quedé más pillado que un tonto con una gorra a cuadros. Me como las peticiones por segundo como si fueran churros.