Los días 22 y 23 de noviembre, se celebró en Moscú la próxima conferencia DotNext 2018 para amantes de .NET. Mi nombre es Maxim Smirnov, encabezo el Centro de Competencia .NET en Alfa-Bank y quiero presentarles una versión de texto de una de las entrevistas tomadas al margen de DotNext.
Sobre la vida y las aventuras en nuestro banco, sobre la coexistencia con Java y los problemas de implementación, bajo el corte.
Cuánto .NET está en Alpha en general y por qué lo necesitamos
Recientemente, hemos crecido notablemente en términos de uso de .NET. Si hace 5 años no había tantas filiales en Alpha (principalmente en aplicaciones corporativas, préstamos a negocios corporativos, inversiones, etc.), aproximadamente 16-20 personas enfrentaron tal carga. Y ahora el banco está desarrollando activamente segmentos del negocio corporativo masivo y mediano, que se ha convertido en un buen impulso para el desarrollo de sistemas de crédito.
Y nos enfrentamos a una elección: reescribir todo esto en Java, que históricamente siempre ha sido nuestro punto fuerte, y aún prevalece en el comercio minorista, o continuar desarrollando todo en .NET, para lo cual tendríamos que contratar a un grupo de donantes e ir al frente a las mismas tecnologías similares para la arquitectura de microservicios que en Java.
Por supuesto, tal movimiento se vio inmediatamente amenazado porque los riesgos [de aplicar una nueva tecnología aprox. Ed.]. Pero pudimos asumir estos riesgos nosotros mismos, demostramos a nuestros colegas que .NET puede trabajar de manera bastante adecuada en los mismos clústeres y soluciones de infraestructura en las que Java se siente genial. Aquí me estoy refiriendo a nuestro llamado grupo de "frente unido", Apache Mesos - Marathon. Y comenzamos a tomar decisiones de primera línea, incluida la sección central para ellos. El frente permaneció igual que en Java, la parte media permaneció en algún lugar de Java, en algún lugar de .NET.
Y nos vamos: hace 5 años, un máximo de 20 personas se enfrentaron a .NET, y ahora hay tantas tareas que tenemos 75 tipos valientes. Y continuamos expandiéndonos, ahora estamos buscando un
arquitecto y más
desarrolladores . Aunque Java todavía es un total de más, uno y medio o dos, porque domina de manera estable los negocios minoristas y masivos. Estamos en .NET dominados en el marco del promedio corporativo y regional, más canales electrónicos todavía, por supuesto.
Comprobar - probar - implementar
Para que algo funcione de manera continua, es necesario implementar este asunto en los procesos del banco. Para implementarlo normalmente, debe demostrar a todos los responsables que esto no estropeará el estado actual de las cosas y la implementación traerá muchas ventajas.
Lo más difícil fue con la infraestructura. Teníamos un requisito concreto reforzado de ellos: que todo esto se desarrollaría en la ventana acoplable y funcionaría normalmente en Linux. Y aquí vale la pena señalar que todavía no había .NET Core 2.0, solo hubo la primera versión, en la que no hubo todo lo bueno que se lanzó en la segunda, en general, resultó que nosotros mismos no sabíamos exactamente qué bajo el agua podemos encontrar icebergs, pero dijeron que haremos todo lo que debería. Pudimos demostrar esto al negocio lanzando los primeros pilotos: Alfa-Credit, una aplicación para préstamos en línea, emisión de tramos y más.
Entonces los partidarios tuvieron que demostrar la viabilidad de la idea. Necesitaban explicar que ellos mismos no necesitaban saber .NET para acompañar nuestros contenedores (por alguna razón estaban seguros de lo contrario). Les demostraron que no habría problemas de rendimiento, fui uno de los primeros en recopilar todo esto en un clúster: implementamos el contenedor, eliminamos un montón de métricas, observamos cuánto carga la CPU, comparamos todo esto con Java. Acabamos de tener el código Java en un contenedor que emitió ayuda a los clientes minoristas. Bueno, para la pureza del experimento, realizamos absolutamente el mismo servicio, pero en .NET, para que podamos compararlos honestamente en términos de rendimiento, velocidad de respuesta y carga de memoria. Como resultado, escribí pruebas de estrés para todo esto: todo funcionó para nosotros, y en este momento 6 equipos están trabajando en este modo.
Ahora nos estamos deshaciendo lentamente de Legacy: lo envolvemos en servicios y lo reescribimos funcionalmente en microservicios.
.NET Core VS .NET Framework
Volveré a prestar atención a que implementamos .NET Core. Por lo tanto, sigue habiendo una serie de problemas en el sentido de que hay algunas cosas interesantes en el .NET Framework, pero no están en el .NET Core, y aún no lo están. Por ejemplo, servicios SOAP.
Solo imagina. Eres un banco, tienes un sistema que consume otro. Y ella se acostumbró a JABÓN para consumir, y usted no lo tiene. En general No encontramos una sola implementación normal de servicios WCF con SOAP y cosas similares. Tal vez se han visto mal, todo es posible. Por lo tanto, tuve que lanzar y escribir capas en el antiguo .NET Framework.
El segundo conjunto de rastrillos es la API REST. No hay problemas con los nuevos servicios donde se implementa. Y obligar a los servicios antiguos a usar la API REST en lugar de SOAP es otra historia; tendría que reescribir todos los demás sistemas dependientes. Y de nuevo, capas, parches, muletas.
Y también comunicación con colas. Estamos utilizando activamente IBM MQ en Alpha, un bus empresarial típico para colas de mensajes. Existe un cliente bajo .NET Framework, nativo de IBM. Pero no tienen un cliente para .NET Core. Y, hasta donde sabemos, no está planeado. solo hay una implementación en el protocolo AMQP abierto, tratamos de comunicarnos con las colas con su ayuda, pero también hubo una serie de problemas. Solución? Sí, nuevamente las capas.
En general, tuvimos una iteración en un intento de hacer que todo esto funcione normalmente a través del protocolo AMQP y no de forma estúpida. Pero los muchachos de IBM se dieron de baja, nos dicen, lo siento, muchachos, pero él nos desaprobó, muy bien él. Y que solo usarán el protocolo patentado por ciertas razones. En general, ahora nos sentamos y pensamos cómo rehacer todo esto. Lo más probable es que escribamos nuestro cliente en lugar del de IBM, este es el código abierto.
Frente, .NET y NodeJS
En su mayor parte, usamos React JS para el frente; funciona con el nodo normalmente. Cuando comenzamos, teníamos varios proyectos antiguos de MVC. Allí, tuve que reenviar el frente para que la representación del lado del servidor fuera normal, a través de ReactJS.NET.
Ahora que estamos evitando esto, decidimos separar las moscas de las chuletas, al final resultó que hay un frente separado con el nodo, y que NodeJS usa nuestros servicios en la API del resto en la aplicación web. Y, en realidad, eso es todo. En .NET, ya estamos implementando el medio. Y no establecemos un vínculo estrecho, como observé con .NET y Angular, que no podemos separarlos directamente en absoluto, porque nos esforzamos por desarrollar especializaciones en las personas.
Si conoce bien el frente puro, puede ir con seguridad con el equipo de Java para escribir el frente. Esto es conveniente, por lo que puede fluir de un equipo a otro. Y si conoce la pila completa, puede hacer aplicaciones de extremo a extremo. Y el backend con .NET, y el medio, y el frente en la reacción. Aquí tenemos un estándar de tecnología unificada.
Integración de telefonía móvil
No tenemos mucho de eso. Donde lo hay, simplemente está utilizando nuestros servicios en la API web. No escribimos aplicaciones móviles en .NET nosotros mismos, ni siquiera hubo intentos. Los nativos son aún mejores para hacer. Si puede tomar y escribir inmediatamente el nativo, es mejor tomar y escribir de inmediato. Sí, hay cosas útiles como Xamarin de Microsoft, pero eso tiene sentido cuando necesitas un inicio rápido y universal. Pero si hay una pregunta sobre la conveniencia de la aplicación para cada plataforma, con el rendimiento, todavía irá y normalmente escribirá nativo. Y teníamos nativos inicialmente.
Sobre la resistencia a lo nuevo
Cuando tiene una gran empresa (e incluso solo unos pocos equipos), siempre estará insatisfecho con la introducción de nuevas herramientas. Generalmente siempre, esto es normal. Artistas que ven esto, y eso es todo.
Cuando presentas algo que no es muy popular desde arriba, o algo que a los desarrolladores no les gusta, las personas siempre encontrarán muchas maneras de sabotear el proceso, e incluso mostrar en el proceso qué idiota eres que comenzó todo esto. Fue así cuando presentamos StyleCop para .NET. Pero con el tiempo, todos lo aceptaron de todos modos y ahora lo están usando activamente. Un argumento simple ayudó: la configuración de StyleCop es bastante común. El resultado es hermoso y más o menos claro para todos. Aunque, sospecho, un par de desarrolladores todavía afilan un diente. Después de todo, todos tienen sus propios estándares, todos tienen su propia comprensión de la belleza del código, sus propios editores y trucos.
Algo similar fue bien derrotado en la serie Silicon Valley. Allí, los muchachos tuvieron un debate sobre lo que debería usarse: pestañas o espacios. Personalmente, no me importa, pero, como muestra la práctica, para algunas personas, y esto puede ser un comienzo para holivar.
Por supuesto, si escribe todo en forma visual, esta pregunta generalmente se elimina.
Alguien aquí escribe código en Visual Studio, mientras que otros no. Cuando cambiamos al clúster, resultó que hay una serie de tecnologías que no funcionan en Windows. Por ejemplo, Ansible. Hay una parte del cliente en Windows, pero la parte del servidor ya no se puede generar. Por lo tanto, vaya y recoja una máquina virtual en Linux, o simplemente haga todo en un servidor Linux.
En general, vivimos así. Si tiene alguna pregunta sobre .NET en el banco, y .NET en principio, escriba, me complacerá responder.