What is Microservices Architecture?

Microservices are an increasingly popular approach to building cloud-native applications. We hear about them from social media, conferences, webinars, books, framework vendors, and colleagues. It seems like they are the only way to move forward.

But are they? To answer this question, we first need to explore why microservices are so useful, what their downsides are, and what the alternatives are.

Contents

• What is a Microservice architecture?
• What’s the difference between monoliths, microservices, and SOA?
• What are advantages and disadvantages of the Microservices?
• How big is a microservice?
• What are Examples of Microservices?
• Are microservices right for your application?

What is a Microservice architecture?

Microservice architecture, or microservices, is a distinct method of developing software systems that have grown in popularity in recent years.

In short, a microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, such as HTTP API. These services are built around business capabilities and are independently deployable by fully automated deployment machinery. There is minimal centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Servers

Web application features are usually contained in a single codebase. In a microservice architecture, the codebase is split into individual components called microservices. Every microservice encapsulates a specific business function, such as user management, user roles, an e-commerce cart, search engine, or social media logins. When you separate each business need into a microservice, issues that arise in one area of the application will not affect the system as a whole.

Communication

Each microservice communicates with other services through HTTP connections. Using HTTP allows developers to deploy microservices using their existing toolset. In addition, they can easily connect to and wrap 3rd-party APIs.

But there is a communication challenge when using a microservice architecture. Microservices have to find and communicate with other microservices that comprise your application when, at scale, there may be many instances of each microservice. To solve this, microservices need to announce that they exist and then find the required microservices. This challenge is called “service discovery.”

Data Persistence

A microservice architecture works best when each microservice is stateless. This means that each request to a microservice is completely independent of the requests that came before it. It allows for the greatest flexibility when it comes time to scale. Furthermore, each microservice maintains its own data. This eliminates the database as a “single point of failure.”

The above diagram illustrates a general architecture of a microservice application. Each service has its own database and does not connect directly to the database of other services.

Web and mobile applications communicate with these services through an API gateway. An API gateway can be a proxy but can also act as a data transformer, serving the relevant data to the right page. By loading product info into a mobile application, the number of fields may be reduced, which saves bandwidth. Ideally, an integration engineer should take ownership of the API gateway.

The API gateway is as important as any other microservice. In fact, much more important is the only bottleneck of your application, and a failure in the API gateway can bring down the entire application. Hence, it should be as robust as possible.

The event queue acts as a transport layer for communication between microservices.

What’s the difference between monoliths, microservices and SOA?

There is a good chance you have heard the terms monoliths, microservices, and SOA. But what do they really mean?

Monolithic architecture runs on a single application layer that joins all architecture functionalities. This architecture form doesn’t involve as many actors as other architectural styles. To build a web architecture using a monolithic approach, you would start developing its front-end and enable its access to data.

Let’s imagine that you are building a new taxi application to compete with Uber and Ola. You would create a new project manually or by using a generator that comes with Rails, Spring Boot, Play, or Maven. This new application would have a modular architecture, shown in the following diagram:

Unlike monoliths, microservice architectures consist of independent services with a nothing-shared architecture.

SOAs, Service-Oriented Architectures, usually incorporate functions into small and mid-sized applications. They try to keep the complexity of each app or functionality very low and make them communicate over a set of APIs. The services do many things that are limited to the scope of a single functionality.

SOAs usually provide good flexibility but come at a cost. Even though each piece evolves independently and does not impact the others and it is simple, the architecture itself becomes more complex.

Isn’t microservice another name for SOA? SOA is a broader framework and can mean a wide variety of things. Some reject the SOA tag altogether, while others consider microservices to be a refined form of SOA. In any case, the differences are clear enough to justify a distinct “microservice” concept.

The SOA model has more dependent ESBs, with microservices using faster messaging mechanisms. SOA focuses on imperative programming, whereas microservice architecture focuses on responsive-actor programming. Moreover, SOA models tend to have an outsized relational database, while microservices use NoSQL or micro-SQL databases. But the real difference has to do with the architecture methods used to arrive at an integrated set of services in the first place.

Let’s look at an online shopping site. This site would have a handful of different features: a product catalogue, user accounts, and shopping carts to name a few.

A development organization using SOA would split the shopping site into major sets of business logic, then each set will be developed as a separate application to be integrated.

An organization using microservices would break up the shopping cart into smaller task-oriented services. Instead of a shopping cart application, there might be tax calculation, add and remove an item, shipping, billing, and order services.

To save you some clicks, we will explain the difference between monoliths, microservices, and SOA using one picture that represents them as food.

What are advantages and disadvantages of the Microservices?

Benefits of Microservices architecture

Independent scalability

Each module, being in different server nodes, can scale horizontally at a rate independent of other modules. This will be difficult to achieve with a single, large monolithic service.

Independent tech stack

Microservice architecture can be used with different programming languages, communication, monitoring, or data persistence tools. This is great for choosing a tool for the job at hand and innovates by being early adopters of new technologies.

Preserve modularity

Keeping modularity and encapsulation IS possible in both monoliths and microservices. Even so, it can be quite difficult, and we have been trying to do it for decades and despite SOLID rules. The physical partition of the application enforces a logical partition in separate servers/nodes. This physical isolation makes it unnatural to cross the bounded context boundaries.

Independent evolution of sub-systems

We can leave older versions of the microservice running if needed, so a microservice can evolve and break backward compatibility. But, it does not get cluttered with code to support older versions.

Business-focused and team-owned

Microservice architecture is not a technical choice. It should align with and facilitate the goals of your organization. Your customer-facing website is quite different from your payment provider interface. It has a different audience, metrics, testing strategies, and timelines. A microservice architecture allows these functions to evolve in parallel with a minimal amount of developer coordination and planning. Here’s a diagrammatic representation for quick understanding:

Re-usability of services

Microservices are organized around business capabilities, not a specific project or product requirement. This enables technology teams to reuse services and reduce costs.

Decentralized data management

Large-scale and complex enterprise applications are three-tier. Microservices let each service manage its own database, different database instances or systems. This approach is called Polyglot Persistence. Here is a diagrammatic representation for better understanding:

Easy to deploy

While technology teams have to deploy an entire application again because of a small change in the code, with microservices this deployment becomes easy. The scope of deployment is smaller and only the service that has a problem needs to be redeployed.

Better fault isolation

Failure in one service does not impact other services. If you have monolithic service errors in a module, it can impact other modules and functionalities as well.

Easy to enhance

Less dependencies make microservices easy to change and test.

Increased availability and resilience

Microservices improve fault isolation. Complex applications are broken into separate service components and deployed on multiple servers. The failure of one service or module will not impact the entire application. A single service fault can be replaced with another service, increasing the application’s availability.

Easy to understand even in a distributed environment

Understanding how an application is developed is important when there is a change in development teams. In a distributed development project, microservice architecture helps development teams understand the entire functionality.

Microservices Disadvantages

Less stable

An individual microservice may be well-tested, but in conjunction with some common microservices and programs, it is hard to test every configuration. As you combine them, they may interact in unforeseen ways.

Less secure

It is not always easy to tell where microservices reside, which can make securing them a headache. This also provides more opportunities to penetrate the system. Savvy DevOps teams are moving to a more granular security policy called micro-segmentation to get around this problem, but the solution isn’t universal yet.

Difficult to make the transition

It will take time and discipline to replace monolith with a microservices architecture, but many companies have accomplished this and found the investment worthwhile.

Complexities of monitoring

While the system as a whole may live for a long time, its components—the containers—do not. They live and die quickly.

This situation presents new challenges to many areas of software engineering. One of them is monitoring. How can an operator make sure that a system remains healthy if existing monitoring tools are unable to function in this new reality?

To solve this challenge, VironIT developed Environment Overseer, a service for real-time monitoring environments. This is built on the principle of microservice architecture. Service finds the root cause of the microservice architecture problem and allows it to be solved as soon as possible.

How big is a microservice?

“Microservice” has become a popular name for this architectural style, but this name does lead to an unfortunate focus on the size of the service and arguments about what constitutes “micro.” A common question people ask is, “How big or small should my microservice be?” One common answer is that the size of a microservice is variable, but it should be coded by no more than a dozen people.

The largest sizes are reported following Amazon’s notion of the Two Pizza Team. This means that the entire team can be fed by two pizzas.

On the smaller size scale, a team of six would support about six services. In general, the team size, including Dev, QA, and Product for a Microservice should be seven members at most.

What are Examples of Microservices?

Large-scale companies like Netflix, eBay, Amazon, the UK Government Digital Service, realestate.com.au, Twitter, PayPal, Bluemix, and The Guardian have migrated from monolithic to microservices architecture. Let’s look at some of the success stories to see the results.

Netflix has a widespread microservice architecture. It receives more than one billion calls every day from 800 different devices to its streaming-video API. Each API call then prompts around five additional calls to the backend service.

 Another example is Amazon, for instance. All we can see is the website. Amazon made a change from the Obidos monolithic to a microservice with encapsulated databases and “two-pizza” teams. Its microservices receive countless calls from a variety of applications. Amazon has never used the term “microservices.” Those in the microservices movement draw a lot of inspiration from Amazon’s experience.

The auction site eBay is yet another example that has gone through the same transition. Its core application comprises several autonomous applications. Each one executes the business logic for different functional areas.

Walmart was failing on Black Friday for two years in a row. It could not handle 6-million page views per minute and retain any kind of positive user experience, so it re-platformed to a microservices architecture.

Migrating to microservices actually brought notable results:

• Conversions were up by 20% overnight
• Mobile orders were up by 98% instantly
• No downtime on Black Friday or Boxing Day
• The operational savings were significant

Spotify serves more than 75 million active users per month, with an average session length of 23 minutes.

To avoid synchronization hell within the organization, Spotify built a microservice architecture. These teams are autonomous, and their mission does not overlap with other teams’ missions.

Now, Spotify has around 90 teams, 600 developers, and 5 development offices on 2 continents.

How to structure Frontend & Backend?

There are two ways to structure the frontend and backend in a microservices architecture:

1. Break up each piece of the UI per microservice. Keep each piece together with the corresponding microservice. This approach allows the frontend communication in-process with the backend. But, the complexity of maintaining UI consistency across microservices is very high. In case of cross boundary changes of UI, you need to update several microservices simultaneously, creating interconnections and disrupting isolation and independence of microservices.
2. Break up the frontend and backend code bases. Keep the UI of an application together, which then communicates with the microservices through HTTP. Microservices will be separated from each other. This will further divide the frontend and the backend. But the UI can be supported entirely, easily preserving its connectivity. In this case, we have the following options for interaction between the frontend and the backend:

• Many tiny HTTP async requests instead of one big request will exclude the possibility of blocking.
• One big request to a specialized service that gathers all data from the microservices ecosystem. will reduce UI complexity.

Decomposing a monolith into a microservice, we need to think of several dimensions that can support the decision:

• Bounded contexts as defined in DDD
• Business capabilities
• What consumers need
• Communication patterns
• Data architecture
• Correlated change patterns
• Readiness to merge and segregate services
• Tolerant reader pattern
• Stateless and phoenix nodes
• Convention over configuration
• Optimize communication between Microservices
• Service discovery
• Monitoring
• Migrating from Monolith to Microservices
  • Favour many small queries over a few big queries
  • Segregate DBs
  • Build new features as microservice prototypes
  • Replace code in the old system by API calls to the new microservices
  • Test under crazy load/behavior
• Long-term objectives
• Productivity

Are microservices right for your application?

Most projects don’t need microservices architecture.

A monolithic architecture makes sense for simple, lightweight applications. If your application is working well and doesn’t need changes, then adopting microservices will offer very little benefit. After all, microservices bring quirks and difficulties to the development process. Keeping all the new services running can sometimes feel like juggling balls. Adopting tools such as Kubernetes or Docker can take some change as well.

The microservices architecture is a better choice for complex, evolving applications despite the drawbacks and implementation challenges. Microservices are a response to hitting the ceiling. This happens to every successful software development project. Traditional monolithic application architectures do not scale anymore. The database grows too large, or there are too many millions of lines of code, or you can no longer add features.

Microservices are not a silver bullet for challenges of monolithic architecture, but they can empower your team to reach new levels of scale and agility.

Whether you need to improve application or start out with a new one, VironIT, software development company, has the team and experience to develop your vision.

Our team has expertise in:

• iOS applications
• Android applications
• Chatbots
• Web applications

Contact us today for an intuitive and fast app solution for your business or enterprise.