Currently I have the feeling that successfull companies are mostly using SOA architectures, but startups/individuals are writing their whole apps with Django/Flask/Rails/Play.
What would have to change so that those architectures were the obvious way to write an app in the first place? (One could argue they never are the proper way).
Searching somewhat it seems there aren't many posts describing Rails/Django/PHP <-> Backend Service recipes.
Speaking as someone who is using SOA at a startup...
I think there's a lot of value in it, but I also think SOA is overkill for a lot of projects. Plus, given the amount of pivoting that goes on with projects at the beginning, you might wind up implementing a SOA in a totally wrong way. It just seems like a lot of extra overhead. Plus, in many cases you can gradually migrate your project later to a SOA, depending on where the bottlenecks are.
Just as most people borrow to buy their first home tech debt can be good to take on knowingly in a lot of circumstances. As long as the debt is being used to finance higher returns it's a very good idea.
For a new venture it can reduce risk and bring advantages such as time to market. PHP is a major tech debt for most organizations, but it was probably worth it for Facebook.
This might be a good time to restate Markham's Rule of Technical Debt: Technical Debt can never be more than the value of the program to the user
Sure, it might cost a million bucks to rewrite all that bad code. But if the program only provides enough value to some user somewhere to be worth ten dollars, you can never have more than ten dollars worth of technical debt associated with it, no matter what it looks like.
Why don't you call it the bankruptcy rule? It's similar to: Equity in a limited liability company can never turn negative, since you can just let the company go bust.
5 comments
[ 2.3 ms ] story [ 21.6 ms ] threadWhat would have to change so that those architectures were the obvious way to write an app in the first place? (One could argue they never are the proper way).
Searching somewhat it seems there aren't many posts describing Rails/Django/PHP <-> Backend Service recipes.
I think there's a lot of value in it, but I also think SOA is overkill for a lot of projects. Plus, given the amount of pivoting that goes on with projects at the beginning, you might wind up implementing a SOA in a totally wrong way. It just seems like a lot of extra overhead. Plus, in many cases you can gradually migrate your project later to a SOA, depending on where the bottlenecks are.
For a new venture it can reduce risk and bring advantages such as time to market. PHP is a major tech debt for most organizations, but it was probably worth it for Facebook.
Sure, it might cost a million bucks to rewrite all that bad code. But if the program only provides enough value to some user somewhere to be worth ten dollars, you can never have more than ten dollars worth of technical debt associated with it, no matter what it looks like.