Some argue that the rise of microservices is a death sentence for Java EE. Others find the death of Java EE laughable. Readers, what do you think?

The introduction

Some people say that Java is really bloated and often “overcooked.” But PHP, node. js extension shortcomings are too obvious, do small applications can, large applications will not play. In addition, there are so many excellent frameworks in the Java EE world that can address the issue of development efficiency, in fact, with frameworks like Spring, development efficiency is almost as good as PHP.

Many Java developers in the Internet era do not develop Web applications based on servlets and EJBs, and WebLogic and WebSphere only exist in the stock system of large companies. The Java of Internet companies is the world of Tomcat.

So can microservices fully compensate for Java EE’s shortcomings? For Jave EE, are microservices the saviour or the gravedigger?

In the early days of Java, some of the biggest companies, including IBM, BEA, and Oracle, saw that Java as a pre-eminent Web programming language could BEA huge opportunity for them. So how do you make money from a programming language? The answer is to build incredibly complex servers in this language and get big companies to pay a lot of money for them. Then came the Java EE specification, the JSR specification, and server middleware such as WebLogic and WebSphere.

Large packages are deployed on these servers, which run slowly and consume a lot of memory. Development and debugging based on these containers is a nightmare for developers, who are compensated handsomely by their employers.

Because of the cost, it’s hard to find a company that can support Java for a reasonable amount of time. If you’re building a web site in Java, you’ll have to pay a lot of money to run these servers, even if you only use the Servlet container. For a long time, Java was used by enterprises and corporations because only these large companies could afford to spend millions of dollars on servers and pay high salaries for enterprise developers.

Rod Johnson released the Spring framework in 2003, which provides IoC and support for POJOs to help developers escape EJB. As a result, development efficiency has improved dramatically, and many developers have moved to Spring, leaving EJBs behind. Application server developers see this, and in Java EE 5 they have provided some features to ease the developer’s burden. Unfortunately, Spring has become so popular that people almost confuse it with Java EE containers that it still runs in Java EE Servlet containers that are designed ten years ago and do not take into account multi-core cpus and NIO.

In the meantime, PHP has played catch-up. PHP uses less memory and resources and is supported by many companies. Some CMS platforms, such as WordPress and Drupal, are built on PHP and have attracted a large number of PHP developers. But while PHP remains the most popular programming language today, it has its own shortcomings. It’s not very fast, and it’s hard to scale horizontally.

In 2009, Ryan Dahl launched the Node.js project, which supports asynchronous, non-blocking, event-driven I/O. If the server threads are used properly, Node.js can dramatically improve response times, and the throughput of a single server can rival that of a Cluster of Java EE servers. Node.js is a great product, but it has its limitations. Node.js is difficult to scale and integrate with legacy systems.

In 2014, Undertow emerged as a Java-based, non-blocking Web server. According to techempower.com’s test results, on an $8,000 Dell server, it can handle millions of requests per second, whereas Google would need to use a cluster to handle a million of the same requests. It is lightweight, requiring only 1M memory for its core, and contains a built-in server that uses less than 4M heap memory.

The Light Java Framework, built on Undertow Core, is a microservice container that supports design-driven and generated code, as well as runtime security and runtime validation.

Java EE vendors

Years ago, Java EE vendors such as Oracle and IBM spent hundreds of millions of dollars developing application servers (WebLogic and WebSphere) that were sold to large organizations for millions. But now those servers aren’t selling because JBoss is rapidly gaining market share and Oracle’s Support for Java EE is on the decline:

https://developers.slashdot.org/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee

As microservices become more and more of a focus, it’s hard for these application servers to sell well because they’re better suited for deploying standalone applications. One application with hundreds of EJBs took 45 minutes to test a single code change on WebLogic.

Java EE clients

From a customer perspective, it’s not worth the expense of buying these servers because what Java EE promises is not always true. An application developed for WebSphere cannot be deployed on WebLogic, so you need to spend more money to upgrade the server, because the vendor may no longer support the old version of the server, and such an update can cost you millions of dollars.

So some smart people are asking, why are we deploying apps on these behemoths? Why would we want to package an application as an EAR package or war package instead of a JAR package? Why can’t we break up large applications into smaller pieces that can be deployed and scaled independently?

Micro service

Microservices are the antidote to these problems. Wikipedia defines microservices as “… A style of software architecture in which complex applications consist of independent processes that interact using language-independent apis. These processes serve a small scale, are highly discrete, focus on a small task, and build systems in a modular manner.

Microservices architectures make it easier to build applications, and applications are broken down into separate services that can be combined arbitrarily. Each service can be deployed independently or combined as an application. These services may also be relied upon by other applications. It speeds up the development of services because services can be developed in parallel as long as the interface is defined.

Microservices are resilient and scalable. Microservices don’t just depend on a single server and deployment; they can be published on multiple machines, or multiple data centers, or any other area available. If one service fails, another can be started. Because the entire application is broken down into microservices (small services), it’s easy to scale some of these popular services horizontally.

If you’ve ever worked with COM, DCOM, CORBA, EJB, OSGi, J2EE, SOAP, SOA, etc., then you know that services and components are nothing new. One of the biggest problems enterprises have with components is that they rely on large hardware servers and run many applications on the same server. We have EJBs, WAR packages, EAR packages, and various component packages because server resources are too expensive to use as much as possible.

But judging by developments in recent years, that approach is a bit behind The Times. Operating system servers are constantly changing, and virtual resources can be published as components, such as EC2, OpenStack, Vagrant, and Docker. The world has changed. Microservices architecture is seeing this trend, and hardware, cloud, multi-core cpus, and virtualization are also evolving, so we need to change the way we developed.

Do not use EAR or WAR packages when starting a new project. Now we can run the JVM inside Docker, which is just a process, but it can behave like an operating system. Docker runs on the cloud operating system, and the cloud operating system runs on the virtual machine, which runs on the Linux server. These servers are not owned by anyone, but are shared by many people who don’t know each other. What if there is a traffic spike? Simple, use more server instances. This is why you want to run Java microservices in a separate process rather than a Java EE container or servlet container.

Microservices typically provide HTTP/ JSON-based API endpoints. This makes it easy to integrate with other services (open source or closed source) as long as they provide HTTP/JSON interfaces. Services can be consumed and combined in more meaningful ways. EC2, S3, and other services from Amazon (and others) are prime examples. The infrastructure becomes part of the application, and they are programmable.

Applications that use microservices architecture should be modular, programmable, and composable. Microservices can be interchangeable with each other. Parts of an application can be rewritten or improved without affecting the entire application. If all components provide a programmable API, then it becomes easier to interact with microservices (never trust microservices that cannot be accessed through Curl).

As microservices become more popular, many vendors are trying to convert their Java EE Web services into microservices so that they can continue to sell their outdated products. API Gateway is one of these vendors.

In an article by Jason Bloomberg, chairman of Intellyx, he points out the difference between traditional Web services and microservices and puts the traditional Web into perspective

The trend of services to microservices is called into question:

http://techbeacon.com/dangers-microservices-washing-get-value-strip-away-hype

Microservices are not Web services in an enterprise service Bus, nor are they traditional service-oriented architectures, although they follow some of the basic concepts of SOA. Microservices are fundamentally different from SOA because the environment has been completely transformed.

The microservices architecture environment knows no boundaries: end-to-end, cloud-based applications run on a completely virtual and containerized infrastructure. While containers componentize applications and services, DevOps provides a framework for IT infrastructure to help automate development, deployment, and management environments.

Although containers are not required for microservices, microservices can easily run inside containers. Furthermore, deploying non-microservice code in containers is not a wise choice.

Docker and other container technologies have been seen in some ways as the best companion to microservices. Containers are the smallest subset of resources that run microservices.

Docker simplifies the development of microservices and makes integration testing easier.

Containers are helpful for microservice development, but not necessary. Docker can also be used to deploy standalone applications. Microservices and containers work well together, but microservices are much more than containers!

Microservices are hot right now, and everyone claims to be using microservices architecture, but what exactly is microservices architecture? Is microservices architecture a trend? Presumably these are the common doubts of many programmers. If you have the same doubts and want to have a deeper understanding and master the micro-service architecture, you can add my group: 650385180. I will share my experience summarized for many years in the group, and I will also share these technical knowledge points for everyone to learn and download for free.

conclusion

The style of application development has changed over the years, and microservices are becoming more and more popular. Big companies break up large applications into smaller ones that can be deployed individually, in containers in the cloud. Light Java, the open source microservices framework, provides many features for these microservices running in containers. It supports design-driven, allowing developers to focus only on business logic, leaving the rest to be taken care of by the framework and DevOps processes.