![]() Easy defects are resolved, harder ones see additional code introduced – not to fix the defect, but to simply correct the outcome of the defect after it has happened. The initial production release left some amount of technical debt that was never addressed, and years of enhancements, bug fixes, band-aids, “code workarounds”, and the like have left a legacy system that is unpredictable, difficult to fix, enhance, or extend without introducing breaking changes. This pattern is seen in all sizes of companies – large and small, startups and Fortune 100. Each microservice is individually testable and deployable.Įxperience has demonstrated that a substantial amount of legacy systems are monolithic in nature and that there is a repeatable, recognizable pattern that happens in many companies. Since microservice implementation is encapsulated and the interface between the microservices and legacy application is RESTful, the microservice can be written in any language that supports building RESTful APIs. Microservices offer a great way to enforce the SRP when stabilizing a legacy application. The Single Responsibility Principle essentially says that functions, modules, or classes should have responsibility for a single piece of functionality that a software system needs and that responsibility should be encapsulated by the class. We often try to employ the Single Responsibility Principle (SRP) when building software. They allow developers to build in a more practical manner. Microservices are small, autonomous services that work together. Microservices are leading the charge in many modernization projects and for good reason. Sound all too familiar? If so, let’s talk about microservices – what they are and what are various strategies for determining where they might best fit in a stabilizing role. The team lead might say, “We can’t add new features because we end up breaking things even though we think we have tested the application end-to-end. When you ask why it is a priority at this time, it is explained to you that there are some defects that are impacting the business’s ability to operate and “workarounds” that once were sufficient enough to maintain the business process, no longer are. Imagine this scenario: You are working with your team who has been tasked with “stabilizing” a legacy web application that is core to both the operation of the company as well as revenue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |