Estás leyendo la publicación: La historia de dos ex-ingenieros de Uber que crearon una plataforma SaaS para impulsar la productividad de los desarrolladores
Fundada por los ex ingenieros de Uber Naomi Chopra y Haritabh Singh, Hatica se incubó en el Programa Accel Founderstack en 2020. Se formó una plataforma de ingeniería basada en SaaS, Hatica, con la intención de medir la productividad de los desarrolladores y ayudarlos con una mejor gestión del tiempo desde la pandemia obligó a muchas empresas a cambiar al trabajo remoto.
En enero de este año, Hatica recaudó USD 900 000 en su ronda de financiamiento previa a la semilla liderada por Kae Capital, seguida por Titan Capital, iSeed Ventures y el inversionista ángel GBS Bindra. Chopra afirmó entonces que el sistema de la empresa aún se encontraba en etapa beta y se espera que sea lanzado al mercado para el primer trimestre de este año. Hablamos con él sobre cómo se ve la pila tecnológica de Hatica y las lecciones aprendidas en el camino.
OBJETIVO: ¿Cuál es la pila tecnológica que usa Hatica? ¿Cuáles son los detalles de su cuota de pila?
Noemí Chopra: Hatica está construido principalmente con Typescript y Golang. Su front-end se basa en React, mientras que el back-end es un conjunto de microservicios en Node y Golang que se ejecutan en Kubernetes junto con Temporal para orquestación y Hasura como capa de acceso a datos. Su pila de datos se basa en Postgres, Clickhouse y Elasticsearch.
AIM: ¿Cómo decidiste tu cuota de stack? ¿Cuáles son los factores que consideró en la toma de decisiones?
Noemí Chopra: Los factores que influyeron en la decisión de nuestra pila tecnológica fueron una combinación de la experiencia de los fundadores y la disponibilidad de talento, junto con el factor más importante de todos, que era esencialmente qué tan adecuada era la pila para un sistema de E/S y uso intensivo de datos. como el nuestro.
Nuestros factores estaban sesgados hacia nuestra experiencia cuando recién comenzábamos, pero a medida que crecíamos, nuestra decisión giró en torno a elegir la mejor pila para la solución y al mismo tiempo garantizar el acceso al talento y el apoyo de la comunidad.
OBJETIVO: ¿Hatica ha estado usando la misma pila tecnológica desde 2019? Si no, ¿cuáles fueron las razones para migrar a una pila tecnológica diferente?
Noemí Chopra: No, nuestra pila y arquitectura se veían muy diferentes de lo que son hoy. Comenzamos con una pila de Javascript más simple compuesta por microservicios que se ejecutan como contenedores en el servicio AWS ECS, atendidos por las API de GraphQL con tecnología de Hasura en una base de datos de Postgres. Eso nos ayudó a construir prototipos rápidamente.
A medida que ganamos terreno y comenzamos a crecer rápidamente, migramos al uso de Golang para algunos servicios junto con una arquitectura más escalable impulsada por Temporal para la orquestación de microservicios y Clickhouse para atender consultas analíticas. Todo esto ahora está alojado en clústeres de Kubernetes.
OBJETIVO: ¿Cómo abordó Hatica el proceso de migración? ¿Fue costoso migrar?
Noemí Chopra: La migración fue costosa en términos de tiempo y esfuerzo, pero solo a corto plazo. Los beneficios a largo plazo de una arquitectura más escalable y robusta nos han servido bien a medida que crecemos rápidamente en la base de clientes.
OBJETIVO: ¿Cuáles fueron los contratiempos que usted o sus usuarios enfrentaron durante la migración? ¿Cómo solucionaste los problemas tecnológicos durante este tiempo?
Noemí Chopra: Un contratiempo al que nos enfrentamos durante la migración fue el hecho de que nuestra capa de autorización, que decidía a qué puede acceder quién, se volvió demasiado compleja, ya que teníamos que admitir dos conjuntos diferentes de API y capas de acceso a datos, tanto antiguas como nuevas, hasta que migramos por completo. . Resolvimos eso completando primero nuestro conjunto de pruebas unitarias para la capa de acceso a datos para evitar que los problemas de permisos de acceso entren en producción.
OBJETIVO: ¿Cómo cree que ha evolucionado el viaje tecnológico de Hatica desde sus inicios?
Noemí Chopra: Hatica comenzó como un conjunto de tableros para gerentes de ingeniería con poca o ninguna personalización disponible para ellos. A medida que ganamos terreno, necesitábamos brindar una capacidad de configuración que ayudaría a nuestro producto a admitir diferentes tipos de flujos de trabajo de ingeniería. Este fue el primer hito cuando comenzamos a reconstruir muchos de nuestros microservicios. Pero el cambio más grande se produjo cuando aumentamos el tráfico en un período de tiempo muy corto cuando comenzamos a incorporar equipos grandes. Esto nos llevó a evolucionar nuestra pila de datos general, lo que ha supuesto un esfuerzo considerable. Afortunadamente, adoptamos algunas mejores prácticas clave desde el primer día, lo que nos ayudó a migrar los sistemas componente por componente con muy poco tiempo de inactividad.
OBJETIVO: ¿Cuáles son algunas de las lecciones más valiosas que aprendiste que te gustaría compartir con otras nuevas empresas en ciernes?
Noemí Chopra: No elija una pila para resolver para el próximo millón de usuarios; elige algo con lo que puedas hacer un prototipo rápidamente. Juega con tus fortalezas, aunque podría haber otras herramientas más apropiadas para el problema; por ejemplo, elija un lenguaje de programación en el que sea bueno y que simplemente funcione para su solución, en lugar de elegir un nuevo lenguaje interesante.
Elija una pila para la que pueda encontrar talento fácilmente. De todos modos, hay mucha competencia para contratar talentos de ingeniería, no lo haga más difícil eligiendo una herramienta nueva y brillante que es difícil de aprender, al menos no cuando recién comienza.
No reinventes la rueda. Intente buscar una solución robusta de código abierto cuando implemente un componente o un servicio. Si no resuelve su problema por completo, intente extenderlo en lugar de implementar una solución desde cero.
Existen algunos conceptos básicos y fundacionales y las mejores prácticas con las que seguramente debería comenzar, como usar ID únicos como UUID para la mayoría de los recursos. Estas mejores prácticas son fáciles de adoptar desde el principio y difíciles de migrar.
Documente sus sistemas adoptando prácticas como escribir RFC. No solo impulsan la colaboración y las revisiones efectivas que dan como resultado una toma de decisiones sólida, sino que también dan como resultado automáticamente una buena documentación, que es esencial no solo para incorporar a sus nuevos compañeros de equipo, sino también para que los fundadores y los primeros ingenieros recuerden especificaciones y decisiones.
Use infra-as-code, como usar Terraform. Es más simple de lo que parece y lo pone en funcionamiento rápidamente utilizando paquetes de código abierto.
