Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I left Heroku for OpsWorks and shaved 40% off response times

stefanwrobel.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: I left Heroku for OpsWorks and shaved 40% off response times

#41

Post by [deleted] »

Aqueous wrote: post #38
iagooar wrote: post #9

While I can understand the advantages the author of the article mentions, I must say that one should think about making the move to OpsWorks, because you can't compare their prices without considering other costs / tradeoffs. A friend of mine and I have been working on a startup for the last 8 months. It has been tough as we have been working full time for a company and hacking like crazy once we got home, or on week…

If companies think Heroku is more expensive they are failing to factor in how expensive it would be to have an employee to do all the work that Heroku takes off their plate. I work 45 - 50 hours a week developing. If I have to do devops - provisioning, deployment and system administration work - to maintain a server infrastructure there goes 15 - 20 hours! Surely my company is paying less to Heroku to manage that red…

[deleted]

Re: I left Heroku for OpsWorks and shaved 40% off response times

#42

Post by ericd »

vinceguidry wrote: post #39
ericd wrote: post #32

Earlier quoted context omitted.

>Your servers are also likely 2-5 times as fast in the CPU department too. FYI, you've been hellbanned, Sssnake. They use slightly better processors for the C3s than I use (2x8 core 2.8 vs. 2x8 core 2.6). I'd assume that if you get the largest instance, you probably have the whole machine to yourself and don't have issues with bad neighbors, so it's probably actually slightly faster than mine.

Possible he's been hellbanned, but his latest post is the only dead one.

Ah you're right. Sorry if it was a false alarm, Sssnake.

Re: I left Heroku for OpsWorks and shaved 40% off response times

#43

Post by DrJ »

FYI OpsWorks runs their Chef on Ruby 1.8, make sure your cookbooks passes on 1.8, and it doesn't depend on +1.9 :)

This is nothing on AWS OpsWorks, as they greatly simplified interface into managing clusters (for deployments, organization).

I found about this recently as I updated a community cookbook(python), as the Chef community is moving forward (with Chef 11+) that 1.8 has reach EOL and 1.9 is stable (2015) and 2.0 current, and 2.1 is new-hot-ness.

Re: I left Heroku for OpsWorks and shaved 40% off response times

#44

Post by grey-area »

Aqueous wrote: post #38
iagooar wrote: post #9

While I can understand the advantages the author of the article mentions, I must say that one should think about making the move to OpsWorks, because you can't compare their prices without considering other costs / tradeoffs. A friend of mine and I have been working on a startup for the last 8 months. It has been tough as we have been working full time for a company and hacking like crazy once we got home, or on week…

If companies think Heroku is more expensive they are failing to factor in how expensive it would be to have an employee to do all the work that Heroku takes off their plate. I work 45 - 50 hours a week developing. If I have to do devops - provisioning, deployment and system administration work - to maintain a server infrastructure there goes 15 - 20 hours! Surely my company is paying less to Heroku to manage that red…

Once you have done the setup once and have it all automated, it's more like 1 hour per week keeping on top of upgrades, backups etc. So for many people heroku is an expensive option, even when starting out. Nothing wrong with using it, but outsourcing your infrastructure does not come cheap, compared to other options like a VPS.

Re: I left Heroku for OpsWorks and shaved 40% off response times

#45

Post by tgeek »

andrewvc wrote: post #2

Opsworks is nice, and it's a good packaged solution. A large number of smaller apps would benefit from a switch. It's also more fairly priced. That being said, opsworks is still based on chef, which is still cumbersome. For most people Ansible is far easier to deal with if they don't fit into the opsworks box. The overhead of starting from scratch with ansible can be made up for with the faster overall development ti…

"That being said, opsworks is still based on chef, which is still cumbersome."

re:chef

I don't think this is necessarily a fair assessment and true for all. There are a ton of community cookbooks out there, and a very large community now online to help people with Chef. I've been using Chef for years and like anything else once you get over the learning period, it becomes second nature. Any tool that you use will have some learning curve to it, and so the trade offs that make it cumbersome for some, make it easy for others.

Also, you could technically Chef in Ansible in OpsWorks(if OpsWorks met other needs for you), but thats just crazy talk haha

Re: I left Heroku for OpsWorks and shaved 40% off response times

#46

Post by swrobel »

banachtarski wrote: post #37

What do Opswork, Chef, and the Heroku platform have to do with response time? Did the author investigate why the response time were that slow to begin with?

I wouldn't say they were "slow to begin with" but improved speed is always nice. I think the major contributing factor was access to newer, more powerful instances. Heroku Dynos run on very old EC2 instances.

Re: I left Heroku for OpsWorks and shaved 40% off response times

#47

Post by zenojevski »

ghayes wrote: post #19
darklajid wrote: post #7

Earlier quoted context omitted.

Ansible: I was in the "Don't go there" camp a while ago - they documentation was horrible, the whole website a mess and lots of things weren't discoverable at all (people using ansible told me that they used google site search to find stuff in the manual). I returned a couple of days ago to look at the current state of things and I have to admit that I was impressed. Technically I really liked ansible for quite some…

I was really excited by ansible, but I quickly found out that using `register: result` and `when: result|success` throughout so many playbooks meant I was back to the mess that is understanding the flow of a chef script that you didn't personally write. Maybe that's not a problem since I rarely found an open source ansible playbook for anything I needed and had to always write my own.

Hi, I've published some reusable roles for ansible. They are still quite basic, but I'd love for you to have a look at them. https://github.com/search?q=%40zenoamaro+ansible

Re: I left Heroku for OpsWorks and shaved 40% off response times

#48

Post by Aqueous »

grey-area wrote: post #44
Aqueous wrote: post #38

Earlier quoted context omitted.

If companies think Heroku is more expensive they are failing to factor in how expensive it would be to have an employee to do all the work that Heroku takes off their plate. I work 45 - 50 hours a week developing. If I have to do devops - provisioning, deployment and system administration work - to maintain a server infrastructure there goes 15 - 20 hours! Surely my company is paying less to Heroku to manage that red…

Once you have done the setup once and have it all automated, it's more like 1 hour per week keeping on top of upgrades, backups etc. So for many people heroku is an expensive option, even when starting out. Nothing wrong with using it, but outsourcing your infrastructure does not come cheap, compared to other options like a VPS.

VPS is much more expensive because you have to do all the work to provision (either manually or automatically) the software stack you are working with, configure every new instance either, configure your deployment and testing pipeline using a CI server and using git hooks, and keep the whole edifice up and running. The time overhead is very large, and it ends up taking over as the major cost driver.

Re: I left Heroku for OpsWorks and shaved 40% off response times

#49

Post by grey-area »

Aqueous wrote: post #48
grey-area wrote: post #44

Earlier quoted context omitted.

Once you have done the setup once and have it all automated, it's more like 1 hour per week keeping on top of upgrades, backups etc. So for many people heroku is an expensive option, even when starting out. Nothing wrong with using it, but outsourcing your infrastructure does not come cheap, compared to other options like a VPS.

VPS is much more expensive because you have to do all the work to provision (either manually or automatically) the software stack you are working with, configure every new instance either, configure your deployment and testing pipeline using a CI server and using git hooks, and keep the whole edifice up and running. The time overhead is very large, and it ends up taking over as the major cost driver.

Having done most of the steps you mention above for multile clients, I'd contend the time overhead is not very large - most things can be automated, and once that is done an extra instance is just a matter of spinning up a server and deploying - also you can scale a very long way on one or two instances when the hardware is beefy enough (e.g. this website), backup, deploy, testing can all be automated. There are definitely some situations where a service like Heroku or AWS makes a lot of sense, but it can get expensive very quickly; you're trading time to setup/manage for higher ongoing costs forever. VPS is cheaper but requires some setup. That's a trade-off each company has to evaluate individually given the talent and money they have.

Re: I left Heroku for OpsWorks and shaved 40% off response times

#50

Post by ghayes »

zenojevski wrote: post #47
ghayes wrote: post #19

Earlier quoted context omitted.

I was really excited by ansible, but I quickly found out that using `register: result` and `when: result|success` throughout so many playbooks meant I was back to the mess that is understanding the flow of a chef script that you didn't personally write. Maybe that's not a problem since I rarely found an open source ansible playbook for anything I needed and had to always write my own.

Hi, I've published some reusable roles for ansible. They are still quite basic, but I'd love for you to have a look at them. https://github.com/search?q=%40zenoamaro+ansible

Always great to see people putting up open-source projects like this. I'll definitely give them a look, and at the least, get a grip on how other people found solutions with Ansible. Thanks man.
Post reply on HN