Mejorar nuestra infraestructura

From waze
Revision as of 18:02, 20 March 2012 by Adriansinger (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Algunos de ustedes, nuestros queridos usuarios, han tenido la amabilidad de compartirnos su opinión de que nuestras prioridades están erradas. En lugar de rediseñar la aplicación o agregar nuevas funcionalidades, opinan que deberíamos concentrar nuestros esfuerzos en la infraestructura, ya que el material nuevo se construye sobre una base endeble.

Más allá de que "infraestructura" es un término general que incluye distintos servicios, somos totalmente conscientes de que muchas de las cosas que prometimos desde el principio no funcionan como deberían. Esto es así, básicamente, con los procesos diarios que incluyen puntos, cuadrantes del mapa del cliente y edición de mapas. De hecho, desde la perspectiva del usuario todo esto no ha mejorado el último año, pese a nuestra insistencia en que "estamos trabajando en ello".

El hecho es que la mayor parte de nuestro equipo de desarrolladores está trabajando en nuestra infraestructura, y esa tarea no se ha detenido a pesar de la añadidura de nuevas funcionalidades. Hemos rediseñado constantemente el código de nuestros servidores y les hemos añadido otras mejoras.

Entonces, ¿por qué no ven ustedes esas mejoras? Aquí algunas razones:

Estamos creciendo muy rápidamente. Aunque muchas cosas no han mejorado, tampoco se han deteriorado, lo cual significa que hemos mejorado nuestra capacidad. Sólo que no lo suficientemente rápido. Hemos visto es que cada vez que lanzamos un nuevo servicio de código de servidor rediseñado, en sólo unos pocos días la gran cantidad de usuarios nuevos colman la capacidad disponible.

Algunas mejoras son transparentes. El último año hemos tenido dos grandes caídas de varias horas. Nos apoyamos en Amazon Web Services (AWS) para hacer correr nuestros servicios, por lo que cuando ellos tuvieron problemas, nuestro servicio cayó. Así que hemos trabajado los últimos meses (aún lo estamos haciendo) en relanzar todos nuestros servicios en una configuración redundante, con la que cada servicio se hospede en al menos dos zonas de AWS. De esta manera, si una zona cae, nuestro servicio continuará funcionando en la otra zona.

Procesos serializados y dependencias. Históricamente, nuestro proceso diario es un proceso serializado que involucra el análisis de las trazas de los usuarios, actualización de puntos (basado parcialmente en el análisis de trazas), actualización de cuadrantes, etc. Debido a que cada una de estas tareas depende de las otras, un problema en una de ellas hace retrasar todo el proceso. Aunque hemos mejorado y optimizado las diferentes partes de la cadena, siempre ha habido un eslabón débil que ha causado retrasos.

Lanzamiento y testeo. Lanzar cambios de infraestructura es un proceso lento, porque el efecto de un mal lanzamiento sería desastrozo.

Entonces, aunque hemos trabajado en la mejora de la infraestructura, esto no ha sido lo suficientemente rápido para satisfacer la demanda de ustedes, y hemos limitado la voluntad de ustedes de contribuir con tiempo y ganas a la mejora del servicio. También hemos fallado en comunicarles todos los problemas, cómo los procesamos para solucionarlos, y cuánto tiempo demandará. Una vez más, debo decirles que las cosas cambiarán, muy pronto y para bien. Pero en lugar de promesas, les contaré en qué estamos y algunas fechas:

Cartouche. Hemos lanzado recientemente el nuevo cartouche, que tiene una nueva interfaz y que, creemos, significa una gran mejora. Pero no se trata sólo de un proyecto de cambio de interfaz, sino que hemos reescrito el código de servidor sobre el que corría el cartouche antiguo. El nuevo código nos permite añadir más y más servidores a medida que crece la demanda, y estoy seguro de que ustedes ya perciben que el cartouche corre mucho más rápido ahora. Todavía estamos limitados por la cantidad de ediciones que podemos guardar por segundo, pero por ahora tenemos mucho espacio para crecer. Hemos lanzado el nuevo código antes de lo planificado, porque el código antiguo no podía sostener la sobrecarga y no había forma de aumentar su escala. Desafortunadamente, aún tenemos algunos problemas con esto y el cache del cartouche todavía incluye datos malos, que debemos reconstruir. Tenemos planificado empezar a trabajar en ello dentro de unos días y esperamos que esto pueda solucionar muchas de las inconsistencias con las que ustedes se encuentran día a día. Hasta que reconstruyamos todo, dentro de unos días lanzaremos una nueva actualización, que devolverá los mensajes de error detallados (actualmente, al equivocarte en una tarea de edición, sólo recibes un mensaje general de error que no especifica en qué te has equivocado). Estos mensajes les ayudarán a saber en qué se han equivocado al editar, y en muchos casos a resolver el problema y volver a guardar.

Puntos. Hemos estado trabajando para terminar con las dependencias que eran necesarias para el cálculo de puntos. Estos cálculos se basan en una cantidad enorme de eventos producidos por nuestro servicio. Como parte del proceso de aumentar en escala nuestro código de servidor, ahora usamos Hadoop para procesar los cálculos. Así, a medida que los datos crecen, podremos añadir más instancias de una manera más fácil. Nuestro primer objetivo es ser capaces de actualizar los puntos cada día sin tener que depender de otros procesos. La mayor parte del desarrollo ya fue terminada y tenemos pensado lanzarlo dentro de una semana o dos. Nuestro próximo paso (en el que ya hemos empezado a trabajar) será poder actualizar los puntos en tiempo real. Les mantendremos informados cuanto antes.

Unificando trazas. Ya habíamos reescrito el proceso que unifica trazas y ya puede ser aumentado a escala con sólo añadirle procesos. Sin embargo, recién ahora hemos terminado de desarrollar un sistema de soporte que puede acomodar y distribuir los datos de la unificación. Esto nos permite ahora hacer algunas partes del proceso de unificación casi en tiempo real. Nuestro objetivo es que puedas ver tus trazas en cartouche tan sólo una hora después de haber conducido con waze abierta (también podrás ver las nuevas vías pavimentadas y las cámaras añadidas). Junto con eso, recibirás el permiso de edición. Algunas partes del proceso de unificación (como la detección de giros prohibidos y sentidos de las calles) aún son hechas offline una vez al día, pero estamos trabajando para mejorar eso también y que pase a ser casi en tiempo real. El nuevo sistema está bajo testeo final y tenemos planificado su lanzamiento dentro de un mes.

Diferencias en los lanzamientos EE.UU./Mundo. Los problemas de mapa todavía son visualizados sólo en el sistema de EE.UU. Estamos plnificando lanzarlo en los servidores del resto del mundo, pero aún no tengo la fecha estimada de ello. Nuestra política es no tener diferencias como ésta, porque manejar diferentes configuraciones nos complica la vida.

Mejorar nuestros procesos diarios es actualmente nuestra primera prioridad en las tareas de infraestructura. Estamos dedicando todos nuestros esfuerzos en eliminar todas las dependencias y en rediseñar todo de modo que sea posible aumentarlo en escala. Nuestro primer objetivo es alcanzar iteraciones predecibles: sé que es muy frustrante trabajar en el mapa y no tener idea cuándo estará disponible en el cliente.´

Les mantendremos informados!