Understanding Microservices and Their Impact on Companies

What Are Microservices?

Microservices are a trending software design architecture that breaks apart monolithic systems. Often, applications are built altogether in one big code repository.

Currently, there’s a paradigm shift, where applications are constructed with a more functional approach. Each so-called microservice handles a single feature. This means an application consists of multiple microservices. Every service is good at performing one specific function.

A microservice is basically an independent process that provides a unique business capability. Communication between these services often happens via the HTTP protocol. A common setup uses a REST API or a simple messaging queue.

The biggest advantage of a microservices architecture is that teams can develop, maintain, and deploy each microservice independently. This also means they can be easily scaled to process more requests. Kubernetes is a very popular tool that takes care of scaling services.

Besides providing easier management of your services, your code also becomes less bug-prone. This means that your services are pure and have a single responsibility. Often, microservices don’t contain a lot of code and can be easily tested. By isolating your functionalities, they have a higher fault tolerance when compared to a more complex setup. 

Amazon Use Case

To help you understand the concept of microservices, let’s take Amazon as an example. Since they get countless requests from a variety of applications, Amazon decided to move to microservices. Their API needed to scale quickly to handle all requests, and their old two-tiered architecture just couldn’t handle the number of requests in time.

Amazon has multiple services running:

• One service accepts orders.

• One service generates a list of recommended items to buy.

• One is a simple authentication service. A payment service can even be split up into two: one service for credit card related payments and one service for PayPal payments. 

In short, all these services are really mini-applications with a single business capability. This architecture allows developers to stop using traditional software layers. We don’t create a web microservice, business logic microservice, or database microservice. Instead, we create microservices around business capabilities, and each microservice takes responsibility for its own data model.

Benefits of Using Microservices

There are a number of reasons why you’d be well-served to use microservices at your company.

Increased Resilience

With microservices, you can decentralize your entire application and decouple it into services that act as separate entities. Unlike a monolithic architecture, where a single failure can affect the complete application, a microservices architecture means failure has minimal impact.

As microservices are always managed by some higher-level tool like Kubernetes, it’s not as troublesome when one service fails. Another can easily take over. The user will hardly notice anything from this failure.

Also, microservices support the principle of keeping things simple (KISS principle) in order to reduce the number of failures. 

Improved Scalability

Scalability is key for microservices. That’s the main reason for switching towards a microservices architecture. Each service lives as a separate component. This allows each component to easily scale with tools like Kubernetes in case of high demand. Using microservices, you don’t have to scale your whole application. You only need to scale the service that’s in high demand. This saves businesses a lot of money.

In short, microservices allow for increased availability and performance without impacting other services.

Faster Time to Market

A microservice architecture presents flexibility. It allows developers to easily update a microservice’s behavior without having to rewrite a lot of code. This is one of the main benefits of decoupling your services. Also, new functionality can be developed quickly and deployed within this architecture.

Continuous Delivery

Microservices also speed up your CI/CD pipeline. This means more agility, too. Instead of working all together on elements like UI, the database, or server-side logic, microservices allow developers to simultaneously work on a single service. 

Also, testing a new microservice functionality is much easier, as you don’t have to deal with writing complex integration tests for your monolithic setup. Rather, you can focus on simple tests that can be quickly deployed via your CI/CD pipeline.

Reasons to Avoid Using Microservices

Many businesses have embraced microservices. However, bear in mind that not every business is suited for adopting this architectural pattern. That’s why you should make sure your business is capable of managing microservices. 

Let’s discuss some organizational caveats.

You Don’t Have the Right Systems in Place

Using microservices might sound appealing, but you need to make sure your business has the right tools in place to enable this change. One of the most important tools is your CI/CD pipeline, so make sure this is in place before adopting microservices. 

Besides having the right tools, some new resources might be required. For instance, there’s a good chance you’ll be working with technologies like Kubernetes. Plan ahead for this change and hire the needed resources.

You Don’t Have Robust Monitoring

You won’t just be monitoring one application, so you’ll need some clever tools that can monitor and detect issues for your microservices. It’s crucial for you to know when and why a service goes down. Even more important is understanding how to recover this service.

You might have noticed a trend throughout the article: your business will rely heavily on the DevOps team. I recommended you scale up this team when migrating to microservices.

You’d Run the Risk of Having Too Many Microservices

One of the major threats for microservices is developing too many of them. Managing a huge number of microservices can put a lot of stress on your DevOps team. It can also increase the complexity of your overall application. Things like caching issues, network latency, or database errors will start to pop up. These are the kind of problems you generally want to avoid.

Author Criss Jami said, “I am a fan of overdoing something, but not running it into the ground. They are complete opposites with only a fine line separating them.” I advise you to take this philosophy and use it in your application of microservices.

Misconceptions About Microservices

Let’s get a few things straight about the traits of microservices. Some think microservices are the golden solution for every project. They’re not!

Let’s take a look at the following common misconceptions about microservices.

Misconception 1: A Microservice Is Bound by [X] Lines of Code

Although I recommend that you develop a simple service, there are no limitations on the lines of code a microservice should contain. And there’s no risk that your microservice will turn into a monolith by you adding a couple of lines of code.

It’s more important to clearly define the boundaries of each service. Each service should offer specific functionality and be independent of other services.

Misconception 2: You Should Turn Each Function Into a Microservice

Always make sure to evaluate if a function is suited to run as a separate application. If your service only takes three input variables and spits out a result, this might be too simple to be converted into a standalone microservice.

However, in some exceptional cases, this can be turned into a microservice. It depends on its usage. If you expect a function to be critical to your application or if you expect a lot of traffic for this specific function, it might be a good move to migrate it into a microservice.

To give you an example, a function that takes two numbers as input and returns the sum of both numbers is not suited to be deployed as a microservice. A function that takes an image as input and converts it into different file types is a better use case for microservices, as it’s a more encapsulating service.

Here’s your rule of thumb: each microservice must encapsulate a business capability.

Misconception 3: Microservices Completely Eliminate Complexity

Kevin Casey, a writer at The Enterprisers Project, explains perfectly why microservices don’t solve all complexity problems:

It may be tempting to treat microservices as a universal salve for the pains of an enterprise application’s technical complexity. While the microservices approach can certainly offer advantages relative to a monolithic architecture, don’t make the mistake of assuming it will rid your environment of complexity altogether. For instance, poorly-executed microservices could cause latency problems on the network.

So, to summarize what he’s saying, microservices might help you to reduce the complexity of your code. However, as microservices need to communicate with each other, this can introduce a whole new range of network-related issues. These issues can easily pop up in the case of wrong microservice architecture design.

Misconception 4: Microservices and APIs Are the Same

This statement is absolutely wrong. Microservices allow for a unique architectural approach to be developed, and they decouple business capabilities. An API, on the other hand, defines the interfaces of how you can interact with the service. However, an API is a valuable component of each microservice, as it allows for communication between services and clients.

How to Migrate a Monolith Into Microservices?

There might be many different reasons why your company decided to migrate its monolith into microservices. However, you should know that migrating from a monolith into an ecosystem of microservices can become an epic journey. You’ll need to do a few things to make sure it goes well.

First of all, define the business capabilities you want to turn into microservices. Make sure that every microservice encapsulates a specific business capability. A business capability represents what a business does in a particular domain to fulfill its objectives and responsibilities.

Now, let’s break that down into more detailed steps.

Step 1: Start With a Simple Capability

Get started with a business capability that can be easily decoupled from the monolith application. This also allows your DevOps team to set up the required deployment environment and continuous delivery pipelines.

Here are a few starter examples: decouple your user authentication or “customer profile” service. These are edge services that can be easily decoupled.

Step 2: Build an API Management System

As you’ll be dealing with a lot of APIs, start working on your API management system. This often includes the set up of a service mesh, which will act as a dedicated infrastructure layer to run a fast, reliable, and secure network of microservices.

A mesh often starts with container orchestration systems like Kubernetes to provide a higher level of deployment infrastructure abstraction.

Step 3: Minimize Monolith Dependencies

Also, minimize the dependencies for your newly created microservices to the monolith. A microservice needs to be independent and only accept service requests via their exposed API endpoints. If you follow this guideline strictly, you’ll get a monolith that depends on the capabilities of the created microservices and not the other way around.

Tip: Split Deeply Integrated Capabilities Early

In order to speed up your migration process to microservices, it’s best to split deeply integrated capabilities from the monolith application. Whenever deeply integrated capabilities are left in the monolith, this will limit the further move to microservices. That’s because there will always be this dependency back to the monolith for a particular capability.

In order to be able to progress, the team needs to identify the sticky capability, deconstruct it into well-defined domain concepts, and then further divide these domain concepts into standalone microservices.

Is There a Current Trend Towards Microservices?

A survey by Bernd Rücker questioned companies about digital transformation initiatives. In this survey, 63% percent of the 354 questioned enterprises said they were looking into microservices. According to the survey, they mainly wanted to improve their digital processes for the following reasons:

• Improved employee efficiency

• Improved customer/end user experience

• Cost savings on infrastructure and other development tools

When we look at the tech giants, we find Netflix as one of the pioneers of the microservice movement back in 2009. Later, other companies like Amazon, Uber, SoundCloud, and eBay joined the trend. According to the former CTO of eBay, Steve Fisher, eBay utilizes more than 1,000 services. They use front-end services to send API calls and back-end services to execute tasks like shipping and administration.

A Final Comparison: Monolith vs. Microservices

Let’s do a final breakdown of the features of each type of architecture so you know exactly what you’re dealing with.

Monolith Architecture 

The most common features of monolith applications are

• Releases only occur every few months or years. Sometimes, it takes a couple of years before an application moves into production.

• There’s generally a wide range of features.

• There’s a large development team dedicated to those features.

• Dealing with bugs is a huge challenge and requires the knowledge of different people to find the exact problem.

• It’s not easy to bring new technologies or functions into the mix halfway throughout the lifetime of an application.

Microservices Architecture

For microservices, the characteristics look like this:

• There’s a component-based design that allows for individual components to be easily updated or replaced.

• It welcomes an agile development approach, as multiple teams can work independently on multiple components.

• There’s a faster time to market and there are quicker releases—ideally, every few weeks.

• It allows highly used services to easily scale without you having to also scale the whole application. This saves a business quite a lot of money.

The Bottom Line

Microservices offer clear benefits, such as saving costs and faster time to market. It reduces the number of failures and provides higher availability. However, overdoing or wrongly designing your microservices architecture can make things prohibitively complex. This means you’ll lose all of these benefits.

A lot of thought is needed when making a major shift towards microservices. You might need to hire additional resources with new skills. Also, don’t forget to evaluate your current DevOps team. 

If we need to draw a clear line, implementing a microservices architecture makes more sense for a software-as-a-service business than an industrial company. But don’t feel limited by this conclusion, as an industrial company can perfectly implement such an architecture with the right management. Want to learn more about software delivery management? Check out the Plutora platform.