What is a microservice and what are the benefits and challenges associated with implementing a microservice architecture? This article, republished from our partner Caylent’s blog provides some great insights on the topic.

What Is a Microservice?

It is beyond the scope of this article to provide an exhaustive definition of a microservice. That said, here is an attempt at a simple definition:

Microservices are individual and distinct components of a software program that exist to fulfill the smallest possible function of an application while still remaining independent and serviceable. From a practical standpoint, each service is a small, highly defined, and discrete piece of code that is responsible for one task (e.g., end-user authorization).

The Good

Microservices, when implemented correctly, can greatly improve the reliability and scalability of software. One of the most compelling aspects of microservices, when compared against monoliths for example, is that a flaw or bug in one service should not affect the ability of other services to carry on working as intended.

Microservices have a number of advantages, such as…

• Ability to scale independently
• Fault tolerance
• Can be swapped out or easily re-written
• Framework and language agnostic
• Adheres to KISS principle
• Be 12 factor compatible

What this means from a practical standpoint is that an application should:

• Scale easily and in a highly efficient way
• Have no single point of failure
• Be retired, refactored, or re-written without compromising the integrity of the entire application
• Be written in many languages and frameworks to suit the requirement of each service
• Be simple and discrete
• Easily meet requirements for modern PaaS and SaaS environments

Many well-known and well-respected engineering teams from companies like Amazon, Netflix, eBay, and others have adopted microservices. It makes sense, then, that every developer or new software startup should naturally ponder whether to embrace a microservice architecture. If we’re all honest about this, who doesn’t admire the engineering prowess of these forward-thinking companies?

If it’s good enough for Netflix, then surely it must be good enough for us. Right? Right? Well maybe, and maybe not. As we’ll see, the “why not us” mentality should be left at the door. Maybe it does make sense for your application or company, and maybe it doesn’t.

The Bad

Just because something is trending in the industry, does not necessarily mean it’s a viable solution for each use case. One of the principal disadvantages is all the hype surrounding microservices. There are other drawbacks, too. Some of the more superficial discomfort with microservices includes:

• More complexity, thanks to the expertise required to maintain a microservice-based application with all its moving parts
• If the application doesn’t need to scale or isn’t cloud-based, microservice-based architecture may not provide any meaningful benefits
• No greenfield options because microservices need to connect to existing (and possibly monolithic) systems
• Smaller units of functionality communicating via APIs necessitate more robust methods of testing as well as buy-in from the entire engineering team
• The need for increased team management and communication to ensure everyone, not just certain engineers, understand each service and the system as a whole

The Ugly

And that’s just touching the surface of the disadvantages. Just because Netflix or some young hot Silicon Valley darling has embraced microservices does not mean it is the correct architectural style for all applications. Application architecture should be based not just on what’s in vogue at the moment but also on efficacy and fit. When it comes to it, the truly intrinsic pain points that microservices come hand-in-hand with are…

• Dealing with distributed systems’ development, deployment, and operational management overheads can be expensive, requiring a high initial investment to run
• Choosing a different tech stack for different components leads to non-uniform application design and architecture
• Endless documentation in the form of updated schemas and interface documents for every individual component app
• The costs of maintenance, operational costs, and production monitoring are much higher, and the latter also suffers from a dearth of available tools
• Automation testing becomes difficult when each microservice component is running on a different runtime environment
• Increased resource and memory consumption from all the independently running components which need their own runtime containers with more memory and CPU
• Microservices, when implemented incorrectly, can make poorly written applications even more dysfunctional

Microservices are a true double-edged sword for any application architecture consideration. If you’re thinking of migrating, block out the noise surrounding all the hype and carry out your own due diligence to see if microservices is the right solution for your application’s needs.