What are Microservices?

Microservices architecture is a flexible and scalable approach to software programming, with individual services able to be deployed independently of one another.

It is the counterpoint to traditional monolithic architecture, in which the entire program is developed and deployed as a single application.

Instead, microservices allow each service to be programmed and deployed in its own right – a kind of modular approach to building the finished program.

Similarly, obsolete microservices can be removed from the stack more easily, whereas a monolithic application could be difficult and uneconomical to rewrite or redevelop to remove obsolete components.

Are microservices and SOA the same thing?

SOA is Service Oriented Architecture – and microservices are clearly service-oriented in the more general sense too.

However, there are some key differences between SOA and microservices:

• SOA uses independent software components but is not inherently modular in the same way as microservices.
• Modifying SOA can still require monolithic modifications and application-wide downtime.
• Microservices are typically more cloud-based rather than locally server-based.
• Microservices can have independent storage; SOA services typically share data storage.
• Microservices are less restricted in standards and governance, giving development teams more choice and control.

Microservices have been called ‘fine-grained SOA’, an indication of the close similarities between the two architectures, and also of the lightweight, streamlined nature of individual microservices.

What are the Advantages of Microservices? 


The ability of microservices to decompose a monolithic application into a set of independent services offers faster production, a more efficient workflow, and marked increases in resiliency and productivity.

Faster deployment and scaling

A microservices architecture speeds up each production cycle by enabling teams to develop, deploy and scale services in parallel. This also helps them reduce the time needed to put changes or improvements into production.

Reduced downtime

Parallel development reduces system downtime and increases performance, helping an organization get more from its investment. And the greater autonomy gives teams more agency to simplify and maintain code for any single service.

High availability

Microservices are capable of dispersing functionality across multiple services. This prevents any single point of failure to disable the application. If a component dies, teams can simply spin up another as the application continues to function.
These shorter cycles and reduced downtime improve productivity, making it easier to update and ship within Agile’s tighter production sprints. That, in turn, gives companies more opportunity to push improvements that can increase user engagement.

Microservices as an API Gateway

A microservices API gateway is a proxy that brokers traffic from one service to another. It’s intended to make your microservices respond like an API that’s been customized to meet a client’s unique requests. Think of it as an air traffic controller, directing the information from the client to the underlying microservice.

An API gateway can serve as the client’s single entry point into the system, performing services like:

• Routing or proxying requests to the appropriate service/services/groups of services
• Responding to certain requests by fanning them out to a custom series of services and aggregating their results
• Translating between different databases or protocols

All conducted in a way that reads like a universal point of contact with the app.

Are web services microservices?

Microservices and web services are broadly similar but the definitions are subtly different.

Web services are simply services that are accessed over the web, typically via HTTP protocol, and increasingly many of these are deployed as standalone or modular microservices.

In contrast, microservice architecture is more about the way the application is built and deployed – its form, rather than its function.

Web services can be microservices, and microservices can be web services, although this is not necessarily the case 100% of the time.

What Issues Can Come Up When Using Microservices?

While microservices provide DevOps with increased agency and responsibility, they also increase the intricacy of systems and practices. For teams that are used to legacy systems and monolithic architectures, a certain amount of “culture shock” can be expected.

Teams should expect greater complexity across service discovery, monitoring, testing and networking. Those teams are tasked with maintaining parity of performance between each service and managing the flow of information across the enterprise. New or increased duties will include:

• Addressing network latency
• Mitigating fault tolerances
• Load balancing
• Engaging with multiple message formats
• Orchestration across multiple teams and services
• Consistent communication with (and updating of) other teams and internal stakeholders

The sooner teams acclimate to the requirements of a microservices architecture, the less they’ll risk duplication of services, and the sooner they’ll be able to leverage the benefits.

Why is Open Source Important for Microservices?

Microservice applications feature dozens, even hundreds, of separate components, often running under fast production cycles and tight budgets. The rigid, centralized, “black box” methods of development simply don’t offer the flexibility and adaptability that open source provides.

Because open source solutions enable your applications to be modular from the start, they free up your DevOps team to customize and extend their applications. Any team can build on top of their service, modifying open source code to repair or improve it. The result: greater opportunity for innovation and speed-to-solution.