Microservices in a Nutshell – What Is the Microservice Architecture?

Summary

What Is the Microservices Architecture?

How Do Microservices Work?

What Are the Benefits of a Microservices Architecture?

FAQs about Microservices

Microservices Today: A Short Overview

Before we get into the explanation, first, it’s important to understand how things were working before the emergence of microservices.

In the traditional application development process (what we use for purely desktop applications like the Office Suite, for example), each application has its own code project. This means that each time you want to add a new functionality or feature, you add more code to the project. As you can imagine, in time, this leads to a very large code base that becomes increasingly difficult to manage.

A better approach was needed, so, as a best practice, developers started to break the code down into multiple modules (modular application development). Each module would correspond to a single functionality, and they could also be reused to provide the same functionality to other apps. The idea was not bad, but the problem was all these modules would still be combined into one single application that would be deployed to a single machine – this is known as monolithic architecture.

The problem with monolithic applications is that the bigger they are (meaning the more complex the applications is, the more functionalities it has), the harder they are to deploy (and also scale, but we’ll discuss this further down). Let’s take testing as an example. Whenever you make code changes by adding a new feature or fixing a bug, even though you’re just adding a new module or making changes to just one module, because the application will be deployed as a whole, you have to retest everything every single time.

As you can imagine, this takes a lot of time and effort, and there’s no way you can achieve the pace applications like Netflix have of several hundreds of deployments per day.

In the history of development, there are two key moments that have led to the idea of microservices: the emergence of web applications and the rising complexity of web applications.

In the early years of the internet, we had static pages like blogs or presentation websites. The way web apps worked was that, instead of deploying the application on the end user’s machine, it was deployed on a server, and the user would access it via the internet. Because the complexity of web apps was quite low, it didn’t really matter that they were monolithic.

However, as technology evolved, so did the complexity of web applications – now we have ride-sharing apps, streaming services, online document editors, online shops, etc. Having one big monolithic app deployed to a server is no longer efficient.

The best example is the scalability problem of eCommerce apps. Online shops are known for having very irregular streams of traffic – think of how websites crash during Black Friday. Whenever there’s a traffic spike, you want to scale up your infrastructure to accommodate the increased number of users, and when the traffic decreases, you want to scale it down to make your costs more efficient. If you have a monolithic app, in order to scale your infrastructure, you need to duplicate your “main” server that contains your app, meaning you’re going to have multiple servers that contain your entire app (as you cannot break it into smaller pieces).

The problem is, during traffic spikes, you don’t need to scale every single module in your eCommerce app – that’s very inefficient cost-wise as most modules will remain unused. You just need to scale the module that takes care of the traffic. And that’s how the microservices concept was born.

Here’s a video that explains the concept of microservices in a more visual way.

Desktop-only apps need to be compiled and deployed on a single machine; that’s the only way a user can use them. Web applications are different in that the user only needs an interface to communicate with the app – whether the app is deployed on one server or multiple ones is of no importance for the user.

This is critical because why would you have multiple servers each hosting your entire app when you can deploy each individual module on a different server and have them communicate with each other over a network (via REST APIs)? Now, this is called microservices.

Coming back to the eCommerce application example, being able to deploy each individual module on a different server is crucial because, in case of a traffic spike, you can scale only the module that takes care of the traffic, which speeds up deployment and also significantly reduces infrastructure costs for online shops(you need fewer resources and resources specialized for that module, which is almost always cheaper).

Each individual application has its own unique architecture, so, for that reason, it’s hard to find a one-approach-fits-all. However, each microservices architecture shares the same characteristics:

1. Distinct components – an application built using microservices can be broken down into multiple (independent) pieces; each piece can be created, tested, deployed, or changed without affecting the performance of the application as a whole.

2. Decentralization – since each module (microservice) can function independently, the traditional centralized governance model doesn’t apply. Microservice architecture also embraces decentralized data management. This means the development team is responsible for all aspects of the software they built, including operating the software 24/7; nowadays, more and more companies push responsibility to the development teams.

3. Failure resistance – microservices are designed to cope with failure. When one service fails, the application can still function (although not at 100%), unlike with monolithic applications where, when one feature fails, the whole app crashes.

4. Simple routing – the way microservices work is similar to the UNIX system in that they receive requests, process them, and generate a response accordingly.

5. Infrastructure automation – most of the applications that use a microservices architecture are built by teams with extensive experience in Continuous Delivery and Continuous Integration, so they take full advantage of infrastructure automation techniques (automated tests and automatic deployments are just two examples).

6. Product ownership – unlike in the monolithic development model where each team has a specific focus (interface, server-side, database, etc.), microservices architectures use cross-functional teams responsible for creating one or more independent services. Then, the team is responsible for that service for its full lifetime (this was inspired by Amazon’s notion of “you build, you run it”).

7. Evolutionary design and architecture – we cannot anticipate the types of devices we’ll have in the future. An app built using a microservices architecture can easily be tweaked and adapted to fit the changing needs and requirements.

This is an extensive topic we could cover in a series of dedicated articles. As there is no right way and wrong way of doing microservices, it’s hard to answer this question briefly.

However, to sum it up, we will go back to the definition of microservices. Microservices architecture is a collection of services that communicate with each other via APIs. Used together, these services enable the functionality of an application.

Because each service functions independently, they are built using the best tools for the job. For example, you could use Node.js for a simple reports page and C++ for a near-real-time component. There are no constraints regarding hardware or software when it comes to microservices.

Considering the mindset behind a microservices architecture, it’s no surprise that it’s often associated with containerization technology. Orchestrating and managing large groups of containers is one of the most critical challenges of microservices, so Kubernetes has risen as the solution of choice.

So, if we were to sum up how microservices work, we could say that they are enabled by:

Cloud computing takes the responsibility from the user to have powerful computing capabilities to run all the necessary operations and, instead, places it on the organization to use servers to run the services each time the user uses the app. This way, the user is only responsible for sending and receiving network calls to other computers.

Keep in mind that most popular apps today (Facebook, Uber, Netflix, eBay, etc.) use thousands of computers to process information and answer user requests.

“Microservices are not a free lunch.” Netflix has become a benchmark in this area after the company revealed they use over 700 microservices to run their platform, so many organizations have jumped the gun and began implementing them into their business as well.

But just because something is trending or your competitors are using it doesn’t automatically mean it’s the best tool for the job. You should take a moment to assess whether you really need microservices by asking yourself:

If your answers are positive, you can proceed with implementing microservices. Ideally, you should consider using a microservices architecture over a monolithic one when you:

On the other hand, microservices are not for you if:

The microservices architecture is a model that facilitates the desired operation model – 87% of microservices users agree that microservices adoption is worth the expense and effort. That’s because:

1. Microservices are independently deployable

This is the most crucial characteristic of microservices, and the main reason so many organizations choose to implement them. This means that code changes and new features can be deployed more easily and more often, which significantly increases speed and agility.

An added benefit is that bugs and errors don’t necessarily cause the whole application to stop functioning. And once issues are solved, you can deploy only the affected service instead of the entire application.

The microservices model also enables organizations to create small, cross-functional teams around each service and have them operate in an agile fashion, which further increases delivery speed. And last, but not least, given the small size of services and their clear communication patterns, new team members have an easier time understanding and contributing to the code base.

2. Microservices are independently scalable

Not only are microservices independently deployable, but they’re also independently scalable. This is a HUGE advantage compared to a monolithic application that doesn’t enable precise scaling of only the components that require it (remember the eCommerce platform example earlier).

3. Different services can be built using different technologies

Traditional applications share a common stack and a large relational database. The major drawback of this approach is that all elements have to be built using the same technology stack, even if there’s a better tool for some individual components.

The microservices architectural model removes this limitation – each individual component can be built using the best tool for the job. This is particularly helpful as technology is continuously evolving because individual components can be improved as new technology becomes available.

4. Individual components can be reused

For organizations that build multiple products, this is great news because it means that components such as login, authentication, or search modules can be reused for multiple applications. This significantly lowers development time.

5. Microservices enable DevOps

This is great news for organizations that want to adopt a DevOps culture. In fact, given the complexity that comes with the implementation of microservices, DevOps becomes a necessity – you simply can’t (or rather shouldn’t) implement microservices without deployment, monitoring, and lifecycle automation.

Are microservices worth it?

Given all the benefits described above, yes, microservices are worth it. The only question is whether using a microservices architecture is the best approach for your product.

Can microservices call each other?

Yes, individual microservices communicate with each other using REST APIs in order to enable the app functionality.

How do microservices communicate with each other?

Microservices communicate with each other using REST APIs.

Which approach do microservices use for designing?

The most common design pattern used in microservices is the API Gateway Style Microservices Architecture.

Which companies use microservices?

A few of the most known ones are Netflix, Facebook, Uber, Amazon, eBay, but many organizations these days use microservices.

Why are microservices popular?

Thanks to all the benefits they have compared to the traditional monolithic development approach that’s no longer fitting for today’s complex web apps.

An IBM survey revealed that, within the next two years, 56% of non-users are likely to adopt microservices, 78% of users will increase their investment in microservices, and 59% of applications will be created with microservices.

However, although the microservices model comes with many benefits, it also raises many challenges, the most significant one being the increased complexity. The DevOps approach could be the answer to these challenges, but keep in mind that transitioning to a DevOps culture is already a challenge in itself.

Fear not, though, as we at Bunnyshell aim to make the transition to DevOps as easy as possible for every organization. After many iterations, we have managed to bring our platform to a stage where there’s ZERO DevOps experience required for teams to build, deploy, and scale modern apps.

At the end of the day, the microservices architecture is just a small part of the shift towards DevOps that many organizations are already working towards in order to make their businesses more agile.q

Do you want to give Bunnyshell a try?

Start your FREE trial