
Paying Money To Save It And Doing More With Less - bbrunner
http://brianbrunner.com/automation/saas/2013/10/23/automation.html
======
nahname
Jenkins easily runs on a $20/month digital ocean box and should take less than
2 hours to setup. I scripted jenkins to shutdown and wake up the workers on
heroku during off hours. It took me less than five minutes to script up the
job and saves us $35 a month per environment. Effectively, jenkins costs
nothing per month (actually saves us money).

Most testing services are horribly over priced and you don't get that level of
control. Maybe you want to reconsider that one?

[http://travis-ci.com/plans](http://travis-ci.com/plans)

[https://circleci.com/pricing](https://circleci.com/pricing)

[https://www.digitalocean.com/community/articles/how-to-
insta...](https://www.digitalocean.com/community/articles/how-to-install-and-
use-jenkins-on-ubuntu-12-04)

~~~
arohner
Thanks for the link! (founder of CircleCI here)

Before Circle, I led multiple engineering teams, building multiple products
from "nothing" to "shipping, and making lots of money". I set up buildbot,
hudson, bamboo, jenkins, and some other things I don't even remember the name
of. I was always the build guy, I was always the one that said "yes, we will
be testing, yes, the build will be green." Those were controversial statements
back then.

I've been there, done that, and I didn't want to set up Bamboo again. I didn't
want to debug why the tests failed. That's why I built Circle.

Our customers, most of whom switched from Jenkins, will tell you we are a
steal.

Maybe your project is still simple. Maybe your platform is fairly stable. But
for most professional developers, keeping CI running and green is a challenge.
Even at Circle, I spend more time than I'd like debugging the test suite. But
we're fixing that. Every day is spent making devs lives easier.

Jenkins costs you nothing per month, but your developers cost money, and
Circle's hardware is faster than digital ocean, and the cost of keeping the
build green on Circle is lower than the cost of keeping it green on Jenkins
anywhere else. If you're running a startup, or a tech company, odds are very
good that salary is the number one cost center. Optimizing your Digital Ocean
bill is penny wise, pound foolish.

~~~
nahname
>Maybe your project is still simple.

It's moving past the simple app point that gets problematic on someone else's
solution.

I have dependencies on postgres, redis and elasticsearch within the
application. I need a browser too run the feature tests. I need phantomjs to
run the javascript suite. Is there any saas offer that covers these?

>...keeping the build green on Circle is lower than the cost of keeping it
green on Jenkins anywhere else

Keeping the build green involves my team figuring out what we broke. Faster
build times help, is that what you mean here?

Don't even get me started on the stuff we are doing with deployment
automation...

Edit: I think it was too hostile initially, appologies

~~~
arohner
> I need redis and elasticsearch installed to run my test suite. Will that run
> on CircleCI? What kind of browser support for my feature specs do you offer?

Yes. Redis and Elasticsearch are already installed. firefox, chrome,
phantomjs, casperjs are already installed.

Build pipelines are coming. I guarantee you they'll look nothing like what is
available on Jenkins. They might be more opinionated than you like, but for
the people they do work for, they'll save a lot of time.

> Keeping the build green involves my team figuring out what we broke. Faster
> build times help, is that what you mean here?

That's part of it. The other part is that we are a high-touch CI service. This
week, rubygems had tons of SSL problems. Debugging that, and bugging the
#rubygems IRC guys was "outsourced" to me. Thousands of developers didn't have
to individually debug sporadic rubygems failures because I was doing it for
them.

We see common bugs and test failures often enough that we have in-app warning
messages that say "hey, it looks like your selenium tests are failing because
firefox auto-updated on you. If you upgrade your selenium gem/jar, that will
probably help". Those are things that won't get added to Jenkins.

~~~
nahname
That is good to hear. I have been happy to set this stuff up myself, but it
sounds like you have a great, full featured product. The world can always use
easier ways to do automated testing.

------
pm
Is NIH syndrome such a big deal with engineers that they need to implement
EVERYTHING? I'm leading a team of 3, including myself, and I can't imagine a
worse way to spend your time. Why would I spend precious hours re-implementing
a non-core problem badly when there's someone already doing it well?

When you support a SaaS service, assuming the product is good, you're
essentially paying for an entire team to work on a problem you don't like that
much but need, but which they love. You're also paying for the future of that
product. Unless the software is really bad, or you need something so
specialised that a current solution is out of the question, how does an
engineer not understand this?

You only have limited time in the world. Work on something you find
meaningful.

~~~
marquis
If you hark back to the days before, say even 2010, there just weren't many
SaaS's that worked or were affordable. We ran our own ticking system, chat,
accounting, hosting, email servers, error reporting, server load checks.. it
was all handmade cobbled together from open source and when we were running as
fast as we could to get products together it was quite a mess yes, but there
was no Github, Google Apps, Hipchat, OpenHosting, whathaveyou, and looking at
our own list I see we have now a huge amount of stuff we used to build
ourselves thanks mostly I suppose to what we find on HN as it comes up, and
the article is spot on - definitely costs less than a full time employee to
run all this.

However my point? This is all terrible for security, we're reliant on someone
else's data integrity, and I would assume it's safe to say that if we had the
time to have someone do all this in-house and maintain good documentation we
wouldn't hesitate, given the security and data integrity tradeoffs.

~~~
pm
You make some good points, and HN has been such a boon for finding new
services to integrate. Of course, if we could all do it in-house reasonably
we'd all be doing that no doubt, but it's just not feasible, even for large
corporations. Who can justify the cost?

Security is always a concern, and I do hope most services have taken heed of
online security breaches in recent history. However, I don't find it an
argument against using SaaS because most of the time, the security from doing
software in-house is dispelled by poor security in meatspace, i.e., social
engineering (which is WAY easier to do than people suspect).

------
greenyoda
The risk of outsourcing to an SaaS is that the vendor can disappear - it may
be a small startup that goes bankrupt, gets acqui-hired, pivots to a different
product, etc. Or maybe they can't provide the bandwidth you need to grow or
the 99.9% uptime your customers are demanding. At that point you have to
scramble to find a replacement SaaS or implement the service in-house.

I have nothing against paying for software that someone else wrote, but I'd
feel much more comfortable buying the software and running it on my own
servers (with a contract that says that if the vendor goes out of business, I
retain the right to use the software).

------
nfm
I have mixed feelings about this, but that might just relate to a certain
subset of SaaS products we've used - namely products that require heavy
integration with your data.

I'd sooner spend engineering time writing our own report generators than
writing code to push data to another service, in the format they expect, pre-
empting which data we might want to have in that service down the track,
understanding exactly how the different reports are calculated, and then
inevitably having to write a few custom ones of our own as well.

Of course, the exception to this are services have a huge set of useful
features and take basically no time to fully integrate with, like Google
Analytics.

------
PaulHoule
The "we don't buy software here" syndrome is going away.

GitHub is a bit part of it. At a lot of shops you have time to drive to the
next town and back to update the Wiki or close out a trouble ticket.
Uncompromising speed is a feature that turns your developers into winners.

------
drsim
An engineer reinventing the wheel, other than an intellectual exercise, can be
a symptom of them being bored with their work or not feeling ownership of the
company mission.

Building something from scratch exactly how you want to is stimulating, gets
you respect from peers inside and out and is something you completely own.

When an engineer develops NIH it can be a cry for help. Their leaders need to
inspire them to refocus on their customers.

------
Xorlev
Agreed. I used to think it was best to "do it yourself so you know it" but was
quickly abused of that notion. Do important things yourself (if you can do it
better -- the stuff the makes or breaks your business). SaaS is a godsend.

TRWTF is that the author knows someone who reimplemented NodeJS in house.

------
bluedino
Article is extremely hard to read on my phone.

~~~
bbrunner
Thanks for the heads up. Redid some styling recently. Haven't checked mobile
yet. Yea, it's real bad haha.

------
melindajb
Love this idea. Of course it assumes one finds the right software quickly
without too much time and hassle.

