“Microservices has the power to bring together those old monolithic applications in one seamless efficient application that is both secure and flexible.”
Microservices, also known as the microservice architecture, is a distinctive approach to software architecture that structures a large, complex application as a suite of single-function component services that are:
- Loosely coupled
- Highly maintainable and testable
- Independently developed, deployed and maintained
- Organized around business capabilities
- Owned by a small team
Each microservice is responsible for a single discrete task, has its own codebase, infrastructure, and persistence layer and can communicate and work together with other services through standardized APIs to solve a larger, complex business problem.
This architectural style draws parallels to the human body which is a combination of different independent systems that specialize in discrete functions yet cohesively operate together as one body.
Microservices vs SOA
“When we’ve talked about microservices a common question is whether this is just Service Oriented Architecture (SOA) that we saw a decade ago”
With merits to both side of the divide, the question on whether Microservices Architecture is simply just Service Oriented Architecture is deeply divisive; perhaps due to the glaring similarities between them. Some microservices advocates reject the SOA tag altogether, while others consider microservices to be an ideal, refined form of SOA.
Service Oriented Architecture means a wide variety of different things, usually with a focus on ESBs used to integrate monolithic applications. More often that not when we come across something labelled “SOA”, it turns out to be significantly different to the style described by microservices.
Microservices is a revolutionary approach to application development that despite roots in and similarities with SOA is nuanced and made distinct by the fact that SOA aims at integrating various (business) applications whereas a suite of microservices belong to one application. SOA also focuses on imperative programming, whereas microservices focuses on a responsive-actor programming style.
Why Microservices?
“Microservices can help a business achieve unprecedented levels of agility, empowering development teams to innovate faster by building new features and services in parallel.”
A monolithic approach to software architecture and development is quite a natural way to build systems especially while starting out, when the team is small, business requirements are succinct and lean, and the scale is manageable. The architecture is kept simple, everybody understands everything and knows everyone, and the organization is structured in tandem with this simplicity; there is harmony and stability in the grand scheme of things.
The deficiencies and pain points of monolithic architectures manifest at scale, when the team has a few dozen more people because business requirements have tremendously grown — with overlaps and ambiguity nonetheless — and the capacity of systems needs a significant boost to handle the more than welcome growth.
Suddenly, a modification intended on a small section of the application becomes risky and tedious as it could affect the entire system, often requiring input from a few more people than is necessary and an entirely new version having to be built and deployed. Scaling specific functions of an application, also means the entire application has to scale as there is no components isolation. At that moment, an application developed as a single, autonomous unit poses challenges for development cycles, maintenance and scalability.
Microservices solve these shortcomings of monolithic systems by applying as much loose coupling and modularity as possible. As Martin Fowler points out, this approach to architecture comes bearing many benefits for Agile and DevOps teams. For this reason, it has grown quite popular in recent years as organizations look to become more Agile and transition towards DevOps and continuous testing and delivery. Leading tech stars such as Netflix, eBay, Amazon, Twitter, PayPal, etc, have all evolved from monoliths to microservices in response to the inherent challenges of monolithic applications; the bulk of which are slow development cycles, high maintenance complexity and risk, low technical flexibility, and limited scalability and reusability.
Pros and Cons of Microservices
“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” — Conway’s Law
Microservices are not a silver bullet. By implementing them, structural challenges of communication, teamwork and collaboration, responsibility and ownership as well as other organizational problems that may have been previously implicit are forced out into the open.
Moreover, as is the case with any architectural style, microservices architecture has its own shortcomings such as complicated testing due to the distributed nature, varying tech choices across an organization, and the stratification of teams in their domains. Most of these shortcomings are dealt with through strong architectural principles and standards that apply across an organization while still allowing reasonable freedom and flexibility.
Below are some of the strengths of microservices:
1. Enhanced Efficiency
Microservices architecture speeds up the entire development cycle because unlike a single unit, teams can work simultaneously on multiple components of an application. There is also increased productivity as microservices allow a more focused approach to specific components during both development and maintenance phases.
2. Specialization and Decentralized Governance
“Not every problem is a nail and not every solution a hammer.”
Centralized governance has a constricting tendency towards standardizing on single technology platforms even though there’s never one right tool for all jobs.
Monolithic applications offer limited “right tool for the job at hand” choices because of the high coupling and low independence. An application that combines an accounting and a notifications functions ends up sharing the same database even though the distinct data properties of each function calls for different types of database technologies.
Splitting a monolith’s components out into independent, loosely coupled services allows conscious tech stack choices when building each of them; typically along the lines of what best fits the job at hand.
The build it / run it / own it ethos popularized by Amazon is perhaps the apogee of devolving governance through microservices. Teams specialize in and are responsible for all aspects of the software they build. This clear cut devolution of responsibility to the development teams while not the norm is being adopted by an increasing number of organizations. At JUMO, we adopted a service ownership model inspired by the build it / run it / own it ethos with the rationale that being woken up at 2 am severally by your service’s pager is quite a powerful incentive to find and fix root causes and focus on quality while writing code.
3. Decentralized Data Management
In keeping with the decentralization theme, microservices allow greater degrees of freedom in decentralization of data management in a number of different ways.
At the most abstract level is conceptual modeling and decisions around it. The conceptual view (model) of the world greatly differs between systems. For instance, the sales view of a customer will differ from the support view. Some things in the sales view may not exist at all in the support view while those that do may have different attributes and worse still, have common attributes with subtly different semantics. While this is a common phenomenon between applications, it can also occur within applications; particularly those that are divided into different components.
As Martin Fowler points out, a useful way of thinking about this is the Domain-Driven Design concept of Bounded Context which divides up a complex domain into multiple bounded contexts and maps out the relationships between them. This process is useful for both monolithic and microservice architectures, but there is a natural correlation between service and context boundaries that helps clarify and reinforce the separations.
Centralization of data management that is an eventuality with monoliths — as is the case in the earlier accounting and notifications application example— presents a database design nightmare and a huge performance and scalability bottleneck. You certainly must have experienced, as I have, or at least heard cases of an entire application being impaired by the load on one database table. And it’s easy to see how it comes to be; the number of notifications our example application handles could grow as different kinds of notifications (marketing, informational, transactional) are sent out while accountable transactions remain constant. In a monolith with a single logical database for persistent data, that added load has a direct impact on all its functions.
Microservices decentralize decisions around data persistence and storage as well. Each service manages its own persistence mechanism with an appropriate database technology; a decision that is driven by the different distinct data properties of each domain — an approach called Polyglot Persistence.
Decentralizing responsibility for data across microservices however has implications for managing updates.
4. Products not Projects
Amazon’s build it / run it / own it ethos that are a perfect microservices fit, due to the smaller granularity of services, where a development team takes full responsibility for software in production have had an impact in shifting the mentality towards models software development follows; product vis-a-vis project mentality.
In a project mentality, the aim is to deliver some piece of software which is then considered to be completed. Upon completion, the software is handed over to a maintenance organization and the project team that built it is disbanded.
Microservice tend to avoid this model, preferring instead the notion that a team should fully own a product over the entirety of its lifetime; the product mentality. The implication is that developers are brought into day-to-day contact with how their software behaves in production. There’s also increased contact with the software’s users, as the development team has to take on at least some of the support burden.
The product mentality has a natural correlation with business capabilities. Rather than view software as a set of functionality and milestones to be completed, there is an on-going relationship and conscious efforts to assist its users to enhance the business capability.
5. Smart endpoints and dumb pipes
Some inter-process communication structures have approaches that greatly favour putting significant smarts into the communication mechanism itself. A great example of this is SOA’s Enterprise Service Bus (ESB) which includes sophisticated features of message routing, choreography, transformation, and applying business rules.
“Be of the web, not behind the web”
Applications developed with a microservices architecture aim to be as decoupled and as cohesive as possible; they own their own domain logic, receive a request, applying logic as appropriate and return a response. Proponents of microservices thus favour an alternative approach to communication between different processes: smart endpoints and dumb pipes. Teams building microservices apply the principles and protocols that the world wide web (and to a large extent, Unix) is built on. HTTP request-response with resource APIs and lightweight messaging are the two most commonly used protocols.
Communication by exchanging messages over a lightweight message bus typically utilizes dumb infrastructure — dumb in the sense that it acts only as a message router — with the intelligence living in the endpoints that produce and consume messages; in the services.
Summary
With an ever changing business landscape characterized by fast evolving models and service offerings, organizations often seek to continuously roll out updates at regular frequency, sometimes up to multiple times a day; continuous delivery. This requirement for fast roll outs of updates is not easy to fulfill with a monolithic design that has tightly coupled architecture and infrastructure.
Microservices is the logical response to the shortcomings of monolithic applications in a time of frequent functionality change and constant operational churn. Despite its complexities, a microservices architecture allows much greater application performance, flexibility, availability, scalability, and agility.
Principles and standards are an integral part in the efficacy of microservices. They reinforce the architecture’s strengths while addressing its shortcomings. They are thus the subject of part 2 and 3 of this post.
