Diego Pacheco Tech blog

Have you ever thought about how to evaluate software? Outside of the context of Build vs Buy - Sounds like a crazy question, right? Well, the reality is that at scale, you must do more than just refactor everything for the sake of refactoring. Re-writes, Refactorings, and Re-Architect need to be opportunistic and deliver real value to the business. So if it's pretty hard to refactor everything, how to approach software at scale? Some rationalization of the state of affairs is important. Rationalization leads to proper prioritization paired with a good execution can be a powerful tool to deliver change and improve quality. First, the question might sound a bit overwhelming and difficult, but when you start diving deep, you realize what makes sense and what dont, and some shapes emerge. So before I go too deep into this matter, let's start with a simple question - why evaluate software? Why Evaluate software? Besides the context of Build vs Buy - There are plenty of reasons to ev...

Big Companies have lots of software. The Software industry moves pretty fast. However, not all pieces of software are moving that fast. There are always competing priorities between news business domains, acquisitions, new features, improving user experience, fixing bugs, improving security, and being up to date. If you have good architecture, isolation of databases, proper contracts, and tests, migrations can be much easier. However, not all pieces of software have the same conditions as you might have orphan software with no owners, old tech, lack of testing, lack of isolation; in those conditions, migrations could be pretty challenging. There will always have migrations one way or another. In the last decade, lots of companies have been migrating from on-premises to the Cloud. 

The first blot post on this series was focus on the data part. This one will be focused on the code and functionality part.  After explaining the Strangler Pattern and understanding some of the options and the challenges, we will cover how we can combine Strangler and CDC as the ultimate solution for Slice and Dice the Monolith. Migrations are hard and often need to be performed into waves. There is a reason for that. Strangler is a code pattern focused on stopping the bleeding and either easily or more painfully migrating to a new codebase from either a legacy or a poorly designed solution. Some people have issues understanding Strangler, but it's an incremental pattern; even when you do things a bit, atomically, it's incremental(minimum 3 steps).