Microservices and Java EE

Microservices and Java EE

Today, microservices-based architectures are everywhere. We have seen how innovators like Netflix and Amazon use microservices to achieve business success. However, where should developers who use Java EE servers to write traditional systems go? What we have always done is wrong? How can we adapt technical design to the future?

Single Architecture

First, let's look at these traditional systems, or single applications. Although the word monomer seems to have a bad taste, it is indeed the way we build software for a long time. Basically, it refers to the fact that we build applications to implement certain functions. Java EE or the first Java 2 Enterprise Edition design goal. Centralized applications can be scaled and clusters, but their design is not necessarily elastic. In most cases, the failure scenario depends on the underlying infrastructure and O & M.

Traditionally, Java EE applications follow some core models and are divided into three main layers: presentation, business and integration. The presentation layer will be packaged into Web Application Archives (WARs), and the business and integration logic will be divided into separate Java Archives (JARs. They will be packaged as a deployment unit, the so-called Enterprise Archive (EAR ). Java EE technologies and best practices are sufficient to build well-designed single applications. However, most enterprise-level projects do not focus much on architecture. This also explains why sometimes well-designed pasta is the best way to visualize project dependencies and internal structures. When this happens, we will soon experience some serious defects. Because everything is coupled and integrated together, even small changes require a lot of work (sometimes restructuring ), then we can put the modified parts into the product. At the same time, we also need to carefully test the application from the pipeline. The entire application is not only a procedural component: it also contains many deployment descriptors and server configuration files, but also attributes of third-party environments. Developing these enterprise projects requires multiple teams to work together, and many people need to review the entire project from a higher perspective. Most business components and fields are driven by existing database designs or business object definitions.

The high risk of changes and the complexity of introducing new configurations into production will lead to lower release frequency. A new release may be several times a year. Even the team structure is severely affected by the monolithic software architecture. A long test cycle is the most intuitive evidence.

Microservices

The times are constantly evolving, and the next generation system architecture and design emerged several years ago. With the increasing complexity of centralized integration components and the increasing cost of connecting applications, people begin to seek more lightweight and Elastic Solutions, gradually begin to give up large-scale and heavyweight infrastructure and design. Together, the IT Department began to review application servers and lengthy protocols and interface technologies.

For SOA-based and ESB-based projects, their service implementations return to more agile components and services. Compared with smart routing and conversion, microservices use simple routing and encapsulate the logic into the endpoint itself. Microservices are centered on individual business goals. Although the enterprise system settings are annoying, the most effective runtime for microservices is not necessarily a fully functional application server. It may be just a Servlet engine, and JVM is enough to serve as an execution environment. The ever-changing runtime and a large number of programming languages are selected. Therefore, this development mode may become another O & M nightmare. Even developers may be lost in defining microservices and how to apply such designs to existing applications. Microservices are designed to form small, stateless, independent, and self-contained applications. Ideally, you can deploy it anywhere, because the deployment itself contains all the necessary components.

Microservices must be small enough. However, the definition of "small" is subjective. You can use estimation methods such as the number of lines of code, function points, and use cases. But in general, there is no inevitable relationship between the "small" and the size. In the Book Building Microservices, Sam Newman provides some techniques for defining microservice dimensions:

Small enough, a small agile development team can rewrite the complexity of one or two agile sprints (generally two to four weeks) without further splitting the service.

Stateless applications only use the information contained in the request when processing each request. Microservices must be stateless and do not need to remember the information that was previously communicated with the external system when processing requests. Microservices must be able to process requests independently. They can collaborate with other microservices in the ecosystem for processing. For example, a microservice that generates a report after interacting with other microservices is an interdependent system. In this scenario, a microservice that only provides necessary data to the report microservice may be an independent service. Full-stack applications can be deployed. It has its own server, network, and hosting environment. Business logic, data models, and service interfaces (Apis/UIS) must be part of the entire system. Microservices must be full-stack applications.

Innovation and continuous improvement are the booster behind enterprise and enterprise-level projects. Without innovation, outdated and expensive infrastructure components may have a longer life cycle than the software running on them. Old middleware may be out of service and only a few vendors know how to develop it. A platform stack that lags behind the latest standards may introduce temporary emergency solutions, and eventually generate technical debt. The open-source projects that can be quickly migrated to microservices. Netflix OSS, Spring, Camel, and Fabric8 are all good examples. With the current PaaS, we can more easily manipulate full-stack applications consisting of multiple languages, while PasS is generally maintained by open-source projects such as Docker and Kubernetes. In this fast-paced era, the time from development to launch and Bug fixing has been greatly shortened. Few companies can tolerate a few months of product cycles, and they need software to create more value for their businesses. This is especially true for software-driven companies such as Uber, NetFlix, and Amazon. We need to build a system for flexibility and elasticity, not just for efficiency and robustness. Java EE will not die, and it will be supplemented and improved.