Ante las palabras "código abierto", muchos parecen ser un entusiasta que se compromete por las noches con su proyecto favorito, o una pequeña empresa que gana dinero al apoyar un producto abierto. Pero si solo piensa en ellos, se perderá un segmento importante e interesante de la comunidad. Una vez que las palabras "empresa" y "código abierto" parecían ser antónimos, pero ahora las grandes corporaciones no solo utilizan activamente los proyectos OSS, sino que ellas mismas contribuirán a ellos.
Con el tiempo, Sbertech ha estado cada vez más activo en la comunidad OSS, y decidimos preguntarles al respecto. ¿Cómo se combina la estricta especificidad bancaria con el espíritu de libertad de código abierto? ¿Cuáles son los requisitos de código abierto que otras compañías podrían no tener? ¿Hay empleados en Sbertech que escriban código abierto como sus principales tareas laborales? ¿Cuáles son tus planes y deseos para el futuro?
Anton Churaev , que supervisa Free & Open Source, nos contó sobre todo esto y más.
Oleg: Hola Anton. Vamos a presentarte un poco a los Khabrovitas. Cuéntanos sobre ti: ¿quién eres, qué estás haciendo?Anton: Soy un ingeniero que, sin embargo, solo se desarrolla en su tiempo libre. Ahora estoy incorporando en Sbertech prácticas y competencias para el desarrollo y la aplicación de productos de código libre y abierto. Debe comprender que estas son cosas ligeramente diferentes.
- Sí, entiendo, un par de veces, cuando hablé con Stallman, llamé a Free as Open y luego escuché una conferencia tal que la recordé de por vida :-) Bueno, ¿cuál es tu posición?- Curador del desarrollo de Free & Open Source. Y entusiasta del código abierto :)
- ¿Puedes descifrar un poco más sobre las "competencias para la implementación de código abierto"? Suena como una especie de conocimiento secreto.- Pocas personas imaginan lo que Open Source significa para las corporaciones. Por un lado, se trata de innovaciones y la ausencia de la necesidad de desarrollar productos básicos, centrarse en las ventajas competitivas de sus productos, reutilizar y reducir costos. A menudo, estos son proyectos que en realidad se han convertido en estándares de la industria. Tome el mismo Hadoop: todos lo saben, todos lo saben, siempre ha sido un estándar. O las bases de datos más comunes: las cinco principales son tres productos de código abierto: MySQL, PostgreSQL y MongoDB.
Pero pocas personas piensan que usar OpenSource implica muchos costos ocultos. Esto no quiere decir que encontramos algo de código abierto y resolvimos todos nuestros problemas. Por ejemplo, hay grandes preguntas sobre la "higiene legal". Cuando se trabaja con el software del proveedor, todo está muy claro: tomé una licencia, usted trabaja en ella y usa el soporte. Cuando se trabaja con Open Source, queda mucho a merced de los desarrolladores y usuarios. En este caso, los asuntos legales y legales son uno de los primeros lugares. Además, en Rusia hay matices. Si en todo el mundo el concepto de propiedad intelectual está bastante desarrollado y todos entienden que es muy importante que haya un propietario específico, entonces, históricamente, en Rusia todo resultó de manera diferente. Aquí no somos tan cuidadosos y respetuosos con la propiedad intelectual, aunque esto es extremadamente incorrecto. Y si no puede garantizar la "higiene" del uso de Open Source, no puede garantizar la calidad de su uso.
- ¿Puedo aclarar? ¿Cuál es el estado legal de las licencias GPL en Rusia? Por ejemplo, la GPL no permite modificaciones a las leyes locales y no indica restricciones territoriales. Por lo tanto, dicho acuerdo no es compatible con el régimen legal establecido en el territorio de la Federación de Rusia, y esto es muy, muy malo.- No quiero dividir las licencias en algunas zonas. Sberbank es una compañía global, por lo que el software se puede usar tanto en los Estados Unidos como en la Unión Europea. Y, según tengo entendido (no soy abogado, pero que yo sepa), en caso de violación de las restricciones de las licencias del titular de los derechos de autor en el territorio de, por ejemplo, los EE. UU., Seremos responsables bajo las leyes de los EE. UU. Dado esto, debe tener mucho cuidado al garantizar los derechos y cumplir con los requisitos para la propiedad intelectual de otra persona. Respetamos a los autores que nos permitieron utilizar nuestro trabajo, por lo que aceleramos, optimizamos soluciones, resolvimos nuestros problemas y finalmente brindamos un servicio de calidad a nuestros clientes. Cumplamos con los derechos y requisitos. Esta es la primera tarea.
- Y el segundo?- La segunda tarea es la seguridad de la información. Está claro que la mayoría de las licencias contienen un descargo de responsabilidad que establece que el autor / desarrollador / contribuyente no es responsable del posible daño que causará el funcionamiento de este software. Esto es correcto, esta es una responsabilidad que se transfiere al consumidor y requiere su madurez. No todo es gratis.
Debe pagar esta responsabilidad y, por supuesto, trabajar con estos riesgos. No todas las empresas pueden hacer esto. Tenemos un departamento de seguridad de la información muy sólido, tenemos suerte. Por lo tanto, nos tomamos en serio la presencia de vulnerabilidades y códigos maliciosos en general. Todos los que planean usar Open Source deben tener en cuenta todos los riesgos, no solo legales, sino también en términos de seguridad de la información.
- ¿Qué licencias te gustan?- Académico.
- Oh! Seamos más específicos. Hay MIT / BSD, etc., y hay licencias de copyleft de virus como Affero GPL. ¿Cuál de estos?- Pues bien. No se puede amar o no me gusta una licencia. El producto está hecho para una tarea específica y se utilizará de manera específica. Al usar código abierto, su tarea es asegurarse de proporcionar su producto o servicio sin violar los derechos de terceros. En este caso, por supuesto, puede usar copylefts (por ejemplo, la GPL), si asegura su uso para que no violen las restricciones y los derechos de otras personas. Por supuesto, hay menos dificultades al usar licencias académicas, simplemente porque conllevan menos restricciones y, por lo tanto, son más fáciles de seguir. Para abreviar, llamo MIT "académico", BSD, Apache, etc.
- Bien, ¿los desarrolladores comunes tienen que lidiar con la seguridad de la información? ¿O está asignado a un departamento separado?- Todos los desarrolladores deben comprender los conceptos básicos de seguridad de la información y los principios de seguridad para sus sistemas. Pero en nuestro caso, trabajamos con desarrolladores individuales que se especializan en amenazas a la seguridad de la información. Además, recurrimos a ellos no solo para el análisis de productos de código abierto, sino también para el análisis de algoritmos y soluciones de diseño.
"Está claro que estos guardias de seguridad especiales lo saben todo". ¿Y qué necesita saber un desarrollador ordinario a este respecto? ¿Cuáles son los puntos básicos?- Modelo de amenazas, protección de canales, protección de datos. Lo que es propenso a las amenazas: tal vez esta sea una interfaz de usuario o transmisión de datos a través de una red (todo se distribuye con nosotros, por lo que este es un tema muy importante). Herramientas básicas como cifrado, SSL, TLS, autenticación, autorización, manejo de tokens, etc. No necesitas saber mucho.
- Se rumorea que tienes algo que ver con Apache Ignite :-)- En términos de contribución, este es el proyecto principal en el que estoy trabajando actualmente. La participación en Apache Ignite pertenece a mi segunda tarea: garantizar una inversión equilibrada en proyectos de código abierto y gratuito. Esto implica el uso competente de productos (está claro que el uso de bibliotecas es una inversión, nosotros, como usuarios, aumentamos el atractivo del producto), así como el desarrollo y la contribución.
Para mí, probablemente, esta tarea es aún más significativa. Rindimos homenaje a los productos que utilizamos en nuestra empresa, y gracias a los cuales construimos muchos productos y sistemas. Intentamos mejorarlos y garantizar la posibilidad de su uso en empresas como la nuestra: para optimizar, llevar a un estado empresarial.
Apache Ignite no es el único proyecto, pero lo introduciremos de manera muy intensiva, ya que una de las plataformas clave del banco se está construyendo sobre la base de Apache Ignite. Ignite es una red informática distribuida que le permite almacenar y procesar datos en la memoria, y de hecho es la base del panorama de TI de nuestro negocio. Por lo tanto, estamos extremadamente interesados en su desarrollo.
- Muchas personas saben que Sbertech usa GridGain, y estás hablando de Apache Ignite. ¿Cuál es la diferencia entre los dos?- GridGain es un producto de núcleo abierto creado sobre la base de un núcleo abierto, que es Ignite. Y GridGain es un conjunto de complementos para este núcleo, que simplifica los procedimientos de mantenimiento y operación, proporciona una serie de requisitos importantes de seguridad y confiabilidad de la información. Pero, de hecho, el núcleo es la parte más importante, y los complementos le permiten explotar todo esto en una empresa real. Y el banco ya opera GridGain.
- Dado que Ignite está abierto, puedes hablar un poco sobre eso, ¿verdad? ¿Solo lo explotas o haces algo para terminarlo e interactuar con los desarrolladores?- Lo modificamos intensamente. Las direcciones de las tareas están claramente definidas, por ejemplo, asegurando el rendimiento teniendo en cuenta las características específicas de Sberbank: gran escala, océano de datos, alta actividad operativa. Por lo tanto, debe ser rápido y mucho. Con esto quiero decir latencia y rendimiento.
El segundo es garantizar la fiabilidad, es decir disponibilidad y tolerancia a fallos.
El tercero es la eficiencia operativa, la gestión de TCO. Dado el tamaño de Sberbank, incluso una ligera reducción en el uso de recursos, por ejemplo, los discos en un cierto porcentaje, en nuestras escalas ofrece enormes ahorros.
Y el cuarto es la tarea del desarrollo funcional. De hecho, lo principal es el desarrollo de interfaces y la integración con otros componentes de la pila tecnológica de Sberbank. Esto es útil e importante en términos de construir una arquitectura de TI madura e integrada.
Por separado, existe la tarea de eliminar la deuda técnica y los defectos (que siempre existen). Probablemente se puede atribuir a la fiabilidad.
- Repasemos estos puntos para aclarar. Usted dice que está trabajando para mejorar el rendimiento, la latencia, el rendimiento, eso es todo. La pregunta es: ¿Ignite tiene algún problema con esto? Quiero decir, ¿hay algo que modificar o es un producto ideal?- No, el producto no puede considerarse ideal. En cada versión, manejamos tanto puntos de referencia generales como microbenchmarks en componentes específicos, estamos trabajando constantemente en el rendimiento, no debemos detenernos aquí. La tarea es difícil, ya que los componentes y las soluciones ya están bastante ajustados, el rendimiento está casi al límite del hierro. Esto agrega complejidad, pero siempre hay margen de mejora. Tenemos diferentes casos de uso, aparecen nuevas tareas de usuario, en las que existe la posibilidad de optimización. Por ejemplo, optimice la unidad de cinta para la naturaleza específica de los datos. Hay tareas para optimizar la capa de red, que, de nuevo, depende de casos individuales. Por lo tanto, siempre debe mantener el dedo en el pulso.
"Dijiste que contribuirías a la comunidad". Y todas estas decisiones sobre varios casos y su optimización son una especie de compensación. Cuando tomamos nuestras compensaciones y las llevamos a la comunidad, puede resultar que las personas en la comunidad tengan condiciones ligeramente diferentes, prioridades diferentes. ¿Cómo organizar la interacción y aún copiar el código que se necesita para sus casos?- Otros clientes con otras tareas. Es absolutamente cierto que este es un problema estándar. Todo depende de la arquitectura de la solución. Si la solución incluye, por ejemplo, la capacidad de hacer extensiones de complementos, complementos, bibliotecas para diferentes soluciones de usuario, puede salir. Por ejemplo, si hay un comparador, el usuario siempre puede desarrollar una solución que pase este comparador a la entrada, y esto resolverá el problema en función de condiciones específicas. Una vez más, las capacidades dependen mucho de la arquitectura. Es incorrecto simplemente codificar y esculpir aproximadamente nuestra tarea sin pensar en otros clientes; tales solicitudes de extracción no pasan por una revisión.
Todos entienden qué es un proyecto de código abierto y, en general, usted puede influir en él. Por supuesto, hay comunidades en las que las corporaciones están claramente presentes que influyen en el desarrollo en sus propios intereses, pero si jugamos al Código Abierto puro, entonces se comparará correctamente con la meritocracia (la autoridad de los dignos). Demuestre que su decisión es buena, y luego se tomará. Actuar, como suele ser el caso en el desarrollo cerrado, es decir, desde la posición de "Soy el jefe, lo dije" no funcionará.
- Uno de los casos más interesantes que Sbertech contó en público es la capa semántica única. Una gran cantidad de datos repartidos en una cuadrícula en memoria. ¿Cómo ha afectado esto a la parte abierta de Ignite y qué tan interesantes son estos desarrollos para la comunidad?- Sí, tales desarrollos están en marcha, y estamos trabajando muy intensamente en tareas para garantizar la escalabilidad y la accesibilidad. Encontramos casos en los que el esquema de gestión de topología actual no es óptimo, porque su complejidad temporal crece a partir del número de nodos no exactamente como nos gustaría. Esto complica un poco el logro de la meta.
- Hasta donde recuerdo, la arquitectura del clúster es un anillo. Es decir, cuando nos unimos al anillo, al principio vamos al coordinador y seguimos el anillo hasta encontrar la cola. Y cuantos más elementos, más tiempo, ¿verdad?"Sí, más o menos". Al mismo tiempo, con un aumento en el número de nodos en la topología, aumentan tanto el tamaño de los mensajes que se transmiten a lo largo del anillo como el número de transiciones entre los participantes. Esto no quiere decir que un anillo sea una mala decisión, pero en algunos casos no encaja. Por lo tanto, desde finales de 2017, nosotros en la comunidad estamos finalizando la administración de topología para que los usuarios puedan elegir un esquema de administración de topología: un anillo (a veces encaja perfectamente) o una estrella en Zookeeper.
- ¿Y de dónde vino el anillo? Por que es Donde es perfecto- Esta es una solución maravillosa en las topologías de 100-200 nodos en un centro de datos. Le permite sincronizar de manera simple y confiable todos los nodos, simplemente van en orden. Si vamos a la estrella, comienzan a trabajar en paralelo, más rápido, pero al mismo tiempo sincronizarlos se vuelve mucho más difícil. Es decir, el anillo puede ser más estable y confiable, ¿de acuerdo?
"Sí, por supuesto". Pero, ¿se puede hacer para que esta topología se pueda cambiar mediante algún parámetro en la configuración, cómo es la configuración?- Sí, lo estamos haciendo ahora, incluimos ambas topologías en el lanzamiento. Probablemente, las implementaciones ya propuestas no cubren todos los casos de usuarios, y tan pronto como aparezcan nuevas, intentaremos asegurar su procesamiento efectivo.
- Que yo entienda, esta es una revisión bastante complicada. ¿Y esta revisión la realizan personas en Sbertekh, durante las horas de trabajo o por las tardes por placer?- Esto lo hace la comunidad, que incluye a los empleados de PBT, cuya tarea principal durante las horas de trabajo es contribuir a este proyecto. El problema de topología afecta a una de las soluciones clave en el núcleo del producto, por lo que la carga principal recayó en los mantenedores de DiscoverySPI, pero espero que la participación de nuestros desarrolladores también haya afectado positivamente el resultado.
- Bueno, es decir, estas son personas que resuelven un problema durante las horas de trabajo, pero al mismo tiempo son miembros de la comunidad.- Sí, la parte más importante del trabajo de nuestros desarrolladores tiene lugar en la comunidad. Pero también veo de nuestros muchachos tales compromisos que aparecieron en una hora, dos, tres noches.
- ¿Y estos empleados no tendrán problemas por el hecho de que trabajan en un banco, en un sistema cerrado y al mismo tiempo se comprometen con un código abierto?- No, no lo hará. Todos los participantes son contribuyentes corporativos oficiales. La creación de la dirección y la decisión sobre las inversiones se tomó a nivel de la gerencia de la compañía, y sí, este grupo de colaboradores corporativos dedicados que, de acuerdo con todos los estándares de la compañía y TC, desarrollan productos de código abierto en interés de la compañía. Sí, esto es desarrollo y código abierto, sí, esto es durante las horas de trabajo y también durante las horas no laborales, pero esto ya ocurre si la comunidad lo solicita.
- Acabamos de hablar sobre algunos asuntos externos que la comunidad decide. Pero lo más probable es que la empresa necesite hacer sus propias integraciones, mejorar en algunos de sus casos ... ¿Ha escrito mucho por su cuenta? ¿O es solo un pequeño dopilka?- Hablando sobre el proyecto Apache Ignite, durante el último trimestre, nuestra contribución al proyecto ascendió al 8-10 por ciento de todos los cambios, y nos esforzamos por aumentar este porcentaje. Escribimos mucho, y esto no es solo el desarrollo y la optimización de la funcionalidad existente, sino que también estamos trabajando en una nueva funcionalidad para el proyecto. Este es un desafío para la comunidad y una responsabilidad para nosotros, ya que después de su inclusión, la comunidad en cierta medida tiene la tarea de apoyarla.
Las tareas pueden aparecer no solo de la comunidad, sino también de los usuarios de la empresa: arquitectos, equipos de desarrollo y mantenimiento. El desarrollo del proyecto en estas tareas también afecta significativamente el producto.
- Pero, digamos, hubo varios informes del programa Sbertekh del PRPRB con respecto a su "feng shui especial". ¿Necesito escribir herramientas adicionales y páginas de administración para apoyar esto?- Las interfaces para la operación están en constante evolución. La consola de administración del mismo Oracle es más familiar de mantener y tiene más funcionalidad. Si necesita ser reproducido completamente es otra cuestión.
- ¿Y en forma abierta, puedes ver la consola de administración?"Sí, por supuesto". Consola web publicada, Visor, CLI: todo es público.
- Y si lo miras de manera más global, ¿cuáles son las direcciones y objetivos generales?- Ahora estamos más centrados en el desarrollo de Apache Ignite, que cumple con las prioridades de la empresa. Pero nuestra pila tecnológica no termina ahí. Open Source , , . , , . ( ), , . . , . . .
— , . - ?— — , availability, durability, fault tolerance ..
— , .— , — . , Open Source . . , .
— - , , ? , - , ceph?— , ceph — . , , , .
— - ? ?— OpenStack.
— , OpenStack — , . - , , ?— OpenStack , , , Cloud Foundry, .
— ?— :-) , ( ) . , — , , .
— .— , - Open Source .
, . , , -.
— -?— , , , -: , .. , , , , . . , Open Source, , , .
. , . -, , . . , , , .
, , ( -, , , ) — . , , , .
— .
— , . , «», , « , » «, ». , . , , . , , , . — , .
— , ? , … , , .— . , , , , . , , ( ). , , , .
, , - .
Open Source . , . . , .
— ? ?— , . , , – . — , ROI, .., .
— , - . , : , . , - Spring Hibernate, , , , . , , , . , .- Quizás es por eso que hay más buenos candidatos en el mercado que desarrolladores de sistemas. Estoy muy contento de que hayamos logrado formar el equipo actual, donde todos los muchachos son muy brillantes. Es sorprendente cómo piensan y trabajan, pueden resolver casi cualquier problema. Espero que podamos atraer desarrolladores aún más talentosos. Por lo tanto, no se puede decir con certeza que en Rusia nadie necesita desarrolladores de sistemas.