Armedia Solution Engineering Team

• Vishal Deshpande
• Andrew Slade
• William Phillips
• Naga Krishna Sumanth Kovvuri

What Are Microservices?

The microservice architectural design is a style of software architecture design which allows for increased encapsulation and separation of functionality. It is utilized successfully by large companies such as Netflix, Amazon, Uber, eBay, and many more.

Microservices are tiny, focused, optimized services that meet a specific goal with a very limited scope. They produce reusable building blocks which aid both developers and clients. In addition, microservices allow greater resiliency and reliability because if a lone microservice fails, this failure does not have to bring down the entire application.

Another benefit of microservices is that they can be re-used multiple times by separate microservices or applications, which saves development time and increases the value of your existing code.

What Is The Microservice Architecture?

The microservice architecture is the organization, management, and access to a collection of microservices. It utilizes an intermediary to facilitate communication between different microservices, as well as between microservices and the outside world. This intermediary also tracks the addition and removal of services, the status of running services, as well as the documentation for each service.

Why Use Microservices?

To understand the appeal of microservices, we must first explain the monolith. A monolith is the “traditional” style: a large application is made up of several services, all working together to achieve a goal. It is deployed on one location, utilizes one set of resources, and deployments, upgrades, and updates usually require the entire system to be shut down.

If two monoliths have a service or component with similar functionality, the code is a duplicate which wastes development time and resources; monoliths essentially reinvent the wheel every time a new application is needed.

Conversely, a set of microservices attempts to separate and de-couple each service as best as possible. Each microservice has its own container and can be co-located on the same server as other microservices or each microservice can be siloed on its own server.

Microservices can talk to each other and work in tandem to solve needs, and a single microservice can be used as a dependency for countless other microservices. This means if two separate clients have an overlapping need, a single microservice can be used for both clients.

What Are The Benefits Of This Approach?

Microservices are very effective in that each microservice can have its own allocated resources. If one microservice is not getting much traffic, its resources can be reduced, and if another microservice is getting hammered with traffic, its resources can be ramped up. This division of resources allows for targeted scaling as necessary and can provide information to usage patterns which may not have been as readily available.

As stated earlier, if a single microservice goes down then your application is not necessarily affected. Only a microservice which is dependent on the downed microservice will be affected, all others will operate normally. In this sense, each microservice is its own fully formed application, but much smaller in scope.

How Do Large Companies Leverage This Style?

Netflix is a company which values uptime as their highest priority. Netflix developed a unique testing tool, “Chaos Monkey,” to vet their system. “Chaos Monkey” is a powerful tool which “randomly disables our production instances to make sure we can survive this common type of failure without any customer impact.” (Yury Izrailevsky, 2011) This tool tests the microservices idea to the highest level by destroying running active services and analyzing the effects of disaster-recovery tools.

Netflix shifted to microservices from their previous monolithic approach because they saw the value of the distribution of services and the resiliency of their architecture when Chaos Monkey is on a rampage. Now when a microservice fails they can take down that specific microservice and either diagnose the issue or spin up another microservice to restore functionality.

What Are The Concerns Of This Approach?

The development of microservices is not without its own concerns. Because the idea of microservices is improved reusability and granularity, each microservice must be designed as cleanly and optimized as possible.

Because each microservice is separated, if a microservice makes a call to a failed microservice, unexpected consequences can occur. An application must be designed to accept and accommodate failure between services. Because of this, it may result in overall larger infrastructure costs and concerns as you will need to be prepared for calls to other services to fail at unexpected times.

Documentation is also extremely important, as each component is potentially a building block in future applications. Therefore, the functionality must be clearly defined and expected. When it comes to designing a microservice, thought should be given for potential future use cases of the service. Due to the complexity of this system, it can result in greater planning complexity.

Are Microservices Worth Utilizing In My Project?

As is usually the case, the answer is not a simple yes or no. Microservices can be more resilient but can fail in unexpected ways if a dependent microservice fails. If this potential failure is not adequately prepared for, such as through effective exception handling, your application can randomly fail at inopportune times.

Since each service is specialized they can be more efficient, but the tradeoff is greater architectural development complexity and design. Each microservice can have exactly the amount of resources it requires, but because it is separated out from other services, it will have a larger overhead cost in comparison to a monolithic application.

In short, there is no right or wrong answer between monoliths and microservice architectures. Each can be correct or incorrect depending on your organization’s and your clients’ needs, expectations, goals, and experience.

Armedia Architecture Example Diagram

Below is an example of how the gateway interacts with each microservice as well as exterior applications. A detailed discussion of each application to be accomplished in a future blog post.