Paying Money To Save It And Doing More With Less | Hacker News Reader

Paying Money To Save It And Doing More With Less

brianbrunner.com

46 pointsbbrunner18 comments

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

https://circleci.com/pricing

https://www.digitalocean.com/community/articles/how-to-insta...

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.

>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

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

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.

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.

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.

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

At least two out of the three enterprise(ish) software companies I've worked at had their own in-house bug trackers, their own in-house build systems, and their own in-house version control systems. (To be fair, the versioning systems were custom front-ends over Rational Clearcase at one and Perforce at the other, but still...) The third had it's own in-house monitoring and logging infrastructure. (One team maintained its own monitoring daemon entirely because they preferred to do that than learn how to use Nagios!)

As you might guess, I was very frustrated by how much time I spent re-learning how to do the most trivial tasks when I switched jobs.

So, yeah, NIH is a real thing.

Depends case-to-case. It is very strong with some people. They are very intelligent, but I think they rely on their own programming too much.

I worked with someone and we needed a file storage mechanism for a startup that needed to launch yesterday. So I was pushing to put it on AWS, simple enough. The CTO thought we would be locking ourselves in (for a startup that had yet to launch, yet alone make any money) and wanted to make some extra abstraction layer and then make his own file managing API so that he could plug in his own in house datacenter storage later. Such a colossal waste of time and the startup never launched. I am sure there were other things, but I could never see eye to eye with that person. Should have used something simple like filepicker.io to launch and then looked at it later.

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

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.

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.

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.

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.

Article is extremely hard to read on my phone.

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

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

Reply on news.ycombinator.com