Azure ofrece muchas opciones para que los equipos creen e implementen aplicaciones Java. En este artículo, se tratan los escenarios estándar de Java en Azure y se proporcionan sugerencias y consideraciones de planeación generales.
Apache®, Apache Kafka, Apache Struts, Apache Tomcat y el logotipo de la llama son marcas registradas o marcas comerciales de Apache Software Foundation en los Estados Unidos y otros países. El uso de estas marcas no implica la aprobación de Apache Software Foundation.
Plataforma
Antes de seleccionar un escenario en la nube para la aplicación Java, identifique su plataforma. La mayoría de las aplicaciones Java utilizan una de las siguientes plataformas:
- Aplicaciones JAR de Spring Boot
- Aplicaciones de Spring Cloud
- Aplicaciones web
- Aplicaciones de Jakarta EE
Aplicaciones JAR de Spring Boot
Las aplicaciones JAR de Spring Boot se invocan normalmente directamente desde la línea de comandos. Controlan las solicitudes web. En lugar de confiar en un servidor de aplicaciones para controlar las solicitudes HTTP, estas aplicaciones incorporan comunicación HTTP y otras dependencias directamente en el paquete de aplicación. Estas aplicaciones se suelen crear con marcos como Spring Boot, Dropwizard, Micronaut, MicroProfile y Vert.x.
Estas aplicaciones se empaquetan en archivos con la extensión .jar, conocidos como archivos JAR.
Aplicaciones de Spring Cloud
El estilo arquitectónico de microservicios es un enfoque para desarrollar una aplicación individual como un conjunto de pequeños servicios. Cada servicio se ejecuta en su propio proceso y se comunica mediante mecanismos ligeros, a menudo una API de recursos HTTP. Estos servicios se basan en las funcionalidades empresariales.
La maquinaria de implementación automatizada implementa de forma independiente estos microservicios. Hay una administración centralizada mínima, que puede estar escrita en distintos lenguajes de programación y usar diferentes tecnologías de almacenamiento de datos. Estos servicios se suelen crear con marcos como Spring Cloud.
Estos servicios se empaquetan en varias aplicaciones como archivos JAR.
Aplicaciones web
Las aplicaciones web se ejecutan en un contenedor de servlets. Algunas usan las API de servlet directamente, mientras que otras usan otros marcos que encapsulan las API de servlet, como Apache Struts, Spring MVC y JavaServer Faces.
Las aplicaciones web se empaquetan en archivos con la extensión .war, conocidos como archivos WAR.
Aplicaciones de Jakarta EE
Las aplicaciones de Jakarta Enterprise Edition (Jakarta EE) pueden contener algunos, todos o ninguno de los elementos de las aplicaciones web. También pueden contener y consumir muchos más componentes, tal y como se define en la especificación de Java EE. Las aplicaciones de Jakarta EE se conocían anteriormente como aplicaciones Java EE o aplicaciones J2EE.
Las aplicaciones de Jakarta EE se pueden empaquetar como archivos WAR o como archivos con la extensión .ear, conocidos como archivos EAR.
Las aplicaciones de Jakarta EE se deben implementar en servidores de aplicaciones compatibles con Jakarta EE. Algunos ejemplos son WebLogic, WebSphere, WildFly, GlassFish y Payara.
Las aplicaciones que solo se basan en las características proporcionadas por la especificación de Jakarta EE se pueden migrar desde un servidor de aplicaciones compatible a otro. Si la aplicación depende de un servidor de aplicaciones específico, es posible que tenga que seleccionar un destino de servicio de Azure que le permita hospedar ese servidor de aplicaciones.
Opciones de plataforma
Use la siguiente tabla para identificar las posibles plataformas para su tipo de aplicación.
| Azure Spring Apps | Java SE en App Service | Tomcat en App Service | JBoss EAP en App Service | Azure Container Apps | AKS | Virtual Machines | |
|---|---|---|---|---|---|---|---|
| Aplicaciones de Spring Boot/JAR | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Aplicaciones de Spring Cloud | ✔ | ✔ | ✔ | ✔ | |||
| Aplicaciones web | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Aplicaciones de Jakarta EE | ✔ | ✔ | ✔ | ||||
| Disponibilidad de regiones de Azure | Detalles | Detalles | Detalles | Detalles | Detalles | Detalles | Detalles |
Azure Kubernetes Service (AKS) y Virtual Machines admiten todos los tipos de aplicaciones, pero requieren que el equipo asuma más responsabilidades, como se describe en la sección siguiente.
Compatibilidad
Además de las opciones de plataforma, las aplicaciones Java modernas pueden tener otras necesidades de compatibilidad, como:
- Trabajos por lotes y programados
- Integración de redes virtuales
- Sin servidor
- Inclusión en contenedores
Trabajos por lotes y programados
En lugar de esperar solicitudes o entradas de usuario, algunas aplicaciones se ejecutan brevemente, ejecutan una carga de trabajo determinada y, a continuación, finalizan. A veces, estos trabajos se deben ejecutar una vez o a intervalos regulares programados. En el entorno local, estos trabajos se suelen invocar desde la tabla cron de un servidor.
Estas aplicaciones se empaquetan como archivos JAR.
Nota
Si la aplicación usa un programador (como Spring Batch o Quartz) para ejecutar tareas programadas, se recomienda ejecutar esas tareas fuera de la aplicación. Si la aplicación se escala a varias instancias en la nube, el mismo trabajo se puede ejecutar más de una vez. Si el mecanismo de programación usa la zona horaria local del host, es posible que haya un comportamiento no deseado al escalar una aplicación entre regiones.
Integración de la red virtual
Cuando se implementa una aplicación Java en la red virtual, tiene dependencias de salida de servicios fuera de la red virtual. Para la administración y las operaciones, el proyecto debe tener acceso a determinados puertos y nombres de dominio completos. Con Azure Virtual Network, puede colocar muchos de los recursos de Azure en una red que se pueda enrutar distinta de Internet. La característica de integración de red virtual permite a las aplicaciones acceder a los recursos de una red virtual o mediante esta. La integración de red virtual no permite el acceso privado a las aplicaciones.
Modelo de desarrollo sin servidor
El modelo sin servidor es un modelo de desarrollo nativo de la nube que permite a los desarrolladores crear y ejecutar aplicaciones sin tener que administrar servidores. En las aplicaciones sin servidor, el proveedor de servicios en la nube aprovisiona, escala y administra automáticamente la infraestructura necesaria para ejecutar el código. Los servidores siguen existiendo en el modelo sin servidor. Se abstraen del desarrollo de aplicaciones.
Inclusión en contenedores
La contenedorización es el empaquetado conjunto del código del software con todos sus componentes necesarios, como bibliotecas, marcos y otras dependencias. La aplicación está aislada en su propio contenedor.
CI/CD
La integración continua y entrega continua (CI/CD) es un método para entregar con frecuencia aplicaciones a los clientes mediante la introducción de la automatización en las fases del desarrollo de aplicaciones. Los conceptos principales de CI/CD son la integración continua, la entrega continua y la implementación continua. Todas las opciones de Azure admiten la mayoría de las herramientas de CI/CD. Por ejemplo, puede usar soluciones como Azure Pipelines o Jenkins.
Motor de búsqueda de código abierto
Las búsquedas son partes integrales de cualquier aplicación. Si la velocidad, el rendimiento y la alta disponibilidad son críticas, las búsquedas en terabytes y petabytes de datos pueden ser un desafío. Al hospedar aplicaciones Java en Azure, planee hospedar las instancias de Solr y Elasticsearch relacionadas. Como alternativa, considere la posibilidad de migrar a Azure Cognitive Search.
Herramientas de macrodatos
Las herramientas de macrodatos permiten la automatización del flujo de datos entre sistemas de software. Admiten gráficos de enrutamiento de datos escalables, sólidos y optimizados junto con la lógica de mediación del sistema. Se usan para crear canalizaciones de flujo de datos en vivo y aplicaciones de transmisión. Obtenga información sobre cómo pueden ser adecuados para sus necesidades Nifi y Apache Kafka en Azure.
Opciones de compatibilidad
Use la siguiente tabla para identificar las posibles opciones para su tipo de aplicación. AKS y Virtual Machines admiten todos los tipos de aplicaciones, pero requieren que el equipo asuma más responsabilidades.
| Azure Spring Apps | Java SE en App Service | Tomcat en App Service | JBoss EAP en App Service | Azure Container Apps | AKS | Virtual Machines | |
|---|---|---|---|---|---|---|---|
| Trabajos por lotes y programados | ✔ | ✔ | ✔ | ✔ | |||
| Integración de redes virtuales | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Sin servidor | ✔ | ✔ | ✔ | ✔ | |||
| Inclusión en contenedores | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Disponibilidad de regiones de Azure | Detalles | Detalles | Detalles | Detalles | Detalles | Detalles | Detalles |
Además, consulte este árbol de decisión.
Descargue un archivo de Visio de este diagrama.
Creación o migración de aplicaciones Java
Para crear o migrar las aplicaciones Java, identifique la plataforma de Java de las aplicaciones. Algunas plataformas populares son Java SE, Jakarta EE y MicroProfile.
Java SE
La plataforma Java Standard Edition (Java SE) es una plataforma informática para el desarrollo e implementación de código portátil para entornos de escritorio y servidor. Entre los proyectos más populares basados en Java SE, se incluyen Spring Boot, Spring Cloud, Spring Framework y Apache Tomcat.
Jakarta EE
Jakarta EE es el futuro del código abierto de Java empresarial nativo de nube. Se trata de un conjunto de especificaciones que amplían Java SE con características empresariales como la informática distribuida y los servicios web. Las aplicaciones de Jakarta EE ejecutan entornos de ejecución de referencia. Estos entornos de ejecución pueden ser microservicios o servidores de aplicaciones. Controlan las transacciones, la seguridad, la escalabilidad, la simultaneidad y la administración de los componentes que implementa la aplicación.
MicroProfile
El proyecto MicroProfile proporciona una colección de especificaciones diseñadas para ayudar a los desarrolladores a crear microservicios nativos de nube de Java Enterprise. Quarkus y Open Liberty son implementaciones populares de MicroProfile.
Resumen sobre la creación o migración
En la tabla siguiente, se proporciona información de creación o migración por tipo de aplicación y servicio de Azure.
| Tipo | Java SE | MicroProfile | JarkartaSE | |
|---|---|---|---|---|
| Máquina virtual | IaaS | ✔ | ✔ | ✔ |
| VMware Tanzu | IaaS | ✔ | ||
| Azure Kubernetes Service | Contenedor | ✔ | ✔ | ✔ |
| Red Hat OpenShift | Contenedor | ✔ | ✔ | ✔ |
| Azure Container Apps | PaaS | ✔ | ✔ | |
| JBoss EAP | App Service de PaaS | ✔ | ✔ | |
| Apache Tomcat | App Service de PaaS | ✔ | ||
| Java SE | App Service de PaaS | ✔ | ✔ | |
| Azure Spring Apps | PaaS | ✔ |
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Asir Vedamuthu Selvasingh | Responsable principal del programa
- Hang Wang | Responsable de producto
- Xinyi Zhang | Administrador de proyectos principal
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Azure Container Apps: Información general
- Azure Kubernetes Service
- Documentación de Azure Spring Apps
- Integración de red virtual de Azure
- Máquinas virtuales en Azure