Live data from Hacker News

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

stefanwrobel.com

31–40 of 53 posts

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

#31
post #17

Based on his mention of SSD-backed instances (c3.large) being only $100/mo, I looked at EC2 pricing again to see if it had become more competitive. Turns out it only has 2x16 gigs of storage and 1 physical core. Looking at the c3.8xlarge instances, they're specced pretty much exactly like the servers I just built for $9k/each, except they have half the ram (60 vs. 128) and half the storage (2x320 vs 4x320). And they…

>Looking at the c3.8xlarge instances, they're specced pretty much exactly like the servers I just built for $9k/each, except they have half the ram (60 vs. 128) and half the storage (2x320 vs 4x320)

Your servers are also likely 2-5 times as fast in the CPU department too.

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

#32
post #17

Based on his mention of SSD-backed instances (c3.large) being only $100/mo, I looked at EC2 pricing again to see if it had become more competitive. Turns out it only has 2x16 gigs of storage and 1 physical core. Looking at the c3.8xlarge instances, they're specced pretty much exactly like the servers I just built for $9k/each, except they have half the ram (60 vs. 128) and half the storage (2x320 vs 4x320). And they…

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

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

#33
post #30
post #16

Earlier quoted context omitted.

I was using 2X dynos on Heroku. I did have memory issues and had to continually reduce the number of unicorns that I was running. I think CPU and disk were the major bottlenecks, but again, Heroku makes it hard to track down exactly what the cause is. Also, we're an ecommerce site so we rely on a lot of external services (specifically for payments) where we have to run the call in the web process ... hence the issue…

> we have to run the call in the web process I know you probably have good reason for this, but this smells like an architecture problem. Whenever you are talking to an external service it is a good idea to have your code laid out such that you can do that in the background. I understand that if you didn't plan enough architecture and maybe even product design to make that feasible from the get-go it is an expensive…

valid point.

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

#34
post #26

Earlier quoted context omitted.

Good stuff schneems, in my case, too little, too late.

Understood, can't be everything to every one. BTW thanks for sticking around and answering questions/engaging :)

gladly :)

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

#35
post #30
post #16

Earlier quoted context omitted.

I was using 2X dynos on Heroku. I did have memory issues and had to continually reduce the number of unicorns that I was running. I think CPU and disk were the major bottlenecks, but again, Heroku makes it hard to track down exactly what the cause is. Also, we're an ecommerce site so we rely on a lot of external services (specifically for payments) where we have to run the call in the web process ... hence the issue…

> we have to run the call in the web process I know you probably have good reason for this, but this smells like an architecture problem. Whenever you are talking to an external service it is a good idea to have your code laid out such that you can do that in the background. I understand that if you didn't plan enough architecture and maybe even product design to make that feasible from the get-go it is an expensive…

How would you do payment processing in the background without temporarily storing the payment details?

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

#36
post #30

Earlier quoted context omitted.

> we have to run the call in the web process I know you probably have good reason for this, but this smells like an architecture problem. Whenever you are talking to an external service it is a good idea to have your code laid out such that you can do that in the background. I understand that if you didn't plan enough architecture and maybe even product design to make that feasible from the get-go it is an expensive…

How would you do payment processing in the background without temporarily storing the payment details?

I work for a payments company.

Generally, you use JavaScript to actually tokenize the card. You then save that token in your actual application, and then use it to actually charge against.

This model works just fine with background jobs.

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

#38
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 redundant, and at this point formulaic infrastructure than to me to do the same things that they've automated away. I can then work on our products. That seems less expensive, not more.

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

#39
post #32
post #17

Based on his mention of SSD-backed instances (c3.large) being only $100/mo, I looked at EC2 pricing again to see if it had become more competitive. Turns out it only has 2x16 gigs of storage and 1 physical core. Looking at the c3.8xlarge instances, they're specced pretty much exactly like the servers I just built for $9k/each, except they have half the ram (60 vs. 128) and half the storage (2x320 vs 4x320). And they…

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

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

#40
post #38
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]
Post reply on HN