4 ms·
It's ultimately a short-sighted choice - you get running really fast but then if you do well, you basically have to re-engineer from scratch. It's basically th
by nasalgoat 11y ago
It's ultimately a short-sighted choice - you get running really fast but then if you do well, you basically have to re-engineer from scratch.
It's basically the ultimate technical debt.
- xref 11y agoThis is what I'm worried about, PaaS lets you get going very quickly but if you succeed...well I haven't heard great stories about scaling out PaaS. The situation I'm in is our apps currently do low enough traffic to exist in a PaaS, but they weren't built that way from the ground up and live on bare metal currently. Migrating to say, AWS, would using ElasticBeanstalk be burdening myself with technical debt I don't currently have vs using something like CloudFormation (Terraform) and CodeDeploy?
- nasalgoat 11y agoWell, the question is - does that app have the potential to outgrow the SaaS offerings? There's plenty of things that won't, for a long time, so you're fine to save the time since you won't need to re-do it later. But if you can really see the product expanding to a large scale, you need to think a year or more into the future when planning your infrastructure.
- bpicolo 11y agoI'm not sure that's always the case. If it's e.g. RDS, moving to your own Postgres cluster is doable when necessary
- bpicolo 11y agoI'm not sure that's always the case. If it's e.g. RDS, moving to your own Postgres cluster is doable when necessary. You can certainly get vendor lock in in many cases though.