By using GraalVM and a Service Mesh we provide a road map for building/refactoring an application to microservices, including definitions.
Join the DZone community and get the full member experience. The title says it all, but details are always welcome. But first some definitions. According to the classic article by Martin Fowler: “The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable.” A monolith on the other hand is an application deployed as a single logical executable. The problem with a monolith is that, again quoting Fowler, “Change cycles are tied together – a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it’s often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.” Continuing, “For as long as we’ve been involved in the software industry, there’s been a desire to build systems by plugging together components… A component is a unit of software that is independently replaceable and upgradeable… We define libraries as components that are linked into a program and called using in-memory function calls, while services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call.” Thus, a microservice architecture (MSA) is a decomposition of an application into components as services. The advantages of an MSA are the components have firm module boundaries which can be developed by independent teams. They are independently deployable and scalable (thus increasing the feature velocity) and can be built in different languages, such as Nodejs and Java.
