Microservices architecture: Origin, benefits and challenges

These different services then communicate with each other through APIs or web services.

And instead of teams focusing on areas of the system like UI and database as they would in a service-oriented architecture (aka SOA), for microservices they are organized around specific business outcomes that bridge system functions—like a product or service.

To better understand its definition and why they've become so popular, it's helpful to know where they came from. Here is a brief history.

Origins of microservices: The promise of services

Like a Phoenix, microservices were born in the ashes of their former incarnation: services. Two decades ago, architects conceived services, and today, microservices fulfill their original promise. Service-oriented architecture promised the IT world something of a miracle cure for intractable monolithic applications.

Businesses were plagued by backlogs and political wrangling, while startups were building scalable products that ate away at market share. Businesses could break up their monoliths by creating mini-monoliths that house core business functionality.

A mini-monolith or, better yet, a “minilith” was created to promote agile practices, assign full product ownership to a horizontal team, and provide easy access to the service for whoever needed it. That's pretty impressive. What happened?

A fall from grace

In this case, we're discussing a "hot tech trend," and almost all trends follow the fad pattern. Fads disappear because the professionals who initiated them have been practicing for years. However, amateurs galvanized by their success find it difficult to reproduce their success. A few talented individuals crafted their services with care, while the rest of the IT industry enviously admired those who made it look so easy.

Martin Fowler, one of the founders of agile, has stated that the majority of organizations do not migrate to true SOAs, rather they move complexity from one place to another, primarily to the enterprise service bus. The enterprise service bus (ESB) is a piece of middleware designed to handle communication between services and their consumers. Companies use ESBs in order to mitigate the difficulties associated with decoupling a business process from its monolithic parent company.

In the end, the result is a black-box solution that technically "works," but is hard to change, difficult to test, and impossible to manage. Martin Fowler decided to rename ESBs to a more appropriate initialism: Erroneous Spaghetti Boxes.

Enter microservices

When describing something, have you ever found that your listener regurgitates a twisted, clearly misinterpreted version of what you just described? When in doubt, remember any conversation in which there was a noticeable amount of head nodding. That's it. Developers felt precisely the same way when the enterprise world ate up service-oriented architectures and spat out whatever it is that is being presented:

And in that social situation, one wishes to correct misunderstandings. Developers have done so by rephrasing their original point in the form of microservices.

At their core, microservices provide the same benefits originally promised by services. Generally, they follow these conventions:

• Network-accessible: No sign of custom spaghetti-box code here. Microservices strictly limit themselves to platform-agnostic network protocols like HTTP, TCP/UDP, etc. This practice, consequently, has spilled back into the SOA world.
• Deployed independently: True decoupling is a pillar of microservice architecture. Teams must be capable of deploying updates independently of other components, especially their consumers.
• Replaceable: Due to the first two conventions, one microservice may replace another simply by adhering to the service contract of the original. The contract, in this case, is an API specification.
• Narrowly-scoped: A microservice limits itself to a specific business value or feature. Defining the scope of each microservice is challenging, but billing, photo storage, or location-based services are all par for the course.
• Heterogeneous: They employ the libraries and technology that best suit their use case rather than those forced upon them by a monolith architecture.
• Fully automated: Microservices are a terrific companion use-case for DevOps, the philosophy that bridges the gap between software development (the creators) and IT operations (the ones who get it up and running—and get it to work if it’s changed). Teaming up DevOps and microservices creates automated deployment, testing, and monitoring processes that improve service reliability and promote frictionless development cycles.

Microservices vs. SOA: Understanding the differences

Microservices are cloud-native, designed to bring extreme agility and to provide the most autonomous way to deliver software. The two approaches are similar and aim to promote the same reusability and agility, but they do differ in scope:

• SOA looks at services in the context of the enterprise and their use in many different applications
• Microservices are focused on the architecture of the application itself.

In many ways, microservices can be seen as an evolution of service-oriented architecture, although the latter already enforces a modular approach, they provide a number of different enhancements to this—but it is not a silver bullet, and not every organization is equipped to provide a full-blown architecture.

To learn more about this topic, please refer to OutSystems documentation on this topic.

Benefits of microservices

Several tech giants like Netflix, Amazon, and Uber have already adopted microservices due to the many benefits they promise. Those advantages include:

• Reduced time to POC: Developers can build microservices using whichever tools best suit the business value they intend to provide. Combine that with complete data isolation and you have a formula for hyper-fast prototyping.
• Owned by a team: By dividing business value into a collection of microservices, a small horizontal team can assume full ownership. This empowers and motivates them to deliver an excellent product. By contrast, in large monoliths, developers are thrown from task to task; rarely do they feel their contributions are individually meaningful.
• Scalable: Built and published independently of other application elements, a microservice can scale as needed by the organization (which includes downscaling).
• Reusable: Once built, the microservice is available to any consumer. And as it is meant to scale as needed, they can handle the additional workload as well.
• Fault tolerant: By isolating both its data and application servers from other components, microservices can fail without causing a full product shutdown. Because they are a smaller product that is independently released, managed, and scaled, it’s easier to introduce fault tolerance with this type of architecture. It becomes easier to create a more fault-tolerant system by introducing fault tolerance in the smaller parts that constitute the system; namely, it is much easier to create experience gradients when one or more services fail without full disruption to the complete system.
• Risk mitigation: By definition, microservices provide a business value. And they mitigate risk by remaining independent of other components. This way, aligning their development with the interests of the organization is inherent in their design.

Why use microservices?

Microservices architectures are highly scalable applications designed to reach millions of users, like Netflix, Twitter, and Amazon. They are cloud-native architectures focused on achieving high levels of agility and autonomy. And thanks to the granularity and independence of these services, you can achieve a fluid, continuous delivery of service.

But all this begs the question—why wouldn’t you use this type of architecture?

Disadvantages of microservices

By breaking down a system into these fine-granular pieces, you create one that is incredibly complex. And with complexity come consequences.

• Network dependency: They communicate exclusively over standard network protocols, which means that a network outage or disruption of any kind (often beyond an organization’s control) will interfere with business operations. And, as the number of deployed microservices grows, so does the risk of a network outage, putting one of these services in jeopardy. On the other hand, network also means that latency is introduced in the system, and that needs to be accounted for. No end-user likes to wait seconds to see the balance of their accounts simply because network communications became slower.
• Overhead: With microservices, you break apart a big product into a constellation of smaller products. As a result, there's overhead that is created in managing this constellation. This is, in fact, one of the reasons why many organizations are not ready for full adoption. In addition to that, each microservice requires its own DevOps processes. As the number of microservices within an organization grows, so does the amount of maintenance and monitoring required for upkeep.
• Dependency hell: Imagine hundreds of application components relying on a microservice with an established contract (API spec). And now imagine the team wants to redesign (or even slightly modify) its specifications. Not only must the organization coordinate this change across myriad teams, they must also track who relies on whom at all times.
• Strict contracts: Speaking more to the point above, developers must be careful to define a microservice API specification robust enough to provide business value long after the initial release. That kind of foresight is rare, if impossible, in some organizations, and renders microservices a tougher sell.
• Too easy to launch: This is a strength-as-a-weakness scenario. The ability to deploy and incorporate microservices so simply can lead to overzealousness. Microservice-ifying everything before an organization fully understands the tradeoffs can lead to a failed or poorly executed re-architecting.

When to use microservices?

You should be able to answer the question, “Is microservices the right architecture for your next software project?" now that you are aware of all the pros and cons. As a final point for you, before you search for tutorials, consider why you would like to develop a microservice architecture. You are probably on the wrong track if you respond, "because all the big ones do it."

In this article, we outlined some of the benefits, and it is clear why such an architecture might be beneficial. Several teams can have independent continuous integration and continuous delivery (CI/CD) pipelines while capitalizing on different skills, vendors, and technologies.

However, it is crucial to recognize when it is worthwhile. As a result, most companies are not like Netflix, which has a large development staff with some of the best engineers in the world all dedicated to managing a single application. Typically, talent is scarce and difficult to find in the average enterprise; plus, they tend to be smaller and focus on a portfolio of applications that serve the business rather than a single product, which may result in impossible situations if improperly utilized.

An understanding of the advantages and disadvantages of each approach is critical to making good decisions about your architecture.

To learn more about the different approaches and how to choose the right architecture for your development projects, I recommend the following resources:

• Application Architecture: Best Practices for Future-Proofing Your Apps
• What Is a Service-Oriented Architecture?
• How to Design a Web Application Architecture

Frequently asked questions