Data and Devops practices and tools: Microservice Architecture (Examples and Diagram)

A graph depicting examples of microservice architecture

Introduction

It certainly makes sense to evaluate the “Microservice Architecture” with examples and diagrams since it has become an important pattern.

You must consider application architecture when designing your application. Why should you do so? Well, over the years, many different software development paradigms have come and gone. A constant theme, however, has been the need to componentize software systems in a modular way.

You gain many benefits if you modularize software systems. You will find it easier to understand and follow the source code, and programmers can easily visualize the codebase. Modularizing also helps developers to know where they should look for defects. As a result, you can maintain your software with relative ease.

If you architect software systems well, then they scale better. This helps immensely when you have more users for your application.

You can also manage your development process better if you architect the software well. New developers can easily learn such a system, therefore, they become productive quickly. A well-architected software also follows the application coding standards. This further improves your productivity.

There are many approaches to architecting software projects such as N-Tiered, Service Oriented Architecture (SOA) or Microservice Architecture to name a few. In this post, however, aimed at software developers, development managers and CTO’s we specifically look at Microservice Architecture and cover the following topics:

By the time you’ve read this blog post you’ll have a solid understanding of what microservice architecture is, its benefits, if you should consider it and how to go about structuring an application to adopt this architectural paradigm, so let’s get started!

What is Microservice Architecture?

In the past decades, applications have been developed in a monolith fashion, coded from top to bottom as one single unit, sometimes with no real structure or thought for future maintenance which can cause a range of problems. Poorly architected software solutions can also be problematic to debug or extend with new features and in general, aren’t very nice to work on.

Microservice architecture is a form of service-oriented architecture (SOA) whereby software applications are built as a collection of loosely coupled services, as opposed to one monolithic software application. Each microservice can be created independently from the other, or even in a completely different programming language and run on their own.

At the core of it all, each microservice tries to satisfy the specific user story or business requirement that you’re working on. It is an ideal architectural design pattern in today’s ever increasing interconnected world and helps support multiple platforms and devices that can span the cloud, mobile, Internet of Things (IoT) and even wearable devices.

A popular way to implement microservices is to use protocols such as HTTP/REST alongside JSON, as an architectural design pattern, we’re seeing a lot of the main SaaS providers adopt microservices into their solutions and services.

From Microsoft to IBM and much more, software vendors and service providers are implementing the microservice architecture. Major players like Twitter, Netflix, eBay, and Amazon have also favored microservice architecture as it helps with the development, scalability and continuous delivery of their services. This brings us to some of the benefits of microservices architecture.

Benefits of Microservice Architecture

As an architectural practice, microservice architecture has been growing in popularity in recent years, this is down the benefits that it can bring software development teams and the enterprise. As software increased in complexity, being able to componentize functional areas in the application into sets of independent (micro) services can yield many benefits, which include, but are not limited to the following:

More efficient debugging – no more jumping through multiple layers of an application, in essence, better fault isolation
Accelerated software delivery – multiple programming languages can be used thereby giving you access to a wider developer talent pool
Easier to understand the codebase – increased productivity as each service represents a single functional area or business use case
Scalability – componentized microservices naturally lend themselves to being integrated with other applications or services via industry-standard interfaces such as REST.
Fault tolerance – reduced downtime due to more resilient services
Reusability – as microservice are organized around business cases and not a particular project, due to their implementation, they can be reused and easily slotted into other projects or services, thereby reducing costs.
Deployment – as everything is encapsulated into separate microservices, you only need to deploy the services that you’ve changed and not the entire application. A key tenet of microservice development is ensuring that each service is loosely coupled with existing services.

But don’t just take our word for it, here are some real-world examples of microservices in action how this architectural design pattern as benefited Walmart and Amazon.

Microservice Architecture in Action in the Real World

Here we explore how adopting microservice as a software architecture could add real business value and bring a whole range of benefits for Amazon and Walmart.

MICROSERVICES RESCUE WALMART’S AGING SOFTWARE ARCHITECTURE

The Canadian arm of retail giant Walmart has serious issues with their existing software architecture, especially around Black Friday – for two consecutive years. At its peak, the Walmart site couldn’t handle 6 million page views per minute and ultimately made it practically impossible for visitors to have any positive sort of user experience.

Part of the problem was that Walmart’s software architecture was design for the internet of 2005 which was centered around desktops and laptops. The use of mobile, smart and IoT devices hadn’t fully peaked back then. The firm decided to re-platform its legacy system in 2012 using microservices and have set a target that by 2020 to be able to service 4 billion connections!

By migrating to a microservices architecture, Walmart identified that:

Mobile orders increased by 98% –
Zero downtime on Black Friday and Boxing Day (Canadas Black Friday)
Conversions increased by 20%

AMAZON

Amazon the retail and now logistics giant is no stranger to delivering software at scale. Rob Birgham, senior AWS Product Manager shared a story of how microservice architecture was used in conjunction with DevOps.

Back in the early 2000’s Amazon’s site was developed as one, big, monoliths solution and to be fair, a lot of business started out that way. Over time, however, as functional areas were built, from multiple teams of developers or bugs were fixed, not to mention, as the platform grew, the job of integrating all this work started to impact on overall productivity.

Days or sometimes whole weeks were dedicated to merging developer changes into a master version of the product, merge conflicts had to be resolved which again, all had an impact on productivity.

Realising quickly that operating like this wasn’t sustainable, Amazon took the decision to decouple their monolith codebase by adopting a microservice architecture. Each service was responsible for a single purpose as was accessible through web service APIs.

Once this exercise was complete, this paved the way for Amazon to create a highly decouple architecture where each service could operate independently – providing each developer adhered to the respective web service interface definitions.

NETFLIX

Netflix uses the Microservice architecture pattern to great effects. The company had a monolithic architecture and its datacentre aligned with it.

In 2008, Netflix was still using its monolithic architecture. A program had a missing semicolon, and the effect of that was substantial. This single bug brought down the Netflix website, and it took several hours to recover from it.

That’s not surprising given the monolithic architecture has various components coupled together tightly. One error in one component can significantly impact the entire software. Naturally, Netflix needed its engineers from all areas to take part in troubleshooting when something went wrong.

Around the same time, Netflix noticed how they were finding it hard to scale. The popularity of Netflix was growing, however, the company wasn’t able to build data centers fast enough. This limitation had started to hamper its growth.

Netflix started to transition from its monolithic architecture in 2009. We in the development community weren’t even using the term “microservice” at that time, however, Netflix took the plunge!

The company began its transition to AWS cloud-based microservice architecture. In the beginning, Netflix moved an application that wasn’t a customer-facing one. This was a smart decision since the company needed to contain the impacts if anything was to go wrong with the move. The first to move was the movie encoding application, and the move was successful.

Subsequently, Netflix started to move various customer-facing functions to AWS. This included its functions like account sign-up, movie selections, TV selections, etc. The company achieved success with these too.

Netflix completed its move to the microservice architecture by December 2011. With this move, Netflix now had hundreds of microservices instead of a giant monolith application that they had earlier.

As of December 2015, the Netflix microservice architecture featured an API gateway that handled 2 billion API requests daily. You can read about this transition in “Why you can’t talk about microservices without mentioning Netflix”.

Challenges of Microservice Architecture

As with every new software programming architecture, each has the list of pros and cons, it’s not always peaches and cream and microservices aren’t an exception to this rule and it’s worth pointing some of these out.

Too many coding languages – yes, we listed this as a benefit, but it can also be a double-edged sword. Too many alternative languages, in the end, could make your solution unwieldy and potentially difficult to maintain.
Integration – you need to make a conscious effort to ensure your services as are loosely couple as they possibly can be, otherwise, if you don’t, you’ll make a change to one service which has a ripple effect with additional services thereby making service integration difficult and time-consuming.
Integration test – testing one monolithic system can be simpler as everything is in “one solution”, whereas a solution based on microservices architecture may have components that live on other systems and/or environments thereby making it harder to configure and “end to end” test environment.
Communication – microservices naturally need to interact with other services, each service will depend on a specific set of inputs and return specific outputs, these communication channel’s need to be defined into specific interfaces and shared with your team. Failures between microservices can occur when interface definitions haven’t been adhered to which can result in lost time.

So now that we’ve talked about what microservice architecture is, what some of its benefits are and look at a few examples of microservice architecture in the real-world as well as the benefits of this paradigm, you might be wondering if microservices architecture is for you or your software project and it’s a valid question to ask.

Should You Adopt Microservice Architecture?

You don’t want to implement a microservice architecture in your project just for the sake of it, so we’ve put together some points to consider that will help you decide if that’s architectural pattern is right for you or your project.

If you answer yes to any of these questions, then you might want to consider implementing a microservice bases architecture:

Is your current application monolith and difficult to maintain?
Do you anticipate that your application will have to deal with high volumes of traffic?
Is modularisation and code reusability the main priority?
Does your application need to be accessed on multiple device types such as mobile, IoT and web?
Do specific areas your application need to be able to scale -on demand?
Are you looking to improve your software products build and release process?

If you answer yes to most of these, however, you can probably get away with a traditional monolithic application architecture:

Do just need to ship and MVP, to test the market?
Do already have a stable product/team that will continue to work on the product until you retire it?
Is your product “in the wild”, generating revenue and the user community is happy? If so, no sense in reinventing the wheel

Sample Microservice Architecture

Now that we’ve introduced the microservice architecture, discussed some of the benefits, respective challenges and looked a few examples of how microservices have been deployed in the real world, it’s time to look at a basic microservice in terms of its architecture and how it can be designed. In the image above, you can see the following 3 microservices:

Account Service
Inventory Service
Shipping Service

As this microservices architecture diagram shows, each microservice is accessed in one of two ways in this fictitious application:

From an API gateway (via a mobile app)
From a Web application (via the user’s web browser)

Note: There could be theoretically may be more as the architecture lends itself to that.

You can see that each microservice also exposes a dedicated REST API, this is the interface which defines the operations that can be executed against the respective microservices and will detail the data structures, data types, or POCOSs that can be passed into the microservice as well as its return types. For example, the Inventory service REST API definition may contain an endpoint called GetAllProducts which allows consumers of the microservice to fetch all products in the e-commerce store, this could return a list of Product objects is JSON, XML or even C# POCO.

As each microservice has its own set of responsibilities and can only ever interact with its respective database, a solution architected like this makes it easier for more than one developer to make changes to the system. By implementing a microservice like the one we’ve just detailed, you will gain some of the benefits that we outlined earlier. As you roll out an architecture using this approach, it’s important to ensure that each microservices architecture example can operate completely independently, otherwise, it defeats the purpose of pursuing this architectural approach.

Best practices you should consider when implementing the microservice architecture

How would you implement the microservice architecture effectively? I recommend that you seriously consider the following best practices:

Determine if this architecture pattern works for you.
Define your microservices carefully.
When you design your microservices, use “Domain-Driven Design” (DDD).
Get buy-in from the senior leadership in your organization since a transition to the microservice architecture can be hard.
Use RESTful APIs since they can help you to implement this architecture pattern. Remember to design your APIs based on their domain, and document the APIs well.
Organize your team around your microservices.
Plan for separate data storage for each microservice.
Invest in high-quality DevOps and application monitoring solutions.

Wondering how you can learn more about these best practices? Our guide “10 best practices for building a microservice architecture” is just what you need!

Summary

So, there you have it, an overview of Microservices architecture. In this blog post, we’ve looked at microservices architecture, we covered the key concepts, the benefits this architectural design pattern can bring to the enterprise and how it can help software development professionals better structure their products.

We’ve also outlined the main components of an application that adopts a microservice architectural pattern and give you some ideas as to why you might want to introduce microservices to your project. In case you do, it’s best to hire expert developers capable of building an exceptional product. Feel free to comment or share this article with your friends or colleagues, or if you have a comment then leave one below!

Data and Devops practices and tools

Saturday, June 20, 2020

Microservice Architecture (Examples and Diagram)