What Is a Microservice?

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 that 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. Microservices at their core 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 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?

You should be able to answer this question now that you are aware of all the pros and cons of microservices. As a final point for you, before you search for microservices 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 associated with microservices, 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. Microservices 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?
• Monoliths or Microservices: Make Both Your Domain
• How to Design a Web Application Architecture