4 ms·

Offering advice is difficult without more information... but I'll try. Yet maybe I'm talking more about systems architecture than software architecture. A cutt

Offering advice is difficult without more information... but I'll try. Yet maybe I'm talking more about systems architecture than software architecture. A cutting-edge architecture is often using cutting-edge technologies. We don't have much details about your system, but it feels like "big data" is your keyword: be it NoSQL databases, map-reduce, or maybe streaming/events systems are areas to investigate. Apache has many projects related to big data, which may give you a broader vision... and guide you. Be prepared for a paradigm shift: you can't apply old recipes to new technologies. For example, believing Cassandra could replace MySQL because it has "almost SQL" would be such a mistake: Cassandra requires a different data model. Try to understand how big data technologies could fit together for your problem, and you'll gain valuable insight. Apply these technologies in a successful project, and you'll gain experience. As for your frontend, in terms of architecture, there's not much that can be done but to decouple it (with a REST api) if not already done... It could make a rewrite easier. Sorry for such general advice. Maybe it's too basic to really help you.

Ace17 11y ago
Software architecture precisely is about abstracting your application code away from technology. Practising TDD is a good way to allow you learn about how to better design your components. Because all your components end up having two clients: your application code, and your test code. This will guide you through better components interfaces (and also make your code a lot more flexible!).
- weddpros 11y ago
  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.

Ace17 11y ago

Software architecture precisely is about abstracting your application code away from technology. Practising TDD is a good way to allow you learn about how to better design your components. Because all your components end up having two clients: your application code, and your test code. This will guide you through better components interfaces (and also make your code a lot more flexible!).

weddpros 11y ago
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.