What Is a Microservice?

Microservices are a type of software architecture where the functionality of the application is broken up into smaller fragments to make it more resilient and scalable. We call these fragments “services”. Each service focuses only on a single functionality of the application and is isolated from the others, making each one of them independent. This means that your development teams can work separately on different services and avoid a complex orchestration between them.

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

Sounds confusing? Well, to better understand what microservices are and why they’ve become such a hot topic, it’s useful to understand where they came from. Please bear with me in this brief history lesson.

Origins of Microservices: The Promise of Services

Like a Phoenix, microservices were born in the ashes of their former incarnation: services. Still in use today, architects conceived services approximately two decades ago, and microservices are here to fulfill their original promise. Service-oriented architecture (aka SOA) promised the IT world something of a miracle cure for intractable monolithic applications.

Enterprises were dealing with ever-growing backlogs and political in-fighting; meanwhile, their startup competitors built scalable, fast-moving products that ate away big-business market share. Enterprises could break apart their monoliths by pulling core business functionality out of the main application and into mini-monoliths.

These mini-monoliths or, better yet, miniliths (I call “trademark!” You just call trademarks out loud like shotgun, right?) were designed to encourage agile practices, assign full product ownership to a horizontal team, and provide easy access to the service for whoever required it. Pretty stellar! So what happened?

A Fall From Grace

We’re discussing a “hot tech trend” here, and nearly all tech trends follow the fad pattern. Fads fade because the professionals that set them into motion have practiced for years; meanwhile, amateurs galvanized by their success struggle to replicate the results. While a few talented individuals crafted their services with care, the rest of the IT world went about enviously ogling at the people who made it look so easy.

According to Martin Fowler, one of the founding fathers of agile, the majority of enterprises do not migrate to true SOAs; rather, they simply move complexity from one place to another, specifically, to the ESB. An ESB (enterprise service bus) is a piece of middleware designed to handle the communication layer between services and their consumers. Companies employ ESBs to mitigate the difficulties of properly decoupling a business process from its monolithic mothership.

However, the result is a black-box solution that technically “works,” but is slow to change, impossible to test, and beyond the organization’s control. And this is why Martin Fowler rebranded ESBs to a more appropriate initialism: Erroneous Spaghetti Boxes.

Enter Microservices

Have you ever found yourself explaining something only to have your listener regurgitate a twisted, clearly misunderstood version of what you just described? If you’re not sure, think back to any conversation that involved a suspicious amount of head nodding. Yep, that’s it. And that’s precisely how developers felt when the enterprise world chewed up service-oriented architectures and spat out whatever this thing is:

And in that social situation, one wishes to correct misunderstandings. Developers have done so by rephrasing their original point in the form of microservices. Microservices at their core provide the same benefits originally promised of 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 to their microservices 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: Microservices 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.

Microservice Advantages

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 of a microservice. 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, a microservice 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 microservices 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.

Disadvantages of Microservices

Unfortunately, like any other hot trend, microservices are not all roses. Here’s the catch.

• Network dependency: Microservices 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 to fully adopt microservices. 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 up-keep.
• Dependency hell: Imagine hundreds of application components relying on a microservice with an established contract (API spec). And now imagine the microservice team wants to redesign (or even slightly modify) their specification. 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, that 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.

Is Microservices the Right Architecture for Your Next Software Project?

Now that you know all the pros and cons of microservices, you should be able to answer this question. My final takeaway for you is: before searching for microservices tutorials, ask yourself why do you want to build a microservice architecture? If your answer is “because all the big ones are doing it”, you’re probably starting with the wrong foot.

We’ve covered some of the benefits of microservices, and one can undoubtedly understand the pros of using such architecture. Multiple teams can have independent continuous integration/continuous delivery (CI/CD) pipelines while capitalizing on different skills, vendors, and technology.

However, it is essential to understand when it pays off. After all, most companies are not like Netflix, with a large development pool with some of the best engineers in the world entirely dedicated to managing a single application. For the common enterprise, talent is scarce and hard to source; plus, they’re usually smaller and focus on a portfolio of applications that serve the business rather than a single product. If badly used, microservices can lead to impossible situations.

Making good decisions about your architecture is key to your app’s success, and this is only achieved with a complete understanding of the benefits and costs of the available approaches.