Tres razones para que los Ingenieros .NET utilicen Atlas Framework

6 septiembre
Tres razones para que los Ingenieros .NET utilicen Atlas Framework
DataArt lanzó recientemente Atlas Framework, un conjunto integral de herramientas de infraestructura para iniciar proyectos de desarrollo en GitHub bajo una licencia Apache 2.0.

Permite una integración y entrega continua desde el primer día de desarrollo, y es de gran ayuda a la hora de seleccionar, implementar y configurar herramientas clave de migración en la nube. Es compatible con el estándar .NET y puede ser útil tanto en proyectos reales de negocio como convirtiéndose en una plataforma para la capacitación y prueba de nuevas integraciones.

Atlas fue creado después de estudiar cuidadosamente las dificultades que surgen en los proyectos de nuestros clientes. El uso de un Framework listo para usar permite a las empresas reducir el tiempo de desarrollo y evitar riesgos al migrar un sistema a la nube o agregar nuevas funcionalidades. Los ingenieros podrán estar interesados ​​en el propio código Atlas, que incluye: organización de módulos, abstracciones y uso de bibliotecas de terceros.

Uno de los creadores de este proyecto, Nikita Kozlov, Solutions Architect de DataArt, detalló los tres motivos principales que existen para utilizar Atlas:

Soporte Multi-Plataforma

Al desarrollar en C #, podemos hablar sobre el tiempo de ejecución en términos de .NET Framework o el .NET Core multiplataforma más moderno. Si bien hay muchos artículos acerca de cómo migrar un proyecto de .NET Framework a .NET Core, es muy difícil encontrar un buen ejemplo en GitHub que permita comprender lo que realmente viene con tal migración. Como regla general, los autores de estas recomendaciones usan aplicaciones simples que son diferentes de los sistemas con los que hay que lidiar en la vida real. Atlas ayuda a comprender cómo soportar ambos frameworks en paralelo y qué consecuencias puede tener ese intento.

El propio Atlas se desarrolló originalmente bajo el Framework .NET 4.5.2, y la compatibilidad con el estándar .NET 2.0 se agregó más tarde. El proyecto muestra en detalle cómo se hizo esto.

 

Entornos aislados para nuevas integraciones

Yo mismo disfruto utilizando el código Atlas como sandbox. Tiene componentes listos para usar a los que se les puede agregar nuevas funciones y probar nuevas bibliotecas. Al mismo tiempo, tiene un núcleo listo para usar, con mecanismos de registro y manejo de excepciones incorporados, que permiten verificar el nuevo proveedor sin distraerse con detalles.

Digamos que tenemos un agente de mensajes y varios servicios. Un servicio envía un mensaje y otro lo recibe y hace algo. Digamos que estaba usando RabbitMQ y que, cuando se movió a la nube, decide probar Azure Service Bus. Para probar la nueva integración, es conveniente tener un entorno listo: Atlas permite lanzar rápidamente varios servicios por plantilla. La integración se lleva a cabo a través de componentes de terceros, y Atlas ya tiene abstracciones adecuadas. Todo lo que queda es proporcionar la implementación correcta.

De esta forma, brinda la oportunidad de conocer y probar diferentes patrones arquitectónicos en el desarrollo de software, por ejemplo: correlación de llamadas, registro estructural, etc.

 

Convenciones de código

Al comienzo del proyecto, Atlas permite que el nuevo equipo acuerde una visión de desarrollo común: cómo dividir el código en proyectos, dónde colocar esta o aquella funcionalidad, etc. Atlas no impone ningún estándar, obviamente, pero brinda una plataforma desde la cual iniciar. Es mucho más efectivo comenzar y comprender qué es exactamente lo que no le conviene, que coordinar los estándares dentro del equipo desde cero.

Damos la bienvenida a las mejoras de proyectos de los desarrolladores e invitamos a todos a compartir sus comentarios.