Twitter

Tag: technical-debt

I want to start off by saying that having a monolithic application isn’t always a bad thing, and this article may not necessarily be for you. Yet. It just comes down to the correct timing of using microservices when it make sense and then diving into that work at the moment it’s needed, and not a moment later. Utilizing a microservices architecture too soon will hold you back and slow the development process back, whereas waiting too long to perform the migration makes the refactoring effort very painful.

If you have a single product that was designed well, is easily maintainable, and carries minimal technical debt, you may not have a lot of reasons to invest into a microservices architecture. Or certain areas are becoming areas of concern for performance and scalability, then you may slowly split those areas out.

If you’re like the rest of us dealing with multiple products through acquisitions, mergers, or reorganizations that were originally built in a time long ago before best practices existed for online services, there is little hope that it is maintainable or carrying minimal technical debt.

Unless you have some really great connections, every type of debt I have ever had the displeasure of dealing with has come with some sort of interest payment. If your company has adopted Agile software development methodologies (Scrum, Kanban, XP, etc), but is only delivering software on a quarterly basis (or less often), chances are that you are paying a ‘release debt’ with interest.

If the concept of ‘technical debt’ could be overly simplified as ‘stuff that you’ve been meaning to fix‘, then you could easily view release debt as ‘stuff that you’ve been meaning to deploy‘.Continue reading