"unless you’re willing to spend beaucoup dollars on buying and operating physical infrastructure"
This is the biggest misconception out there about cloud computing.
Cloud computing has nothing to do with saving money. It is usually MORE expensive than comparable--and even more powerful--physical hardware. The advantage of cloud computing is the ability to spin up and shut down instances when you want.
But this time, Wordnik got smart and tuned the application to account for the strengths and weaknesses of MongoDB (“Your app should be smarter than your database,” he says), and MongoDB to account for the strengths and weaknesses of the cloud.
That's my one major concern about Mongo DB. When I'm using a traditional database with a well normalized schema, my app doesn't have to be smarter than my database. My app can be pretty dumb, actually, and rely on the database to handle optimizing the way it stores data. Having the app concerned with the way data is stored violates the separation of concerns in my mind. The app should be dealing with transforming and performing logic on the data. Let the database deal with the messy details of how the data is actually stored.
Excluding projects that immediately crashed and burned, I've never seen a database used by just one app. Even apps all in the same language is very rare. If anyone on your team can absent-mindedly circumvent all your data integrity rules merely by setting up a database client, you're in for some long and painful nights.
8 comments
[ 3.7 ms ] story [ 39.8 ms ] threadThis is the biggest misconception out there about cloud computing.
Cloud computing has nothing to do with saving money. It is usually MORE expensive than comparable--and even more powerful--physical hardware. The advantage of cloud computing is the ability to spin up and shut down instances when you want.
That's my one major concern about Mongo DB. When I'm using a traditional database with a well normalized schema, my app doesn't have to be smarter than my database. My app can be pretty dumb, actually, and rely on the database to handle optimizing the way it stores data. Having the app concerned with the way data is stored violates the separation of concerns in my mind. The app should be dealing with transforming and performing logic on the data. Let the database deal with the messy details of how the data is actually stored.
For too long we've assumed the solution is tightly structured data, when nature shows us that this is incorrect. Yet we ignore it because it's hard.