The more moving parts you add to a system , the more points of failure and latency you will add to your system. Not to mention their impact on your marginal costs.
Some specialized services are not only essential but also replicating them in-house is beyond the expertise of a normal start-up. I would put Stripe, AWS/Heroku/Google, Github in this list.
Others are neither essential (mission critical ) nor rocket science to implement in-house. The start-up has to figure out if the impact of these non-essential services on the marginal costs is justified or not. And how long can you get away without spending money on nice-to-have services ?
good points that need to be considered in building your startup! it's a balancing act, i think, and that balance will change over time. for me, with an early stage of my service, being able to focus on my system's features and functionality is more important than the performance and customization that i would get out of writing some of these services myself. i imagine that later on in the lifecycle of this system, i will remove some of the 3rd party services in favor of my own code. but right now, being able to get features done quickly is more important than the monthly subscription costs. i don't expect everyone's situation to be the same, but i think it's a good place to start when you are bootstrapping your own apps / services
I'm not fundamentally against SaaS, but I think it's not necessarily a good thing for every use case possible. I mean, it's a good thing that anyone can provision infrastructure with an API call, but there are two things I'm worried about:
- vendor lock-in: by integrating whoever's API in your code and making it part of your application you make it hard to switch to a similar service offered by someone else. Example: say you're writing a service that has to scale automatically. Cool, you can do this with EC2's APIs, so you integrate that in your application. When the threshold of request per second crosses a certain value, you spin up a new VM. If it's deeply integrated with Amazon's APIs (i.e you're using it to its full potential, tracking spot instances, whatever) it's very hard to switch to DigitalOcean, because they might have different concepts, and I'm not talking about just nomenclature.
- black box syndrome: you stop knowing how things work. This is convenient at first, but if you forget how to configure things "from the ground up", you stop being in control of your infrastructure/data, and ultimately, of your service.
definitely things that need to be considered - vendor lock in being the worst, IME. i'm less worried about API call integration, as i tend to isolate 3rd party APIs from my code... but that doesn't prevent all vendor lock-in.
for me, being able to focus on features is more important than these concerns, right now. i expect that over time i will take some of these tasks in and write the code myself, but at the moment i'm more concerned with feature growth.
My point is that even if you isolate 3rd party APIs from your code there might be things that can't be "translated". Obviously both EC2 and DigitalOcean give you the same basic product, virtualisation (the greatest common divisor), but the "quirks" each one of them have are the ones you should be exploiting to get maximum efficiency, and this is generally non-portable.
But yeah, I think SaaS is a great way to scaffold or MVP your ideas. You can have a hugely complex infrastructure up and running in just a few clicks, but I don't think it's a great long-term solution.
Derick, always impressed with your writing and work. The challenge I hit recently is that the saas providers I'd like to use don't enable the user experience I need my app to have. I will likely end up doing most everything directly on aws, even though I would prefer the improved time to market gained by leveraging higher level paas abstractions. Of course, iaas is still a nice high level abstraction itself :-)
thanks! :) i totally get the need to move things in house, too. i'm pretty happy that i can get the right experience for my users without having to do that, at this point. IaaS is definitely amazing! "oh, i need more servers? (fiddles with a knob) DONE!" :D
The more moving parts you add to a system , the more points of failure and latency you will add to your system. Not to mention their impact on your marginal costs.
Some specialized services are not only essential but also replicating them in-house is beyond the expertise of a normal start-up. I would put Stripe, AWS/Heroku/Google, Github in this list.
Others are neither essential (mission critical ) nor rocket science to implement in-house. The start-up has to figure out if the impact of these non-essential services on the marginal costs is justified or not. And how long can you get away without spending money on nice-to-have services ?