SaaS vs build

[AdrianCole]

Hi, guys.

I don't know why exactly the latest devops cafe post spurred this tangent, but I'm interested in your take on...

When do you decide to take advantage of awesome SaaS X that "really could save you hours + expensive hires" vs something "you could build similarly"?

I'll scope it to a case where your service runs on the same infrastructure SaaS X does (ex. same EC2 region, etc).  Ex. say you have free servers.. would you use CloudBees?  When wouldn't you?  say you have kick-ass mongo dude.. would you run mongohq, or would you not?  Does strategy of the SaaS company affect your position one way or another?  What do you care about?

What makes you leap towards or away from SaaS vs build?

/me listens

-A

[Max Lincoln]

I wouldn't call either SaaS.  SaaS is typically a complete product that end users can sign-up and start using - like Salesforce, Google Apps, Loggly, Expensify, Mvelopes or TripIt.  They are more Platform as a Service (PaaS).  CloudBees labels themselves as PaaS.  Wikipedia calls MongoHQ "Data as a Service", but I just think of it as the data portion of the platform.  So it's arguably (Data) PaaS.

Its difficult to make many generalizations about build-vs-buy decisions, but I'll try.  I often lean towards PaaS for small, fast-paced projects and spikes.  I'll use PaaS on larger projects if it looks like a good fit, but you need to be more cautious about risks of vendor lock-in and not having full control of the platform.

PaaS advantage: You have fewer problems to solve.  Many PaaS options take care of deployments, maintenance, and scalability and have partners available for monitoring and other services.

IaaS advantage: You are less locked-in to a vendor, especially if you just use it as a "self-service data center".  If you're just spinning up blank servers and handling everything from there then it doesn't matter if its Amazon, Rackspace, Linode, or your own data center.

[Ryan Miller]

For apps that non-technical people will use, SaaS is a no-brainer as long as you can get your data in and out, because UI/UX is hard--look at the time people waste on all the internal apps with terrible UX, even at big companies.  For infrastructure, I think they only make sense if you don't have the talent in-house, and aren't the sort of business that will easily be able to attract such talent (too small or too Dilbert).

Yes, good sysadmins are expensive, but a good sysadmin will quickly turn "managing 25 application servers" into a pretty trivial part of his job.  Then he'll help you with your build/test pipeline, architecting for performance and redundancy, planning for migrations to new providers, etc.  Devs hate doing infrastructure, and even with cloud & SaaS, there's still a good bit of infrastructure that needs doing.

Ryan

[Christopher Webber]

For me, it is about analyzing where it fits as far as business value goes. For example, sure I could run my own jabber server, or my own git server neither of those make sense. On the other hand, lighting up an icinga server and a graphite box made sense because of the added flexibility along with the nature of my network.

-- cwebber

[Ryan Miller]

Chris--yes, I guess I was thinking of deployment infrastructure, not services that don't have to layer with your own code.  Once you have a couple of sysadmins for other reasons Jabber and Git are trivial to insource, but they're definitely great candidates to start outside.  Outsourced monitoring is much more frighteningly expensive, inflexible, and hard to troubleshoot.

Max--I'd agree with your PaaS criteria except nobody ever knows what projects will stay small.

Ryan

[Max Lincoln]

Ryan - You just need to know what projects will start small :)

My favorite measure of project size is "how soon are we going to production."  You could have a project that will put out an initial version in 1 month, but has years worth of features in the backlog.  Those projects might make sense to start on a public PaaS, but could shift to your own custom platform on IaaS later.

[Adrian Cole]

Yeah, so I tried to dodge the PaaS part of this, as typically that is a tougher call to buy wholesale into or our of.  In hindsight, I also realize how aged my shortcut of "cloudbees" for "JenikinsaaS" is :)

Great angles though and particularly I think we could spend ages on the 'data part of the paas' as particularly services like mongo can be viewed from that angle, as DaaS, and probably even strategic in cases where it is put to use in product specific ways.

Anyhow... from this thread I'm gathering a few thoughts in such a decision:
* Is there impact to either choice (ex. Non strategic or no big deal to bring back)
* Is flexibility with the tool strategic to producing value?
* Can the cost of this service get scary?
* Is there a staffing point where this can be insourced with little impact?
* How evolved is the troubleshooting process? Is it better or worse than off the shelf?

What did I miss/misinterpret?

Also, I've not heard too much about is where the SaaS/PieceOfPaaS is a happier place.  Ex. Like normal software, premium services has more features, or even cannot be installed at all.  Do you have examples where some 'thing you need as a service' like escalation, backups, etc were only available as a service and you felt best to go ahead and use it? Why, or what made the call not to?

-A