21–30 of 38 posts
That's a hell lot of things to change, break, go down, lose your data, start charging ridiculous prices, be discontinued, etc... I'm all for SaaS and not re-inventing wheels, but I'd be nervous if I had to rely on so many external dependencies.
Earlier quoted context omitted.
Latency to another server in the same AWS availability zone is 1ms.
So it's really just a deployment solution for EC2?
The Bolt-On Engineering for Dummies.
"Don't reinvent the wheel." Classic advice. And it has some merit. But it's a broken idea.
Google? Not the first search company. The iPod? Not the first mp3 player. The iPhone? Not the first smartphone. Hacker news? Not the first tech oriented community site.
"Don't reinvent the wheel...
unless you think you can do much better."
Also, if you're merely iteratively improving the wheel, do so whenever you like. We don't drive around on hand-carved roughly circular hunks of wood any longer, and that's good.
Sigh. "Don't reinvent the wheel." Classic advice. And it has some merit. But it's a broken idea. Google? Not the first search company. The iPod? Not the first mp3 player. The iPhone? Not the first smartphone. Hacker news? Not the first tech oriented community site. "Don't reinvent the wheel... unless you think you can do much better." Also, if you're merely iteratively improving the wheel, do so whenever you like. We…
Earlier quoted context omitted.
I don't think that's a viable solution. Some of these are quite complicated and replicating them in-house is not something you just up and do in a short time. That tactic might expose you to significant downtime.
I agree they take a long time to replicate. Which is why it doesn't make any sense to me to suggest that you should build them in house before you get your product out to the world.
Sometimes though you can make do with something significantly simpler if you restate the problem slightly and move the pieces around.
You might be able to do the core of the job with a cron job and some command line tools rather than the fancy SaaS platform with graphs and everything.
Building on top of the fancy SaaS APIs and then trying to scale down when you want to move away is a lot more difficult than starting with the simpler approach and then scaling up when you really need that extra functionality.
Believe me, I've done it in both directions.
That's a hell lot of things to change, break, go down, lose your data, start charging ridiculous prices, be discontinued, etc... I'm all for SaaS and not re-inventing wheels, but I'd be nervous if I had to rely on so many external dependencies.
Presumably when any of those things happen, that's when you bring it in-house.
When you are raking in profits, you'd better use some of them to secure your business and make it independent of such risks. Which is the point the blog post seems to be trying to make.