En este documento, se describe el proceso, las prácticas recomendadas y las herramientas para usar Anthos a fin de modernizar las aplicaciones heredadas monolíticas de Java.
Este documento está dirigido a directores de tecnología, directores generales de información, arquitectos empresariales, desarrolladores de aplicaciones, administradores de seguridad de TI, equipos de DevOps y equipos de ingeniería de confiabilidad de sitios (SRE). Se supone que tienes un conocimiento básico de creación de contenedores y sus beneficios operativos y de desarrollo.
En este documento, se propone un enfoque de dos fases en la modernización:
- Creación de contenedores. En esta fase, alojarás en contenedores las aplicaciones candidatas adecuadas y las implementarás en la plataforma de Anthos (ya sea a nivel local o en Google Cloud). En esta fase, se usan varios servicios y tecnologías, como Migrate to Containers, las prácticas modernas de integración continua/implementación continua (CI/CD) y las herramientas de integración del sistema.
- Reestructuración y rediseño de la plataforma. Con el tiempo, refactorizas y rediseñas aplicaciones monolíticas heredadas a frameworks modernos de Java (como Spring Boot) y microservicios.
En este documento, se proporcionan recursos y orientación para cada una de estas fases. También, se ofrece una ruta de acceso alternativa en caso de que planees mantener tu empresa en máquinas virtuales (VM).
Un caso de modernización
Muchas organizaciones tienen dificultades para mantener sus aplicaciones empresariales en ejecución mientras intentan innovar. Los equipos de operaciones y desarrollo deben satisfacer las exigencias nuevas para los servicios de aplicaciones y, además, mantener, operar y mejorar las carteras de aplicaciones existentes.
Esta demanda nueva proviene de las iniciativas comerciales digitales y del objetivo de la transformación digital para mejorar las funciones existentes. Sin embargo, según un informe de Gartner (Building a Multi Application Modernization Business Case [Compila un caso empresarial de modernización de aplicaciones multiplataforma], noviembre de 2019), el 90% de las aplicaciones actuales seguirán en uso en el 2025, y la deuda técnica para respaldar y administrar estas aplicaciones continuará combinándose y consumirá más del 40% de los presupuestos de TI actuales.
Aunque las empresas desarrollan y adoptan aplicaciones nuevas, la mayoría de sus aplicaciones aún son aplicaciones convencionales monolíticas. Muchas de estas aplicaciones heredadas se ejecutan en servidores de aplicaciones comerciales y de propiedad como Oracle® WebLogic o IBM WebSphere. Debido a que estas aplicaciones suelen estar bien optimizadas, mantenidas y administradas, las empresas deben afrontar un desafío para innovar sobre ellas. Además, los servidores de aplicaciones de propiedad pueden aumentar la sobrecarga operativa y requieren (en muchos casos) contratos de licencia con costos inaccesibles.
Varios estudios sugieren que las organizaciones pueden ahorrar tiempo y dinero mediante la modernización de aplicaciones convencionales en lugar de volver a escribir el código de la aplicación existente. Cualquier estrategia para modernizar las aplicaciones heredadas debe enfocarse en reducir el tiempo y el costo de la modernización.
Aplicaciones modernas
Las aplicaciones modernas pueden ayudarte a ofrecer mejores experiencias para los clientes, lo que puede generar la retención y satisfacción de los clientes y, en consecuencia, aumentar la rentabilidad. Los principios del desarrollo moderno de aplicaciones y plataformas destacan los beneficios que trae la transformación digital. En las siguientes secciones, se explican estos principios.
Aumenta la productividad de los desarrolladores y de los operadores
Las aplicaciones heredadas suelen ser aplicaciones monolíticas. Estas aplicaciones tienen una base de código grande que realiza varias funciones. A medida que las aplicaciones crecen, junto con los equipos que las desarrollan y administran, se vuelve difícil mantenerlas y lanzar funciones nuevas con rapidez. Existen muchas dependencias entre equipos que se deben conciliar y aprobar antes de que se pueda lanzar un cambio a la producción y al cliente. Esta dinámica puede provocar una menor productividad de los desarrolladores y los operadores y la insatisfacción de los clientes.
Las aplicaciones modernas se compilan mediante microservicios. Los dominios diferentes de una aplicación monolítica se dividen en servicios independientes, y cada uno es responsable de una función específica (por eso se usa el término microservicios). Esta arquitectura proporciona varios beneficios:
- Para desarrolladores. Separar los servicios uno de otro permite que tus desarrolladores trabajen en sus funciones específicas, sin importar los otros servicios. Este enfoque aumenta la productividad de los desarrolladores, ya que pueden agregar funciones a su servicio sin dependencias estrictas a otros servicios y equipos.
- Para operadores. Con cada actualización de un microservicio, se implementan pequeños cambios, lo que es mucho más fácil de administrar para tu equipo de operaciones que un cambio grande y complejo. La implementación de cambios pequeños de esta forma controlada genera menos riesgos si falla una actualización, lo que aumenta la productividad para las operaciones.
- Para clientes. Las eficiencias operativas y de desarrollo de una arquitectura moderna pueden ayudar a tus equipos a entregar funciones nuevas a los clientes con mayor rapidez que con una arquitectura monolítica.
Enfócate en los servicios y las API
Las aplicaciones heredadas a menudo se consideran en términos de infraestructura. Los servidores, las máquinas virtuales (VM), las herramientas de redes y el almacenamiento son elementos de diseño clave para una aplicación monolítica. Las aplicaciones modernas se consideran en términos de servicios y API. Este enfoque en los servicios y las API ofrece varias ventajas:
- Redundancia y resiliencia del servicio. Puedes ejecutar servicios en cualquier lugar, a menudo en muchos lugares, como en VM, contenedores o clústeres.
- Disponibilidad del servicio. Trabajar con un enfoque en los servicios puede aumentar la disponibilidad general de tu aplicación. Siempre y cuando el servicio esté disponible, las fallas en la infraestructura son irrelevantes y discutibles. Diseñar y pensar en términos de servicios y API en lugar de infraestructuras destaca el tiempo de actividad, y el tiempo de actividad te ayuda a cumplir tu objetivo de nivel de servicio (SLO).
Ejecuta como microservicios en contenedores
Las aplicaciones heredadas, por lo general, se ejecutan como VM o en un equipo físico. Estas plataformas son costosas, se usan de manera ineficiente (CPU y RAM con poco uso) y son más difíciles de administrar que las plataformas modernas basadas en la nube (en especial para servidores de equipos físicos). Las aplicaciones modernas se ejecutan como microservicios en contenedores, lo que proporciona varios beneficios, incluidos los siguientes:
- Aplicaciones más pequeñas y eficientes. Los contenedores pueden empaquetar un microservicio con un impacto de dos a tres órdenes de magnitud más pequeño que una aplicación monolítica.
- Aislamiento de espacio del usuario de Linux. Puedes ejecutar varios contenedores en un solo host si usas el host de manera eficiente.
- Portabilidad entre diferentes infraestructuras y entornos. Debido a que los contenedores encapsulan la aplicación con todas sus dependencias y bibliotecas requeridas, puedes ejecutar contenedores en cualquier entorno, ya sea en un centro de datos local o en un entorno de nube pública.
Compila en estándares abiertos
Las aplicaciones heredadas a menudo usan productos comerciales o con licencia para su funcionalidad. Este enfoque es costoso debido a los costos de licencia y hace que la aplicación dependa en gran medida de las plataformas comerciales.
En algunos casos, el software comercial está limitado por la infraestructura o el hardware en el que se puede ejecutar. Por ejemplo, si el software solo puede ejecutarse de forma local, tu empresa debe administrar infraestructuras y centros de datos costosos (como herramientas de redes, almacenamiento, servidores, energía y HVAC).
Las aplicaciones y los servicios modernos a menudo se compilan mediante software de código abierto, lo que proporciona varias ventajas:
- Extensibilidad y portabilidad. Puedes ejecutar servicios en cualquier lugar.
- Compatibilidad. Las tecnologías de código abierto bien adoptadas, como Kubernetes y Docker, a menudo tienen comunidades sólidas (compuestas por muchas empresas) que compilan funciones que no están vinculadas a una sola empresa o no están orientadas solo para su beneficio. Este enfoque de código abierto da como resultado un mejor conjunto de atributos general para el producto. Cuanto más adoptes una tecnología de código abierto (como Kubernetes), mejor será el conjunto de atributos en comparación con casi cualquier equivalente comercial.
- Flexibilidad. En este modelo, tu empresa ya no está bloqueada con un solo proveedor para la infraestructura o plataforma de tu aplicación. Adoptar estándares abiertos te permite tomar decisiones sobre la aplicación y la infraestructura según los requisitos de la empresa y del cliente.
La plataforma moderna
Las aplicaciones modernas necesitan una plataforma moderna. La plataforma moderna debe satisfacer varias necesidades.
Lanzamiento rápido, confiable y seguro de funciones
Las plataformas modernas deben admitir lanzamientos rápidos, confiables y seguros de funciones nuevas.
- Rápidos. Este requisito depende de la suficiente automatización para implementar servicios y funciones nuevas. La automatización elimina el trabajo y los errores humanos y aumenta la velocidad de entrega.
- Confiables. La plataforma debe permitir a los equipos lanzar funciones de forma gradual o revertirlas a sus estados originales si no funcionan.
- Seguros. La plataforma debe admitir controles de acceso detallados. Solo los operadores autorizados deben poder acceder a los servicios o implementar funciones y servicios en la plataforma.
Prioridad en los servicios
Las aplicaciones modernas se diseñan, desarrollan y ejecutan con vistas a servicios y no a la infraestructura. Esta prioridad en los servicios depende de las plataformas que son resilientes a las fallas de la infraestructura. Las plataformas modernas tienen una funcionalidad integrada que recupera servicios (y la propia plataforma) de fallas de hardware y software.
Enfoque de nubes híbridas y múltiples con un plano de control coherente
Como parte de su transformación digital, muchas empresas se trasladan a una estrategia de nube híbrida o de múltiples nubes para su cartera de servicios. Quizás no puedas mover ciertas aplicaciones de centros de datos locales a la nube pública (por motivos regulatorios, de cumplimiento o de seguridad), pero aún deseas usar la nube para otros servicios. Las plataformas modernas pueden (y a menudo lo hacen) ejecutarse en varios entornos, como centros de datos locales, nubes privadas o una o más nubes públicas. Mientras se ejecutan en varias infraestructuras, las plataformas modernas deben proporcionar una experiencia de plano de control unificada y coherente a los desarrolladores y operadores, lo que aumenta la eficiencia operativa.
Todo como código declarativo
Las plataformas heredadas (como las VM) son imperativas por naturaleza. Los operadores suelen crear recursos y proporcionar secuencias de comandos y parámetros de configuración que se ejecutan en el entorno de ejecución de la aplicación. Cuando los operadores cambian una aplicación, realizan el cambio directamente en la VM en la que se ejecuta la aplicación. Este proceso puede generar un desvío de configuración, lo que significa que no se garantiza que la aplicación y la plataforma estén en el estado previsto en todo momento. En un entorno como este, solucionar problemas y recuperarse ante fallas puede ser difícil.
Las plataformas modernas son sistemas declarativos en los que todos los recursos se definen como código, también conocidas como Infraestructura como código (IAC). La infraestructura, los servicios, las implementaciones, la seguridad y la política se codifican en documentos de recursos que definen el estado previsto de la plataforma. Este enfoque declarativo permite que los operadores definan sus servicios, seguridad y políticas a través de un lenguaje unificado. Debido a que estos recursos son código, se pueden almacenar en un repositorio de código y se someten a la misma etapa de verificaciones de código que las aplicaciones. Cuando el estado de la plataforma reside en un repositorio de Git (junto con el historial de todas las confirmaciones de cada cambio de estado), es más fácil recuperar a un estado anterior cuando se produce una falla del sistema o un desastre.
La plataforma Anthos
Anthos es la plataforma de aplicaciones modernas de Google Cloud. Con la plataforma de Anthos de nubes abiertas, híbridas y múltiples, puedes modernizar tus aplicaciones existentes, compilar nuevas y ejecutarlas en cualquier lugar de forma más segura. Anthos, que está compilada en tecnologías de código abierto creadas por Google (incluidas Kubernetes, Istio y Knative), te ayuda a acelerar el desarrollo de aplicaciones y a lograr la coherencia entre los entornos locales y en la nube.
En el siguiente diagrama, se muestran los componentes de Anthos y sus interacciones en un entorno empresarial típico.
En las siguientes secciones, se describen de modo breve los componentes principales de Anthos.
Clústeres de Anthos: Organización de contenedores
El entorno de procesamiento principal de Anthos se basa en clústeres de Anthos para administrar las instalaciones de Kubernetes en los entornos en los que deseas implementar tus aplicaciones. Estas funciones empaquetan las versiones ascendentes de Kubernetes y te permiten crear, escalar y actualizar clústeres de Kubernetes que cumplan con las especificaciones.
Kubernetes tiene dos partes principales: el plano de control y los componentes de nodos. Cuando usas GKE, Google Cloud aloja el plano de control, y el servidor de la API de Kubernetes es el único componente del plano de control al que pueden acceder los clientes. GKE administra los componentes de nodos en el proyecto del cliente mediante el uso de instancias en Compute Engine. Cuando usas clústeres de Anthos, todos los componentes se alojan en el entorno de virtualización local del cliente.
Con Kubernetes instalado y en ejecución, puedes acceder a una capa de organización común que administra la implementación, la configuración, la actualización y el escalamiento de las aplicaciones.
Anthos Config Management: Administración de políticas
Anthos Config Management te permite administrar implementaciones de Kubernetes de clústeres individuales, clústeres multiusuario y varios clústeres mediante archivos llamados de archivos de configuración. Almacenas archivos de configuración en un repositorio de Git.
Algunos archivos de configuración son manifiestos de objetos de Kubernetes. Otros archivos de configuración no son manifiestos de objetos, sino que proporcionan información que necesita Anthos Config Management. Puedes escribir archivos de configuración en YAML o JSON. Anthos Config Management supervisa las actualizaciones de estos archivos y aplica cambios de forma automática a todos los clústeres relevantes.
Un enfoque de configuración como código te permite administrar la configuración de tus clústeres de Anthos con los mismos principios que podrías usar para administrar tus aplicaciones implementadas en Kubernetes.
Anthos Service Mesh: Administración de servicios
Anthos Service Mesh es un framework compatible con Istio que te permite conectar, supervisar y ayudar a proteger los servicios que se ejecutan en los clústeres de Anthos. Con Anthos Service Mesh, puedes crear una red de servicios implementados, como el balanceo de cargas, la autenticación de servicio a servicio y la supervisión, sin que se necesiten cambios en el código de servicio.
Anthos Service Mesh inserta de forma automática un proxy de sidecar para cada Pod de tu aplicación. Un Pod es la unidad de ejecución básica de una aplicación de Kubernetes. Un Pod encapsula el contenedor de una aplicación (o, en algunos casos, varios contenedores). En Anthos Service Mesh, todos los Pods contienen dos contenedores: el contenedor de la aplicación y un contenedor de proxy de Envoy (también conocido como proxy de sidecar). El proxy de sidecar intercepta todo el tráfico de red desde los Pods y hacia ellos. Anthos Service Mesh también configura una puerta de enlace de entrada para administrar el tráfico entrante a la malla. Puedes usar las API de Istio de código abierto para configurar las políticas que se aplican en los sidecars y las puertas de enlace.
El camino hacia la modernización
Google Cloud proporciona un proceso prescriptivo para trasladar tus aplicaciones de Java de un estado monolítico a microservicios. Puedes optar por adoptar los siguientes pasos y seguir el ritmo que mejor se adapte a tus requisitos y necesidades empresariales:
- Acelera y moderniza las aplicaciones adecuadas que se ejecutan en las VM para que se ejecuten en contenedores sin volver a escribir código.
- Implementa aplicaciones en contenedores en la plataforma Anthos mediante prácticas modernas de CI/CD. Es posible que algunas aplicaciones no sean buenas candidatas para la creación de contenedores y puedan permanecer como VM.
- Refactoriza aplicaciones para pilas de aplicaciones OSS, frameworks modernos y microservicios a lo largo del tiempo.
En el siguiente diagrama de flujo, se ilustra este recorrido.
Cada uno de estos pasos importantes se explica en la próxima sección.
Pasos para la modernización
En las siguientes secciones, se explica cada paso del proceso de modernización y cómo Anthos y Migrate to Containers ayudan en cada etapa.
Paso 1: Crea contenedores para las aplicaciones de Java
En este paso de modernización, creas contenedores para las aplicaciones de Java adecuadas que se ejecutan como VM.
La creación de contenedores es un proceso que empaqueta el código de la aplicación junto con todas las dependencias y bibliotecas de su entorno operativo. Puedes ejecutar varios contenedores en un solo host, cada uno con sus propios entornos de aplicaciones independientes aislados. Los contenedores son alternativas livianas, portátiles y eficientes a las VM.
Por lo general, se compilan y empaquetan aplicaciones de Java como archivos JAR mediante herramientas como Maven o Gradle. Luego, debes ejecutar los objetos binarios en las VM o en servidores de equipos físicos.
Puedes crear contenedores para aplicaciones de Java de dos maneras:
- Usa Migrate to Containers para mejorar y modernizar la aplicación.
- Usa las herramientas del integrador de sistemas para compilar contenedores.
Mejora y moderniza mediante Migrate to Containers
Puedes usar Migrate to Containers para migrar aplicaciones directamente de VM a artefactos alojados en contenedores (como un Dockerfile o manifiestos de recursos de Kubernetes). Luego, implementa los contenedores en Anthos (en GKE y en los clústeres de Anthos en VMware).
Migra con Migrate to Containers
El proceso de usar Migrate to Containers para migrar aplicaciones es el siguiente:
- Identifica candidatos para la migración. En este paso, evalúa qué aplicaciones son adecuadas para la migración. Dos tipos de aplicaciones son buenos candidatos para la migración:
- Aplicaciones que no permiten acceder a su código fuente. Es posible que los desarrolladores ya no sean parte de una empresa y ya no se admita la base de código. En lugar de administrar estas aplicaciones como VM, puedes usar el proceso de creación de contenedores simplificado de Migrate to Containers para migrar estas aplicaciones a Anthos.
- Aplicaciones que se mantienen, pero no se desarrollan. Es posible que algunas aplicaciones no se desarrollen de forma activa, pero las empresas aún las necesiten debido a las dependencias de otros servicios. Migrate to Containers simplifica el proceso de modernización de la plataforma que admite estas aplicaciones.
- Migra a Anthos. Después de identificar los candidatos adecuados para la migración, debes usar Migrate to Containers a fin de convertir las VM en artefactos alojados en contenedores que se puedan implementar en Anthos mediante prácticas modernas de CI/CD (consulta la siguiente sección). Migrate to Containers también ayuda a migrar los datos y el estado de las aplicaciones.
Migrate to Containers y migraciones complejas
A veces, las empresas pueden administrar miles de aplicaciones. La cantidad de aplicaciones que se migrarán o la complejidad de la creación de contenedores pueden impedir que las empresas avancen en iniciativas importantes en la nube. Como resultado, las empresas pueden perder oportunidades de negocios y las ventajas de los mejores servicios de nube pública. Estos servicios pueden ser servicios de datos y estadísticas, como BigQuery, aplicaciones de inteligencia artificial, como AutoML, o aplicaciones de aprendizaje automático (AA), como las API previamente entrenadas de Google Cloud.
Migrate to Containers puede ayudarte con los desafíos y la complejidad de tu cartera de aplicaciones de las siguientes maneras:
- Administra migraciones de aplicaciones a gran escala. Con Migrate to Containers, puedes modernizar y, en paralelo, migrar varias aplicaciones a Anthos sin acumular una deuda técnica para tus desarrolladores y operadores.
- Simplifica la creación de contenedores. Junto con una gran cantidad de aplicaciones, la creación de contenedores puede ser compleja, y las empresas podrían no contar con las habilidades o la cantidad de recursos necesarios para respaldar grandes esfuerzos de modernización de manera oportuna. Para estos casos, Migrate to Containers te proporciona una ruta simplificada y eficiente a Anthos y la modernización.
Para obtener más información, consulta la documentación de Migrate to Containers.
Otras herramientas para la creación de contenedores
Docker es una plataforma muy usada para compilar imágenes de contenedor. Un Dockerfile es un documento de texto que contiene todos los comandos que puedes llamar en la línea de comandos para ensamblar una imagen. Para crear un contenedor de Docker, debes compilar tus objetos binarios (archivos JAR) y, luego, empaquetarlos en un Dockerfile. Después de crear el Dockerfile, puedes usarlo en una canalización de CI/CD. En el siguiente diagrama, se ilustra el flujo de trabajo que usa un Dockerfile.
Paso 2: Implementa aplicaciones en Anthos mediante la CI/CD moderna
En este paso de modernización, implementarás aplicaciones de Java en contenedores en Anthos mediante prácticas de entrega de software modernas.
Las aplicaciones requieren una manera bien organizada, automatizada, repetible y confiable para compilar, probar y entregar a los clientes. Debido a que varios equipos de desarrollo agregan funciones de manera continua, suelen compilar, probar e implementar aplicaciones en contenedores mediante CI/CD.
Beneficios de las prácticas de entrega de software modernas
La plataforma de entrega de software o CI/CD moderna de Anthos te permite hacer lo siguiente:
- Crear y actualizar prácticas recomendadas para el aprovisionamiento de aplicaciones
- Incorporar aplicaciones nuevas a través de proyectos de inicio (o estándar)
- Desarrollar e iterar aplicaciones sin interferir en el desarrollo de otras
- Implementar y propagar políticas en toda la plataforma sin problemas
- Usar GitOps para la implementación y un mejor seguimiento de cambios y administración de versiones
Plataforma de entrega de software con Anthos
Los componentes del siguiente diagrama forman una plataforma de entrega de software completa, que está disponible con la plataforma Anthos.
Cada componente proporciona funcionalidad para el sistema y las aplicaciones que se ejecutan en la plataforma. Varios equipos (como de desarrollo, operaciones y seguridad) suelen ser responsables de mantener el tiempo de actividad, la configuración, la estabilidad y el escalamiento de la plataforma.
Un componente central de la plataforma de entrega de software es el sistema de CI/CD. Cuando comienzas a definir el proceso de CI/CD, debes asegurarte de que cada componente produzca o use artefactos que cumplan con una interfaz estandarizada. Cuando usas una interfaz estándar, es más fácil intercambiar cada componente cuando llega una implementación mejor al mercado. Cuando creas una plataforma para aplicaciones en contenedores, puedes elegir entre tres interfaces estandarizadas:
- Repositorios de Git
- Imágenes de Docker
- Manifiestos de Kubernetes
Con estas interfaces implementadas, puedes crear una canalización de CI/CD reutilizable y flexible con los flujos que se muestran en el siguiente diagrama.
El proceso es el siguiente:
- Los desarrolladores confirman el código de la aplicación en el repositorio de Git de la aplicación.
- El sistema de CI prueba el código, crea un artefacto de imagen de Docker y almacena la imagen en un registro.
- Una vez que el artefacto está listo para la implementación, se agrega una referencia al artefacto en el archivo de configuración de la aplicación.
- Esa configuración de la aplicación se renderiza en un formato legible en Kubernetes y se almacena en un repositorio de código, que lo implementa en un entorno de preproducción.
- Después de confirmar los cambios en el repositorio de código, los operadores los revisan y, luego, los fusionan en la rama principal.
- La aplicación se implementa en producción.
- Cuando los operadores quieren realizar cambios en toda la organización, confirman esos cambios en sus repositorios, lo que activa una configuración de la aplicación. Cuando los desarrolladores implementan el siguiente cambio, toman las actualizaciones de los operadores.
- Al mismo tiempo, los ingenieros de seguridad pueden implementar y ajustar las políticas que definen lo que se puede implementar mediante la confirmación de su propio repositorio de políticas.
Paso 3: Optimiza las VM locales para aplicaciones de Java heredadas
En este paso de modernización, las aplicaciones de Java se ejecutan como VM en centros de datos locales o en Google Cloud, como se muestra en el siguiente diagrama.
Algunas aplicaciones de Java podrían no ser buenas candidatas para la creación de contenedores por los siguientes motivos:
- Algunas de tus aplicaciones son fundamentales para la empresa. Si migrar a contenedores las aplicaciones fundamentales para tu empresa es demasiado riesgoso, aún puedes obtener los beneficios del costo de elasticidad de la infraestructura si migras las VM a Google Cloud. En Google Cloud, puedes personalizar el tamaño de la VM para maximizar los costos de uso.
- Los equipos operativos no están familiarizados con la administración de una plataforma moderna. Es posible que algunos equipos de operaciones no se sientan cómodos con la administración de entornos de VM o que no tengan las habilidades para operar en plataformas modernas en contenedores. Por ejemplo, es posible que tu equipo ya esté familiarizado con la cadena de herramientas actual para administrar la conectividad y las dependencias entre aplicaciones heredadas, pero que necesite tiempo a fin de mejorar el funcionamiento de una plataforma en contenedores en producción.
- Debes adoptar la nube en etapas. Por ejemplo, es posible que desees comenzar a adoptar la nube, pero no quieras realizar demasiados cambios a la vez. O quizás no desees cambiar el entorno (de un centro de datos a la nube) y las plataformas (de VM a contenedores) al mismo tiempo por los riesgos que conlleva.
- Tienes restricciones operativas y de presupuesto. Esto puede incluir los requisitos de hardware, infraestructura, licencias o arquitectura de la aplicación.
Opciones para ejecutar cargas de trabajo de VM
Puedes elegir una o más de las siguientes opciones para ejecutar tus cargas de trabajo de VM de manera más eficiente:
- En Google Cloud. Puedes ejecutar las VM en Google Cloud de dos maneras:
- Como instancias de Compute Engine. Compute Engine ofrece VM configurables que se ejecutan en los centros de datos de Google y tienen acceso al almacenamiento en bloque y la infraestructura de red de alto rendimiento. Con esta opción, se evita que las empresas administren servidores y centros de datos locales y paguen por las licencias comerciales de virtualización (si corresponde).
- Como VMware como servicio. La sociedad entre VMware y Google Cloud ofrece una plataforma abierta con el fin de garantizar implementaciones, operaciones y opciones de seguridad coherentes para las aplicaciones en la nube en entornos de nubes híbridas y múltiples. Esta opción es aplicable para las empresas que ejecutan VMware en la actualidad y que dependen de la funcionalidad específica de VMware. Las empresas se encuentran en un entorno de nube híbrida en el que quieren un plano de control coherente para administrar sus VM (en varios entornos) o ya no desean administrar sus propios centros de datos ni la infraestructura del servidor.
- Centros de datos locales. Es posible que ejecutes ciertas aplicaciones como VM locales por distintas razones:
- Consideraciones reglamentarias o de cumplimiento
- Necesidades de rendimiento que requieren que estén más cerca de sus usuarios o de otras aplicaciones
- Inversiones actuales en hardware local
Herramientas y soluciones para migrar VM
Google Cloud proporciona varias herramientas y soluciones que puedes usar para migrar tus VM a Google Cloud. Con Migrate to Virtual Machines, puedes validar, ejecutar y migrar aplicaciones a Google Cloud en cuestión de minutos, mientras se migran los datos de manera transparente en segundo plano. Para obtener recursos sobre cómo migrar a Compute Engine, consulta Migración a Google Cloud: Comienza ahora.
Para las migraciones a VMWare como servicio, Google trabaja con socios de confianza a fin de proporcionar servicios profesionales que puedan ayudar a tus migraciones de VMware a Google Cloud.
Paso 4: Refactoriza las aplicaciones en microservicios
Después de modernizar la plataforma, puedes enfocarte en modernizar aplicaciones que se ejecutan en la plataforma. En esta etapa, tomarás las aplicaciones que se ejecutan en la plataforma de Anthos y las refactorizarás en microservicios.
Es posible que tengas algunas aplicaciones que aún se ejecuten como monolíticas en contenedores, pero eso no es un problema. Un requisito para modernizar tus aplicaciones es migrarlas a una plataforma moderna (como Anthos). Después de la migración, el proceso para modernizar tus aplicaciones en microservicios puede ocurrir más adelante.
El traspaso a Anthos permite que los desarrolladores y operadores se familiaricen con las formas nuevas de administrar aplicaciones y plataformas. Los desarrolladores se acostumbran a combinar código con mayor rapidez y realizar pruebas con frecuencia, mientras que los operadores se familiarizan con la forma moderna de compilar, probar y entregar software a sus clientes.
Para las aplicaciones que se ejecutan en la plataforma de Anthos, tus líneas de negocio pueden priorizar las que se modernizarán en microservicios. Google y nuestros socios de integración de sistemas proporcionan varias herramientas para desarrolladores y operadores a fin de ayudar a las empresas en este paso de modernización. En las siguientes secciones, se analizan estos recursos.
Spring Google Cloud
Como parte de la refactorización, puedes migrar las aplicaciones de Java a frameworks de Java modernos, como Spring Boot. Spring Boot y Spring Framework proporcionan un modelo de configuración y programación integral para aplicaciones empresariales modernas basadas en Java. Spring Cloud proporciona herramientas para que los desarrolladores creen con rapidez algunos de los patrones comunes en sistemas distribuidos, como administración de configuración, descubrimiento de servicios, disyuntores, enrutamiento inteligente, micro-proxy, bus de control, tokens únicos, bloqueos globales, elección de liderazgo, sesiones distribuidas y estado del clúster.
Para simplificar el uso de Google Cloud desde aplicaciones de Spring Boot, el proyecto Spring Google Cloud proporciona varias bibliotecas y funciones que admiten los siguientes productos de Google Cloud:
- Pub/Sub: Spring Integration y Spring Stream
- Cloud Spanner, Datastore y Cloud SQL: Spring Data
- Cloud Logging y Cloud Trace
- Firestore: repositorios reactivos de Spring Data
- Cloud Storage: Spring Resource y Spring Integration
- API de Cloud Vision: la plantilla
CloudVisionTemplate - Identity-Aware Proxy (IAP): extracción de identidad de Spring Security desde encabezados de IAP
- BigQuery: Spring Integration
Herramientas para desarrolladores
Google Cloud proporciona herramientas que te ayudan a crear aplicaciones modernas de Java en contenedores. Algunas de estas herramientas son las siguientes:
- Cloud Code. Cloud Code proporciona asistencia de IDE durante todo el ciclo de desarrollo de las aplicaciones de Kubernetes, desde la creación de un clúster para desarrollo y pruebas hasta la ejecución de una aplicación finalizada en producción. Cloud Code proporciona muestras listas para ejecutar, fragmentos de configuración listos a fin de usar y una experiencia de depuración personalizada a fin de simplificar el desarrollo con Kubernetes. Cloud Code proporciona una experiencia optimizada de Google Kubernetes Engine (GKE) que simplifica la creación de clústeres alojados en Google Cloud y se integra mejor a las herramientas de Google Cloud, como Cloud Source Repositories, Cloud Storage y diferentes bibliotecas de Cloud. Puedes usar Cloud Code con VS Code o IntelliJ.
- Artifact Registry. Artifact Registry proporciona una ubicación central para almacenar artefactos y compilar dependencias como parte de una experiencia integrada de Google Cloud. Artifact Registry proporciona una ubicación única para administrar paquetes, imágenes de contenedor de Docker y bibliotecas. Puedes usar estos artefactos (imágenes de contenedor y paquetes) en una canalización moderna de CI/CD, como se describe antes en este documento.
Herramientas de compilación como Jib y Buildpacks. Jib y Buildpacks te permiten compilar contenedores mediante las herramientas de Java que ya conoces (como Maven o Gradle). Sin esas herramientas de compilación, debes crear y probar el Dockerfile de forma manual. Este enfoque manual requiere un host con el daemon de Docker en ejecución para crear y ejecutar los contenedores. Este proceso incluye algunos pasos más y puede ser repetitivo para los desarrolladores que deseen enviar su código a la producción lo más rápido posible y sin problemas. En un solo paso de compilación, Jib organiza la compilación del objeto binario, crea la imagen de contenedor y la envía a un registro de contenedores. Jib usa herramientas de compilación que los desarrolladores conocen, lo que aumenta su productividad. Después de enviar el contenedor de Java al registro, puedes implementarlo a través de una canalización de CI/CD. En el siguiente diagrama, se muestra este flujo general para Buildpack o Jib.
Actualiza tu plataforma a servidores de aplicaciones de código abierto
En algunos casos, la refactorización de las aplicaciones de Java también implica rediseñar sus servidores. A fin de reducir los costos de licencia, las aplicaciones Java que se ejecutan en plataformas de servidores de aplicaciones comerciales (por ejemplo, WebSphere o WebLogic) se rediseñan para incorporar componentes de código abierto (por ejemplo, JBoss o Tomcat).
Arquitectura heredada de aplicaciones de Java
Las aplicaciones de Java heredadas, por lo general, usan una arquitectura JEE de 3 o 4 niveles. La arquitectura JEE admite el desarrollo basado en componentes de aplicaciones empresariales de varios niveles. En el siguiente diagrama, se muestran los niveles que se suelen encontrar en un sistema de aplicaciones JEE.
Los niveles son los siguientes:
- Nivel de presentación. En el nivel de presentación, los componentes web, como servlets y páginas JavaServer (JSP o JSF), o las aplicaciones Java independientes proporcionan una interfaz dinámica para el nivel intermedio.
- Nivel medio o de la aplicación. En el nivel de la aplicación, o nivel medio, Enterprise Java Beans y los servicios web encapsulan la lógica empresarial reutilizable y distribuible para la aplicación. Estos componentes a nivel del servidor se encuentran en un servidor de aplicaciones de JEE, que proporciona la plataforma para que estos componentes realicen acciones y almacenen datos.
- Nivel de datos empresariales. En el nivel de datos, los datos de la empresa se almacenan y persisten, por lo general, en una base de datos relacional.
Estos diferentes niveles suelen implementarse en entornos virtualizados y se basan en servidores de aplicaciones, lo que puede generar costos de licencia altos.
Beneficios de pasar a estándares abiertos
El cambio a estándares abiertos reduce los costos de licencias y proporciona los beneficios de las metodologías de implementación basadas en la nube y una plataforma basada en la nube.
Herramientas y soluciones
Google Cloud se asocia con varios integradores de sistemas (SI) que tienen enfoques comprobados y herramientas para rediseñar aplicaciones de JEE y adoptar tecnologías de OSS.
El proceso de actualización de plataforma comienza con la evaluación de tus aplicaciones de Java heredadas. La evaluación considera varios factores, como la complejidad de una aplicación, la funcionalidad, las métricas de uso y la importancia empresarial. Esta evaluación proporciona una lista priorizada de aplicaciones que son candidatas para someterse a una actualización de plataforma. Los SI proporcionan herramientas para desarrolladores y DevOps que ayudan a las empresas a quitar todas las dependencias del servidor de aplicaciones comerciales del código fuente. Se tienen en cuenta las pruebas y los criterios de salida para cada aplicación antes de pasar a la siguiente etapa (implementación). Esta etapa es aplicable para aplicaciones en las que es posible acceder al código fuente y existe la variante de código abierto de la plataforma.
Refactoriza las prácticas recomendadas
En los siguientes dos artículos de Google Cloud, se explican los beneficios y el proceso para pasar de aplicaciones monolíticas a microservicios:
- Migra una aplicación monolítica a microservicios
- Respalda tu migración con la expansión de malla de Istio
Conecta microservicios a las VM con Anthos Service Mesh
Las empresas tienen una variedad de aplicaciones. Casi todas las empresas terminan con aplicaciones que se ejecutan en una de las siguientes plataformas:
- La plataforma Anthos para ejecutar microservicios en contenedores
- Una plataforma de virtualización para ejecutar VM
A menudo, los servicios que se ejecutan en estas dos plataformas dependen el uno del otro y deben poder comunicarse de manera segura entre sí. En el caso de los microservicios que se ejecutan en la plataforma Anthos, Anthos Service Mesh proporciona una conexión con seguridad mejorada a las VM que se ejecutan fuera de Anthos en un entorno virtualizado.
Beneficios de Anthos Service Mesh con las VM
- Las VM pueden aprovechar el mismo framework declarativo de administración de políticas y seguridad del estilo de Kubernetes, como contenedores y microservicios que se ejecutan en Anthos. Con este enfoque, se permite que los operadores se aseguren de que haya una conexión autenticada con seguridad mejorada (mTLS) entre los contenedores que se ejecutan en Anthos y las VM que se ejecutan en otro entorno.
- No es necesario volver a codificar en las VM existentes para que aparezcan como servicios en la plataforma Anthos. Después de que la VM aparece como un servicio, Anthos la trata como un servicio que se ejecuta en GKE.
- Los operadores obtienen una observabilidad mejorada (métricas) para las VM sin ninguna instrumentación. Las métricas aparecen como si fueran un servicio que se ejecuta en Anthos.
De las VM a la creación de contenedores
Con el tiempo, puedes mover tus VM existentes refactorizadas a contenedores. Este enfoque te permite avanzar hacia la modernización a tu propio ritmo y priorizar las aplicaciones que deseas modernizar.
¿Qué sigue?
- Consulta la lista de tareas de integración de Google Cloud Enterprise.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.