Beware of these pitfalls on your product modernization journey
Back to table of contents
Ignore these common development practices for maximum success
Next
03
Previous
01
Table of content
6 minute read
Back to table of contents
Doesn’t have to be an end-to end propositio
Can be designed and implemented in levels
Delivers benefits at each stage—there’s no need to modernize everything at once to begin seeing ROI
How it’s going to scale up
Why you’re creating it
What business benefit it’s going to deliver
Next steps
Re-imagine software products
Leverage our expertise in next-gen MACH software architectures to modernize your software products quickly.
Learn More
Rejuvenate mature products
Focus on improving revenue, efficiency and customer delight with our intelligent sustenance engineering framework.
Learn More
Re-group with our experts
Schedule a discussion with our modernization and sustenance experts who can help you chart a path forward.
Contact Us
Next steps
Re-imagine software products
Leverage our expertise in next-gen MACH software architectures to modernize your software products quickly.
Learn More
Rejuvenate mature products
Focus on improving revenue, efficiency and customer delight with our intelligent sustenance engineering framework.
Learn More
Re-group with our experts
Schedule a discussion with our modernization and sustenance experts who can help you chart a path forward.
Contact Us
Any organization considering a product modernization initiative should pay close attention to four common pitfalls, outlined in
Mark Richards' excellent book Microservices Antipatterns and Pitfalls. These four approaches may seem at the outset like journey accelerators, but they have the potential to doom the project to failure before it even gets underway.
5 Key Architecture Pattern Combinations on an M2Mu Journey
It’s tempting for product development teams to assume that you can start taking advantage of microservices anywhere in the product architecture and begin reaping the benefits right away. After all, any microservices adoption should be better than the existing monolithic codebase, right?
Not true. Microservices architecture is based on the premise that multiple capabilities—or business capabilities—are utilized by multiple services, and even relying on each other for maximum benefit.
That effort must always start with understanding the business needs, then identifying which specific business capabilities can be optimized through microservices.
For example, beginning a microservices effort with a micro-frontend has a lot of appeal, since those changes directly impact the customer experience and are highly visible to product managers. But without a cohesive and strategic approach to support that effort, the lackluster results could negate any positive momentum for the modernization initiative just as it’s getting underway.
Pitfall 1:
Any organization considering a product modernization initiative should pay close attention to four common pitfalls, outlined in Mark Richards’ excellent book Microservices Antipatterns and Pitfalls. These four approaches may seem at the outset like journey accelerators, but they have the potential to doom the project to failure before it even gets underway.
5
What started as a multi-cloud workload migration for greater consistency and ease of manageability led to a technology refresh that enabled a natural next step toward automation.
4
What started as a multi-cloud workload migration for greater consistency and ease of manageability led to a technology refresh that enabled a natural next step toward automation.
3
2
1
1
2
3
4
5
6
1\ Backend micro-services — everything else monolithic
2\ Service mesh, ‘dumb’ message broker — everything else monolithic
3\ Service mesh, micro-integrations — everything else monolithic
4\ Service mesh, micro integrations, Edge gateway (not monolithic API management layer)
5\ Through and through microservices, including security and analytics
Jumping on the Microservices Bandwagon
In a discussion a one customer recently, they proudly shared they had created 10,000 microservices. Our only response was to ask, “Is that a good thing?” Conventional wisdom would indicate that if one microservice is good, then lots of microservices must be better.
However, optimizing with microservices is only beneficial if it’s providing a clear business advantage. Before embarking on any microservices effort, you should know:
Pitfall 2:
More Microservices = Better
This applies whether you’re developing one microservice or 10,000. For example, let’s say you have a business need to do batch uploads of sales tax data on a quarterly or annual basis. The amount of data may be large, but it’s infrequent.
Adding microservices to the application that handles the aggregation and handling of that tax information to decrease downtime during incremental releases isn’t going to drive business value or improve the customer experience. Availability isn’t a concern to the customer or a competitive differentiator. It may ease the continuous improvement/continuous development pipeline, but those benefits are only experienced by the development team.
In this case, investing in a microservice to improve a metric that isn’t important to the customer is only going to reduce the ROI for the entire modernization initiative. It’s much better to begin by focusing on fewer microservices efforts that deliver the greatest business value and/or improve the customer experience in ways they truly care about.
Why you’re creating it
What business benefit it’s going to deliver
How it’s going to scale up
In a microservices architecture, each service relies on the others, and they’re in constant communication. But microservices are also distributed systems to the core. What happens in a global enterprise when one service gets implemented in the US while another is implemented in a European data center?
That distance between the two microservices adds just the slightest bit of latency to each remote call. It’s not enough for anyone to notice on its own. It’s also difficult to replicate in a development environment. But consider the implications as your microservices architecture continues to get built out, and you’re managing 10,000 microservices or more.
As the volume of microservices increases, that latency begins to add up and can negatively impact your overall performance. Years from now this won’t be an issue as developers will have gained considerable experience understanding the impact of latency on globally distributed microservices infrastructure.
But this knowledge base doesn’t exist yet. It’s being built in real time. So working with developers who understand latency and can mitigate it as microservices scale is essential as your modernization efforts get underway—particularly for globally distributed systems.
Pitfall 3:
Ignoring the Impact of Latency
REST principles have been broadly adopted as part of API development efforts for many years now, so it’s natural to want to integrate them into your microservices as well. But here again, the interdependent nature of microservices requires a different mindset.
Microservices architectures rely on synchronous communication, while REST is suited towards asynchronous communication models where one service waits for the other to broadcast.
This may be fine as your modernization efforts get underway. But as the number of microservices scale up, you may have multiple microservices talking to each other, until one of them stops for whatever reason. It could be due to network issues, lack of service availability, speed of the application, or any number of reasons.
This break in the communication would force all other REST-based services to stop as well, waiting to hear back from the non-functional service. The more a REST-based microservices architecture scales, the more fragile it becomes.
The key is to develop and integrate API best practices that accommodate and encourage the synchronous communication that supports a robust microservices environment. One alternative best practice to consider would be gRPC, a more modern, open-source Remote Procedure Call that’s better suited to the needs of modernized environments.
Pitfall 4:
Depending Solely on REST Protocols
Jumping on the Microservices Bandwagon
This applies whether you’re developing one microservice or 10,000. For example, let’s say you have a business need to do batch uploads of sales tax data on a quarterly or annual basis. The amount of data may be large, but it’s infrequent.
Adding microservices to the application that handles the aggregation and handling of that tax information to decrease downtime during incremental releases isn’t going to drive business value or improve the customer experience. Availability isn’t a concern to the customer or a competitive differentiator. It may ease the continuous improvement/continuous development pipeline, but those benefits are only experienced by the development team.
In this case, investing in a microservice to improve a metric that isn’t important to the customer is only going to reduce the ROI for the entire modernization initiative. It’s much better to begin by focusing on fewer microservices efforts that deliver the greatest business value and/or improve the customer experience in ways they truly care about.
Pitfall 2:
More Microservices = Better
In a discussion a one customer recently, they proudly shared they had created 10,000 microservices. Our only response was to ask, “Is that a good thing?” Conventional wisdom would indicate that if one microservice is good, then lots of microservices must be better.
However, optimizing with microservices is only beneficial if it’s providing a clear business advantage. Before embarking on any microservices effort, you should know:
In a microservices architecture, each service relies on the others, and they’re in constant communication. But microservices are also distributed systems to the core. What happens in a global enterprise when one service gets implemented in the US while another is implemented in a European data center?
That distance between the two microservices adds just the slightest bit of latency to each remote call. It’s not enough for anyone to notice on its own. It’s also difficult to replicate in a development environment. But consider the implications as your microservices architecture continues to get built out, and you’re managing 10,000 microservices or more.
As the volume of microservices increases, that latency begins to add up and can negatively impact your overall performance. Years from now this won’t be an issue as developers will have gained considerable experience understanding the impact of latency on globally distributed microservices infrastructure.
But this knowledge base doesn’t exist yet. It’s being built in real time. So working with developers who understand latency and can mitigate it as microservices scale is essential as your modernization efforts get underway—particularly for globally distributed systems.
Pitfall 3:
Ignoring the Impact of Latency
REST principles have been broadly adopted as part of API development efforts for many years now, so it’s natural to want to integrate them into your microservices as well. But here again, the interdependent nature of microservices requires a different mindset.
Microservices architectures rely on synchronous communication, while REST is suited towards asynchronous communication models where one service waits for the other to broadcast.
This may be fine as your modernization efforts get underway. But as the number of microservices scale up, you may have multiple microservices talking to each other, until one of them stops for whatever reason. It could be due to network issues, lack of service availability, speed of the application, or any number of reasons.
This break in the communication would force all other REST-based services to stop as well, waiting to hear back from the non-functional service. The more a REST-based microservices architecture scales, the more fragile it becomes.
The key is to develop and integrate API best practices that accommodate and encourage the synchronous communication that supports a robust microservices environment. One alternative best practice to consider would be gRPC, a more modern, open-source Remote Procedure Call that’s better suited to the needs of modernized environments.
Pitfall 4:
Depending Solely on REST Protocols