Understanding Microservices: History, Principles, and Benefits

Article originally from IBM developerWorks

From early 2014 to 2015, microservices became a new buzzword, quickly overtaking cloud . This is the first part of a multi‑article series that introduces how to implement microservices, covering their history and the meaning of building on a microservice architecture, laying a solid foundation for later practical examples.

Netflix Stream: The Popularization of Microservices

Whether you have heard of microservices or not, you have probably heard of Netflix and its open‑source software (NOSS) that powers its digital entertainment streaming platform.

Starting around 2009, driven entirely by APIs and the first wave of what we call microservices, Netflix completely redefined its application development and operations model. Initially mocked as "crazy", by 2013 the attitude shifted to "we are adopting microservices" with over 525,000 Google search results for the term, indicating its effectiveness and strength.

But what exactly is a microservice ? What is a microservice‑based architecture ? Figure 1 shows a conceptual view of a travel‑booking service composed of seven independent microservices, each represented by a tile that can interact with others and provide functionality to internal and external applications.

For a deeper explanation of the original intent behind microservices, see Martin Fowler’s blog. This article extracts the essence of that blog, discusses the applicability of microservices to your environment, and how to apply them.

In a conference talk, Adrian Cockcroft (formerly of Netflix) defined microservices as "fine‑grained SOA". You don’t need deep SOA knowledge; just understand a few key terms. Ideally, you build the entire architecture from services from the start. Each microservice has a single purpose, no side effects, allowing fewer specialized engineers to handle more work.

To define microservices and their associated architecture, I adapt the classic "bigger, faster, stronger" slogan to "smaller, faster, stronger" (see Figure 2). In essence, microservices are many smaller components that can be built and delivered quickly, becoming increasingly powerful both individually and collectively.

Smaller

Microservices eliminate monolithic models, which are large, rigid, slow, and inefficient (see Figure 3, the "Grim Monolith"). We are moving away from 2 GB WAR files toward many 500 MB services that each contain a complete application, server, and necessary OS components.

The migration from mainframes to client‑server, and from web‑centric core servers to SOA, has been a difficult step for many companies. Traditional WebSphere® Application Server + Java™ EE deployments (Figure 4) still bundle many GB of binaries, whereas microservices aim for plug‑and‑play, loosely coupled components.

Microservices practice integrates very loosely coupled interactive components, making the overall system "plug‑and‑play". In the "stronger" section later, I will discuss how large‑scale adoption of a "shotgun" approach—maintaining many small components rather than a few large ones—eliminates single points of failure.

Fault‑tolerant construction is achieved through smaller components. A monolithic fault‑tolerant system requires far more effort to handle edge cases, whereas independent service instances can take over when one fails.

Figure 5 shows an example implementation for a streaming video application.

Each box in Figure 5 maintains itself, scales independently, knows its location, and knows where to obtain required information. Not every microservice architecture needs every component shown, but they are helpful.

Comparing Figure 4 (monolithic) with Figure 5 (microservice) illustrates the difference: the monolith runs all components in a single vertically scalable process, scaling the entire JVM stack even if only one component needs more resources. In contrast, Figure 5’s components can scale independently.

In the "faster" section, I will discuss how each component scales, but the key point is that distributed, single‑purpose services evolve much more quickly than a monolithic stack.

Faster

Another buzzword that emerged with the cloud is DevOps . DevOps enables developers to control more code in the delivery pipeline, achieve continuous integration, and gain higher visibility. Its core principles—observe, orient, decide, act—are shown in Figure 6.

Delivering updates to many small services is far more efficient than updating a massive application server every two weeks. While continuous delivery can be done with monoliths, it is far easier to discard a small, fast‑failing component (a "marble") than a large, cumbersome one (a "boulder").

DevOps cycles align well with microservices: short development cycles, continuous addition of features, and agile practices enable rapid construction of a full infrastructure that would have taken years in a waterfall model.

Speed also relates to resource provisioning. By building each service as independently scalable, resources can be allocated where needed, rather than funneling everything through a single interface.

In the streaming video example (Figure 5), the Service Registry automatically discovers new service instances as they scale. Edge services (e.g., Movie Service, Review Service) query the registry to obtain up‑to‑date client references, ensuring high reliability and load distribution.

This high‑speed scaling, with services aware of new instances, makes microservice‑based applications more robust—not a "Terminator" scenario, but a resilient architecture.

Stronger

Not all systems are intended to exist forever. They are created when needed and removed when no longer suitable, eliminating single points of failure and distributing risk across many instances.

Livestock, Not Pets

Pets have names; livestock have numbers.

Pets are unique; livestock are identical.

Pets are cared for; livestock are replaced when sick.

This concept helps create many identical services—"livestock"—instead of a few unique "pets" that require special handling.

Netflix demonstrated the advantage of this approach with Chaos Monkey (Figure 8), a component that deliberately introduces failures into production to test resilience.

Chaos Monkey forces the system to handle sudden service outages, revealing weak points and ensuring that enough instances exist to satisfy 99.9999% of requests. Netflix later expanded this idea into the Simian Army (Figure 9), which includes Janitor Monkey, Conformity Monkey, and Latency Monkeys, adding targeted chaos such as latency and compliance issues.

Thus, Netflix and other microservice adopters agree that applications become stronger through intentional failure injection.

Conclusion

The main advantages of microservices I have introduced are:

Smaller size allows developers to stay highly efficient.

Easier to understand and test each service.

Faults in dependent services can be handled correctly.

Reduces the impact of correlated failures.

Future articles in this series will dive deeper into large‑scale management and monitoring of complexity, emphasizing fine‑grained metrics and timelines.

More services mean more contracts between teams, increasing the need for interface and API version management—issues typically addressed within a DevOps model.