Let's look at some of the reasons why you might want to choose microservices for your applications. Not every application should utilize microservices, as you will see in the next section. Very distinct reasons warrant the use of microservices. Let's take an example to justify why we want to choose microservices.

Let's pretend you want to develop a simple e-commerce app. If we say that there are three different elements of microservices in an app, User, Product, and Order. The app should cover the following features:

• User: Log in
• User: Register
• User: Change addresses
• User: Change payment methods
• Products: Show the list of products in a category
• Products: Show details about an individual product
• Order: Submit an order of products
• Order: Submit payment for an order

You could develop the backend for such an app as a monolith, of course. It would, without a doubt, be a rather big application and require many models and controllers. But if you were to develop the same app with microservices, you could end up with three more flexible packages, such as the following:

• User Manager
• Products Manager
• Order Manager

You can now enjoy the following benefits from using microservices:

• Effective team management
• Reusable code base
• Flexible scope of functionality
• Maintainability
• Scalability
• Mixed stacks

Let's dive into each of these sections now.

If you have ever worked in a team on a bigger monolithic application, you know very well how chaotic and unorganized it can get. Various preferences, styles, and trains of thoughts are commonly joined together, resulting in a decently sized mess.

With microservices, you can assign different services to different team members. In the preceding example, if you happen to be a three-member team, each one of you could develop one service. The added efficiency will not just increase productivity in the beginning but carry through the entire project.

Spreading out the workload across multiple people working separately but still together is a significant benefit for all of the teams. Imagine you have to manage 500+ programmers for a big project (think Facebook or Google). It is close to impossible to function well over a longer period of time if everyone is using the same code base. If the application is split up into small microservices, you can have a lot of 10-people teams that are working on various services. While this comes with its own challenges, it will certainly reduce the potential for error in the code itself.

But even if you happen to be in a small team, few developers can experience a noticeable increase in productivity when developing microservices.

In essence, microservices allow you to spread work out effectively in a team.

For the sake of this discussion, let's assume that you have already written a user manager once before and now you can use it again. With microservices, you can use and reuse any given service that you have developed previously. If a service does not quite fit your case, you could just modify it instead of writing it from scratch.

Reusing the same code across multiple projects saves you valuable time and resources. You may even start thinking about microservices abstractly so that you purposefully can reuse the services. You can try to define a set of functions that fit more than one project for you to reuse with other projects.

Let's take a look at the aforementioned user manager service. Almost all applications that interact with users have a login. In most cases, the functionality is pretty much identical, as shown here:

• Log in via email and password
• Registration with email verification
• Forgot password; send recovery email
• Log out
• Delete account

Once you have written this service you can easily implement it with other projects.

Another similar case is when you are choosing a SaaS solution for user management. Examples include AWS Cognito, Auth0.com, Okta, and Backendless. Microservices allow you to easily incorporate such services to save yourself the time and effort of writing a user management solution at all in this case. Naturally, the same principle applies to other types of services as well.

To summarize, microservices allow you to reuse existing code for new projects and save time and effort. Next, let's explore the scope of functionality.

We know that this app will grow and that users will need more features. Microservices are ideal for such cases because you can simply add more services for functionality or modify the ones that you already have. Take the earlier example; you start out with a very manageable and small set of features. If you know these are all of the features you will ever need, there would be no reason for not using a simple monolithic approach for this. The reality, however, is that many projects grow, both in terms of users and mostly in terms of what they offer. You may decide to add functionality to your offering or to significantly change it.

Imagine you need to add a new payment method to your online shop. In a monolith, you need to work on and deploy the entire application, which comes with risks. However, in microservices, if you have the order manager, you can simply add the payment method to that service and deploy it and you are good to go. The user manager and product manager do not need to be touched.

Microservices allow you to grow your functionality as you need and without needing to touch other parts of the software.

It makes a lot of sense to use microservices not only when your specifications may change, but also in cases where your requirements are highly defined. Microservices are easily maintained; each service can be updated, upgraded, and serviced individually without influencing the other services. This is particularly important with bigger applications as it reduces the risk and impact of potential downtime.

If you are serving a lot of users, you want to avoid downtime as much as possible. Because microservices are independent, you can replace them in time without going offline. You will explore deployments later on in more detail, but most cloud service providers have procedures in place that will keep your application up 100% of the time while switching out the services.

Additionally, you and your team can focus your efforts on the services that need it most. While one service is being heavily updated, the other services can stay the way they were. I have been in a project that had legacy microservices running for over two years because it worked reliably and effort was put into developing new features instead of updating the old ones. You should not neglect updating all parts of your system though, but microservices allow you to keep old infrastructure longer than with a monolith.

In conclusion, microservices allow you to work on them while other services stay as they are and therefore give you the ability to focus on what matters most.

Another element to consider is that you want to be able to grow and scale your application easily. Microservices are arguably the easiest form of application for a server application to grow. Remember, we have individual and independent services running. It means, in principle, that no problem should have the same service run in many instances, for example, you could have 100 servers running the same service. Alternatively, it could also run as only one service, based on your needs.

Let's look into the following three distinct advantages microservices have when it comes to scalability:

• Auto-scaling
• Flexible cost
• Service-oriented availability

You can have your hosting provider automatically scale (up and down) according to your needs. Predefined and customizable rules allow you to define and to scale up and down. If you have an upcoming marketing gig (such as a TV promotion), your backend will automatically scale according to your demand without you having to adjust anything manually.

This goes hand-in-hand with auto-scaling. You may pay for the infrastructure depending on your needs. In an ideal world, you would pay nothing for no users and increasingly more as you have more users. In reality, this rarely happens just like that, however, you do end up saving money as you don't need to buy more hardware than you need in most cases.

Often, not every service is used equally. In the preceding example, the user service only performs authentication and registration. Once the user is authorized, this service is mostly irrelevant to the app. You may decide to have the email processing service to be a lot more available than your user service.

Concretely, this may look like five servers are running the product manager application while only one server runs the user and the order manager. As your app grows and changes, you can adjust this setup precisely to what you need.

So, we can conclude that microservices allow your application to grow effortlessly and you have many options for how you want your entire backend application to run.

Sometimes, you may find yourself in a situation where a part of your tech stack is using other technologies. You may want to write your microservices with Vapor and Swift but have a good bit of infrastructure in PHP. You can utilize microservices to keep some of the old parts while already developing new services. Your setup will then look like the following diagram:

In this case, your user request will be routed either to the (old) PHP monolithic Media & File Management service or to your new Vapor services. Your old monolith is actually turned into a microservice itself, though it most likely covers more functionality than you want it to have. But, deciding to go with microservices allows you to incorporate software that you may depend on even if it is written in an entirely different language.

If you are wondering how the preceding example would look like in real life, most microservices are operating out of containers (for example, Docker containers). These containers operate as mini-servers and are completely isolated. So, even with just one actual hardware server, you can implement the preceding scenario with a local load balancer such as nginx.

Hence, microservices allow you to integrate older parts of your infrastructure while already using your newer parts.