by Mark Sontz –
Microservices are all the rage these days. They are currently getting a lot of attention: articles, blogs, and discussions on social media, and conference presentations. They are rapidly heading towards the peak of inflated expectations on the Gartner Hype cycle.
Microservice architectures promise to deliver flexibility and scalability to the development and deployment of service-based applications. But there are many skeptics out there. Is microservice architecture really new, or is it just rebranding SOA?
Despite both the hype and the skepticism, microservice architectures offer significant benefits. But they also bring their own complications, and developers and admins should be mindful of these when building and deploying microservices.
The Monolith
Enterprise Applications are often built in three main parts: a client-side user interface (rich desktop or web based), a server-side application, and a database (consisting of many tables inserted into a common, and usually relational, database management system). The server-side application receives requests, executes domain logic, retrieves and/or updates data from the database, and responds back to the client. This server-side application is a monolith — a single logical executable. Any changes to the system involve building and deploying a new version of the server-side application.
Modularity within the application is typically based on features of the programming language (e.g., packages, modules). Over time the monolith grows larger as business needs change and as new functionality is added. It becomes increasingly difficult to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module.
Even a small change to the application requires that the entire monolith be rebuilt and deployed.
In order to scale the application, we would simply create more instances of that process. It is not possible to scale the components independently.
Microservices
Microservices is an architecture that promotes breaking down a big monolithic application into smaller and simpler services (organized around business capabilities) to be built and deployed independently, communicating with lightweight mechanisms (often REST based).
The “micro” in microservices refers to the scope of the service’s functionality, not the number of Lines of Code.
Key characteristics of microservices are:
- Domain-Driven Design. Functional decomposition can be easily achieved using Eric Evans’s DDD approach1.
- Single Responsibility Principle. Each service is responsible for a single part of the functionality and does it well.
- Explicitly Published Interface. A producer service publishes an interface that is used by a consumer service.
- Independent DURS (Deploy, Update, Replace, Scale). Each service can be independently deployed, updated, replaced, and scaled.
- Smart Endpoints and Dumb Pipes. Each microservice owns its domain logic and communicates with others through simple protocols such as REST over HTTP
Benefits
Need to release an update to your order service? Well, it’s “micro,” so it’s simple to understand, and its developers can focus on just that functionality. And when it’s ready, you can just test and deploy that service – no need to bundle it up with the rest of your application, and no waiting for a release window.
Is the same service creating bottlenecks when demand spikes in the evenings? Scale out by deploying a few more instances of just that microservice. This is very different from monolithic applications, which may have very diverse requirements but must still be deployed together as a single unit.
Microservices are just as much about team process and organization as technology. From Conway’s Law, microservices are changing how teams are structured, allowing organizations to create teams centered on specific services and giving them autonomy and responsibility in a constrained area. This approach helps the company rapidly adjust in response to fluctuating business demand, without interrupting core activities. It also makes it easier to onboard new staff quickly.
Microservices are simpler, developers get more productive and systems can be scaled quickly and precisely, rather than in large monolithic blobs; an architecture that embraces DevOps practices.
Challenges
But, microservices are not the silver bullet that will solve all architectural problems in your applications. Developing distributed systems is complex. More granularity means more moving parts. Refactoring a monolithic application to microservices creates many small components that constantly communicate; the complexity is shifted around to the interconnections between services.
When more services are interacting, you increase possible failure points. Smart developers stay one step ahead and plan for failure.
Tracing performance problems across tiers for a single business transaction can be difficult. This can be handled by correlating calls with a variety of methods including custom headers, tokens or IDs.
Distributed logic with distributed data increases the effort of finding the root cause of issues. Traditional logging is ineffective because microservices are stateless, distributed and independent — you would produce too many logs to easily locate a problem. Logging must be able to correlate events across several platforms.
Operational complexity is also increased due to the increased demands on managing these services and monitoring them. The ability to quickly deploy small independent services is a win for development, but it puts additional strain on operations as half-a-dozen applications now turn into hundreds of little microservices. Coordinating a large number of rapidly changing services necessitates automated continuous integration and continuous delivery.
Worth Consideration
Microservices architecture is worth serious consideration for enterprise applications. A monolithic architecture is useful for simple, lightweight applications. It will be a maintenance nightmare if used for complex applications. The microservices architecture is the better choice for complex, evolving applications despite the drawbacks and implementation challenges.
We are seeing an increase in the adoption of microservices. There are a number of factors that lead to this trend, with cloud computing and scalability among the most important. Utilization of Microservices by “big guys” like Amazon, Netflix, eBay, and others, provides enough confidence that this architecture is here to stay.
We covered a brief overview of the overall concepts involved in microservices. We saw why we need microservices, the benefits it offers, some of the challenges faced and possible solutions. However, this post only scratches the surface — there is a lot more to microservices.
Stay tuned for future posts about this topic.
#IdeasRealized
Works Cited
1. Domain Language https://www.domainlanguage.com/ddd/