

Stitching Together A SaaS of SaaS (and never owning a server) - derickbailey
http://lostechies.com/derickbailey/2014/01/14/stitching-together-a-saas-of-saas-and-never-owning-a-single-server/

======
manishsharan
Lets think this through !

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 ?

~~~
derickbailey
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

------
jdiez17
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.

~~~
derickbailey
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.

~~~
jdiez17
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.

------
davidjnelson
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 :-)

~~~
derickbailey
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

------
etimesg
For those dealing with multiple services, I recommend taking a look at Zapier
(zapier.com) for automating data exchange between *aaS providers.

------
zgohr
Opinion on a good CRM that isn't Salesforce?

~~~
etimesg
[http://www.zoho.com](http://www.zoho.com) is the one I have been using
recently, but unfortunately I don't have much experience with Salesforce to
make a proper comparison.

