In this first installment in a series on the evolution of API and microservices ecosystem, we will learn about how microservices and APIs became industry standards and what are different benefits microservices offer. We will explore different challenges with this ecosystem and how to solve them in the second part of this series.

Most of the tech giants including companies like Amazon, Netflix, started to build their systems using a monolithic architecture because back in the time it was much faster to set up a monolith and get the business moving. But over time as the product matures or fat growth happens, with growing systems the code gets more and more complicated. They all faced this problem and looked at microservices as a solution. One of the biggest benefits of microservices is that each microservice can be developed, scaled, and deployed independently. You can replace or upgrade any part of the system without affecting the whole system.

But, what is microservice architecture? As called out by James Lewis and Martin Fowler, The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
I hope it’s not that hard to guess but these microservices talk to each other via APIs and two of the most commonly used protocols are HTTP request-response with resource APIs and lightweight messaging. Although as I mentioned above, companies like Netflix and Amazon have been using microservices for quite a long time, many small organizations have also started adopting API first or microservice driven architectures recently, because APIs have become the heart of the global tech industry in the past decade.

Rise of Microservices

Let’s dive more into the origins of APIs and Microservices as they share a common origin story.

• Rise of service-oriented architectures
• Rise of cloud computing and managed services
• Rise of decentralization movement
• Rise of Agile movement

Rise of service-oriented architectures

As we all know, building distributed systems is hard and managing them is even harder. The rise of the web back in the days opened the doors to innovate the way we build distributed systems and that’s where Service based architecture came into the picture. SOA was defined as a style of multi-tier computing that helps organizations share logic and data among multiple applications and usage modes. [as defined by Gartner ]

Though a failed movement back in the time, SOA surely helped a lot in initiating microservice movements, and even organizations like Netflix and Amazon were calling their architectures SOAs before the microservice movement. Due to the centralized nature of ESB topology and some other reasons, SOAs increased complexity and introduced bottlenecks, and the costs of implementing an SOA infrastructure (based on the ESB, registry, and service platform template) were excessive.

Due to these problems, people started looking for better alternatives.

Rise of cloud computing and managed services

The rise of RESTful Web APIs arose as a lighter-weight alternative to SOAP services. -- a style of interconnecting applications that had evolved organically on the Web --. The distributed nature of cloud infrastructure challenged the placement of the centralized ESB topology.
Everyone started adopting microservices due to the benefits they provided and here we are today looking at complex modern architectures. Cloud computing helped in removing barriers for deployment and provided a variety of new use-cases for APIs. It worked out as a novel platform for deploying more granular API-fronted application components. Cloud services provided another reason to move towards more service-oriented and modular deployment architectures.

Rise of decentralization movement

As we discussed earlier, at one point in time, service-oriented computing became an increasingly popular paradigm for modeling and building distributed systems in open and heterogeneous environments. However, proposed service-oriented architectures are typically based on centralized components, such as service registries or service brokers, that introduce reliability, management, and performance issues.

During this whole time, the capabilities and scale of distributed systems have increased. The trend towards decentralization in both the system itself as well as the supporting organization started to catch up and the decentralization moment started.

Rise of Agile movement

In his blog post titled “Coding the Architecture”, Simon Brown pointed out that agile architecture does not naturally emerge from agile development practices. Rather, it must be consciously sought. Note that his description of agile software architecture is a perfect match for microservice architecture.

If we look at the characteristics of agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified, and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed.

The agile software movement arose as a reaction to the same centralized approach to enterprise IT that hampered the SOA movement. Agile’s popularity and success in software development led to the CI/CD approach to software deployment, followed by the cultural philosophy of the DevOps movement. Between CI/CD, DevOps, agile development, and progressive delivery, the software delivery train also started speeding up.

Benefits of Microservices

Now that we have gone through the reasons behind the rise of Microservices, Let’s try to understand what business value microservices provide.

The main reason that drives the move to microservices in any organization is speed and agility at scale which helps in software delivery. Reducing cross-team coordination, building diverse language applications, flexible deployments, enhanced manageability are some of the additional perks that organizations with microservice architectures enjoy.

Many of the benefits which come with Microservice architectures are mostly due to the API-first nature of microservices and here are a few of them:

• Composability: When services are published through an API, it is easier to use them in multiple business contexts to assist in various business processes
• Testability: When services are accessible over a network boundary, it is easier to isolate tests and exercise individual components of the system
• Scalability: Each microservice can be scaled autonomously without disrupting the other microservices that comprise the application. When demand increases, you only need to upgrade or divert more resources to the microservice affected by the increasing demands.
• Evolvability: When services are exposed through an API, implementation details can be hidden from the consumer, making it easier to change components without impacting dependent parts of the system
• Comprehensibility: When a complex system is broken down into modular APIs, it is easier to understand the overall business functionality of the system, which helps in both designing and maintaining the system
• Automatability: Along with the data plane API benefits above, control plane APIs allow automation in the deployment and management of microservices, thus increasing the velocity of software delivery

But as we know with great power comes great responsibility and the same thing applies to microservices and API ecosystems as well. These complex systems bring a lot of challenges with them and we will discuss those challenges in the next part of this blog post.

Until then, if your organization is using microservice architecture and exploring Observability solutions, feel free to check out our Open Source Observability platform Hypertrace. If you are in transition and want to learn more about Observability or want to contribute to Hypertrace, join our slack community to interact with folks who have been through this transition or going through this transition.

References:

• https://www.martinfowler.com/articles/microservices.html
• https://www.infoq.com/articles/web-apis-business-perspective/
• https://www.gartner.com/en/documents/302868
• https://www.infoworld.com/article/3080611/learning-from-soa-5-lessons-for-the-microservices-era.html
• https://docs.broadcom.com/doc/microsurfaces-the-role-of-apis-in-a-microservice-architecture
• https://www.thoughtworks.com/insights/blog/microservices-nutshell
• https://link.springer.com/article/10.1007/s12083-009-0062-6
• https://www.infoworld.com/article/3075880/microservice-architecture-is-agile-software-architecture.html