Microservices: An alternative architecture

This is what I explained to my friend, when he questioned me that the microservices are a bit overrated SOA and they both are just the same. As always I negated his question and tried to explain him with the best of my abilities as below:

Before you look at a comparison of microservices and SOA, you need to understand what a microservices architecture means. From a fundamental point, microservices are an alternative architecture for building applications. They offer a better way to decouple components within an application boundary. In fact, if microservices were called "micro components," their true nature would be clearer.

The boundaries of the application remain the same. As shown in the figure, despite being broken into separate microservice components on the inside, the application might still look the same from the outside. The number and granularity of APIs that a microservice-based application exposes should not be any different than if the API was built as a siloed application. The prefix "micro" in microservice refers to the granularity of the internal components, not the granularity of the exposed interfaces.

That's how it is extremely difficult or sometimes practically impossible to bring in microservice architecture into a COTS package, as you as a customer can't break into application. However if you are revamping an corporate legacy application, you need to start thinking of microservices - just the benefits that brings into the overall ownership.

Logically separating components within an application is not new. A host of different technologies has been developed over the years to enable clean separation of the parts of an overall application. In my long career in ERP applications, I've seen the facelifts with a newer technology whereas the backend remained the same for two decades. Application servers can run multiple application components within them for a long time as shown by the middle image in the following figure. Microservices go one step further by making the isolation between those application components absolute. They become separately running processes on the network as shown on the right side in the figure. To achieve decoupling, you should also partition your data model to align with the microservices.

With this understanding, let's see some of the organizations that have invested heavily on microservices. Amazon and Netflix are two major entities who uses microservices as a part of delivering their products and services to their customers. That begs us the question of why! - and let's see the benefits of microservices.

The benefits of microservices

Fully independent microservice components enable completely autonomous ownership, resulting in the following benefits:

• Agility and productivity: The team that is developing the microservice can completely understand the codebase. They can build, deploy, and test it independently of other components in much faster iteration cycles. Because the microservice component is simply another component on the network, you can write it in the best suited language or framework for the required functionality and the most appropriate persistence mechanism.This approach can significantly reduce the amount of code to write and make it dramatically simpler to maintain. It ensures that teams can take on new technologies or versions of existing technology as needed rather than waiting for the rest of the application domain to catch up. For some definitions of microservice granularity, a microservice component should be simple enough that it can be rewritten in its next iteration if it makes sense to do so.
• Scalability: The microservices development team can scale the component at run time independently of other microservice components, enabling efficient use of resources and rapid reaction to changes in workload. In theory, the workload of a component can be moved to the most appropriate infrastructure for the task. It can also be relocated independently of the rest of the components to take advantage of network positioning. Well-written microservices offer extraordinary on-demand scalability, which was demonstrated by early innovators and adopters in this space. These microservices are also best placed to take advantage of the elastic capabilities of cloud-native environments that have cost-effective access to enormous resources.
• Resilience: The separate run time immediately provides resilience that is independent of failures in other components. With a carefully decoupled design, such as avoiding synchronous dependencies and using circuit breaker patterns, each microservice component can be written to satisfy its own availability requirements without imposing those requirements across the application domain. Technologies, such as containers, and lightweight run times have enabled microservice components to fail quickly and independently, instead of taking down whole areas of unrelated functionality. Equally they are written in a highly stateless fashion so that they can immediately redistribute workloads and almost instantaneously bring up new run times.

These examples of benefits capture some of the most common reasons that many more organizations are turning to microservices. However you can't just jump into microservices bandwagon blindly. There are some key factors that need to be evaluated/considered before choosing them as your architecture.

Key factors to consider when choosing microservices

Before you decide whether to write applications as microservices, you must understand the following factors to ensure that your organization is prepared to handle them:

New patterns of technology. Microservices are a radically different approach to building applications. Because they are on the network, they require a whole new set of components on the network alongside them. The enabling technologies exist, including service discovery, workload orchestration, container management, and logging frameworks. However, you must pull them into one coherent set, which takes significant experimentation, skill, and learning. You must determine what constitutes the perfect setup for microservices for your requirements, which might be different than those of other enterprises.

Application suitability. Microservices aren't right for every application. One paradox in the microservices community at the moment is that you do not gain any advantage by wading in the murky waters of microservices for a new, relatively straightforward application, with a highly cohesive data model. Also, it is a huge undertaking to refactor a complex existing application into a microservices architecture.If not on old or new applications, when would you use microservices? One recommendation is not to use microservices until the evolution of a traditionally written application starts to reach an inflexion point of complexity. However, for this approach to work, you need to write a suitably structured application from the beginning and choose the right moment to make the transition.

Different design paradigms. The microservices application architecture requires different approaches to design. To get the best results from the microservices approach, you might need to:

• Accept eventual consistency models, rather than the transactional interactions that you are used to.
• Understand how to work with event-sourced applications with no central operational data store.

You also need to:

• Ensure that your application logic is state free if it needs to take advantage of the significant rapid scalability benefits.
• Become familiar with the subtle potential side effects of asynchronous communication if you decouple yourself from downstream components.
• Understand the logic implications of implementing circuit breaker patterns.
• Recognize the error handling limitations of HTTP/JSON communication compared to in-process communication.
• Consider network latency in chained interactions.

DevOps maturity. Microservices require a mature delivery capability. Continuous integration, deployment, and fully automated tests are a must. The developers who write code must be responsible for it in production. Build and deployment chains need significant changes to provide the right separation of concerns for a microservices environment.

If you're comfortable with these factors, you might be in a position to realize big benefits from a microservices application architecture.

I've executed a carefully planned and integrated ERP, BI and external application data with event sourcing and built a set of microservices that would have costed a fortune, if not executed that way.

I hope I've not lost you with information, the next chapter I'll describe, how you can integrate and orchestrate SOA and microservices in Chapter 4: How microservices fit within the SOA picture and the integration challenge