No, you're still serving the same assets. It's only really an issue if your users like seeing where network requests are going and spot the cloudfront URL.
They don't actively lock you in which is great but you will almost certainly end up with bits of your workflow which are extremely dependant on Heroku. IMO pure AWS has exactly the same problem if not more.
If you compare this to deploying to "choose a generic VPS" the lock in is substantial. If any of my apps fail, I'm comfortable I can provision an Ubuntu VPS from any provider with a one line chef command and then deploy to it with one more.
So although Heroku isn't locking you in through any bad practices on their part, by using them you're choosing to make your workflow very specific to them. To me and quite a few of my clients, while Heroku is awesome for getting started, there isn't enough benefit for the increased single provider dependency and costs.
Not hating on them at all, I use them quite regularly, but I can understand where people are coming from when they talk about Vendor lock in. Perhaps a more accurate description would be single vendor dependency.
Yeah, I don't buy that. The build packs are open source. Clone them and use them to build your app. It's no different than Heroku. Yeah, you have rebuild some of the stuff they were giving you for free, but that's the whole premise behind their business. They handle things like deployments, etc. so that you don't have to.
Why can't you write a Chef cookbook, Ansible playbook, or the like to deploy a 12-factor-compliant app on a generic VPS? Especially since all the Heroku buildpacks are open source?
I think it's less that you can't and more that most people won't. The reason I know I can provision a new server for app x without hassle is because the chef setup to do it gets used regularly, it's part of the workflow of developing the app. If it breaks I know it's broken because next time me or someone in the team spins up a staging enviro, it won't work.
If you're using Heroku sure you could write that cookbook but in 90% of cases it's going to end up being unmaintained because it's there as a contingency that no-one uses in their everyday workflow. What's more for it to have real value it needs to be tested regularly to make sure it actually functions as expected.
So it's definitely possible to avoid the dependency as long as you don't mind adding a big chunk of devops work. At that point you've got to ask why are you paying the premium for Heroku if you're maintaining the devops expertise and codebase to deploy to a VPS alongside?
I'll try to get around to it, sure. Adept isn't a log-on issue it's after I'm authenticated, just any time you hit "History" it Rails errors, sometimes works after a few refreshes.
And that's exactly what I didn't mean. It's a sample of one, and offers no information whatsoever about how much code quality can contribute to success, except that rubbish code doesn't totally preclude the hope that a product might be successful.
Let's say things had turned out a little differently, and someone had used one of those SQL injections to irreversibly erase all of early Facebook's data. We'd probably never have heard of it again.
Code quality is a good thing - like scalability, and security. Ultimately, you might succeed without it. But it'll probably be easier if you do.
