{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"Servicios hu\u00e9rfanos: la otra cara de la arquitectura de (micro)servicios","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

El director de operaciones del portal Banki.ru, Andrey Nikolsky, habl\u00f3 en la conferencia del a\u00f1o pasado. DevOpsDays Mosc\u00fa<\/a><\/noindex> sobre los servicios hu\u00e9rfanos: c\u00f3mo identificar un hu\u00e9rfano en la infraestructura, cu\u00e1les son los problemas de los servicios hu\u00e9rfanos, qu\u00e9 hacer con ellos, y c\u00f3mo proceder si nada ayuda.<\/p>\n

A continuaci\u00f3n, la versi\u00f3n textual de la presentaci\u00f3n. <\/p>\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\n\u00a1Hola, colegas! Mi nombre es Andrey, y dirijo las operaciones en la empresa Banki.ru.<\/p>\n

Tenemos grandes servicios, como los monolitos, hay servicios en un sentido m\u00e1s cl\u00e1sico, y hay algunos muy peque\u00f1os. En mi jerga, digo que si un servicio es simple y peque\u00f1o, es un microservicio; y si no es tan simple y no es peque\u00f1o, simplemente es un servicio. <\/p>\n

Ventajas de los servicios<\/b><\/h3>\n

\nVoy a repasar r\u00e1pidamente las ventajas de los servicios. <\/p>\n

\"Servicios
\n
\nLa primera es la escalabilidad. Puedes hacer algo r\u00e1pidamente en el servicio y lanzarlo a producci\u00f3n. Si llega tr\u00e1fico, clonas el servicio. Si llega m\u00e1s tr\u00e1fico, lo vuelves a clonar y as\u00ed contin\u00faas. Esta es una buena ventaja y, de hecho, cuando comenzamos, era lo m\u00e1s importante para nosotros, la raz\u00f3n por la que est\u00e1bamos haciendo todo esto.<\/p>\n

\"Servicios
\n
\nEn segundo lugar, el desarrollo aislado, cuando tienes varios equipos de desarrollo, diferentes desarrolladores en cada equipo, y cada equipo trabaja en su propio servicio.<\/p>\n

Surge un matiz con los equipos. Los desarrolladores son diferentes. Y, por ejemplo, hay personas \u2018copos de nieve\u2019<\/a><\/noindex>. Lo vi por primera vez con Maxim Dorofeev. A veces hay personas \u2018copos de nieve\u2019 en algunos equipos, y en otros no. Esto hace que los diferentes servicios utilizados en la empresa sean un poco desiguales. <\/p>\n

\"Servicios
\n
\nMira la imagen: este es un buen desarrollador, tiene grandes manos, puede hacer muchas cosas. El problema principal es de d\u00f3nde provienen esas manos. <\/p>\n

\"Servicios
\n
\nLos servicios permiten utilizar diferentes lenguajes de programaci\u00f3n, m\u00e1s apropiados para diferentes tareas. Un servicio puede estar en Go, otro en Erlang, otro en Ruby, uno en PHP, otro en Python. En general, se puede ampliar mucho. Tambi\u00e9n hay matices aqu\u00ed.<\/p>\n

\"Servicios
\n
\nLa arquitectura orientada a servicios se trata, ante todo, de devops. Es decir, si no tienes automatizaci\u00f3n, no hay un proceso de despliegue, si lo configuras manualmente, tu configuraci\u00f3n puede cambiar de una instancia de servicio a otra, y tienes que ir all\u00ed a hacer algo, entonces est\u00e1s en el infierno. <\/p>\n

Por ejemplo, si tienes 20 servicios y necesitas desplegarlos manualmente, tendr\u00e1s 20 consolas y presionar\u00e1s \"enter\" al mismo tiempo, como un ninja. Eso no es lo ideal. <\/p>\n

Si tienes un servicio despu\u00e9s de pruebas (si, por supuesto, se hicieron pruebas), y tienes que ajustarlo para que funcione en producci\u00f3n, tengo tambi\u00e9n malas noticias para ti. <\/p>\n

Si dependes de servicios espec\u00edficos de Amazon y trabajas en Rusia, hace dos meses tambi\u00e9n estabas pensando \"Todo arde a mi alrededor, estoy bien, todo est\u00e1 genial\".<\/p>\n

\"Servicios
\n
\nUtilizamos Ansible para automatizar el despliegue, Puppet para la convergencia, Bamboo para la automatizaci\u00f3n del despliegue y Confluence para documentar todo esto de alguna manera.<\/p>\n

No profundizar\u00e9 en esto, porque la charla se centra m\u00e1s en las pr\u00e1cticas de interacci\u00f3n que en la implementaci\u00f3n t\u00e9cnica. <\/p>\n

\"Servicios
\n
\nHemos tenido problemas en los que Puppet en el servidor trabaja con Ruby 2, mientras que alguna aplicaci\u00f3n est\u00e1 escrita para Ruby 1.8, y juntos no funcionan. Sucede alg\u00fan tipo de error. Y cuando necesitas mantener varias versiones de Ruby en una sola m\u00e1quina, generalmente comienzan los problemas. <\/p>\n

Por ejemplo, a cada desarrollador le proporcionamos un entorno donde tiene casi todo lo que tenemos, todos los servicios que se pueden desarrollar, para que tenga un entorno aislado donde pueda romper y construir a su antojo. <\/p>\n

A veces, se necesita un paquete especialmente compilado con soporte para algo. Eso es bastante estricto. Escuch\u00e9 una presentaci\u00f3n donde la imagen de Docker pesaba 45 GB. En Linux, por supuesto, es m\u00e1s sencillo, all\u00ed todo es m\u00e1s peque\u00f1o, pero de todos modos, no habr\u00e1 suficiente espacio. <\/p>\n

Y tambi\u00e9n hay dependencias conflictivas, cuando una parte del proyecto depende de una versi\u00f3n de biblioteca, otra parte del proyecto de otra versi\u00f3n, y las bibliotecas no se pueden instalar juntas en absoluto. <\/p>\n

\"Servicios
\n
\nTenemos sitios y servicios en PHP 5.6, de los cuales nos avergonzamos, pero \u00bfqu\u00e9 podemos hacer? Esa es nuestra \u00fanica plataforma. Hay sitios y servicios en PHP 7, son m\u00e1s numerosos, de los cuales no nos avergonzamos. Y cada desarrollador tiene su propia base donde se divierte programando. <\/p>\n

Si en la empresa se programa en un solo lenguaje, tres m\u00e1quinas virtuales por desarrollador suena normal. Si tienes diferentes lenguajes de programaci\u00f3n, la situaci\u00f3n se complica.<\/p>\n

\"Servicios
\n
\nTienes sitios y servicios aqu\u00ed, aqu\u00ed, luego otra plataforma para Go, una plataforma para Ruby, y alg\u00fan Redis adicional. Al final, todo esto se convierte en un gran campo de soporte, y siempre hay algo que puede romperse.<\/p>\n

\"Servicios
\n
\nPor eso reemplazamos las caracter\u00edsticas del lenguaje de programaci\u00f3n por el uso de diferentes frameworks, ya que los frameworks en PHP son bastante diversos, tienen diferentes capacidades, diferentes comunidades, y diferente soporte. Se puede desarrollar un servicio de manera que ya tengas algo disponible para \u00e9l. <\/p>\n

Cada servicio tiene su propio equipo.<\/b><\/h3>\n

\n\"Servicios
\n
\nNuestra principal ventaja, que se ha cristalizado a lo largo de los a\u00f1os, es que cada servicio tiene su propio equipo. Esto es conveniente para un gran proyecto, ya que se puede ahorrar tiempo en documentaci\u00f3n, y los gestores conocen bien su proyecto. <\/p>\n

Se pueden asignar tareas de soporte de manera efectiva. Por ejemplo, si se rompe el servicio de seguros, el equipo que se encarga de los seguros inmediatamente va a repararlo. <\/p>\n

Se desarrollan nuevas funciones r\u00e1pidamente, porque cuando tienes un servicio at\u00f3mico, se le puede a\u00f1adir algo de forma \u00e1gil. <\/p>\n

Y cuando rompes tu propio servicio, lo cual es inevitable, no afectas a otros servicios, y no vienen desarrolladores de otros equipos con palos a decirte: \u00abAy-ay, no hagas eso\u00bb. <\/p>\n

\"Servicios
\n
\nComo siempre, hay matices. Tenemos equipos estables, los gestores est\u00e1n firmemente compenetrados con el equipo. Existen documentos claros, los gestores est\u00e1n muy pendientes de todo. Cada equipo tiene varios servicios y hay un punto concreto de competencia. <\/p>\n

Si los equipos son fluidos (lo cual tambi\u00e9n es algo que usamos a veces), hay un buen m\u00e9todo llamado \u00abmapa estelar\u00bb.<\/p>\n

\"Servicios
\n
\nTienes una lista de servicios y personas. Una estrella indica que la persona es experta en ese servicio, un libro indica que la persona est\u00e1 estudiando ese servicio. La tarea de la persona es cambiar el libro por una estrella. Y si no hay nada escrito frente al servicio, comienzan los problemas, de los cuales hablar\u00e9 m\u00e1s adelante. <\/p>\n

\u00bfC\u00f3mo aparecen los servicios hu\u00e9rfanos?<\/b><\/h3>\n

\n\"Servicios
\n
\nEl primer problema, la primera forma de tener un servicio hu\u00e9rfano en tu infraestructura, es la despedida de personas. \u00bfAlguien ha experimentado alguna vez que llegan plazos del negocio antes de haber evaluado las tareas? A veces, los plazos son estrictos y simplemente no hay tiempo para la documentaci\u00f3n. \"Hay que entregar el servicio a producci\u00f3n, luego lo escribiremos\". <\/p>\n

Si el equipo es peque\u00f1o, puede que haya un solo desarrollador que escribe todo, mientras que los dem\u00e1s est\u00e1n para ayudar. \"He escrito la arquitectura principal, t\u00fa enc\u00e1rgate de los interfaces\". Luego, en alg\u00fan momento, el gerente, por ejemplo, se va. Y durante ese periodo, cuando el gerente se ha ido y no se ha nombrado uno nuevo, los desarrolladores deciden por s\u00ed mismos hacia d\u00f3nde va el servicio, qu\u00e9 est\u00e1 sucediendo. Y como sabemos (regresando unas diapositivas atr\u00e1s), en algunos equipos hay personas 'copos de nieve', a veces un copo de nieve es el l\u00edder de equipo. Luego se va y tenemos un servicio hu\u00e9rfano. <\/p>\n

\"Servicios
\n
\nSin embargo, las tareas del soporte y del negocio no desaparecen, se acumulan en el backlog. Si durante el desarrollo del servicio hubo errores arquitect\u00f3nicos, tambi\u00e9n se acumulan en el backlog. El servicio se degrada lentamente. <\/p>\n

\u00bfC\u00f3mo identificar un hu\u00e9rfano?<\/b> <\/h3>\n

\nEsta lista describe bien la situaci\u00f3n. \u00bfQui\u00e9n se ha identificado con algo en su infraestructura?<\/p>\n

\"Servicios
\n
\nSobre los workarounds documentados: hay un servicio que, en general, funciona, tiene un manual de dos p\u00e1ginas sobre c\u00f3mo trabajar con \u00e9l, pero nadie sabe c\u00f3mo funciona internamente. <\/p>\n

O, por ejemplo, hay un acortador de enlaces. En nuestro caso, actualmente estamos utilizando tres acortadores de enlaces para diferentes objetivos en diferentes servicios. Estas son las consecuencias. <\/p>\n

\"Servicios
\n
\nAhora voy a ser el capit\u00e1n obvio. \u00bfQu\u00e9 se debe hacer? Primero, hay que transferir el servicio a otro gerente, a otro equipo. Si tu l\u00edder de equipo a\u00fan no se ha ido, en este otro equipo, cuando entiendes que el servicio se asemeja a un hu\u00e9rfano, debes incluir a alguien que entienda algo sobre \u00e9l. <\/p>\n

Lo m\u00e1s importante: deben tener procedimientos de transferencia escritos a conciencia. En nuestro caso, generalmente soy yo quien se encarga de esto, porque necesito que todo funcione. A los gerentes les interesa que se entregue r\u00e1pido, y lo que suceder\u00e1 despu\u00e9s ya no les importa tanto. <\/p>\n

\"Servicios
\n
\nLa siguiente forma de hacer una 'sorpresa' es: 'Lo haremos en outsourcing, as\u00ed ser\u00e1 m\u00e1s r\u00e1pido y luego lo pasaremos al equipo'. Es obvio que todos tienen ciertos planes en el equipo, hay una fila. A menudo, el cliente de negocios piensa que en el proveedor externalizado har\u00e1n las cosas igual que el departamento t\u00e9cnico de la empresa. Aunque sus motivaciones son diferentes. En el outsourcing a veces hay soluciones tecnol\u00f3gicas extra\u00f1as y soluciones algor\u00edtmicas inusuales.<\/p>\n

\"Servicios
\n
\nPor ejemplo, tuvimos un servicio en el que hab\u00eda Sphinx en diferentes lugares inesperados. M\u00e1s adelante contar\u00e9 qu\u00e9 tuvimos que hacer. <\/p>\n

En el caso de los outsourcers puede haber frameworks hechos a medida. Es simplemente PHP puro con copias y pegados de un proyecto anterior, donde se puede encontrar de todo. Grandes trucos en los scripts de despliegue, cuando necesitas cambiar algunas l\u00edneas en alg\u00fan archivo usando complejos scripts Bash, mientras que estos scripts de despliegue son llamados por alg\u00fan tercer script. Al final, cambias el sistema de despliegue, eliges otra cosa y, de repente, tu servicio no funciona. Porque hab\u00eda que poner otras 8 enlaces entre diferentes carpetas. O a veces, mil registros funcionan, pero cien mil ya no. <\/p>\n

Continuar\u00e9 al mando. La aceptaci\u00f3n del servicio del outsourcing es un procedimiento que es obligatorio. \u00bfA qui\u00e9n le ha pasado que un servicio del outsourcing llega y no es aceptado en ning\u00fan lado? No es tan com\u00fan como el servicio hu\u00e9rfano, pero a\u00fan as\u00ed. <\/p>\n

\"Servicios
\n
\nEs necesario verificar el servicio, hay que revisarlo, hay que cambiar las contrase\u00f1as. Tuvimos un caso en el que nos ofrecieron un servicio, donde el panel de administraci\u00f3n dec\u00eda \u00abif login == \u2018admin\u2019 && password == \u2018admin\u2019\u2026\u00bb, as\u00ed de claro estaba en el c\u00f3digo. Estamos sentados pensando, \u00bfy esto lo escriben personas en 2018?<\/p>\n

Las pruebas del volumen de almacenamiento tambi\u00e9n son importantes. Hay que ver qu\u00e9 suceder\u00e1 con cien mil registros, antes de lanzar este servicio a producci\u00f3n. <\/p>\n

\"Servicios
\n
\nNo deber\u00eda dar verg\u00fcenza enviar el servicio para mejoras. Cuando dices: 'No aceptaremos este servicio, tenemos 20 tareas, h\u00e1ganlas, luego aceptaremos', est\u00e1 bien. La conciencia no debe doler porque pongas en apuros al gerente o porque el negocio gaste dinero. Despu\u00e9s, el negocio gastar\u00e1 m\u00e1s.<\/p>\n

Tuvimos un caso en el que decidimos hacer un proyecto piloto en outsourcing.<\/p>\n

\"Servicios
\n
\nSe entreg\u00f3 a tiempo, y ese fue el \u00fanico criterio de calidad. Por eso se hizo otro proyecto piloto, que ya ni siquiera era del todo piloto. Estos servicios fueron aceptados, dijeron administrativamente, aqu\u00ed est\u00e1 su c\u00f3digo, aqu\u00ed est\u00e1 el equipo, aqu\u00ed est\u00e1 su gerente. Los servicios ya empezaron a generar ganancias. Sin embargo, de hecho, siguen siendo hu\u00e9rfanos, nadie entiende c\u00f3mo funcionan, y los gerentes se desentienden de sus tareas. <\/p>\n

\"Servicios
\n
\nHay otro concepto excelente: desarrollo guerrillero. Cuando alg\u00fan departamento, generalmente el de marketing, quiere probar una hip\u00f3tesis, y encarga el servicio completamente externamente. Comienza a recibir tr\u00e1fico, cierran documentos, firman actas con el contratista, entran en operaci\u00f3n y dicen: 'Chicos, aqu\u00ed tenemos un servicio, ya tiene tr\u00e1fico, nos genera dinero, vamos a aceptarlo'. Nosotros decimos: 'Vaya, \u00bfc\u00f3mo es posible?'.<\/p>\n

\"Servicios
\n
\nY otra forma de obtener un servicio hu\u00e9rfano: cuando alg\u00fan equipo se ve de repente sobrecargado, la direcci\u00f3n dice: 'Vamos a pasar este servicio de este equipo a otro equipo, que tenga menos carga'. Luego pasamos a un tercer equipo y cambiamos al gerente. Y al final, nuevamente tenemos un hu\u00e9rfano.<\/p>\n

\u00bfCu\u00e1l es el problema con los hu\u00e9rfanos?<\/b><\/h3>\n

\n\"Servicios
\n
\nQuien no lo sepa, es el barco de l\u00ednea Wasa, levantado en Suecia, famoso por haberse hundido cinco minutos despu\u00e9s de ser botado al agua. Y el rey de Suecia, por cierto, no mand\u00f3 ejecutar a nadie por esto. Fue construido por dos generaciones de ingenieros que no sab\u00edan construir tales barcos. Efecto inevitable.<\/p>\n

El barco podr\u00eda haberse hundido, por cierto, mucho peor, por ejemplo, cuando ya estuviera llevando al rey a alg\u00fan lugar en una tormenta. As\u00ed fue, se hundi\u00f3 de inmediato, en t\u00e9rminos \u00e1giles esto es bueno: fallar temprano. <\/p>\n

Si fallamos temprano, generalmente no hay problemas. Por ejemplo, durante la aceptaci\u00f3n se envi\u00f3 para mejorar. Pero si fallamos ya en producci\u00f3n, cuando se han invertido dinero, podr\u00edan surgir problemas. Consecuencias, como se les llama en los negocios.<\/p>\n

\u00bfCu\u00e1les son los peligros de los servicios hu\u00e9rfanos?<\/p>\n