Microservices Architecture

Microservices Architecture has captured the imagination of the software industry.

Unless you’ve been living under a rock, you must have definitely heard or read about microservices. All the way from being hailed as the second-coming of Christ to being suspected by all and sundry, the reaction to microservices architecture has been everything but consistent.

But why is the response to microservices architecture so polarized?

Is microservices just a buzz word?

Are building microservices extremely tough?

These are questions worth examining for any software developer or architects out there.

In fact, these are some of the most important questions worth examining right now.

The answer to these questions may define the success and failure of your organization in the coming decade.

But let’s not get ahead of ourselves. Let’s start from the beginning.

What are microservices?

Microservices is an architectural style.

To elaborate, it is an architectural style that promotes the building of an application as a group of services.

And that’s basically it. Nothing more. Nothing less.

Immediately, I can sense a question creeping up because of this apparently simplistic definition.

What’s the difference between microservices and SOA?

Well, here’s the thing. Microservices is related to SOA. We can consider Microservices architecture as a variant of Service Oriented Architecture or SOA.

However, there are some defining microservices features that make them different to SOA.

So what are those defining microservices features?

• Microservices are loosely coupled. Just like SOA.
• Microservices are highly testable and maintainble. Just like SOA.

Oops! I think I missed the ball over there. Let’s try again with some more features of microservices.

• In microservices architecture, each service can be deployed individually and independently. Not like SOA.
• Microservices are fine-grained. In other words, they are organized around business capabilities. Pretty different from SOA.
• Microservices should talk to each other by means of faster messaging mechanisms. A solid difference from SOA that relies on ESB.
• Lastly, microservices architecture can support polyglot programming. In other words, you can use different technologies for difference microservices. Quite different to SOA.

If you have been hearing around, often you might come across SOA vs Microservices debates. Some of those discussions are exaggerated.

In my opinion, there is no microservices architecture vs SOA battle going on in the industry. Service Oriented Architecture solves and is still solving certain needs for building enterprise application. And it has been pretty successful in doing that over the years.

Microservices are a specialization of Service Oriented Architecture. They help in designing flexible and independently deployable software.

In other words, microservices architecture is definitely not an enemy of SOA. In fact, both can co-exist.

Why should we care about Microservices Architecture?

At this point, you might be thinking that microservices are nice and all. But they don’t sound so radical, after all.

And that’s exactly the point!

Most of the time, the negative reaction to microservices stems from the fact that it all sounds so drastically different. On the contrary, the reality is quite opposite. On a conceptual level, microservices are not so difficult to understand.

Often, it is the fear and uncertainty coupled with the not-invented-here syndrome that gives microservices a bad name in organizations.

There are arguments that only large tech companies (with deep pockets) can benefit from microservices. Other time, it is thought that you need an extremely cutting-edge technology stack to build a microservices application.

While some of it might be true to some extent, a shift to microservices is more about mindset change as compared to technology change. And we will come back to this in detail later.

But the question still stands.

Should we care about microservices?

And my answer is that yes, we should.

Some Facts about Microservices Architecture

1. Netflix receives almost a billion API calls every day from more than 800 different types of devices. Each API call might lead to 3-5 additional calls. The complexity of managing all this prompted Netflix to move to a microservices architecture.
2. Amazon, the largest e-commerce platform in the world, has migrated from monolithic to microservices. They get billions of calls from a plethora of applications. It would have been impossible to manage the same using a typical 2-tier architecture.
3. Uber, the giant cab-aggregator service, has embraced microservices architecture. With 500+ functionalities, managing them and releasing continuous updates could not have been possible with traditional monolithic applications.

Those are some pretty big players using microservices. And there are many more organizations moving in that direction. The reason is simple. A large part of the success Netflix, Uber and Amazon have seen relates to their microservices architecture.

Microservices, APIs and Containers

There are some terms that get mixed up quite often. Some examples are Microservices, APIs and Containers.

On a high-level below are what each of these terms mean:

APIs stands for Application Programming Interface.

Microservices is an architectural style of building applications. Typically, a microservice is a place where your APIs live. But exposing APIs are not the only reason for building microservices.

A Container is a house for a microservice. Containers are like run-time environments for our microservices. In a typical microservices architecture, containers are deployed on cloud platforms.

As you can see, APIs, Microservices and Containers relate to each other. But they are not the same.

However, demystifying API, Microservices and Containers is extremely important to make appropriate use of these concepts while building microservices.

Monolithic to Microservices Architecture

Microservices architecture is usually touted as the replacement for monolithic architecture. This is largely because microservices try to solve the problems that occur because of monolithic approach.

To understand what microservices architecture brings to the table, we need to also understand what is monolithic architecture.

Let’s begin by looking at simple example.

Monolithic Approach

In a typical application (example, an e-Commerce site), there would be a Presentation Layer. This Presentation Layer is a user-interface that handles the allows users to interact with the e-Commerce store.

Then, there would be an Application Layer where all the business logic is written. Lastly, there would be a Database Layer that will take care of all the heavy-lifting with regards to persistence.

The entire application is then packaged as a WAR and deployed on an application server such as Tomcat, JBOSS. Since the entire application is packaged together, it acts as a monolithic application. Even though there are separate components in such an application, they are not independent of each other.

The below diagram shows an illustration of the monolithic approach of building applications.

Flaws of the Monolithic Approach

• As more features add up in your application, the code base increases. This can overload your development and run-time environment. This is usually bad news for developers. Developers now need to wait longer for their changes to be deployed.
• If any one component of the application fails for some reason, the entire application goes down, effectively bringing down the entire functionality.
• Since the application is packaged as a WAR, it is not possible to change the technology stack of one component. Also, refactoring the code base is hard because its tough to predict the ripple effect of changes on one part of the application on another part.
• Scaling a monolithic application for increased demand is not easy. This is because the entire application is packaged as a single WAR. Due to this, scaling such an application can be accomplished only by deploying the same WAR into additional servers.
• In the monolithic approach, developers cannot work independently on different components. Also, testing efforts increase with every new feature. Because every time there’s a change, the risk of breaking something unrelated increases.

Microservice Approach

The above mentioned problems with monolithic approach has led to the increased popularity of microservices approach.

The major factor behind microservices architecture is scalability.

While horizontal scaling was possible even with monolithic approach especially by adding more servers, microservices architecture allows functional scalability. This approach is known as functional decomposition.

Functional decomposition advocates deploying various functions of an application independently. Instead of deploying the entire application together, respective services can be deployed separately. This brings about increased flexibility and agility for development teams.

Below is how a microservices approach can look like.

It is not straightforward to implement microservices architecture if your application is monolithic. There are several strategies for moving from monolithic architecture to microservices architecture. However, there are no easy routes.

Pros and Cons of Microservices Architecture

As with everything in life, there are pros and cons of microservices architecture.

Let’s start with the pros:

• With microservices architecture, stability increases. This is due to functional decomposition. With this approach, each component of the application can scale up or down independently of the other.
• Faults can be isolated. A single component being down cannot bring down the entire application.
• There is no vendor or technology lock-in. You can potentially select a different technology stack for different microservices. Although I would suggest evaluating this approach on its own merit.
• Applications are easy to understand. This is because there are smaller components in microservices architecture. Therefore, it is also easier for developers to make changes.

Microservices architecture is not a silver bullet. It has its own disadvantages and it is important to understand them if you wish to build good microservices.

• The task of building distributed systems is inherently complex. Since everything is independent, developers need to carefully handle requests between individual components. There might be complications due to latency or disruption due to network instability.
• In microservices architecture, there are multiple databases. Due to this, transaction management can be painful.
• Testing a distributed application can be challenging. This is because each dependent service needs to be setup before testing can start.

Learn Microservices Architecture

Whether you or me like it or not, microservices architecture is here to stay. It definitely makes sense to learn more about microservices.

At Progressive Coder, my goal is to help you Learn Microservices Architecture

And how do we approach this task?

In my view, to learn microservices architecture, one needs to follow a two-pronged strategy.

Firstly, you should focus on microservices design patterns. There is a lot to a successful microservices architecture than simply creating some stand-alone applications. However, learning microservices patterns can open your eyes about the various tried-and-tested patterns used across the industry. In other words, knowledge of the microservices design patterns will let you make the correct design decisions for your microservices architecture.

The second important aspect to learn microservices architecture is to learn microservices frameworks. Frameworks make life easy for developers by taking care of most of the heavy-lifting. In other words, as a developer, you can focus on writing your business logic.

At Progressive Coder, we focus on both aspects of learning microservices architecture.

Let’s look at both of them in detail.

Microservices Design Patterns

I can’t stress this enough. Design Patterns are an extremely important aspect of successful microservices architecture.

But what exactly are design patterns?

Think of design patterns as the tried-and-tested ways of doing any particular task. Each of these ways has some pros and cons.

However, design patterns are not like off-the-shelf libraries or set of functions. You can’t just copy code from somewhere and plop it into your program. Design Patterns are general concepts that can be applied to solve a specific problem. You can follow a particular pattern and implement a solution according to your exact problem.

As a developer, you need to be aware of a pattern’s advantages and disadvantages and use the correct approach to solve a particular problem.

With microservices architecture, design patterns become extremely important. As a developer, you don’t want to re-invent the wheel.

Instead, you want to tap into the power of ready-made microservices design patterns.

There is a plethora of design patterns applicable to the world of microservices. Each of these patterns target a specific aspect of microservices architecture.

Microservices Data Management Patterns

Data plays a key role in most enterprise applications. In a microservices architecture, it becomes even more important due to the distributed nature of microservices.

As a developer, you can tap into several patterns for microservices data management.

• Database-per-service
• Shared Database across services
• API Composition
• Command Query Responsibility Segregation or CQRS
• Event Sourcing
• Saga for Distributed Transactions

Microservices Deployment Patterns

Microservice deployment patterns deal with areas pertaining to the deployment of microservices. Based on the problem statement, there are many options available to a developer with regards to deploying microservices:

• Multiple service instances per Host
• Service instance per Virtual Machine
• Service instance per Container
• Platform-as-a-Service Solution
• Service instance per Host

Microservices Communication Patterns

In a typical microservices architecture, different services need to talk to each other. In other words, they should be able to communicate with each other to handle a business process. Since it is such an important facet of microservices architecture, there are some important patterns that can be used by developers based on specific use-case:

• Remote Procedure Invocation using REST, gRPC and so on.
• Messaging Patterns
• Domain Specific Patterns such as SMTP

Service Discovery in Microservices Architecture

In a typical microservices architecture, services can be deployed or removed based on demand. In other words, service discovery becomes an important requirement. Basically, it is imperative that microservices know about each other so that they can communicate whenever required. There are some service discovery patterns used to solve such challenges:

• Client-side discovery
• Server-side discovery
• Self-registering services
• Service Registry

Microservices Observability

Microservices need to observed and managed. In case of failures, quick action is required because an issue with one microservice can propagate to other microservices pretty fast. In such cases, strategies surrounding microservices observability should be used:

• Aggregating Logs
• Application Metrics
• Audit Logging
• Distributed Tracing
• Health Check

Microservices Frameworks

As we discussed earlier, frameworks make life easy for a developer. Frameworks allow a developer to focus on writing business-specific code rather than worrying about the intricacies of managing the application’s run-time.

For example, while dealing with microservices architecture, you want one microservice to communicate with another micorservice through some messaging system. Naturally, you don’t want to write and manage the code to connect these microservices to the messaging infrastructure (such as RabbitMQ or Kafka). A framework such as Spring Cloud can help you do it without writing and managing a ton of code.

Another example could be that you wish to implement automatic service discovery in your microservices-based application. You can use something like Netflix Eureka to handle service-discovery and registration without writing any complex code to check the network and find services.

Basically, the goal of microservices frameworks is to make it easy to build microservices architecture. The more you know about these microservices frameworks, the better will be your ability to solve the challenges of microservices architecture.

There are many frameworks available that help in building and managing microservices architecture. Some of the more popular ones are as follows:

• Spring Boot Microservices
• Axon 4.0 (Axon Server and Axon Framework)
• Spring Cloud Microservices

Conclusion

Microservices architecture is definitely going to get more popular over time. As technology becomes a business driver, architecture of an organization’s applications can act as the differentiating factor.

An agile, fault-tolerant architecture is important. And microservices architecture certainly fits the bill in this regard.

Organizations today need to make the decision. To embrace microservices architecture and handle it challenges. Or run the risk of falling behind.

As developers, we are the advocates of an architectural style. And to help organizations make the right decision, we need to learn microservices architecture. We need to understand the ins and outs of microservices to help organizations make better decisions.