MicroServices and Java EE

This article is from my translation of the Infoq Chinese station, the original address is: Http://www.infoq.com/cn/news/2016/01/microservices-and-java-ee

Today, MicroServices-based architectures are everywhere. We've seen how innovators such as Netflix and Amazon are using microservices to achieve business success. But what about developers who write traditional systems with Java EE servers? What we've been doing is wrong? How do we make technology design adaptable to the future?

Monolithic architecture

First, let's take a look at these traditional systems, or individual applications. Although the word monomer now looks like a bad taste, it's really the way we've been building software for a long time. Basically, it refers to the fact that we build applications to implement certain functions. Monomer refers to the Java EE or the beginning of the Java 2 Enterprise edition design goals. Centralized applications can be scaled and clustered, but their design is not necessarily resilient. Most of the time, the failure scenario relies on the underlying infrastructure and operations.

Traditionally, Java EE applications have followed some core patterns and are divided into 3 main tiers: presentation, business, and integration. The presentation layer is packaged into the Web application Archives (WARs), and the business and integration logic is divided into separate Java Archives (JARs). They will be packaged as a deployment unit, the so-called Enterprise Archive (EAR). Technology and best practices around Java EE are enough to build well-designed monolithic applications. However, most enterprise-level projects are less concerned with architecture. This also explains why sometimes well-designed spaghetti is the best way to visualize project dependencies and internal structures. When this happens, we will soon experience some serious flaws. Since everything is coupled and integrated, it takes a lot of work (and sometimes refactoring) to make some very small changes before you can put the modified parts into the product, and we need to be very careful to test the application from start to finish. The entire application is more than just a few programmatic artifacts: It also contains a number of deployment descriptors and server-side configuration files, as well as the properties of third-party environments. Developing these enterprise projects requires multiple teams to work together and requires a lot of people to review the entire project from a higher perspective. Most of the business components and domains are driven by existing database designs or business object definitions.

The high risk of change and the complexity of introducing new configurations into production can lead to an increasingly low release frequency. The new release may only be a few times a year. Even the team structure can be severely impacted by the monolithic software architecture. A long test cycle is the most intuitive evidence.

Micro-Service

Times are evolving, and the next generation of systems architecture and design emerged a few years ago. As the growing complexity of centralized integration components and the increasing cost of connectivity between applications, people are looking for lighter, more resilient solutions that are beginning to abandon large, heavyweight infrastructure and design. Together, IT departments are starting to revisit application servers and lengthy protocols and interface technologies.

For SOA and ESB-based projects, their service implementations return to more agile components and services. In contrast to intelligent Routing and transformation, microservices use simple routing and encapsulate the logic in the endpoint itself. MicroServices are built around a single business goal. Although the enterprise system is very annoying to set up, but for microservices, the most effective runtime is not necessarily a fully functional application server. It's probably just a servlet engine, and the JVM is enough to be an execution environment. With the ever-changing running time and the sheer number of programming language choices, this development model is likely to be another operational nightmare. Even developers may lose their way in defining microservices and how to apply this design 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 already contains all the necessary components.

Micro services are small enough. However, the definition of "small" is very subjective. You can use some estimation methods such as line of code, function point, use case, and so on. In general, however, there is no definite link between "small" and size. In building microservices, the author Sam Newman gives some techniques for the definition of micro-service dimensions:

• Small enough to be owned by a small agile development team
• Rewrite can be done in one or two agile sprints (typically 2-4 weeks)
• Its complexity does not require further splitting of the service

A stateless app uses only the information contained in the request when it processes each request. MicroServices must be stateless, without having to remember the information that communicates with the external system when processing the request. MicroServices must be able to handle requests independently, which can be processed in collaboration with other microservices in the ecosystem. For example, microservices that generate reports after interacting with other microservices are interdependent systems. In this scenario, microservices that only provide the necessary data to a report micro-service may be a standalone service. The full stack application itself can be deployed. It has its own server, network, and hosting environment. The business logic, data model, and service interface (API/UI) must be part of the entire system. MicroServices must be a full stack application.

Innovation and continuous improvement are the boosters behind enterprise and enterprise-level projects. Without innovation, outdated and expensive infrastructure components may have a longer life cycle than the software they run on. Older middleware may be out of service, as a result, only a handful of vendors know how to develop it. A platform stack that lags behind the latest standards may introduce a temporary contingency solution, eventually creating technical debt. The rapid migration of projects to microservices is the open source project. Netflix OSS, Spring, Camel, FABRIC8, etc. are all good examples. With today's PAAs, we can more easily manipulate multi-lingual, full-stack applications, and pass is generally maintained by open source projects such as Docker and Kubernetes. In this fast-paced era, the time from development to on-line and bug fixes has been greatly shortened. Few companies can tolerate months of product cycles, and they need software to create more value for their business. This is especially true for companies that are completely software-driven, such as Uber, NetFlix, Amazon, and more. We need to build systems for flexibility and resilience, not just efficiency and robustness. Java EE does not perish, it will be supplemented and perfected.

If you are interested in how to evolve a Java EE application into a microservices, please download this ebook. In addition, you can find more information here.

MicroServices and Java EE