Cloud Key: C贸mo construir sus aplicaciones nativas de la nube

En una publicaci贸n anterior, hablamos sobre c贸mo los servicios en la nube se han convertido en un est谩ndar no escrito para proporcionar servicios de TI. Es f谩cil adivinar que las empresas que a煤n quieren ganar dinero con las aplicaciones de los usuarios deben adaptarse y crear nuevos productos teniendo en cuenta el enfoque nativo de la nube. Sin embargo, para los desarrolladores esta es definitivamente una noticia positiva, ya que el uso de tecnolog铆as en la nube les abre nuevas y enormes oportunidades. Lo principal es poder deshacerse de ellos correctamente.


Cuando una aplicaci贸n ordena un entorno


Si ya ha le铆do la gu铆a de tecnolog铆a en la nube, probablemente recordar谩 que la tecnolog铆a de virtualizaci贸n es una de las "fuentes m谩gicas" de las nubes. Gracias a esto, el desarrollador pr谩cticamente no necesita pensar en los par谩metros de los servidores en los que funcionar谩 su aplicaci贸n. 驴Por qu茅 dedicar tiempo a esto si un hipervisor o contenedor configurado correctamente puede configurar una m谩quina con casi cualquier caracter铆stica que la aplicaci贸n necesite para funcionar?

El desarrollo de esta idea es el enfoque de Infraestructura como c贸digo (IAC). Su esencia es permitir que los desarrolladores o servicios operativos usen los mismos enfoques que se usan durante la fase de desarrollo para mantener la infraestructura. Le permite preparar unidades de control de software comunes por adelantado e integrar f谩cilmente dichos componentes en nuevos proyectos.

Las capacidades de los centros de datos modernos ya nos permiten pasar al lenguaje declarativo de la gesti贸n de la infraestructura. Idealmente, la aplicaci贸n deber铆a administrar el grupo de recursos que ocupa en el centro de datos. Esto permitir谩 que el desarrollador no quede bloqueado en las limitaciones asociadas con el proceso de trabajar con la infraestructura, cuando sea necesario ordenar y dise帽ar con anticipaci贸n o si los mismos componentes de la infraestructura se repiten en diferentes proyectos.


De hecho, el desarrollador o ingeniero realiza una solicitud de extracci贸n, que contiene la configuraci贸n de la m谩quina virtual (kernel, memoria, red, plantilla, etc.), luego el administrador del entorno virtual crea la m谩quina de forma independiente o crea una nueva instancia de base de datos o inicia el servicio preinstalado, de acuerdo con la configuraci贸n en archivo. Este enfoque es una verdadera salvaci贸n cuando se trabaja con big data y redes neuronales. Las aplicaciones asociadas con estas tecnolog铆as, en algunos casos, requieren cantidades din谩micamente cambiantes de memoria y potencia del procesador.

Por ejemplo, para entrenar una red, es necesario "manejar" cientos de gigabytes de informaci贸n a trav茅s de ella, y las nubes le permiten obtener la capacidad requerida para esto a pedido. Una vez completada la capacitaci贸n, los recursos se devuelven al grupo de proveedores y el desarrollador no necesita pensar qu茅 hacer con ellos o c贸mo configurar la aplicaci贸n de otra manera para que contin煤e funcionando a menor capacidad.

Monolito vs. caos ordenado


Debido al hecho de que las nubes pueden adaptarse de manera flexible a las necesidades del desarrollador, esto, en teor铆a, simplifica otra tarea: el problema de escalar aplicaciones. 驴Por qu茅 te贸ricamente?

Desafortunadamente, la tarea de escalar aplicaciones no es lineal. Para que la aplicaci贸n pueda hacer frente a grandes cargas durante los per铆odos de m谩xima asistencia (o computaci贸n), no es suficiente solo darle memoria adicional y potencia de procesador. Absolutamente cada aplicaci贸n tradicional tiene un umbral, despu茅s del cual ya no puede "digerir" nuevos recursos y demostrar un aumento en el rendimiento. El problema en este caso no son los recursos, sino la arquitectura de la mayor铆a de los programas.

Este problema es especialmente grave para aplicaciones con una arquitectura monol铆tica, que, de hecho, son archivos binarios 煤nicos. Las ventajas de este enfoque son obvias: las aplicaciones monol铆ticas son bastante simples y lineales. Todos los escenarios de comportamiento del usuario pueden predecirse, rastrearse y, si es necesario, depurarse.

Sin embargo, tal simplicidad tiene un precio. En primer lugar, estos son los problemas de escalamiento mencionados anteriormente. En alg煤n momento, incluso la aplicaci贸n monol铆tica m谩s considerada deja de funcionar de manera m谩s eficiente a partir de una actualizaci贸n de la configuraci贸n del servidor en la que se ejecuta.


En segundo lugar, una aplicaci贸n monol铆tica no es tan f谩cil de transferir a nuevos servidores y esto puede requerir una recompilaci贸n completa del programa.
En tercer lugar, dicha aplicaci贸n es dif铆cil de mantener y desarrollar. Cualquier cambio de actualizaci贸n requiere el ensamblaje completo de todo el programa, y 鈥嬧媢n error en uno de los bloques de c贸digo puede provocar la ca铆da de todo el sistema.

En busca de ideas sobre c贸mo resolver estos problemas, se desarroll贸 otro concepto: la arquitectura orientada a servicios (SOA). Implica que la aplicaci贸n se divide en varios m贸dulos, cada uno de los cuales proporciona a los dem谩s alg煤n tipo de funcionalidad. Los m贸dulos interact煤an entre s铆 a trav茅s de un conjunto de servicios web y pueden acceder de forma independiente a una o sus propias bases de datos.

Este enfoque realmente simplifica el soporte del programa y no convierte su actualizaci贸n "en el trabajo de un zapador", en el que no hay lugar para el error; pero 茅l tambi茅n tiene sus defectos. La clave son los problemas para escalar el desarrollo de tales aplicaciones. A medida que el programa crece, se hace cada vez m谩s dif铆cil "insertar" nuevas caracter铆sticas en los paquetes 5-10 aprobados originalmente por el arquitecto. Su n煤mero est谩 creciendo, lo que se convierte en problemas con el apoyo.

El microservicio como elemento de evoluci贸n de la aplicaci贸n.


El resultado de la evoluci贸n de SOA es la idea de la arquitectura de microservicios, que se utiliza en el dise帽o de aplicaciones en la nube. Conceptualmente, las ideas de ambos enfoques son extremadamente similares, y algunos arquitectos ni siquiera seleccionan la arquitectura de microservicios como un paradigma separado, consider谩ndolo un caso especial de SOA.

La arquitectura de microservicios implica que la aplicaci贸n no consta de una peque帽a cantidad de m贸dulos grandes, sino de muchas partes independientes. A diferencia de un monolito, en una aplicaci贸n de microservicio, puede usar varios m茅todos para la interacci贸n de componentes entre s铆. El sistema no tiene un solo estado predeterminado. En cambio, cada componente funciona "de acuerdo con la situaci贸n": tan pronto como recibe un evento, comienza a funcionar. Esto permite una arquitectura muy flexible e independiente.
Al mismo tiempo, la cantidad de servicios en la aplicaci贸n de microservicios cambia constantemente: algunos se agregan y otros se eliminan. En el nuevo enfoque, cualquier microservicio puede ser reemplazado y una cadena de microservicios incrustada en su lugar. Otros servicios contin煤an funcionando de manera estable, porque no est谩n directamente relacionados. Esta es la evoluci贸n natural del programa. Gracias a esto, los desarrolladores y arquitectos tienen la oportunidad de cambiar algo r谩pidamente para responder a los cambios en los requisitos comerciales y superar a los competidores.

Adem谩s de aumentar la velocidad de actualizaci贸n de actualizaciones, el uso de la arquitectura de microservicios permite una administraci贸n descentralizada. El equipo responsable del desarrollo de un servicio tiene derecho a determinar su arquitectura interna y sus caracter铆sticas. Tal enfoque, por cierto, ahora est谩 siendo implementado por el Consejo de Arquitectura de Sberbank en el Bloque de Tecnolog铆a.

Al mismo tiempo, si茅ntate a desarrollar tu aplicaci贸n en la nube, no debes apresurarte con la rapidez de aplastarla en sus elementos constitutivos. El principal oponente de un enfoque tan irreflexivo es Martin Fowler; Es uno de los autores de la idea de la arquitectura de microservicios. Es m谩s f谩cil usar inicialmente un enfoque monol铆tico, y luego estimular la evoluci贸n de la aplicaci贸n de una manera "natural", enfoc谩ndose en la ruptura de cuellos de botella y la adici贸n de funciones adicionales.

Como resultado, podemos formular la siguiente regla: la tarea del programador cuando trabaja con la arquitectura de microservicios no es solo dividir la aplicaci贸n en el n煤mero m谩ximo de componentes, sino distinguir deliberadamente entre su responsabilidad de recibir y procesar datos.

Cuatro detalles


Adem谩s de las muchas ventajas obvias, la arquitectura de microservicios tiene sus propias caracter铆sticas, que deben tenerse en cuenta al desarrollar su aplicaci贸n en la nube. En particular, para respaldar el funcionamiento de una aplicaci贸n de este tipo, es necesario mantener constantemente requisitos crecientes para la calidad de la gesti贸n de las API internas.

Cuando uno de los componentes cambia su interfaz, debe admitir la compatibilidad con versiones anteriores para admitir la versi贸n anterior de su propia API. Si se observa esta regla, puede cambiar din谩micamente de la versi贸n anterior a la nueva sin fallas. Si no se resuelve el soporte para la versi贸n anterior de la API, esto amenaza, en el mejor de los casos, con la p茅rdida de parte de la funcionalidad de la aplicaci贸n y, en el peor de los casos, con bloqueos permanentes en su funcionamiento.

La segunda caracter铆stica importante de las aplicaciones de microservicios es la dificultad de encontrar errores en ellas. Si una aplicaci贸n escrita en l贸gica monol铆tica o SOA se bloquea, no ser谩 dif铆cil encontrar la fuente del problema. En una aplicaci贸n que consta de muchos servicios, la b煤squeda de la causa del error puede llevar mucho tiempo debido al hecho de que los datos del usuario a menudo pasan por varios microservicios, y es dif铆cil determinar cu谩l falla. Al mismo tiempo, el proceso de b煤squeda de errores debe llevarse a cabo con mucho cuidado: cualquier refactorizaci贸n fallida puede conducir a un colapso del m贸dulo de trabajo y, adem谩s del problema inicial, el desarrollador recibir谩 un segundo.


El tercer detalle importante que debe tenerse en cuenta al desarrollar una aplicaci贸n en la nube es la forma en que sus componentes interact煤an entre s铆. Al igual que en SOA, los servicios utilizan servicios web para intercambiar datos, pero los patrones de interacci贸n, como la transmisi贸n, CQRS, el abastecimiento de eventos, han aparecido en la arquitectura de microservicios. Por lo general, los desarrolladores esperan que el tiempo de respuesta entre la solicitud y la respuesta en la aplicaci贸n sea bastante peque帽o. En un sistema distribuido, uno ni siquiera puede confiar en el hecho de que la respuesta llegar谩 en absoluto.

Adem谩s, en la arquitectura de las aplicaciones en la nube, los microservicios utilizan varias bases de datos que son las m谩s adecuadas para resolver sus problemas espec铆ficos. Por ejemplo, las cuadr铆culas pueden leer r谩pidamente, pero dif铆cilmente pueden hacer frente a una gran cantidad de operaciones de cambio de datos. Tal base es muy adecuada para mantener cuentas de dep贸sito; rara vez cambian. Otro tipo de operaci贸n es el procesamiento; puede haber docenas de cambios en cada mapa en 茅l todos los d铆as y, por el contrario, hay pocas lecturas de datos.

Finalmente, el cuarto hecho que debe recordar al desarrollar una aplicaci贸n en la nube es que la arquitectura de microservicios se centra principalmente en el uso de servicios sin estado. En este caso, no vayas a los extremos. Algunos servicios, si es necesario, a煤n pueden proporcionar apoyo estatal si la l贸gica empresarial lo requiere, y deben dise帽arse con especial cuidado.

Por ejemplo: si el usuario solicita un pr茅stamo, el sistema que recibi贸 la solicitud debe guardar este estado para transferirlo a otros servicios. Pero el servicio responsable de encontrar informaci贸n en el archivo interno de historiales crediticios puede no guardar su estado y olvidarse de los datos sobre el nombre de usuario que busc贸 hace un par de minutos; de todos modos, despu茅s de un momento llegar谩 una nueva solicitud (aunque en este proceso puede ser diferente comportamiento del servicio).

Todos los ejemplos y pr谩cticas descritos anteriormente ya son utilizados activamente por los l铆deres de la industria global de TI. Por ejemplo, Netflix es pionero en el desarrollo de la arquitectura de microservicios. La compa帽铆a ha lanzado muchas aplicaciones de c贸digo abierto, bibliotecas y un marco para monitorear, equilibrar y registrar aplicaciones de microservicios.

Source: https://habr.com/ru/post/437488/


All Articles