Foto: Alex Smith | UnsplashBuenas tardes
Mi nombre es Victor Pryazhnikov, trabajo en el departamento de Características de Badoo . La tarea principal de nuestro departamento es desarrollar la funcionalidad que ven los usuarios de nuestro sitio y aplicaciones. Cuando me encontré con un artículo del cofundador de Unsplash, Luke Chesser, ella me intrigó por el hecho de que pudieron desarrollar un proyecto relativamente grande con un equipo muy pequeño. El enfoque del autor me impresiona con su pragmatismo y de alguna manera me recordó que no eres Google , así que decidí traducirlo.Una de las cosas más divertidas en el desarrollo de Unsplash es la gran escala y popularidad del producto.
En un día típico, nuestra API procesa más de
10 millones de solicitudes de
unsplash.com y miles de aplicaciones de terceros,
millones de eventos pasan por nuestra línea de procesamiento de datos, se agregan
60 millones de actualizaciones a nuestros feeds y servimos
60 millones de imágenes.Al mismo tiempo, nuestro equipo es relativamente pequeño: dos diseñadores, tres personas que trabajan con el frontend, dos con el backend y un ingeniero de datos. No tenemos un ingeniero de DevOps separado, y cada miembro del equipo pasa la mayor parte de su tiempo experimentando y desarrollando nuevas funciones para garantizar el desarrollo posterior del producto.
Aunque ya hemos logrado mucho con Unsplash, todavía estamos en el comienzo de su viaje como producto y negocio. Todavía tenemos algo que demostrar, y esto significa que todo el equipo necesita concentrarse en resolver problemas únicos de Unsplash, y no en los que cualquier otra compañía tiene, como organizar cálculos, seguridad de red, construir infraestructura, administrar dependencias, etc.
En los últimos tres años, hemos desarrollado un conjunto de principios que nos permiten centrarnos en el crecimiento y evitar problemas de escala. Desafortunadamente para aquellos que buscan una bala de plata, no estará aquí: es solo sentido común y un conjunto de principios que tomamos prestados de otros.
1. Utilice soluciones obvias aburridas
O ser pragmático.
Antes de embarcarse en la introducción de una nueva herramienta, una base de datos (RethinkDB, RocksDB, etc.), un nuevo patrón ("¡todo funciona!"), O una nueva arquitectura ("microservicios, ayuda"), pruebe todas las opciones obvias.
En el lado del backend, hay muy pocos problemas que no se pueden resolver de manera bastante efectiva utilizando herramientas estándar y bien conocidas y patrones probados como el almacenamiento en caché, el procesamiento por lotes, el procesamiento asincrónico y la preparación preliminar de los datos necesarios.
2. Céntrese en resolver los problemas del usuario, no en la tecnología.
Unsplash es un producto, no una empresa de tecnología. Recibimos una gran cantidad de dinero de los inversores para centrarnos en resolver los problemas de nuestro producto y el mercado, en lugar de tratar de lograr una reducción del tres por ciento en los costos operativos por el uso de tecnologías comunes.
Dedicamos nuestro tiempo al uso de tecnologías listas para usar de una manera que ayudará a resolver los problemas de nuestros usuarios y a aumentar la comunidad Unsplash. Estas son tareas exclusivas de Unsplash, y si logramos crear algo nuevo y valioso, podemos diferir la optimización hasta una fecha posterior, cuando estas optimizaciones del 3% pueden convertirse en la principal fuente de crecimiento.
Nuestros potenciales colegas que han escuchado sobre la escala de Unsplash y un pequeño equipo, el uso de imágenes e inteligencia artificial, características futuras, pueden estar confundidos por el hecho de que utilizamos muchas tecnologías, servicios y marcos listos para usar. Esto nos hace pagar un poco más en este momento, pero nos permite posponer el desarrollo interno de estas tecnologías por un tiempo y trasladarlo a los hombros de nuestros futuros colegas.
El proceso de diseño del código, la configuración de servidores, las dependencias del sistema, el procesamiento y análisis de datos, el procesamiento de imágenes y la personalización son ejemplos de áreas que hemos elegido
no centrarnos en nuestros recursos de ingeniería, sino utilizar servicios de terceros ya preparados para cada uno de ellos.
3. Gastar dinero en resolver problemas tecnológicos.
El otro lado del enfoque en los problemas del producto es el costo adicional de acceso a tecnologías estándar y servicios de terceros.
Se convirtió en una broma dentro de nuestro equipo. Dicen que mi primera reacción ante cualquier problema será la pregunta: "¿Has intentado resolverlo con dinero?". Pero esto no es una broma, sino uno de mis enfoques favoritos para resolver problemas.
La optimización de los costos asociados con la infraestructura y la tecnología es un problema tan común con soluciones simples y repetitivas que ninguna compañía de productos con inversionistas debería encargarse hasta que sienta que el crecimiento de la métrica principal ha dejado de ser su prioridad.
Cuando gastamos dinero en resolver problemas tecnológicos, desatamos las manos del equipo, lo que le permite concentrarse en problemas complejos recurrentes, como encontrar una manera de aumentar el tamaño de la base de usuarios en un 40% en el trimestre actual.
Entonces, estos son tres principios bastante simples, pero abstractos, que seguimos.
Pero, ¿cómo se ven en la práctica?
Si observa la arquitectura Unsplash, verá que es muy simple y casi aburrida (al menos para los estándares de 2017).
Un diagrama simplificado de las partes principales que componen UnsplashUsamos
Heroku siempre que sea posible para simplificar el diseño, la configuración, las pruebas, el soporte y el escalado de nuestras aplicaciones principales. Heroku es un tipo de magia que separa las partes de la aplicación y el proceso de desarrollo para que los miembros de nuestro equipo no necesiten estar familiarizados con él para desarrollar y diseñar experimentos.
Minimizamos agresivamente la cantidad de código que escribimos para la lógica de negocios de la aplicación (áreas moradas en la imagen). Al escribirlo, utilizamos activamente marcos creados por otras personas que, como expertos en sus campos, han desarrollado soluciones que funcionan con éxito en el 95% de nuestros casos de uso.
Utilizamos activamente Redis, Elasticsearch y Postgres en la producción. En el pasado, probamos otras bases de datos, pero siempre volvimos a estas tres, porque estamos seguros de que entendemos cómo se comportan bajo carga.
También utilizamos activamente colas de tareas, procesando asincrónicamente muchas operaciones, como actualizar, agregar y sincronizar datos entre diferentes fuentes.
Para el procesamiento de datos, utilizamos
Snowplow , un marco integrado abierto escrito en Scala, que elimina la necesidad de que nuestro equipo piense en organizar la entrada y la salida, y no en el procesamiento en sí.
También utilizamos un conjunto completo de servicios de monitoreo en la nube, como
Datadog ,
New Relic ,
Sentry y
Logentries , en lugar de implementar y mantener nuestra propia pila StatsD o ELK.
Subcontratamos el alojamiento y la infraestructura para entregar nuestras imágenes a
imgix , una empresa líder para trabajar con imágenes dinámicas. Si agregan alguna funcionalidad nueva, entonces nuestro equipo realiza un cambio en la URL, y nuestros usuarios también obtienen acceso a esta funcionalidad.
Registramos todas las acciones de nuestros usuarios en el servicio
Stream , utilizando su experiencia en la construcción y optimización de cintas personales altamente cargadas. Stream simplifica el procesamiento de miles de millones de acciones para nosotros y proporciona una API simple para entrar y salir, que funciona con tal productividad que nuestro equipo pasaría meses o incluso años para crear por sí mismo.
Nosotros no entrenamos algoritmos de reconocimiento de imágenes, sino que utilizamos
TinEye para búsquedas inversas de imágenes y
Google Vision para el reconocimiento y clasificación de imágenes.
Registramos todos los eventos de comportamiento en
Vero , una plataforma para trabajar con notificaciones y listas de correo, que nos permite transferir el trabajo con ellos a las manos de nuestros colegas que no son desarrolladores. Ellos mismos pueden crear cartas con un alto nivel de personalización, en función del uso complejo de los datos disponibles sobre el comportamiento del usuario.
Al mismo tiempo, nos estamos centrando en aquellas partes de Unsplash que pueden proporcionar una mejora en nuestra competencia central.
Durante el año pasado,
dividimos nuestra única aplicación Ruby on Rails en la API Rails, la aplicación web Node.js + React y creamos una aplicación de datos separada que recopila y procesa todas nuestras métricas internas y de producto.
Esto permitió a nuestro equipo crear funcionalidades que parecían casi imposibles en nuestra antigua pila que consistía solo en Rails. Después de compartir los problemas y las tecnologías de nuestras aplicaciones, nuestro equipo también tuvo la oportunidad de utilizar las mejores herramientas en cada una de las áreas:
- En la parte frontal, utilizamos React y Webpack junto con un pequeño servidor Express para admitir el procesamiento del servidor y la representación de solicitudes API. No vinculamos intencionalmente las herramientas de nuestro equipo frontend al backend con hacks temporales como react-rails o webpacker . La comunidad de JavaScript, sin lugar a dudas, lanza las mejores herramientas para trabajar con la interfaz, por lo que trabajar directamente con JavaScript permite a nuestro equipo ofrecer rápidamente una funcionalidad de alta calidad a los usuarios.
- En el backend, nuestro equipo continúa utilizando el mejor marco para desarrollar aplicaciones web simples: Rails. El ecosistema Ruby on Rails ofrece las mejores herramientas para la funcionalidad en el lado del backend, y dado que este marco es ampliamente utilizado, cualquier problema ya ha sido encontrado por alguien, documentado y con un alto grado de probabilidad, ya hay una solución para él.
- En el lado de los datos, nuestro equipo utiliza un pequeño servidor Express para recopilar y organizar el procesamiento de datos. El procesamiento en sí se lleva a cabo en Snowplow, que se ejecuta en el clúster de AWS, donde hay imágenes listas para usar que simplifican la configuración y la implementación. Esto permite que nuestro único ingeniero de datos, Tim, pase la mayor parte de su tiempo transfiriendo datos a Snowplow y obteniendo los resultados desde allí de una manera que facilite que otros miembros del equipo comprendan y obtengan información.
Nos
dedicamos activamente
a escribir pruebas , medir el rendimiento utilizando herramientas como
Scientist y Datadog, presentar cambios en forma de experimentos y
automatizar el trabajo con nuestra infraestructura tanto como sea posible.
Estamos desarrollando una
nueva API interna basada en GraphQL para acelerar las iteraciones de experimentos, nuevas características y productos que no dependen entre sí, ya que nos dimos cuenta de que nuestra API basada en REST se descompone sin un alto nivel de coordinación entre los equipos de datos, diseño, front-end y back-end - mejor Pasaremos este tiempo en funciones, no en cambios JSON.
Aunque es interesante trabajar en estos cambios, no los hacemos porque queremos calmar el picor de nuestro programador, sino porque resuelve nuestros problemas reales que nos impiden entregar rápidamente funcionalidad y desarrollo.
Creo que la mayoría de las personas que han leído hasta este lugar tienen una de tres conclusiones en mente:
- Unsplash es muy simple, por lo que puede utilizar este enfoque. Lo que hago es mucho más complicado, por lo que nos vemos obligados a hacer las cosas de manera diferente.
- Soy un desarrollador Suena muy aburrido. ¡Quiero crear un nuevo sistema de reconocimiento de imágenes de alta carga!
- Genial! No me importa, solo dame hermosas fotos gratis que pueda usar.
Las personas con la conclusión número 1, tienen razón: hay empresas que hacen cosas mucho más complejas que nosotros. Pero no hay muchos de ellos. Todos creamos los mismos sistemas, pero centrados en algunas otras cosas, y esta es la razón por la cual las soluciones utilizadas pueden abstraerse en forma de marcos y reutilizarse en diferentes proyectos (por lo tanto, la mayoría de las publicaciones sobre contratación son muy similares entre sí).
Personas con la conclusión número 2, depende de lo que encuentres interesante. Si desea ampliar los límites de la tecnología, vaya a trabajar para una empresa cuya misión es hacer esto. No hay muchos de ellos, pero la mayoría de las otras compañías simplemente no hacen esto.
A las personas con la conclusión número 3, les diré: "Sí, eso es correcto". Al final, esto es para lo que estamos haciendo todo esto.
Badoo está cerca de los principios de los que habla el autor. La principal diferencia es que nuestro proyecto es mucho más grande y el uso de servicios externos para nosotros a menudo es muy costoso. Además, muchas de nuestras soluciones son muy simples y tratamos de abordar cuidadosamente sus cambios comparando el costo de introducir y operar una nueva tecnología con los beneficios que recibiremos de ella. Algunas de nuestras soluciones son bastante anticuadas, ya que se crearon hace bastante tiempo, pero la transición a otras similares por el mero hecho de la moda no pagará los recursos gastados en ella. Al mismo tiempo, estamos listos para introducir nuevas tecnologías, si entendemos que pueden aportar beneficios reales (por ejemplo, PHP 7 , Go , Cassandra , Tarantool , Exasol ).