An Introduction to Microservices
There’s a new sound that’s sweeping the nation. No, it’s not a new musical style or group. Rather, it’s the sound of millions of Web developers scratching their heads in wonderment about the latest trend in the most trendy of industries. That industry is Web development and the trend is Microservices. Before you dismiss the entire concept as yet another fad, you should know that, thus far, projects which have made use of Microservices have had a modicum of success with it. These early results have prompted other businesses to follow suit, leading to the surge in popularity that we’re seeing now.
Does that mean that you should immediately drop what you’re doing and join the revolution? Not exactly. Your application’s architecture is not something to commit to lightly. That’s why this article was written. It will describe what Microservices are, list their pros and cons, and finally, provide a few frameworks and tools that help make developing Microservices easier. At that point, you will be better prepared to decide whether Microservices are for you.
From Service Oriented Architecture (SOA) to Microservices
To understand Microservices, we must go all the way back to the 1980s, when a new type of software architecture emerged, which employed distributed services. In SOA, distinct components of the application provide services to other components via a communications protocol over a network. However, SOA is less about how to modularize an application, and more about how to compose an application by integration of distributed, separately maintained, and deployed software components.
Fast forward to present day. Microservices breaks complex applications down into many small and independent processes that communicate with each other using lightweight HTTP, REST, or Thrift APIs. Decomposing an application into different smaller services offers several benefits:
- It improves modularity.
- It makes the application easier to understand, develop, and test.
- Applications built with Microservices are more resilient to architecture erosion, which refers to the gap between the planned and actual implementation architecture of a software system.
- Parallelizes development by enabling small autonomous teams to develop, deploy, and scale their respective services independently.
- Allows the architecture of an individual service to emerge through continuous refactoring.
- Microservices-based architectures enable continuous delivery and deployment.
Microservices versus Monolithic Application Architecture
Although the old monolithic architecture had worked well in the past, in the current world, where applications need to deploy new features very often and need 99.999% up-time, it’s simply out of date. Having to test, re-build, and re-deploy an entire application for a change in one module is no longer practical. Another glaring drawback is that, because everything runs in the same process, an unhandled exception can bring down the whole monolithic system (see Figure 1).
Figure 1: Monolithic architecture versus Microservices architecture
Shortcomings of Microservices
After having bashed monolithic systems, it should be noted that Microservices are not without their own issues. Even though they solve a lot of problems of the old monolithic paradigm, they also introduce new problems that we need to consider.
With a lot of moving parts, Microservices are on a whole other level of complexity compared to monolithic architecture. Significant DevOps skills are required to successfully deploy and maintain a Microservices application in production. Although a monolithic application can be deployed into a small application server cluster for failover and resilience, each service in Microservices requires its own cluster. Adding features such as load balancing for these clusters is not a trivial matter, either.
Microservices systems are distributed by nature, and distributed systems are difficult to build. What was a simple method call would now be replaced by a remote procedure call, REST, or asynchronous message. Developers will need to consider issues such as network latency between services, fault tolerance, versioning, and so forth.
Even though the services are easy enough to test by themselves, end-to-end tests are made more difficult. If something goes wrong, it can be a challenge to figure out where in the chain the exception occurred, because the flow of code is now more complex.
Microservices Frameworks and Tools
A number of frameworks and tools have emerged to help make developing Microservices easier. Here are a few of them:
- Spring Boot: Spring Boot is a framework for creating stand-alone, production-grade Spring Applications that you can “just run.”
- Dropwizard: Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services.
- Jersey: Jersey is an open source RESTful Web Services framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS Reference Implementation.
- Wiremock: WireMock is a flexible library for stubbing and mocking Web services. It can configure the response returned by the HTTP API when it receives a specific request. It is also used for testing Microservices.
- Docker: Docker is open source project that allows you to create, deploy, and run applications by using containers. By using these containers, developers can run an application as a single package. It allows you to ship libraries and other dependencies in one package.
- Hystrix: Hystrix is a fault-tolerance Java library. This tool is designed to separate points of access to remote services, systems, and third-party libraries in a distributed environment such as Microservices. It improves the overall system by isolating the failing services and preventing the cascading effect of failures.
Going Forward
Now that we’ve gotten a handle on what Microservices are all about, in future articles, we’ll build some Microservices using the various frameworks and tools listed above.
