4 ms·

As for OP, I think his post mentions both systems architecture and software architecture, although he doesn't make a distinction. He cites scalability and main

As for OP, I think his post mentions both systems architecture and software architecture, although he doesn't make a distinction. He cites scalability and maintainability as 2 problems linked to a single definition of "architecture". One is more related to "systems architecture" and the other to "software architecture"... Also I'm not sure I agree 100% about "Software architecture precisely is about abstracting your application code away from technology". Say I want to go from MySQL and night batches to Cassandra and real time events processing: code is unlikely to survive, because of the paradigm shift. Say I want to go from a monolithic Rails application to a Rails REST api server + Angular front end. Same thing: most of the code will not survive. A worthwhile change in systems architecture is probably one some code will not survive to...

collyw 11y ago
If you have a solid database design, that part of your Rails app should remain the same.
- weddpros 11y ago
  Agree! I was kind enough to not throw a noSQL db in the lot :-)
Ace17 11y ago
OK, let me rephrase it. The better your software architecture is, the more resistant to technology changes it will be. (it doesn't only apply to technology changes, by the way). I understand your examples. When a technology changes occurs, all code directly depending on this technology doesn't "survive". If you make SQL requests from your view code, the view code will probably need to be mostly rewritten when you decide to change the database. But a good architecture will not feature SQL requests from the view code. A good architecture will prevent components to depend on things they don't need. A good architecture will introduce layers to guarantee some degree of independence. So when a technology change occurs, most of the code "survives". It all boils down to managing dependencies: you don't want high-level code (business rules, use cases) to depend on low-level code (storage, display). High-level code is the reason why your application exists. It's independent from low-level details such as "my storage system is a SQL database" or "my webserver is Apache", or even "the code runs on MS Windows". Porting is exactly this: changing some low-level concretion (OS, middleware) while keeping the same logical behaviour (i.e from the user point of view).
- weddpros 11y ago
  You can obtain some independence through software architecture, I agree... But it's no panacea. We thought ORMs would shield us from DBs change, then noSQL appeared. We thought 100 concurrent users were plenty and used 1 thread per user, but now it's 100M and we need event loops and sharding. We thought our server had one core, now it has 16, and we use 100s of these. OP's company thought using mySQL was a good idea, but maybe someday, nights will not be long enough for batches to run. Abstracting away mySQL will not help. Nowadays, the number of possible architectures has exploded. Moving from MySQL to Postgres solves no hard problem. But moving from MySQL to a cluster of Cassandra servers does, and it's hard. Just like moving from night batches to real time. I'm biased of course, because I'm working on projects where "old tools" can't be used because of scale. For "old style projects", old tools are still usable, and little benefit can be gained from newest systems architectures. But sometimes, the real "business problem" is scale, not complex business rules. Last word about software architecture: I'm the one who introduced my employer to modular developement, TDD or functional programming (and many others). I'm convinced good software architecture is of paramount importance, but it can't solve most paradigm shifts alone.
  - vezzy-fnord 11y ago
    What do you mean by "then NoSQL appeared"? It has always been around, it just became an extremely peculiar buzzword for a while.
    - weddpros 11y ago
      "It has always been around": not in 2000... I'm 43 :-)
      - vezzy-fnord 11y ago
        So what's this, then: https://en.wikipedia.org/wiki/Dbm https://en.wikipedia.org/wiki/Dbm
        11y ago

collyw 11y ago

If you have a solid database design, that part of your Rails app should remain the same.

weddpros 11y ago
Agree! I was kind enough to not throw a noSQL db in the lot :-)

Ace17 11y ago

OK, let me rephrase it. The better your software architecture is, the more resistant to technology changes it will be. (it doesn't only apply to technology changes, by the way). I understand your examples. When a technology changes occurs, all code directly depending on this technology doesn't "survive". If you make SQL requests from your view code, the view code will probably need to be mostly rewritten when you decide to change the database. But a good architecture will not feature SQL requests from the view code. A good architecture will prevent components to depend on things they don't need. A good architecture will introduce layers to guarantee some degree of independence. So when a technology change occurs, most of the code "survives". It all boils down to managing dependencies: you don't want high-level code (business rules, use cases) to depend on low-level code (storage, display). High-level code is the reason why your application exists. It's independent from low-level details such as "my storage system is a SQL database" or "my webserver is Apache", or even "the code runs on MS Windows". Porting is exactly this: changing some low-level concretion (OS, middleware) while keeping the same logical behaviour (i.e from the user point of view).

weddpros 11y ago
You can obtain some independence through software architecture, I agree... But it's no panacea. We thought ORMs would shield us from DBs change, then noSQL appeared. We thought 100 concurrent users were plenty and used 1 thread per user, but now it's 100M and we need event loops and sharding. We thought our server had one core, now it has 16, and we use 100s of these. OP's company thought using mySQL was a good idea, but maybe someday, nights will not be long enough for batches to run. Abstracting away mySQL will not help. Nowadays, the number of possible architectures has exploded. Moving from MySQL to Postgres solves no hard problem. But moving from MySQL to a cluster of Cassandra servers does, and it's hard. Just like moving from night batches to real time. I'm biased of course, because I'm working on projects where "old tools" can't be used because of scale. For "old style projects", old tools are still usable, and little benefit can be gained from newest systems architectures. But sometimes, the real "business problem" is scale, not complex business rules. Last word about software architecture: I'm the one who introduced my employer to modular developement, TDD or functional programming (and many others). I'm convinced good software architecture is of paramount importance, but it can't solve most paradigm shifts alone.
- vezzy-fnord 11y ago
  What do you mean by "then NoSQL appeared"? It has always been around, it just became an extremely peculiar buzzword for a while.
  - weddpros 11y ago
    "It has always been around": not in 2000... I'm 43 :-)
    - vezzy-fnord 11y ago
      So what's this, then: https://en.wikipedia.org/wiki/Dbm https://en.wikipedia.org/wiki/Dbm
      - 11y ago