Microservicios: ¿el salvador o el sepulturero de JavaEE?

Introducción Algunas personas dicen que Java está demasiado inflado y a menudo "hace una montaña de un grano de arena". Sin embargo, las deficiencias de las extensiones PHP y Node.js son demasiado obvias. Se pueden usar en aplicaciones pequeñas, pero no en aplicaciones grandes. Además, hay demasiados marcos excelentes en el campo JavaEE que pueden resolver el problema de la eficiencia del desarrollo. De hecho, utilizando marcos como Spring, la eficiencia del desarrollo no es menor que la de PHP.

Muchos desarrolladores de Java en la era de Internet no desarrollan aplicaciones web basadas en Servlet y EJB, ¡pero WebLogic y WebSphere solo aparecerán en grandes mercados! En el sistema de acciones de la empresa, el mundo Java de las empresas de Internet es todo Tomcat.

Entonces, ¿pueden los microservicios compensar completamente las deficiencias de JavaEE? Para JaveEE, ¿los microservicios desempeñan el papel de salvador o de sepulturero? Al comienzo del nacimiento de Java, algunas empresas gigantes, incluidas IBM, BEA y Oracle, vieron las enormes oportunidades comerciales que Java como excelente lenguaje de programación web podría brindarles. Entonces, ¿cómo ganar dinero con lenguajes de programación? La respuesta es utilizar el lenguaje para construir servidores increíblemente complejos que hagan que las grandes empresas paguen un alto precio por ellos. A esto le siguieron la especificación JavaEE, la especificación JSR y el middleware de servidor como WebLogic y WebSphere.

En estos servidores se despliegan una gran cantidad de paquetes, que son lentos y consumen mucha memoria. Desarrollar y depurar sobre estos contenedores es una pesadilla para los desarrolladores y, para compensar, sus empleadores les pagan generosamente.

Debido al alto costo, es casi imposible encontrar una empresa que pueda soportar Java a largo plazo a un costo razonable. Si va a crear un sitio web usando Java, tendrá que pagar una enorme cantidad de dinero para ejecutar esos servidores, incluso si solo usa contenedores de servlets. Durante mucho tiempo, Java se utilizó en empresas y corporaciones porque sólo estas grandes empresas podían permitirse pagar millones de dólares para comprar servidores y pagar altos salarios a estos desarrolladores de nivel empresarial.

Rod Johnson lanzó el marco Spring en 2003, que proporcionaba soporte IoC y POJO para ayudar a los desarrolladores a deshacerse de las limitaciones de EJB. Como resultado, la eficiencia del desarrollo ha mejorado enormemente y una gran cantidad de desarrolladores han recurrido a Spring, dejando atrás a EJB. Los desarrolladores de servidores de aplicaciones vieron esto y proporcionaron algunas funciones en JavaEE5 para aliviar la carga de los desarrolladores. Desafortunadamente, Spring ha sido tan popular que la gente casi lo confunde con los contenedores JavaEE, que todavía se ejecutan en contenedores de servlets JavaEE, y los contenedores de servlets JavaEE siguen el diseño de hace diez años y no tienen en cuenta las CPU multinúcleo y NIO.

Durante este período, PHP surgió repentinamente.

PHP utiliza menos memoria y recursos y cuenta con el respaldo de muchas empresas. Algunas plataformas CMS, como WordPress y Drupal, se basan en PHP y estas plataformas atraen a una gran cantidad de desarrolladores de PHP. Sin embargo, aunque PHP sigue siendo el lenguaje de programación más popular en la actualidad, tiene sus propias deficiencias. No es rápido ni difícil de escalar.

En 2009, Ryan Dahl inició el proyecto Node.js, que admite E/S asincrónicas, sin bloqueo y controladas por eventos. Si utiliza los subprocesos del servidor correctamente, Node.js responde muy bien y el rendimiento de un solo servidor es comparable al de un grupo de servidores JavaEE. Sin embargo, Node.js también tiene sus propias limitaciones. Node.js es difícil de escalar e integrar con sistemas heredados.

En 2014 apareció el servidor web sin bloqueo basado en Java Undertow. A juzgar por los resultados de la prueba, puede manejar millones de solicitudes por segundo en un servidor Dell de $8,000, mientras que Google necesitaría usar un clúster para manejar un millón de las mismas solicitudes. Es muy liviano, requiere solo 1 M de memoria del kernel y también contiene un servidor integrado con menos de 4 M de uso de memoria dinámica.

LightJavaFramework construido sobre UndertowCore es un contenedor de microservicios que admite código generado y basado en diseño, así como seguridad y autenticación en tiempo de ejecución. Proveedores de JavaEE Hace años, los proveedores de JavaEE (como Oracle e IBM) gastaron cientos de millones de dólares en el desarrollo de servidores de aplicaciones (WebLogic y WebSphere) y los vendieron a grandes empresas por millones de dólares. Pero ahora estos servidores ya no se pueden vender porque JBoss está ganando rápidamente participación de mercado y el soporte de Oracle para JavaEE también está disminuyendo:

#/story/16/07/02/1639241/oracle- may- have-stopd-funding-and-developing-java-ee

A medida que los microservicios reciben cada vez más atención, estos servidores de aplicaciones que son más adecuados para implementar aplicaciones individuales también son difíciles de vender. Una aplicación con cientos de EJB tardó literalmente 45 minutos en probar una sola línea de cambio de código en WebLogic.

Clientes de JavaEE Desde la perspectiva del cliente, no vale la pena gastar mucho dinero en estos servidores porque lo que JavaEE promete no siempre es cierto. Las aplicaciones desarrolladas para WebSphere no se pueden implementar en WebLogic, por lo que deberá gastar más dinero para actualizar el servidor porque es posible que el proveedor ya no admita la versión anterior del servidor y dicha actualización le costará millones de dólares.

Entonces, algunas personas inteligentes no pueden evitar preguntarse: ¿Por qué implementamos aplicaciones en estos gigantes? ¿Por qué empaquetamos aplicaciones en paquetes ear o paquetes war en lugar de paquetes jar? ¿Por qué no podemos dividir aplicaciones grandes en partes más pequeñas para poder implementarlas y escalarlas de forma independiente?

MicroserviciosLos microservicios son la respuesta a estos problemas. Wikipedia define los microservicios como "un estilo de arquitectura de software en el que las aplicaciones complejas se componen de muchos procesos independientes que interactúan mediante API independientes del lenguaje. Estos servicios de procesos son pequeños y muy discretos, se centran en tareas muy pequeñas y utilizan un enfoque modular para construir sistemas."

La arquitectura de microservicios facilita la creación de aplicaciones, que se dividen en servicios individuales que se pueden combinar de cualquier forma. Cada servicio se puede implementar de forma independiente o combinarse en una aplicación. Otras aplicaciones también pueden depender de estos servicios. Esto acelera el desarrollo de servicios porque los servicios se pueden desarrollar en paralelo siempre que se defina la interfaz.

Los microservicios son elásticos y escalables. En lugar de depender de un único servidor e implementación, los microservicios se pueden publicar en varias máquinas, varios centros de datos y cualquier otra región disponible. Si un servicio falla, se puede iniciar otro servicio. Dado que toda la aplicación se divide en microservicios (pequeños servicios), es fácil escalar algunos de estos servicios populares.

Si alguna vez ha trabajado con COM, DCOM, CORBA, EJB, OSGi, J2EE, SOAP y SOA, sabrá que los servicios y componentes le resultan familiares. Uno de los mayores problemas que encuentran las empresas al utilizar componentes es que dependen de grandes servidores de hardware y ejecutan muchas aplicaciones en el mismo servidor.

Teníamos EJB, paquetes WAR y paquetes EAR y varios paquetes de componentes porque los recursos del servidor eran demasiado caros para utilizar completamente lo que teníamos.

Pero a juzgar por lo que ha sucedido en los últimos años, la antigua forma se ha quedado un poco obsoleta. Los servidores del sistema operativo cambian todo el tiempo y los recursos virtuales se pueden distribuir como componentes, como EC2, OpenStack, Vagrant y Docker. La arquitectura de microservicios ve esta tendencia, el hardware, la tecnología de la nube, las CPU multinúcleo y la virtualización también están evolucionando, por lo que tenemos que cambiar la forma en que nos desarrollamos en el pasado.

No utilices paquetes EAR o WAR al iniciar un nuevo proyecto. Ahora podemos ejecutar JVM en Docker. Docker no es más que un proceso, pero se ejecuta como un sistema operativo. Docker se ejecuta en un sistema operativo en la nube, que se ejecuta en una máquina virtual, que se ejecuta en un servidor Linux. Estos servidores no pertenecen a nadie, sino que están controlados por muchas personas que no se conocen. ¿Qué pasa si el tráfico aumenta? Simple, use más instancias de servidor. Ésta es una razón importante para ejecutar microservicios Java en procesos independientes en lugar de contenedores JavaEE o contenedores de servlets.

Los microservicios suelen proporcionar puntos finales API basados ​​en HTTP/JSON. Es fácil de integrar con otros servicios (de código abierto o de código cerrado) siempre que proporcionen interfaces HTTP/JSON. Los servicios ec2, S3 y otros de Amazon (u otras empresas) son buenos ejemplos. La infraestructura pasará a formar parte de las aplicaciones y serán programables.

Las aplicaciones que utilizan arquitectura de microservicios deben ser modulares, programables y componibles. Los microservicios son intercambiables. Partes de la aplicación se pueden reescribir o mejorar sin afectar toda la aplicación. La interacción entre microservicios se vuelve más fácil si todos los componentes proporcionan API programables (nunca confíe en un microservicio al que no se pueda acceder a través de curl).

Con la popularidad de los microservicios, muchos proveedores comenzaron a intentar convertir sus servicios JavaEEWeb en microservicios para poder seguir vendiendo sus productos obsoletos, APIGateway es uno de ellos.

El presidente de Intellyx, Jason Bloomberg, señaló la diferencia entre los servicios web tradicionales y los microservicios en un artículo, y cuestionó la tendencia de transformar los servicios web tradicionales en microservicios:

#/dangers-microservices- washing-get-value-strip-away-hype

Los microservicios no son servicios web en un bus de servicios empresariales, ni son una arquitectura tradicional orientada a servicios, aunque siguen algunos conceptos básicos de SOA. Fundamentalmente, los microservicios se diferencian de SOA porque toda la arquitectura se ha transformado fundamentalmente.

El entorno de la arquitectura de microservicios no tiene fronteras: las aplicaciones basadas en la nube de un extremo a otro se ejecutan en una infraestructura totalmente virtualizada y en contenedores. Los contenedores componen aplicaciones y servicios, y DevOps proporciona un marco para la infraestructura de TI que ayuda a automatizar el desarrollo, la implementación y la gestión de entornos.

Aunque los microservicios no requieren contenedores, los microservicios pueden ejecutarse fácilmente en contenedores. Además, implementar código que no sea de microservicio en contenedores no es una buena elección.

Docker y otras tecnologías de contenedores han sido consideradas hasta cierto punto como los mejores compañeros para los microservicios. Los contenedores son el subconjunto más pequeño de recursos que ejecutan microservicios. Docker simplifica el desarrollo de microservicios y facilita las pruebas de integración.

Los contenedores son útiles para el desarrollo de microservicios, pero no son obligatorios. Docker también se puede utilizar para implementar aplicaciones monolíticas.

Los microservicios y los contenedores van bien juntos, ¡pero los microservicios son mucho más que contenedores!

Conclusión Los estilos en el desarrollo de aplicaciones han ido cambiando a lo largo de los años y los microservicios se están volviendo cada vez más populares. Las grandes empresas están dividiendo aplicaciones grandes en aplicaciones más pequeñas que se pueden implementar individualmente, y estas pequeñas aplicaciones se implementan en contenedores en la nube. LightJava es un marco de microservicios de código abierto que proporciona muchas características para estos microservicios que se ejecutan en contenedores y está basado en el diseño. Los desarrolladores solo necesitan centrarse en la lógica empresarial, y el resto puede ser manejado por el marco y los procesos de DevOps.

Entonces la pregunta es, ¿qué opinas?