4 ms·

Why not slowly decompose the functionality of your software into modules, abstract those behind some kind of abstract interface, and then move those abstracted

Why not slowly decompose the functionality of your software into modules, abstract those behind some kind of abstract interface, and then move those abstracted modules into microservices when the time comes? Just by slowly rebuilding components as you need to touch them you'll be able to maintain some velocity on feature development, be able to incrementally test your changes to the codebase, and actually find the real world logical groupings of functionality (rather than guessing on business domain like most SOAs do). Full rewrites like this are a pain, high risk, and always take longer than expected (feature creep/deployment/etc)

bwilliams 7y ago
Rewriting piecemeal is a great idea but extracting microservices adds a whole new set of problems that likely aren't worth the tradeoff, especially when your team is just you or only few other people. eg: Now your devops responsibilities aren't just deploying and keeping 1 app up and running, it's all of them.
- gravypod 7y ago
  I specifically mention this in reference to "when the time comes". Sometimes the devops work is worth it. If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc. It's all trade offs and just choosing when you want to make them. If adding 10k QPS load to your monolithic app is going to cost more than the (TOOLS + DEPLOYMENT STRATEGY + INTEGRATION TESTING + ETC) then it's worth pulling it out.
  - bwilliams 7y ago
    I 100% agree it's all trade-offs. I think cost is important, but in that scenario it's going to cost them a lot more in time to split out and maintain several services. Devops was only one example. Their development speed will also likely slow down by a good margin as they now have to worry about inter-service communication and all that comes with it (keeping schemas aligned, making sure the services can actually talk to one another, etc.). I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.
  - geezerjay 7y ago
    > If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc. Serverless costs you money. Running a low-volume db in the same VM you serve the site and the web api costs you zero.
Chris_Newton 7y ago
Full rewrites like this are a pain, high risk, and always take longer than expected (feature creep/deployment/etc) This is accepted wisdom in large parts of the software development world, but I have become sceptical about treating it as a universal rule. In the end, all software maintenance means rewriting part of the system at some scale, whether it’s a one-line bug fix or a Big Rewrite of the whole world. Both the risks and the potential benefits typically increase with the scale of the job, so how much of the system to change in one go is always a cost/benefit question. All software maintenance where we delete or modify old code risks losing subtle bug fixes and behaviour tweaks that have accumulated in that code. However, it also gives us a chance to make the new code more systematic and to take into account additional knowledge gained and better tools that have become available since the older version was written. This means the new version also has an opportunity to eliminate subtle bugs and awkward edge cases that have accumulated in the old code. For me, one of the times when a relatively large rewrite is indicated is when there are big changes to the foundations on which the system or some part of it is built: you need to support new hardware or run on a new operating system, there’s a big update to your programming language available and you want to be able to use it, the protocols or APIs or data models used to interact with other systems have changed. Another is when the original software architecture has been outgrown and technical debt is severely affecting productivity. In this case, it appears that both of those factors may apply, so maybe a wide-reaching update does make sense.
- lugg 7y ago
  I'm of a similar mind but tend towards avoiding rewrites, mostly because I find refactoring more efficient. And with that in mind, I should clarify im not opposed to a complete gutting of a legacy codebase and I'm not afraid of doing it in a full rewrite sense of the word either. I just like to have a strategy and keep master green throughout. > risks losing subtle bug fixes and behaviour tweaks that have accumulated in that code. This shouldn't be happening in a sufficiently tested or sufficiently understood system and I feel like using it as an excuse to not rewrite is a lack of reasoning skills. Full rewrites are a waste of time because you end up spending way more time than expected making useless decisions around the edges about APIs that really don't matter that much. Or you end up finding out your dream design has a fatal flaw. Or you end up just porting a bunch of boiler plate. Rule of thumb, If you can't figure out a peicemeal way to refactor what you have into what you want you want, you have no business discussing what a rewrite should entail. And a caveat to all this, I know a couple of teams that rewrite every system on a two year schedule. They do this as a a way to stay nimble. I believe their feature set and domain requirements are well known. This sort of setup has a few benefits and traits I like. Most notably the fact design skills are constantly being flexed instead of stagnating. Junior devs are made into seniors with this process.
davidgl 7y ago
A classic on the dangers on full rewrites - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
jyriand 7y ago
Not sure where I heard it (probably some podcast), but Basecamp is rewritten every few years from scratch.
- jrs235 7y ago
  It may be rewritten but it is an entirely new product. The new code does not replace old code. The old code continues to live and run on/with the older product. This reduces risk of breaking things but also increases costs due to running multiple versions. It's all trade-offs.

bwilliams 7y ago

Rewriting piecemeal is a great idea but extracting microservices adds a whole new set of problems that likely aren't worth the tradeoff, especially when your team is just you or only few other people. eg: Now your devops responsibilities aren't just deploying and keeping 1 app up and running, it's all of them.

gravypod 7y ago
I specifically mention this in reference to "when the time comes". Sometimes the devops work is worth it. If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc. It's all trade offs and just choosing when you want to make them. If adding 10k QPS load to your monolithic app is going to cost more than the (TOOLS + DEPLOYMENT STRATEGY + INTEGRATION TESTING + ETC) then it's worth pulling it out.
- bwilliams 7y ago
  I 100% agree it's all trade-offs. I think cost is important, but in that scenario it's going to cost them a lot more in time to split out and maintain several services. Devops was only one example. Their development speed will also likely slow down by a good margin as they now have to worry about inter-service communication and all that comes with it (keeping schemas aligned, making sure the services can actually talk to one another, etc.). I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.
- geezerjay 7y ago
  > If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc. Serverless costs you money. Running a low-volume db in the same VM you serve the site and the web api costs you zero.

Chris_Newton 7y ago

Full rewrites like this are a pain, high risk, and always take longer than expected (feature creep/deployment/etc) This is accepted wisdom in large parts of the software development world, but I have become sceptical about treating it as a universal rule. In the end, all software maintenance means rewriting part of the system at some scale, whether it’s a one-line bug fix or a Big Rewrite of the whole world. Both the risks and the potential benefits typically increase with the scale of the job, so how much of the system to change in one go is always a cost/benefit question. All software maintenance where we delete or modify old code risks losing subtle bug fixes and behaviour tweaks that have accumulated in that code. However, it also gives us a chance to make the new code more systematic and to take into account additional knowledge gained and better tools that have become available since the older version was written. This means the new version also has an opportunity to eliminate subtle bugs and awkward edge cases that have accumulated in the old code. For me, one of the times when a relatively large rewrite is indicated is when there are big changes to the foundations on which the system or some part of it is built: you need to support new hardware or run on a new operating system, there’s a big update to your programming language available and you want to be able to use it, the protocols or APIs or data models used to interact with other systems have changed. Another is when the original software architecture has been outgrown and technical debt is severely affecting productivity. In this case, it appears that both of those factors may apply, so maybe a wide-reaching update does make sense.

lugg 7y ago
I'm of a similar mind but tend towards avoiding rewrites, mostly because I find refactoring more efficient. And with that in mind, I should clarify im not opposed to a complete gutting of a legacy codebase and I'm not afraid of doing it in a full rewrite sense of the word either. I just like to have a strategy and keep master green throughout. > risks losing subtle bug fixes and behaviour tweaks that have accumulated in that code. This shouldn't be happening in a sufficiently tested or sufficiently understood system and I feel like using it as an excuse to not rewrite is a lack of reasoning skills. Full rewrites are a waste of time because you end up spending way more time than expected making useless decisions around the edges about APIs that really don't matter that much. Or you end up finding out your dream design has a fatal flaw. Or you end up just porting a bunch of boiler plate. Rule of thumb, If you can't figure out a peicemeal way to refactor what you have into what you want you want, you have no business discussing what a rewrite should entail. And a caveat to all this, I know a couple of teams that rewrite every system on a two year schedule. They do this as a a way to stay nimble. I believe their feature set and domain requirements are well known. This sort of setup has a few benefits and traits I like. Most notably the fact design skills are constantly being flexed instead of stagnating. Junior devs are made into seniors with this process.

davidgl 7y ago

A classic on the dangers on full rewrites - https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

jyriand 7y ago

Not sure where I heard it (probably some podcast), but Basecamp is rewritten every few years from scratch.

jrs235 7y ago
It may be rewritten but it is an entirely new product. The new code does not replace old code. The old code continues to live and run on/with the older product. This reduces risk of breaking things but also increases costs due to running multiple versions. It's all trade-offs.