Build highly available, scalable, and performant applications by following this complete guide to building microservices in Azure, AWS, and Google Cloud.

In 2005, Dr. Peter Rodgers addressed micro web services during a presentation at a Web Services Edge conference, where the first generation of micro web services was based on service-oriented architecture (SOA). SOA is a “self-contained” software module that performs as a task, and this allows the service to communicate based on SOAP (Simple Object Access Protocol). The main SOAP idea is, “Do the simplest thing possible.”

Nowadays, there is no option to avoid talking about microservices during architectural calls, especially if you want to design cloud or multi-cloud, modular, scalable, and multi-user applications. In this article, I will explain microservices and how to design applications based on the multi-cloud scenario. I will walk you through the microservice design pattern and wrap this information into an architectural example.

This is an article from DZone’s 2022 Microservices and Containerization Trend Report. For more: Read the Report

Microservices and Multi-Cloud Environments

Before we jump into microservices architecture, patterns, and how you can build microservices-based applications that support multi-cloud deployment, let’s define the terms. A microservice is an architectural pattern that allows applications to consist of loosely coupled modules. However, microservices designs should follow these rules:

Each module or microservice has its own data and therefore should have an
independent database.

Each microservice should be developed by its own team. This doesn’t mean that
microservices-based applications can’t be developed by one team, however, having
one team per microservice shows how independent microservices can be.

Microservices should have an independent deployment process.

Microservices should give better control over resources and compute power so you
can scale each service independently and according to the service needs.

Microservices can be written in different languages, but they should communicate
with a single protocol like REST.

Multi-cloud (i.e., hybrid cloud) means there are two different approaches to spreading an app through multiple cloud providers. For example, we can build core applications in AWS, and there are some parts that we can deploy to Azure and Google Cloud. Another multi-cloud example is when an app that was designed for one cloud can be migrated to another with minor changes.

Microservices vs. Monolith

Before we jump into examples, let’s look at a brief list of the pros and cons of microservices and monolithic architecture:

Pros: Micoservices

Scalability — As we have all separate services, we can scale each service independently.

Isolation — A large project may be unaffected when one service goes down.

Flexibility — You can use different languages and technology as all services are independent.
We can separate the whole project into microservices where each microservice will be developed and supported by a separate team.

DevOps independence — All microservices are independent; therefore, we can implement an independent deployment process for each microservice.

Cons:

Complexity — Microservices architecture can be a good choice for huge, enterprise-level companies and platforms. Take Netflix, for example. There you can separate domains and subdomains to different services and teams. However, for a small-level company, separating may add redundant complexity. Moreover, it can be impossible to separate small projects into microservices.

Testing — Testing microservices applications can be a difficult task as you may need to have


Debugging — Debugging microservices can be a painful task; it may include running several microservices. Also, we need to constantly investigate logs. This issue can be partially resolved by integrating a monitoring platform.

When I start designing a solution, I always use monolithic architecture as the starting point. Using this approach, we can achieve the following:

During design and implementation, we can already see if our application can be moved to microservices.

We can identify monolithic applications that can be moved to microservices using a step-by-step approach.

Pros: Monolith

Simplicity — Monolithic architecture is relatively simple and can be used as a base architecture or the first microservice step.

Simple DevOps — The DevOps process can be simple as we may need to automate one simple application.

Cons:

Vendor lock-in — With monolithic architecture, we may be locked with one vendor/ cloud provider. All modules in monolithic architecture are closely tied to each other. It’s hard to spread them across different vendors.

Inflexible DevOps — The DevOps process for one enterprise-level, monolithic app can take a lot of time as we need to wait until all modules are built and tested.

Stick with one programming language/technology — Monolithic architecture is not too flexible, you need to stick with one technology/programming language. Otherwise, you must rewrite the whole application to change the core technology.

Figure 1: Travel booking application

The system consists of several modules:

UI/front end

API

SQL adapter

Stripe adapter to process payments

SendGrid to manage emails

Adapter for Twillio to be able to communicate over the phone (calls, SMS, video)

This monolithic architecture can be migrated to the microservices one. Each service can operate independently and can keep the state in its own database.

The solution explained above is quite simple and can be transformed into microservices without a lot of issues. However, when it comes to the enterprise level, this migration is far more complex, as is seen at large companies such as Netflix.