What are microservices vs. monoliths vs. SOA?

Perhaps the best approach to understanding what microservices are is to first identify what microservices are not. There are a number of distinctions between microservices and other organizational approaches. Here, we compare microservices to traditional monolith architecture, as well as the more-recent service-oriented architecture (SOA).

What are characteristics of microservices?

Testability, loose interconnectedness, decentralization, independent deployability, business centricity, simple routing, failure resistance, adaptability and scalability, and no long-term commitment to technology stack.

Get Started

What are microservices?

Q: What are microservices?

Microservices are an architectural and organizational approach where applications are made from loosely-connected independent services and components.

Microservices are an architectural and organisational approach where applications are made from loosely-connected independent services and components.

Get Demo

In nature, bigger isn’t always better. And while a great white shark may be the scourge of the oceans, there are many instances where a school of fish is more capable of surviving and thriving as a group than any single organism. In fact, success by collaboration is a common theme throughout the animal kingdom; ant colonies, beehives, wolf packs etc. all benefit from working within loosely coupled systems to distribute control and achieve common goals. And should one member of the colony, hive or pack perish, the rest of the group can continue to function and make up for the loss.

Microservices take this approach and apply it to software development and system architecture. The idea is that it is often faster, easier, safer and more efficient to build a number of component functions or services separately, than it is to install the same functionality into a self-contained and fully interconnected system. Here, we take a closer look at microservices, along with their attributes, benefits and challenges.

Perhaps the best approach to understanding what microservices are is to first identify what microservices are not. There are a number of distinctions between microservices and other organisational approaches. Here, we compare microservices to traditional monolith architecture, as well as the more-recent service-oriented architecture (SOA).

Microservices vs. monoliths

As the name suggests, monoliths are large, unified applications where each component is largely interconnected and dependent on neighbouring components. Monoliths are the traditional approach to development, with all functions managed and served in one place, and everything built on a single code base. Any changes that developers may wish to implement in monolith structures will naturally change the entire stack. Activities such as testing apply to the entire stack as well and so changes are grouped together in large release that can take a relatively long time from start to finish. Microservices are distinct from monoliths, in that they are composed of a number of smaller, self-contained, loosely joined components. Changes may be implemented on the individual components without affecting other services within the application.

Microservices vs. SOA

The distinction between microservices and SOA is more subtle. However, while both rely on reusable components that may be modularly applied to different applications, SOA is not nearly as granular. Where microservices are containerised to the point where every service performs only a single function, each SOA component may be a complete subsystem responsible for a range of business functionality. Additionally, SOA optimises component sharing and dependencies, while microservices simply try to minimise these aspects as much as possible.

Typically, microservices feature the following characteristics:

Testability

Because microservices are designed as a collection of individual, independent services, they can be easily tested as standalone components. Issues within the components can be quickly isolated, rather than having to test entire systems and applications, and then invest large amounts of time in trying to isolate specific failures.

Loose interconnectedness

To operate in tandem, microservices must maintain communication with one another. That said, this is a loose connection, where changes implemented within one service do not directly affect other services.

Decentralisation

Rather than sharing data stores across services, each constituent component maintains its own data store. This helps prevent accidental coupling of different services, and ensures that changes do not unintentionally impact other independent services.

Independent deployability

Individual services are changed and deployed into the production environment without having to employ any other services. All deployments within the system are managed in this manner making it very quick to enhance a microservice.

Business centricity

Microservices make use of cross-functional teams, which are organised around a single business purpose. These teams often consist of developers, database engineers, testers, infrastructure engineers and others, with the goal being to develop specific products based on multiple independent services.

Simple routing

In microservices, each independent service is capable of receiving, processing and responding to requests. This is greatly simplified over many of the more-traditional systems, where complex routing and business-rule application layers can end up slowing the process.

Failure resistance

For a microservice system to completely fail, essentially all of its independent services must fail at the same time. By relying on loosely-connected services, a system may continue to operate near optimal capacity even in the event of a failure in one of its services. Because the services are decentralised, the loss of one should have little to no impact on neighbouring services.

Adaptability and scalability

Because microservices are modular in nature, it is relatively easy to add new services when needed. This makes it possible for organisations to adapt current systems to new uses, and to scale systems up or down to meet changing demand.

No long-term commitment to technology stack

When developing a new service, organisations have the freedom to choose from various technology stacks. At the same time, new technology stacks may likewise be employed when making changes to existing services.

The modular, containerised approach used in microservices development makes it a natural partner to both DevOps and continuous integration/continuous delivery (CI/CD). Because each service is approached as its own unit, multiple teams can work separately to develop functionality concurrently, applying DevOps principles and moving projects quickly through CI/CD pipelines.

Although it is possible for microservices to communicate directly with each other, many businesses prefer to integrate API gateways to function as intermediary layers to help route requests, provide additional authentication and improve security. API communication may be particularly effective when microservices are first establishing state.

Microservices represent a shift from traditional development architecture, and provide a number of advantages over more-conventional organisational approaches. These benefits include the following:

Agility

Microservices empower small, independent teams to act within clearly defined contexts. This allows them to accomplish more in less time, and to respond with increased agility to unanticipated changes.

Increased accessibility

Microservices break down complex applications and systems into smaller, simpler components. Developers can more easily see distinctions between services and make necessary updates and improvements.

Graphic outlining the benefits of microservices

Developer freedom

Rather than being locked into a single language or technology stack, developers have the freedom to select the best solutions, tools or resources for each individual function—without having to worry about communication between services being affected.

Simplified deployment

Because microservice-based applications are highly modular, they can be developed and deployed with relative ease. Teams can coordinate together to work concurrently on individual, small components, and each component can be deployed independently.

High scalability

In traditional application architecture, meeting changing demand often means scaling the entire application. Microservices allow developers to redirect resources towards scaling only the applicable services and components, improving scaling speeds while reducing associated costs.

Unmatched resilience

In the event that one microservice fails, neighbouring microservices remain unaffected. This means that microservice-based applications do not tend to crash; if one or more components fails, the application itself will continue to operate at reduced functionality until the affected service can be repaired.

Reusability

Because each service is self-contained and designed to independently perform a specific function, developers can reuse and recycle services for use across a number of different applications. Components can function as ‘building blocks,’ significantly reducing the need to create new code from scratch for every new project.

Reduced time to market

Improved agility, increased reusability and simplified deployment all promote shorter development cycles and faster time to market. This has the potential to improve business returns and deliver a more-satisfying user experience.

The advantages represented by microservices also carry with them certain difficulties. Here, we take a closer look at some of the challenges organisations may encounter when implementing a microservices approach:

Building

Making the switch to microservices means identifying and cataloguing any and all dependencies between services. Due to dependencies, completing a single build may directly lead to having to implement a number of other builds, which can be frustrating and time consuming.

Data

A key factor in microservices is that each component has its own, isolated database. But with each new database comes increased complexity in management. The more services, and the more databases, being employed, the less convenient it is to manage the data itself.

Versioning

When updating applications to new versions using microservices, there is a chance that backward compatibility may be affected. The solutions—building in conditional logic or standing up multiple live versions for different clients—may be overly complex in terms of maintenance and management.

Deployment

Microservices are designed to simplify deployment. But the complexity of working with a large number of independent components can be overwhelming. Automation may help resolve this issue.

Logging and monitoring

Logging can become difficult when every service uses its own database. Establishing centralised logging solutions may be necessary. Similarly, monitoring and managing each service may be unfeasible without a centralised view and single source of truth.

Debugging

With potentially hundreds of microservices incorporated into a single application, traditional debugging is not an option.

Coordination

While microservice architecture gives teams a fair amount of independence, issues that span more than one service within an application may demand detailed cross-team communication and coordination to set right.

Duplication

Because microservices applications are distributed systems, it is not unheard of for teams to unknowingly duplicate tasks. This can result in wasted effort and inefficient applications.

In addition to the challenges addressed above, there are certain pitfalls that organisations should be aware of when considering adopting a microservices architecture:

Using microservices as a starting point

Although a very popular approach to development architecture, microservices are generally best suited to repairing and revising existing applications that have gotten overly complex and difficult to maintain. They are not nearly as effective when used as a starting point. If the traditional approach hasn’t reached unmanageable levels, then it’s not actually a monolith in need of restructuring.

Making microservices too granular

As with anything else, a service can always be divided into smaller parts. And while microservices should be granular, consisting of limited functions designed to support a greater whole, it is possible to take things too far. Instead, many companies find that starting with larger services, and then only breaking them down into microservices when they become slow to deploy or too complex to manage, helps ensure that the solution doesn’t offset the potential gains.

Approaching microservices without the right support

A large, distributed system can easily get out of hand. To ensure microservices effectiveness, organisations should incorporate advanced deployment and monitoring automation, along with managed cloud services. This can help ease much of the burden of transitioning to microservices.

ServiceNow can help with the management aspects of services built leveraging microservices as well as by connecting to the methodologies and tools used in the build phases such as CI/CD and other DevOps solutions.

Given the potential for large numbers of microservices and their transitory nature, ServiceNow provides options for automatically populating the CMDB and Service Graph to help track relationships and maintain the definition of services. This is part of our IT Operations Management offering which also provides broader cloud management capabilities.

As with any code developed with DevOps practices, speed is a common goal when maintaining microservices – I.e. providing the fastest possible path between a developer and a production system. But larger or regulated organisations must maintain strong change controls, so IT Service Management Professional includes our DevOps Change Velocity feature that connects to the CI/CD pipeline, gathers information during the development process, and utilises it alongside previously defined policies to automate the change management process.

Finally, ServiceNow is a rich source of capabilities that can be utilised by internal and external applications in a microservice-like way in addition to supporting the integration with external microservices as part of ServiceNow workflows.

Capabilities that scale with your business

The Now Platform includes core capabilities that enable you to quickly and efficiently digitise workflows and run them at scale.

Schedule a demo

Resources