{"id":53442,"date":"2019-12-02T00:00:00","date_gmt":"2019-12-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/legacy-servisy-v-vashej-infrastrukture"},"modified":"2020-02-18T14:01:20","modified_gmt":"2020-02-18T11:01:20","slug":"legacy-servisy-v-vashej-infrastrukture","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Servicios heredados en su infraestructura","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola! Me llamo Pasha Chernyak, soy desarrollador principal en QIWI, y hoy quiero hablar sobre lo inevitable. Sobre Legacy.<\/p>\n

Empecemos con la pregunta: \u00bfqu\u00e9 es un servicio Legacy? \u00bfEs un servicio que el desarrollador no ha tocado en una semana\/mes\/a\u00f1o? \u00bfO es un servicio que fue escrito por un programador menos experimentado, como usted, pero hace un a\u00f1o? \u00a1Ahora ya es m\u00e1s experto y competente! O, \u00bfun servicio Legacy es aquel que ha decidido no volver a modificar y que est\u00e1 preparando lentamente para reemplazar? En cualquier caso, dejar un servicio as\u00ed desatendido y sin actualizar es una bomba de tiempo que puede explotar m\u00e1s adelante.<\/p>\n

\"Servicios<\/a><\/noindex><\/p>\n

Antes de pasar a c\u00f3mo trabajamos en QIWI con nuestros servicios Legacy, les contar\u00e9 c\u00f3mo hemos organizado los servicios en la Billetera. Desde hace dos a\u00f1os, soy responsable de su funcionamiento. Si hay alg\u00fan problema, la primera persona a la que llaman es a m\u00ed. Normalmente, no tengo el descaro de llamar a alguien m\u00e1s a las 11 de la noche, as\u00ed que he tenido que sentarme y entender todos los servicios de nuestro dominio. <\/p>\n

Pero yo, como cualquier persona, amo dormir por la noche, as\u00ed que intent\u00e9 entender la explotaci\u00f3n: 'Chicos, \u00bfpor qu\u00e9 me llaman?'. A lo que recib\u00ed una respuesta bastante concisa como '\u00bfA qui\u00e9n m\u00e1s?'. Porque yo arreglo los servicios y, adem\u00e1s, los chicos simplemente no saben a qui\u00e9n llamar.<\/p>\n

As\u00ed que en una de las retrospectivas del equipo de backend de la Billetera, decidimos que era necesario crear una tabla con la lista de nuestros servicios, microservicios y monolitos de la billetera, y las personas responsables de ellos. Las tablas son realmente \u00fatiles, dentro de l\u00edmites razonables.
\n<\/a><\/noindex>
\nAdem\u00e1s de la informaci\u00f3n sobre qui\u00e9n es responsable de qu\u00e9, tambi\u00e9n hab\u00eda respuestas a las preguntas: qui\u00e9n es el propietario del servicio, qui\u00e9n es responsable de su desarrollo, de la arquitectura y del ciclo de vida. Las personas responsables de este servicio son las que pueden arreglarlo si es necesario. El propietario del servicio tiene derecho a dejar +2 en los commits, y los responsables tambi\u00e9n deben asistir obligatoriamente a la revisi\u00f3n antes de que este servicio acepte un nuevo commit.<\/p>\n

Con el paso del tiempo, comenzaron a aplicarse nuevas pr\u00e1cticas, como la migraci\u00f3n a Kubernetes, el uso de checkstyle, spotbugs, ktlint, la inclusi\u00f3n de logs en Kibana, autodiscovery de servicios en lugar de indicar las direcciones directamente, entre otras utilidades. Y en todas partes nuestra tabla permit\u00eda mantener actualizados nuestros servicios. Para nosotros, es una especie de lista de verificaci\u00f3n que indica qu\u00e9 habilidades tiene el servicio y cu\u00e1les a\u00fan no. Pero seguimos avanzando, d\u00e1ndonos cuenta de que nos falta informaci\u00f3n sobre nuestros servicios, como d\u00f3nde se almacenan los c\u00f3digos fuente, d\u00f3nde se lanzan las tareas de construcci\u00f3n en TeamCity, c\u00f3mo se despliegan, d\u00f3nde se guardan los c\u00f3digos fuente de las pruebas end2end, fotos sobre la arquitectura y las decisiones tomadas. Idealmente, quer\u00edamos que toda esta informaci\u00f3n estuviera disponible y accesible cuando la necesit\u00e1ramos. Por eso, nuestra tabla se convirti\u00f3 en el punto de partida para buscar informaci\u00f3n.<\/p>\n

Pero QIWI, aunque conserva el esp\u00edritu de una startup, es una gran empresa. Ya tenemos 12 a\u00f1os, y los equipos cambian: las personas se van, otras llegan, se forman nuevos equipos. Y descubrimos en nuestro dominio varios servicios que heredamos. Algunos vinieron con desarrolladores de otros equipos, otros estaban de alguna manera relacionados con el Monedero, por lo que ahora tenemos ese servicio en nuestro balance. \u00bfPor qu\u00e9 investigar c\u00f3mo y qu\u00e9 funciona? El servicio est\u00e1 operativo, y tenemos caracter\u00edsticas del producto que necesitamos implementar.<\/p>\n

Como suele suceder,<\/h2>\n

\nPero en alg\u00fan momento nos damos cuenta de que el servicio deja de cumplir su funci\u00f3n, algo se rompi\u00f3, \u00bfqu\u00e9 hacer en esa situaci\u00f3n? El servicio simplemente dej\u00f3 de funcionar. Por completo. Y nos enteramos de esto, primero, por casualidad y, segundo, seis meses despu\u00e9s. As\u00ed suele ser. Lo \u00fanico que sab\u00edamos era en qu\u00e9 m\u00e1quinas virtuales estaba desplegado el servicio, d\u00f3nde estaban sus c\u00f3digos fuente, y nada m\u00e1s. Hacemos un git clone y nos sumergimos en los pensamientos de la persona que escribi\u00f3 esto hace unos a\u00f1os, pero \u00bfqu\u00e9 vemos? No hay nada del habitual Spring Boot, aunque estamos acostumbrados, ya que somos full stack y esas cosas. \u00bfQuiz\u00e1s hay Spring Framework? Pero no, no hay.<\/p>\n

El chico que escribi\u00f3 todo esto era estricto y programaba todo en Java puro. No hay herramientas familiares para el desarrollador, y surge la idea: ser\u00eda bueno reescribir todo esto. Tenemos microservicios, y desde cada tostadora se escucha el habitual \"\u00a1Chicos, los microservicios son lo que necesitan!\". Si algo va mal, pueden tomar cualquier lenguaje y todo estar\u00e1 bien.<\/p>\n

El asunto es que actualmente no tenemos un cliente que se encargue de este servicio. \u00bfCu\u00e1les eran sus requisitos comerciales, qu\u00e9 deber\u00eda hacer este servicio? Y el servicio est\u00e1 estrechamente integrado en sus procesos comerciales. <\/p>\n

Ahora d\u00edganme, \u00bfqu\u00e9 tan f\u00e1cil es reescribir un servicio sin conocer sus requisitos comerciales? No est\u00e1 claro c\u00f3mo se est\u00e1 registrando el servicio, no se sabe si hay m\u00e9tricas. \u00bfCu\u00e1les son, si es que las hay? A\u00fan m\u00e1s desconocido. Adem\u00e1s, hay una gran cantidad de clases con l\u00f3gica comercial confusa. Algo se registra en alguna base de datos de la que tampoco sabemos nada. <\/p>\n

\u00bfPor d\u00f3nde empezar?<\/h2>\n

\nPor lo m\u00e1s l\u00f3gico: la existencia de pruebas. Generalmente, ah\u00ed hay alguna l\u00f3gica escrita y se pueden hacer inferencias sobre lo que est\u00e1 sucediendo. Actualmente, TDD est\u00e1 de moda, pero vemos que hace 5 a\u00f1os todo era pr\u00e1cticamente igual que ahora: casi no hay pruebas unitarias, y no nos dir\u00e1n nada en concreto. Bueno, excepto tal vez alguna verificaci\u00f3n de c\u00f3mo se firma alg\u00fan xml con alg\u00fan certificado personalizado.<\/p>\n

No pudimos entender nada del c\u00f3digo, as\u00ed que decidimos revisar qu\u00e9 estaba pasando en la m\u00e1quina virtual. Abrimos los registros del servicio y encontramos un error del cliente HTTP: un certificado autofirmado que estaba incrustado en los recursos de la aplicaci\u00f3n hab\u00eda caducado sin piedad. Nos pusimos en contacto con nuestros analistas, pidieron un nuevo certificado, nos lo emitieron y el servicio volvi\u00f3 a funcionar. En apariencia, eso deber\u00eda ser todo. \u00bfO no? De hecho, el servicio funciona, realiza una funci\u00f3n que necesita nuestro negocio. Tenemos ciertos est\u00e1ndares de desarrollo de aplicaciones, que probablemente tambi\u00e9n tenga usted. Por ejemplo, no almacenar registros en el nodo dentro de una carpeta, sino en alg\u00fan tipo de almacenamiento, como Elastic, y consultarlos en Kibana. Tambi\u00e9n podr\u00edamos recordar las m\u00e9tricas doradas. Es decir, la carga en el servicio, la cantidad de solicitudes al servicio, si est\u00e1 vivo o no, c\u00f3mo pasa su HealthCheck. Al menos, estas m\u00e9tricas ayudar\u00e1n a saber cu\u00e1ndo se puede retirar el servicio de manera tranquila y olvidar su existencia como un mal sue\u00f1o.<\/p>\n

\u00bfQu\u00e9 hacer?<\/h2>\n

\nPor lo tanto, a\u00f1adimos este viejo servicio a la tabla y luego vamos a buscar entre los desarrolladores voluntarios que se encarguen del servicio y lo pongan en orden: que escriban al menos alguna informaci\u00f3n sobre el servicio, que a\u00f1adan enlaces a los paneles en Grafana, a las tareas de compilaci\u00f3n, que entiendan c\u00f3mo desplegar la aplicaci\u00f3n; no se puede simplemente subir archivos mediante FTP. <\/p>\n

Lo principal: \u00bfcu\u00e1nto tiempo tomar\u00e1 toda esta \u00fatil actividad de voluntariado? Un sprint para un desarrollador m\u00e1s o menos experimentado, por ejemplo, durante el 20% de la deuda t\u00e9cnica. \u00bfY cu\u00e1nto tiempo se ha gastado en entender toda la enraizada l\u00f3gica de comunicaci\u00f3n con alg\u00fan sistema gubernamental, y actualizarla a tecnolog\u00edas m\u00e1s nuevas? No puedo garantizarlo, tal vez un mes, o tal vez dos de trabajo del equipo. Lo digo por la experiencia de integraci\u00f3n en la actualidad con alg\u00fan nuevo servicio.<\/p>\n

Sin embargo, no hay salida de valor empresarial alguna. Absolutamente ninguna. Tomar un servicio en soporte y dedicarle algo de tiempo es normal. Pero despu\u00e9s de nuestros est\u00e1ndares habituales de trabajo con el servicio, lo a\u00f1adimos a la tabla, se agreg\u00f3 informaci\u00f3n sobre \u00e9l y, quiz\u00e1s, en alg\u00fan momento lo reescribamos. Pero ahora cumple con nuestros est\u00e1ndares de operaci\u00f3n de servicios.<\/p>\n

Como conclusi\u00f3n, me gustar\u00eda proponer un plan sobre qu\u00e9 hacer con los servicios Legacy. <\/p>\n

Reescribir el legado desde cero es una mala idea.<\/b>
\nEn serio, ni siquiera hay que pensarlo. Es claro que hay preferencias, y hay algunas ventajas, pero generalmente, a nadie le importa, incluyendo a ustedes mismos.<\/p>\n

Gu\u00eda<\/b>
\nRevise los c\u00f3digos fuente de sus aplicaciones, haga una gu\u00eda que indique qu\u00e9 hay y d\u00f3nde est\u00e1, adem\u00e1s de c\u00f3mo funciona. Tambi\u00e9n incluya una descripci\u00f3n del proyecto (el correspondiente readme.md) para que quien se encargue de esto despu\u00e9s de ustedes pueda entender r\u00e1pidamente d\u00f3nde se encuentran los registros y las m\u00e9tricas. El desarrollador que se haga cargo solo les dar\u00e1 las gracias.<\/p>\n

Entienda el dominio<\/b>
\nSi posee alg\u00fan dominio, trate de estar al tanto. Puede sonar obvio, s\u00ed, pero no todos se aseguran de que los servicios est\u00e9n alineados. En realidad, trabajar bajo un mismo est\u00e1ndar es mucho m\u00e1s sencillo.<\/p>\n

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

\u00bfQu\u00e9 hace con su legado?<\/h2>\n