Cliengo migración y estrategia de contenerización

De tener su despliegue en Heroku, acudieron a DinoCloud para realizar una migración a AWS logrando así el mejoramiento indiscutible de su funcionamiento.

Sobre Cliengo

Cliengo es una empresa que nace en el año 2017 dedicada a impulsar relaciones comerciales ayudando a otros negocios a convertir usuarios en clientes y contribuir a escalar en el proceso comercial de sus propios clientes automatizando todos los canales de contacto. Los negocios que contratan a Cliengo puedan entregar a sus clientes una experiencia suprema con canales abiertos 24/7. Se integran a las tecnologías que ya utilizan dichos negocios y generan reportes que permiten optimizar la atención omnicanal.

Algunos de los productos que ofrecen son:
  • Chatbot Web
  • Chatbot WhatsApp
  • Chatbot Facebook Messenger
  • Chatbot Instagram
  • Chatbot eCommerce
  • Live Chat
  • CRM


Utilizan AI, se integran con otros CRMs del mercado, plataformas de email marketing y automation. A su vez, también se integran con más de 1300 aplicaciones que permiten simplificar la experiencia, conectando las fuentes de los datos de sus clientes y optimizando sus  resultados. 

Tecnologías Usadas

Amazon Elastic Kubernetes Service, Amazon Elastic Compute Cloud, Amazon Elastic File Service, Amazon Relational Database Service & Amazon ElastiCache. New relic, MongoDB Atlas y Cloudflare.

The Challenge

Cuando Cliengo llegó a DinoCloud tenían el principal desafío de migrar de Heroku a Amazon Web Services. Por otro lado existía la necesidad de construir los pipelines de integración continua y delivery continuo. Y por último, se hacía presente el desafío de dockerizar sus microservicios desarrollados en distintos frameworks (Java Play, Node, PHP).

Por otro lado tenían la necesidad de detectar el microservicio que les estaba generando un cuello de botella, lo cuál significaba un gran desafío debido a la cantidad de microservicios que se estaban utilizando en la plataforma. 

Nuestro enfoque

En una primera instancia se hizo un discovery, donde pudimos observar de qué estaban hechos, para poder entender en detalle la infraestructura decidimos diseñar un gráfico donde se veía plasmada la misma.

 El siguiente paso fue empezar a diagramar las épicas. Que resultaron en: 

En paralelo a lo mencionado anteriormente se efectuaba la migración de todo el contenido de la plataforma que tenían en Heroku a Amazon Web Services con Kubernetes, desplegando lo requerido esencialmente para que todas las herramientas funcionen con Kubernetes en Amazon.
Es decir que en una primera instancia se dockerizaron sus aplicaciones, ya dockerizadas y funcionando correctamente, se pasó a levantar en Terraform un cluster de kubernetes. Levantado el cluster de Kubernetes el foco estuvo en que la configuración inicial sea óptima para un funcionamiento correcto. Empezamos a construir los manifiestos de Kubernetes con los microservicios con los que contaban, en esta instancia se vio reflejada la falta de algunos, que fueron implementados luego de dicho descubrimiento. Al validar el funcionamiento de la plataforma, iniciamos los despliegues de pipelines con GitHub Action modificándose acorde a las necesidades del cliente. 

En cuanto a lo técnico

Cliengo tenía el inconveniente de que por cada aplicativo asociado a cada microservicios contaban con demasiados equipos que trabajaban sobre el mismo, entonces se generaba un problema, ya que, al tener múltiples equipos que trabajen sobre lo mismo, consecuentemente surgían complicaciones a la hora de tener que desplegar algo, de este modo lo que hacía el equipo de ese momento tenía lógicamente problemas con el desarrollo del equipo anterior, lo que generaba una inconsistencia a la hora de querer generar ciertos cambios. Básicamente esto se traduce a que  no contaban con un branch strategy. 

Es por eso que nuestro equipo investigó una solución para este problema, la cual terminó resultando en un branch strategy establecido, donde se efectuó a través de los pipelines, que cuando Cliengo generen una pull request, se despliegue dentro del cluster, en otro namespace, pero dentro del mismo cluster, desplegando así su funcionalidad sin afectar a todos los otros microservicios de develop que sabían que estaba funcionando. De este modo una vez que se comprobaba la funcionalidad se hacía un merge y lo combinaban con lo que estaba en develop, así se acortaba ampliamente la brecha de error, dado que cada equipo podía tener dentro del cluster su prueba sin afectar la del otro.

Los Resultados

Los resultados se resumen en la obtención de un cluster de Kubernetes en AWS 100% funcional, es importante destacar que también se logró dockerizar todos los microservicios sin mayores inconvenientes, con el funcionamiento de todos sus pipelines correspondientes y con una estrategia de branching, que logró satisfacer enormemente las expectativas de Cliengo, implementadas. También se pudo evidenciar una inconsistencia a través de New Relic y un Workload de automatización. Por último, y para nada menos importante, una migración de Heroku a Amazon Web Services en un espacio de develop efectuada. 

En DinoCloud nos encargamos de convertir la infraestructura actual de una empresa en una infraestructura moderna, escalable, de alto rendimiento y bajo costo capaz de cumplir con los objetivos de tu negocio. Si desea obtener más información, optimizar la forma en que su empresa organiza y analiza los datos y reducir costos, puede contactarnos aquí.

Nuestras oficinas

Argentina
Humberto 1° 630, Piso 4
Córdoba, X5000HZQ
Argentina.

Miami
40 SW 13th St Suite 102, Miami
FL 33130 USA
+1 574 598 4299

New York
67-87 Booth St #2H, Forest
Hills NY 11375
+1 571 322 6769

Colombia
Cra. 19a #103-19 Usaquén,
Bogotá 110111,
Colombia

Formulario de contacto

(*) Campos obligatorios