Las historias de corte de monolitos a menudo se parecen. El equipo tenía un monolito pesado y torpe, decidieron cortarlo en una dispersión de microservicios regulares e inteligentes, todo se volvió genial. Las historias difieren solo en el grado de horror "antes", alegría "después" y una serie de características secundarias.
En RBK.money, también tenemos microservicios. Pero llegamos a ellos un poco diferente a la mayoría. Todo fue aún peor para nosotros que el monolito: al principio, todo estaba mal.
Bajo el argumento de cómo, de hecho, creamos microservicios, por qué OpenSource no solo es excelente en principio, sino que también funciona como un componente motivador para escribir un buen código.
Entonces, todo estuvo mal. Tanto es así que arreglarlo no tenía ningún sentido, pero tenía sentido acordar nunca recordar este horror y simplemente escribir todo desde cero. E inmediatamente en microservicios. En la primera etapa de desarrollo, inmediatamente hicimos una regla tener en cuenta constantemente el hecho de que algún día querremos volver a abrir todo este bien o parte de él. Después de todo, todo se guarda en la historia de los commits, incluidos los apodos de los desarrolladores, por lo que simplemente nos sentamos e inmediatamente tratamos de escribir todo para que luego no nos avergoncemos de nuestro código frente a la comunidad. Después de todo, nadie quiere sonrojarse por su código o la arquitectura del proyecto, más o menos la historia.
Rápido vs bueno
En un mundo ideal, siempre desea escribir código rápidamente y escribirlo bien. Bueno, es como "Mejor ser rico y saludable que pobre y enfermo". Por lo tanto, los microservicios se han convertido en una excelente forma de salir de la situación. El proceso de escribir código fue construido sobre tareas comerciales. Supongamos que una empresa necesita una funcionalidad que tendrá en cuenta los fondos en las cuentas de contraparte al realizar los pagos. Esta funcionalidad se convierte en un microservicio, con el nombre en código de Contador, que se dedica a las herramientas de contabilidad. Con otros microservicios la misma historia.
Lo principal aquí era asegurarse de que cada funcionalidad comercial estuviera tan concretada que una persona pudiera escribirla. Depende en gran medida de las tareas en sí mismas y de cómo el director técnico o proyecto traduce esto al equipo. Logramos hacer esto, inmediatamente da un par de buenas ventajas significativas.
En primer lugar, proporciona una gran paralelización del desarrollo. Al principio, teníamos unas 10 personas, y logramos escribir una gran cantidad de código al mismo tiempo (y escribir bien). En segundo lugar, le da la oportunidad de rotar completamente. Pero esto ya es un poco más importante de lo que parece a primera vista.
Muy a menudo, una persona comienza a cagar, no porque haya conseguido este trabajo para usted, sino porque sus ojos se vuelven cursi y sus ojos se vuelven aburridos y aburridos. Si una persona está constantemente sentada en el mismo microservicio, puede comenzar a generar govnokod. Y esto no es tanto una cuestión de profesionalismo como una cuestión de tiempo. Después de 7-8 meses, las personas se cansarán de apoyar el mismo microservicio, mirarán a su alrededor, y ahí está la vida, llegó la primavera después del invierno, mis colegas tienen algún tipo de movimiento, nuevamente salió un nuevo iPhone y todos ustedes se sientan en el mismo microservicio. . Así es como nace un monolito con un solo punto de falla en la forma de esta persona cansada con bolsas debajo de los ojos.
O, en general, una persona comienza a pensar que todo está solo en él y descansa en él. Tratará de hacerse indispensable rodeando su trabajo con un montón de "conocimiento secreto" y procedimientos extraños. Al comienzo de mi viaje, tuve situaciones en las que el legado era tan salvaje que era imposible resolverlo sin este conocimiento. Por ejemplo, tenía que iniciar un servicio. Como sueles imaginar esto:
- Inicia el servicio.
Como fue:
- Vaya al registro de Windows.
- Encuentra una clave específica allí.
- Cámbielo a 1.
- Inicia el servicio.
- Restablezca el valor clave a 0.
Este es un ejemplo clásico de complejidad en aras de la complejidad y "Nada funciona aquí sin mí". De hecho, sin esto, todo funciona. Solo que más rápido y mejor. Puede deshacerse de esto por rotación, idealmente cuando una persona escribe un microservicio durante un par de sprints y luego se va a hacer otra tarea. Del mismo modo, apoyamos un intercambio constante de conocimiento en un equipo.
Código del protocolo
Si toma algún TK del negocio, traduzca bien a uno humano, sacúdase la cáscara y evapórese: obtendrá un protocolo, un lenguaje con el que la máquina se comunicará. Es decir, tomamos una tarea comercial, entendemos por nosotros mismos qué exactamente y cómo lo haremos, y la convertimos en una especificación de ahorro o arrogancia (los microservicios dentro se comunican a través de ahorro). El primer paso es describir todo en detalle: qué hará el microservicio, qué tipos de datos recibirá, qué responderá, qué estructuras serán, etc. Este protocolo pasa por la primera revisión de aquellos que tienen una idea clara de cómo funciona todo (arquitectos de facto). Funciona como un filtro grueso a través del cual algunas tonterías francas no pasarán ni siquiera a nivel conceptual.
Tan pronto como aparezca el protocolo, puede sentarse a escribir código. Y si el protocolo es completamente revisado por personas universales, entonces el código en sí está en un equipo de personas específicas. Escribimos en tres idiomas: JS, Java, Erlang. Lo principal es no apurar a nadie con un código de revisión o de escritura. Sí, los negocios siempre y en todas partes deben ser rápidos y geniales. Pero rara vez apuro a los muchachos como director técnico, porque entiendo lo que quieren hacer bien. El resultado es una situación que a menudo me alientan los clientes comerciales con el tiempo. Pero prácticamente no tiene que sonrojarse por la calidad.
Nos apuramos solo una vez cuando el premio gordo se superpuso: un súper cliente y plazos extremadamente urgentes, acaban de crear nuestra billetera. Entonces sí, nos bajamos las mangas e hicimos todo más rápido de lo que planeamos (y peor de lo que queríamos, sí). Idealmente, todo se concibió como un montón de microservicios limpios. Resultó un pedazo de monolito. Las ventajas de la situación son que una vez más nos dimos cuenta de que no hay necesidad de apresurarse. Y el servicio en sí ya se está incorporando lentamente a microservicios separados, como querían.
Hay 50 microservicios en RBK Money, están escritos por unas 20 personas. El ahorro está en todas partes, para los desarrolladores es un protocolo bastante complicado, la degradación es difícil, la documentación también es difícil de escribir. Y si dejé de ahorrar en su forma más pura, me llamarían malas palabras. Por lo tanto, no se nos ocurrió nada: el resto JSON, simple e intuitivo, más OpenAPI, sobresale de manera irregular. Para poder aceptar estas solicitudes desde el exterior, deben ser validadas, autorizadas y luego lanzadas a la plataforma por otros microservicios. Y también escribimos todo esto como un microservicio independiente, que:
- acepta botín exterior;
- valida el esquema;
- autoriza al usuario;
- convierte todo esto en una solicitud de ahorro;
- Bueno, él escribe registros, por supuesto.
¿Es conveniente escribir un sistema de pago en microservicios? Por supuesto, aquí tiene paralelización del trabajo, y mantiene el interés de los empleados, y la ausencia de un solo punto de falla. Un microservicio se averió o, de repente, la persona que lo hizo ayer se fue; no hay problema, puedes arreglar algo rápidamente y poner a una nueva persona en el asiento del piloto durante el nuevo sprint.
Pero existe la opinión de que si una persona se sienta y corta cuidadosamente un microservicio particular durante mucho tiempo, definitivamente lo hace bien. Desde que comenzamos a hablar de esto, por favor escriba en los comentarios qué enfoque está más cerca de usted. Y lo más importante: por qué.