Antecedentes de implementación de la solución
Retrocedamos un poco para ver la imagen completa del caso. La función empresarial del futuro producto que debería funcionar en la arquitectura Dysnix consiste en crear entornos multiusuario independientes para los usuarios que puedan crear múltiples canalizaciones de datos empresariales personalizadas basándose en el principio de código bajo y utilizar el conjunto de datos recopilados aplicándoles modelos de inteligencia artificial y aprendizaje automático. De esta descripción podemos extraer los principales requisitos de la arquitectura:
- Los usuarios finales son representantes de las industrias fintech, medtech, Web3 y empresas de varios tamaños que pueden tener el requisito vital de lanzar servicios similares en perímetros cerrados. Esto significa que la arquitectura que tenemos que crear tiene que ser independiente de las capas subyacentes y puede iniciarse de forma local o en la nube con el mismo éxito.
Para nosotros, como arquitectos, significa que tenemos que seleccionar un único conjunto de herramientas que funcionen, digamos, como un denominador común que nos dé la posibilidad de crear dicha arquitectura. Los requisitos para esta caja de herramientas seguían siendo relativamente altos: debía consistir en herramientas confiables, estandarizadas, compatibles y complementarias. Por lo tanto, no podemos confiar en algo demasiado moderno o exótico.
- Las funciones ETL de la arquitectura futura deben diseñarse sin problemas y cumplir con todos los requisitos de tenencia múltiple: todos los datos de un usuario final deben estar aislados de los demás, y todo debe estar protegido y bajo el control del propietario al 100%. El producto debería funcionar igual de bien en entornos separados bajo una carga de cualquier volumen. No importa si el usuario final solo quiere subir datos de Google Analytics más una hoja de cálculo de una sola página con clientes para analizar o diez fuentes de datos empresariales de los últimos 10 años.
Desde el punto de vista técnico, entendemos que debemos ofrecer opciones de transferencia, almacenamiento y escalado flexibles de datos para que cualquier proceso de ETL se desarrolle sin problemas. Sin una infraestructura preparada para estos desafíos, el producto no funcionará.
- También teníamos que preocuparnos por servir la parte del producto de los modelos ML. La conexión con esta pieza es esencial para ofrecer el valor del producto a los usuarios finales. También lo tuvimos en cuenta al crear la arquitectura del producto.
El paquete tecnológico que seleccionemos debe incluir tecnologías compatibles con la IA y la ML que funcionen sin mucho código adicional o integraciones complejas.
- Otro punto que siempre nos importa es el tiempo. Nuestro cliente debe disponer del tiempo suficiente para desarrollar, escribir el código utilizando nuestras guías de arquitectura y entregar el producto lo más rápido posible al mercado.
Los plazos ajustados para nuestro trabajo son un requisito típico para nosotros. Podemos afrontarlo gracias a la experiencia acumulada en decenas de otros proyectos, a los inventos internos ya preparados, a la amplia práctica del código abierto y a la capacidad de tomar las decisiones técnicas correctas a corto plazo.
Los requisitos eran precisos y continuamos con nuestro trabajo. Creamos un plan para hacer que las cosas sucedan.
Etapas del proceso de implementación
Esta es la vista desde un helicóptero de todo el proceso de implementación desde el principio hasta el momento final de la cooperación.
- Fase de consultoría: 2 semanas. Como resultado, el cliente obtuvo un concepto técnico de arquitectura
- Etapa de I+D SOW +: 2 meses.
During this stage, we conducted technology benchmarking for selecting the best fit for the client. Each part of the architecture was analyzed during the search for best-tailored solutions and estimated the possibility of their implementation. For example, in selecting the tools for serving ML models, we’ve come up with Seldon Core after reviewing over 7 other products.
- Implementación de la arquitectura: 2 meses.
- Pruebas de compatibilidad: se comprobó que todas las tecnologías seleccionadas funcionaban de manera eficiente y coherente.
- Preparación de la documentación y la orientación para los desarrolladores para cada componente y proceso
- Desarrollo de código: ~ 12 meses
- Por nuestra parte, brindamos servicios de apoyo y curaduría para el desarrollo.
- El proyecto se completó satisfactoriamente.
El conjunto tecnológico y la arquitectura del proyecto que hemos creado
Para cumplir con los requisitos del proyecto, creamos la arquitectura independiente de la nube y la capa subyacente basada en el conjunto de herramientas universales disponible para tareas similares que completamos anteriormente.
Seleccionamos cuidadosamente el conjunto de herramientas y tecnologías nativas de Kubernetes aplicables a nuestros objetivos. Diseñamos una solución con k8s por su disponibilidad, estandarización, previsibilidad y experiencia en el uso de estas herramientas. Teníamos que minimizar el número de integraciones ausentes o la necesidad de escribir código adicional, por lo que nos limitamos a utilizar la solución reutilizable al máximo, lo que supuso un enfoque bastante «ecológico», si se nos permite decirlo. Utilizamos herramientas basadas en Kuber no solo para la funcionalidad, sino también para las operaciones de orquestación. Todo lo hicimos a través del configurador k8s.
Sin embargo, no podemos decir que nuestro conjunto creado se haya vuelto demasiado común. La lista de herramientas incluye, pero no se limita a:
- Terraformar
- Kubernetes
- CD de flujo
- Pila Prometeo
- Istio
- Clúster de ElasticSearch
- Núcleo Seldon
- Prefecto Orión
- Jäger
- Pila de orgía
La arquitectura que creció en base a estas herramientas era moderna, estable, previsible, escalable, automatizada y compatible. Por lo tanto, nada podía entrar en conflicto con los requisitos de multiarrendamiento o en materia de seguridad.
Beneficios que aportamos al proyecto y lecciones que hemos aprendido
Como nos mostró la fase de desarrollo, los problemas que hemos estado intentando prever en las etapas de consultoría o I+D no estaban solo en nuestra imaginación. Con nuestra preparación, el equipo de desarrollo evitó múltiples callejones sin salida en lo que respecta a la selección de herramientas y su integración, el seguimiento de errores, la corrección y la rapidez de entrega e implementación.
También hay que mencionar dos puntos con respecto a los beneficios que hemos aportado.
- Código de infraestructura: con este enfoque aplicado, el cliente podrá agregar cualquier modificación a la infraestructura del proyecto en minutos y actualizarla sin problemas. La configuración completa no es una caja negra para el equipo interno, sino una guía explicativa de su producto.
- El sistema de rastreo distribuido se basa en Istio/Jaeger. Esta solución ayudará a los desarrolladores a encontrar problemas en toda la infraestructura en cuestión de minutos si aparecen.
En cuanto a lo que nuestros ingenieros aprendieron de este proyecto, estuvimos encantados de utilizar la pila de herramientas favorita y crear otra solución genuina para el cliente basada en Kubernetes. Creemos que esta tecnología seguirá siendo irremplazable para cualquier proyecto que necesite una solución clara y elegante.
.jpg)
.jpg)
