Microservices: The Good, the Bad, and the Ugly
Microservices: The Good, the Bad, and the Ugly
Microservices architecture provides many benefits, but be prepared for these challenges and downsides when implementing them in your organization.
Join the DZone community and get the full member experience.Join For Free
Deploy commerce faster and keep pace with the demands of your customers and executives. Read this blueprint to learn how to create your own microservices-based commerce foundation so you can quickly move onto building innovative and unique shopping experiences for your customers.
Microservices have been bandied about in the past couple of years, but what are the real advantages and disadvantages of implementing and running them? Like any service architecture, there are pros and cons, benefits and tradeoffs. So, how do microservices compare against other application architectures like monoliths, service-oriented architecture (SOA), and functions? We’re here to break it all down and shed some light on why the developer and DevOps community is pushing back against the microservices-is-the-solution-for-everything mentality in 2018.
What Is a Microservice?
It is beyond the scope of this article to provide an exhaustive definition of a microservice. That said, let me go ahead and give my best 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)."
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. Notice that I caveated it by saying should not, but more on that later.
Microservices have a number of advantages, such as…
- Able to scale independently
- Can be swapped out or easily rewritten
- Framework and language agnostic
- Adhere to the KISS principle
- 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 rewritten 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? I know this nerd does.
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.
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 discomforts with microservices include:
- 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.
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.
Published at DZone with permission of JP La Torre . See the original article here.
Opinions expressed by DZone contributors are their own.