Ignore these common development practices for maximum success
Back to table of contents
Using Fitness-Function Driven Development to optimize product modernization efforts
Next
03
Previous
01
Beware of these pitfalls on your product modernization journey
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
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
Modernizing your products by taking advantage of microservices means challenging—and even abandoning—many of the legacy assumptions that led to successful results in the past.
Think about the transition from waterfall/iterative development models to agile; trying to apply iterative practices in an agile environment is counterproductive at best. The same situation applies as you move from monolithic to microservices. With that in mind, here are five legacy development practices you should leave behind in your product modernization journey. Each of these is explained in greater detail in Microservices Antipatterns and Pitfalls by Mark Richards.
Data is the fuel the engine of business relies on, so our instinct is to want to begin understanding where the data is now and where it will be needed after any modernization effort is complete. We want to rush to start mapping out databases and how they can be parsed out to suit our needs before we even know why we’re doing it.
That’s counterproductive from the start. As noted in the pitfalls earlier, the focus of any microservices initiative must begin with the needs of the business first. Let the functional needs drive the modernization effort, not the type, location, and size of the databases.
Practice 1:
Modernizing your products by taking advantage of microservices means challenging—and even abandoning—many of the legacy assumptions that led to successful results in the past.
Think about the transition from waterfall/iterative development models to agile; trying to apply iterative practices in an agile environment is counterproductive at best. The same situation applies as you move from monolithic to microservices. With that in mind, here are five legacy development practices you should leave behind in your product modernization journey. Each of these is explained in greater detail in
Microservices Antipatterns and Pitfalls by Mark Richards.
Avoid data-driven migration
Timeout patterns are frequently considered as a solution to increase resiliency in distributed systems, which would make a microservices environment an ideal application.
However, timeout patterns are most valuable in situations where one service is reliant on one or more additional services to function. That’s the opposite of a well-designed microservices architecture which is specifically designed to eliminate these kinds of dependencies.
Consider circuit breaker patters for microservices architectures instead. Circuit breaker patterns prevent services from trying to communicate with another remote service—or access a shared resource— if that effort is likely to fail. They’re a better approach to improving stability in the event of a service failure anywhere in the distributed microservices system.
Practice 2:
Don’t rely on timeout patterns
Why you’re creating it
What business benefit it’s going to deliver
How it’s going to scale up
Since our earliest days of school, we’ve been taught the benefits of sharing, and that concept has been embedded through our experience as developers as well.
Successful microservices requires a complete change in mindset, however, microservices is a “share-nothing” architecture, meaning each microservice has its own codebase, entirely separate from every other service.
This ultimately means more code is being written, but the resulting microservices are loosely coupled and independent of one another. This increases performance, stability, and scalability—a few of the cornerstone benefits of product modernization.
Practice 3:
Sharing is not necessarily a good thing
Many legacy reporting applications address the need to deliver timely reports by simply going into the database and taking what they want. Timely, yes, but this can create the exact type of interdependencies you want to eliminate in a microservices environment.
Instead of pulling the data out—through direct database extraction, RESTful HTTP calls or batched requests—it is far better to rely on an event-based push model. This asynchronous approach allows each microservice to report its own updates to an independent reporting service. This approach delivers the most correct information in the timeliest fashion without creating interdependencies than can burden the microservices environment unnecessarily.
Practice 4:
Move away from reach-in reporting