[azov]

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.

[kevinastone]

I think the vendor lock-in (cough heroku) is the bigger risk rather than reliability.

[benjah]

I've heard this a lot lately. Heroku uses super standard stuff (nginx,varnish,postgres,etc). I could move my stuff off Heroku in a matter of days. I used to do a lot of sysadmin work. I go with them because I can't devote time to sysadmin work anymore. Same reason I don't run my own mail servers anymore.

[kevinastone]

I'd argue mail servers (as SMTP endpoints) are more interchangeable than Heroku. They have a completely proprietary configuration and deployment process.

I can understand that competent sysadmins can recreate heroku's underlying hosting, but there's still a decent switching cost (especially if your whole team is accustomed to the heroku way). I've consulted with several companies that have 5-figure a month hosting on heroku that they can't migrate after all their investment.

If SendGrid changes my plan (or somehow degrades), it's a simple config change to send my email through another provider. A more apt comparison would be if your mail provider used a custom ReST endpoint instead of SMTP (say, as MailChimp does).

[benjah]

I agree. If you don't have any good sysadmin in your team, you are likely to be stuck at heroku. But then again, if you didn't have a sysadmin, you wouldn't have built it yourself. Starting at heroku or similar clone, still makes sense if your new thing may not make it past the first year. I guess it also depends what the business model is.

[pbiggar]

Presumably when any of those things happen, that's when you bring it in-house.

[lazyjones]

You should bring it in-house as soon as it becomes critical for your business. Only startups that aren't profitable yet should bet their skin on so many hosted services as long as they allow them to grow faster (that's not a given, sometimes SaaS/PaaS are complicated to use and unstable).

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.

[Hansi]

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.

[pbiggar]

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.

[jiggy2011]

It depends, sometimes you really do need the big complicated thing and you don't have time/money to develop it in house.

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.