5 ms·

My takeaways: 1. Stop. Trying. To. Build. Your. Own. Cloud. A pizza shop doesn't build their own cars to deliver pizzas. 2. There's no such thing as hassle-fr

My takeaways: 1. Stop. Trying. To. Build. Your. Own. Cloud. A pizza shop doesn't build their own cars to deliver pizzas. 2. There's no such thing as hassle-free anything, unless you are paying someone else to deal with the hassle. Sales teams lie. 3. Justifying an untested idea with "but it's modern technology" is going to backfire. Follow established patterns with good track records. 4. Writing your own in-house behemoth product, of which there are already many kinds available, results in long-term expensive engineering projects necessary to to get around the high costs you didn't know were coming. 5. Don't write business logic, or your primary software product, in a way that talks directly to a database. Just... No. 6. Magic new technologies that remove the problems of old technology also introduce the problems of new technology.

indigodaddy 8y ago
Point 5. I'm not a software/application person... can you expound on how else you would interact with a DB if not directly?
- dsirola 8y ago
  I'm pretty sure he wants to say that you should abstract your database away so that your business code / domain model doesn't depend on it. It becomes a "plugin" to your application and you can easily switch it just by writing another implementation.
  - kstrauser 8y ago
    I couldn't disagree more, at least in the context of this article. If you have an abstraction layer so high level that app developers can't tell whether they're using MongoDB or PostgreSQL, then they're not able to use any of the advantages of either of those systems. Sure, use an ORM to abstract away the differences between PostgreSQL and MySQL (up until you need to care about them). That's reasonable. But maintaining a magical MaybeSQL layer that's powerful enough to not totally suck is going to totally suck.
    - dsirola 8y ago
      Why wouldn't you be able to take advantage of those systems? I think it's quite the opposite where you can take the advantages without even knowing about it / affecting other parts of the system.
      - int_19h 8y ago
        Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits. (Alternatively, people find ways to use the abstraction layer such that it produces the desired usage pattern. Of course, then the code is no longer truly portable to another DB, because that same pattern is likely to be a perf issue there.)
        vincnetas 8y ago
        I'm pretty sure you can have one interface for YeSQL an NoSQL. * getUsers() * saveUser() * listUsers() * deleteUser() and implementation can implement it in specific way to take advantage of chosen technology. If you have some esoteric use cases they could be handled in special way separate from business code.
        kstrauser 8y ago
        For that specific use case, maybe. Where it falls apart is in `searchUser`, where the methods (and performance characteristics) of digging through the respective databases are going to be radically different. In a newspaper's implementation, you're going to have to search by date, subject, keyword, body text string, reporter, etc. etc. In MongoDB, that generally involves creating an index on the combination of fields you'll be searching together. In SQL, that generally looks like adding a `where reporter = "Jane Smith"` predicate. The MongoDB version may be faster if you have an enormous amount of data spread across a cluster. The PostgreSQL version will be more flexible when your boss wants to know how many reporters wrote stories about candied yams within three days of the publication of any story containing the word "Thanksgiving". Being tasked to come up with an abstraction layer that supports the speed of precomputed, clustered indexes with the flexibility of SQL - if I were in a content creation business and not a database engine writing business - sounds like the kind of project that would make me quit my job and go on a one year silent meditation retreat.
- BuckRogers 8y ago
  It could be an application frontend interfacing with a webservice or network service. That component handles the database. That could make implementations clean for migration from on-prem to cloud, or if you're ripping out the frontend stack semi-regularly as more web-oriented devs may do more often. I can't say I disagree, and moving an application to this model myself so that I can easily migrate it from a WinForms frontend to Blazor SPA at some point.
stuartaxelowen 8y ago
RE 5: I'd argue that with a relational database (barring extreme scale cases) is the perfect place for your business logic. Constraints, unique indexes, etc, all ensure that your data is always consistent with itself and with the business logic you've encoded.
mscasts 8y ago
Some issues with your statements: 1. Well, they probably own the car though which is a better parable. You don't need to rent your car, you can simply purchase it just as you can purchase servers. People build their own garages. 4. So you should only used already written software? Sometimes it is just faster and better to write it yourself. You get less dependencies, you know how the whole thing works etc. 5. Why not? That is exactly what one should do.
paraditedc 8y ago
Re 5: Adding an abstraction on top of DB query won't help much if you are moving from one type of DB to another, say SQL to document, or document to graph.

indigodaddy 8y ago

Point 5. I'm not a software/application person... can you expound on how else you would interact with a DB if not directly?

dsirola 8y ago
I'm pretty sure he wants to say that you should abstract your database away so that your business code / domain model doesn't depend on it. It becomes a "plugin" to your application and you can easily switch it just by writing another implementation.
- kstrauser 8y ago
  I couldn't disagree more, at least in the context of this article. If you have an abstraction layer so high level that app developers can't tell whether they're using MongoDB or PostgreSQL, then they're not able to use any of the advantages of either of those systems. Sure, use an ORM to abstract away the differences between PostgreSQL and MySQL (up until you need to care about them). That's reasonable. But maintaining a magical MaybeSQL layer that's powerful enough to not totally suck is going to totally suck.
  - dsirola 8y ago
    Why wouldn't you be able to take advantage of those systems? I think it's quite the opposite where you can take the advantages without even knowing about it / affecting other parts of the system.
    - int_19h 8y ago
      Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits. (Alternatively, people find ways to use the abstraction layer such that it produces the desired usage pattern. Of course, then the code is no longer truly portable to another DB, because that same pattern is likely to be a perf issue there.)
      - vincnetas 8y ago
        I'm pretty sure you can have one interface for YeSQL an NoSQL. * getUsers() * saveUser() * listUsers() * deleteUser() and implementation can implement it in specific way to take advantage of chosen technology. If you have some esoteric use cases they could be handled in special way separate from business code.
        kstrauser 8y ago
        For that specific use case, maybe. Where it falls apart is in `searchUser`, where the methods (and performance characteristics) of digging through the respective databases are going to be radically different. In a newspaper's implementation, you're going to have to search by date, subject, keyword, body text string, reporter, etc. etc. In MongoDB, that generally involves creating an index on the combination of fields you'll be searching together. In SQL, that generally looks like adding a `where reporter = "Jane Smith"` predicate. The MongoDB version may be faster if you have an enormous amount of data spread across a cluster. The PostgreSQL version will be more flexible when your boss wants to know how many reporters wrote stories about candied yams within three days of the publication of any story containing the word "Thanksgiving". Being tasked to come up with an abstraction layer that supports the speed of precomputed, clustered indexes with the flexibility of SQL - if I were in a content creation business and not a database engine writing business - sounds like the kind of project that would make me quit my job and go on a one year silent meditation retreat.
BuckRogers 8y ago
It could be an application frontend interfacing with a webservice or network service. That component handles the database. That could make implementations clean for migration from on-prem to cloud, or if you're ripping out the frontend stack semi-regularly as more web-oriented devs may do more often. I can't say I disagree, and moving an application to this model myself so that I can easily migrate it from a WinForms frontend to Blazor SPA at some point.

stuartaxelowen 8y ago

RE 5: I'd argue that with a relational database (barring extreme scale cases) is the perfect place for your business logic. Constraints, unique indexes, etc, all ensure that your data is always consistent with itself and with the business logic you've encoded.

mscasts 8y ago

Some issues with your statements: 1. Well, they probably own the car though which is a better parable. You don't need to rent your car, you can simply purchase it just as you can purchase servers. People build their own garages. 4. So you should only used already written software? Sometimes it is just faster and better to write it yourself. You get less dependencies, you know how the whole thing works etc. 5. Why not? That is exactly what one should do.

paraditedc 8y ago

Re 5: Adding an abstraction on top of DB query won't help much if you are moving from one type of DB to another, say SQL to document, or document to graph.