Este artículo lo llevará a comprender todo el conocimiento teórico necesario sobre la transformación de la contenedorización de aplicaciones de nivel empresarial y cómo planificar claramente el camino de la transformación nativa de la nube, y le enseñará cómo hacer un buen trabajo en la transformación de la contenedorización.
Destinos y rutas de contenedorización
Como todos sabemos, la transformación digital de las empresas está dirigida principalmente al valor comercial . Debido a la singularidad de cada empresa, generalmente es difícil encontrar una experiencia que coincida completamente como referencia. La arquitectura de la aplicación ha tenido un gran impacto y la aparición de una gran cantidad de nuevas aplicaciones también conducirá a la fragmentación de la arquitectura empresarial original. Por lo tanto, de acuerdo con las diferentes características de la aplicación, se reorganizará y tratará de manera diferente. Para resolver este problema, una nueva generación de dual- La dinámica La arquitectura de TI emerge como lo requieren los tiempos.
La arquitectura de TI de dos estados incluye principalmente dos partes: negocio de estado estable y negocio de estado estable. Los negocios sensibles a menudo están directamente relacionados con la rentabilidad del negocio y seguirán cambiando con las necesidades de los usuarios, por lo que presta más atención a satisfacer la rápida diversidad de negocios, enfatizando la agilidad y la velocidad. El negocio de estado estacionario suele ser un negocio de apoyo, como CRM, ERP, OA, etc., que enfatiza la precisión, la confiabilidad y la estabilidad.
Al mismo tiempo, respaldar la evolución continua de las aplicaciones comerciales también es uno de los principales objetivos de la contenedorización. La infraestructura subyacente de la empresa también ha pasado del equipo de red original más servidores a la virtualización, y luego avanzó a la contenedorización, y la forma de las aplicaciones comerciales de capa superior compatibles también cambiará en consecuencia, cambiando gradualmente de aplicaciones monolíticas tradicionales a aplicaciones RPC/SOA virtualizadas en la era de la modernización y luego se transforman en aplicaciones de microservicio en la era nativa de la nube. Muchas empresas pueden haber llevado a cabo la transformación de microservicios en la era de las máquinas virtuales, pero los beneficios pueden no ser obvios. Aunque la aplicación ya es una entidad independiente, todavía tiene requisitos de capacidad extremadamente altos, como el escalado elástico. En este momento, debe realizarse con la ayuda de contenedores. La combinación de los dos realmente puede sacar a relucir las ventajas de los microservicios. Combinado con la plataforma DevOps, puede realizar mejor la expansión de negocios sensibles y la mejora de la eficiencia de producción.
Además, otro dividendo de la contenedorización es promover la evolución de la sistematización a la plataforma. Debido al alto costo de aprendizaje de la tecnología nativa de la nube, cada vez más empresas están adoptando la tecnología lista para usar. Con una plataforma nativa de la nube flexible y controlable de una sola parada, las empresas ya no necesitan preocuparse detalles de la tecnología de contenedores y microservicios Un conjunto de plataformas proporciona una infraestructura de microservicios lista para la producción, gobernanza, operación y un entorno de mejores prácticas para la operación y el mantenimiento.
Formulario de solicitud nativo de la nube
Los formularios de solicitud nativos de la nube incluyen principalmente las siguientes categorías:
· Aplicación de software intermedio
MySQL, Redis, RabbitMQ, MongoDB, Kafka. Este tipo de aplicación es un formulario de aplicación en la plataforma nativa de la nube. Puede estar en la plataforma contenedora, o puede estar en la máquina virtual original, otra nube pública y otros recursos de infraestructura tradicionales. Lo llamamos servicio de datos, que es Se utiliza para proporcionar aplicaciones con soporte de persistencia.
· Carga de trabajo
La carga de trabajo se refiere a la carga de trabajo en K8, incluida la implementación, StatefulSet, DaemonSet, CronJob, etc.
· Modelo abstracto
Por lo general, se requiere encapsulación o definición de abstracción al implementar una aplicación. Específicamente, una aplicación generalmente se refiere a un sistema de aplicación, y el sistema de aplicación tiene su propio front-end, back-end, middleware, archivos de configuración, red, etc. Por supuesto, en diferentes entornos de clientes, también puede haber diferentes definiciones.Por ejemplo, la aplicación definida por el equipo de microservicios es una aplicación de microservicios, que cubre la carga de trabajo, las capacidades de gobierno, etc. Debido a la definición del modelo abstracto anterior, se derivan aplicaciones OAM, aplicaciones de microservicio y aplicaciones nativas.
· Partición de gestión y estructura organizativa
Una plataforma admite varias aplicaciones, una aplicación admite varios clústeres y los clústeres se dividen en diferentes particiones de administración, como clústeres de producción, clústeres de prueba, clústeres de recuperación ante desastres, etc. El sistema empresarial en la capa de la estructura organizativa puede abarcar varios clústeres, establecer y asignar cuotas de recursos para diferentes proyectos y desarrollarse y mantenerse de forma independiente en diferentes proyectos.
La ruta crítica de aplicar a la nube
El camino para que las empresas migren a la nube debe analizarse y evaluarse exhaustivamente en función de diferentes formas de activos de aplicaciones y objetivos esperados después de migrar a la nube, para determinar el modelo de transformación adecuado y luego adoptar las soluciones y los entornos correspondientes. Hay seis modos de transformación para aplicaciones en la nube:
Encapsular: exponer directamente las API para que las aplicaciones innovadoras llamen. También es un modo aplicable a todas las aplicaciones. Es equivalente a no migrar aplicaciones, sino solo abrir las API de aplicaciones antiguas a aplicaciones nuevas.
Rehost: Migra a la nube sin ninguna modificación. Hay dos situaciones aquí. La primera es que la aplicación original no necesita ser modificada. Por ejemplo, la aplicación original es una aplicación en contenedores y se puede migrar directamente a la nube. La segunda es que no hay tiempo para modifíquelo, y muchos proyectos empresariales tienen un período de tiempo ajustado para la transformación.Si no hay tiempo para la transformación arquitectónica y la división de microservicios, entonces el contenedor se puede usar directamente como una máquina virtual, lo que facilita el uso de la plataforma de contenedores para DevOps , acelera el funcionamiento ágil de la empresa y facilita la transformación posterior de una sola aplicación. Es solo que los resultados y los beneficios no son obvios y es difícil disfrutar plenamente de la comodidad de la nube.
Replataforma: use algunas de las ventajas de la nube para llevar a cabo pequeñas transformaciones, como la contenedorización. Por ejemplo, las empresas pueden darse cuenta de las ventajas que brindan los contenedores al externalizar o desactivar los contenedores. La expansión y contracción automática en escenarios comerciales concurrentes mejora la flexibilidad del sistema y Tolerancia a fallos.
Refactorización: Refactorización parcial utilizando ventajas nativas de la nube. Esta parte involucra principalmente la transformación de microservicios, considerando cómo dividir las aplicaciones comerciales.
Rediseñar: Refactorizar aplicaciones con arquitectura nativa de la nube. Además de considerar la contenedorización y la transformación de microservicios de la aplicación en sí, también es necesario considerar de manera integral el middleware nativo de la nube y volver a planificar y construir más a partir de la arquitectura general.
Reconstruir: Cree una nueva aplicación nativa de la nube. La nativaización integral de la nube puede ayudar a las empresas a disfrutar del dividendo técnico de la reducción de costos nativos de la nube y el aumento de la eficiencia más rápido.
En general, muchas aplicaciones comerciales pueden lograr una transformación nativa de la nube sin problemas sin siquiera cambiar el código. Las empresas deben realizar una consideración general y una planificación razonable en función de su propia visión comercial, entrada-salida, entrega ágil, nivel de servicio, ciclo de transformación y otros objetivos. Se recomienda ir primero a la nube y luego transformarse gradualmente, para dar pleno aproveche las ventajas de la nube nativa antes y cree un mayor valor para la empresa.
Pasos clave para que las empresas se vuelvan nativas de la nube
El primer paso es dar prioridad a la creación de una plataforma de nube de contenedores de nivel empresarial. Proporciona una plataforma para alojar todo, desde aplicaciones tradicionales hasta aplicaciones de microservicios. La modernización de aplicaciones permite la contenedorización del middleware existente.
El segundo paso es innovar en el desarrollo de aplicaciones nativas de la nube. Se recomienda que los nuevos negocios se desarrollen directamente utilizando nuevas pilas de tecnología. Desde el principio, se utilizan marcos tecnológicos ágiles como microservicios, DevOps y API para crear aplicaciones nativas de la nube. en plataformas en la nube de nivel empresarial sin carga histórica.
El tercer paso es migrar las aplicaciones existentes a la nube. Después del análisis y evaluación, clasifique y migre gradualmente la aplicación del sistema original.
El cuarto paso es realizar la gestión de aplicaciones de múltiples nubes. Después de que todas las aplicaciones antiguas y nuevas estén en la nube, las empresas enfrentarán el problema de la gestión de múltiples nubes. En este momento, las empresas deben centrarse en el nivel de operación y mantenimiento y separar la tecnología del negocio. Las aplicaciones deben ejecutarse en múltiples entornos de nube para implementar una gestión completa del ciclo de vida para aplicaciones de múltiples nubes.
¿Qué aplicaciones son adecuadas para ir a la nube?
En general, todas las aplicaciones se pueden migrar a la nube, pero las empresas deben considerar exhaustivamente el costo y los beneficios de actualizar las aplicaciones existentes a la nube para una planificación razonable. Los principios de aplicación a la nube se pueden clasificar principalmente en tres categorías:
La primera categoría, nube prioritaria
· Aplicaciones en contenedores
· Aplicación de arquitectura de microservicios
· Aplicaciones sin estado
La segunda categoría es la recomendada para ir a la nube
Aplicaciones que requieren autorreparación de fallas, escalado elástico y capacidades de iteración rápida
· Aplicaciones de IA, como Tensoflow, aplicaciones con uso intensivo de GPU, etc.
La tercera categoría requiere mayor consideración.
· Aplicaciones de caja negra sin mantenimiento y sin soporte técnico
· Aplicación de recursos pesados
· Hay aplicaciones de complementos especiales, como U-shield
· Aplicaciones con requisitos especiales para el sistema operativo
¿Hay algún criterio para juzgar las aplicaciones que tienen prioridad en la nube?
Con base en los muchos años de experiencia práctica de Lingqueyun en la implementación de la transformación en contenedores, hemos resumido las siguientes condiciones para las aplicaciones en la nube prioritarias:
· Se ha establecido un proceso claro y automatizado de compilación y construcción
Se utilizan herramientas como Maven, Gradle, Make o Shell para automatizar los pasos de construcción y compilación, lo cual es conveniente para compilar y construir automáticamente en la plataforma de contenedores.Es mejor si se han utilizado herramientas de integración continua como Jenkins.
· Se ha realizado la externalización de los parámetros de configuración de la aplicación.
La aplicación tiene parámetros de configuración externalizados en archivos de configuración o variables de entorno, para que el contenedor de la aplicación pueda adaptarse a diferentes entornos operativos.
· Se ha proporcionado una interfaz de verificación de estado razonable y confiable
La plataforma de contenedores juzgará el estado del contenedor a través de la interfaz de verificación de estado y mantendrá el estado del servicio de la aplicación.
· Se ha realizado la externalización del estado y se ha realizado la instancia de la aplicación sin estado
La información del estado de la aplicación se almacena en sistemas externos, como bases de datos o cachés, y la instancia de la aplicación en sí no tiene estado.
No involucra las dependencias subyacentes del sistema operativo y los complejos mecanismos de comunicación de red.
La aplicación se ocupa principalmente de los negocios y no depende en gran medida del sistema operativo subyacente ni de los mecanismos de comunicación de la red, como la multidifusión, para mejorar la portabilidad.
· Los entregables de implementación no deben ser demasiado grandes, y se recomienda estar dentro de 2G
Las aplicaciones ligeras facilitan la transmisión y distribución rápidas en clústeres a gran escala, lo que está más en línea con el concepto de contenedores ligeros y ágiles.
· El tiempo de inicio no debe ser demasiado largo, se recomienda que sea dentro de los 5 minutos
Los tiempos de inicio excesivamente largos no podrán aprovechar las características ágiles de los contenedores, y estas aplicaciones a menudo deben modificarse porque son demasiado pesadas.
¿Está listo para una transformación de contenedores?
Si tiene más requisitos para la transformación de contenedores de aplicaciones, le invitamos a planificar y discutir las mejores prácticas de transformación de contenedores de aplicaciones con nosotros.