I left Heroku for OpsWorks and shaved 40% off response times
stefanwrobel.com
I left Heroku for OpsWorks and shaved 40% off response times
1–10 of 53 posts
Re: I left Heroku for OpsWorks and shaved 40% off response times
#2Opsworks 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 time.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#3Opsworks 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…
Good to know! I've been meaning to look into Ansible & SaltStack, and you gave me the kick in the butt I needed.
EDIT: ohai Andrew! Thanks for the comment.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#4Opsworks 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…
Big thumbs up for ansible, I have had great results with it it in a number of different production environments, I think the docs are great, and the devs in the irc channel on freenode are very helpful.
If you are about to embark on the journey of provisioning for the first time, or if you are looking for something a little more straightforward than chef/puppet (in my opinion at least...), I highly recommend checking out Ansible!
Re: I left Heroku for OpsWorks and shaved 40% off response times
#5Opsworks 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…
Big thumbs up for ansible, I have had great results with it it in a number of different production environments, I think the docs are great, and the devs in the irc channel on freenode are very helpful. If you are about to embark on the journey of provisioning for the first time, or if you are looking for something a little more straightforward than chef/puppet (in my opinion at least...), I highly recommend checking…
Another thumbs up. I'm currently in the process of migrating away from CFEngine to Ansible and it's been a breeze.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#6Opsworks 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…
Seems like Opsworks does a lot more than just the provisioning, no?
"AWS OpsWorks can scale your application using automatic load-based or time-based scaling and maintain the health of your application by detecting failed instances and replacing them. You have full control of deployments and automation of each component."
How would you suggest using Ansible to cover that side of things?
Re: I left Heroku for OpsWorks and shaved 40% off response times
#7Opsworks 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…
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 while. Now it even comes with decent documentation. I'd back the suggestion to check it out.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#8Opsworks 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…
Seems like Opsworks does a lot more than just the provisioning, no? "AWS OpsWorks can scale your application using automatic load-based or time-based scaling and maintain the health of your application by detecting failed instances and replacing them. You have full control of deployments and automation of each component." How would you suggest using Ansible to cover that side of things?
Autoscaling groups with ansible-pull + cloud init to configure instances as they are spun up by AWS is what I've had the most success with. So your autoscaling group spins up a new instance using a prebaked AMI, and on first boot cloud-init will run ansible-pull locally to grab the latest configs and start up services as needed. Alternatively you can just use ansible to bake a new AMI as needed and skip the ansible-pull + cloud-init part altogether.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#9While 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 weekends.
We chose to use Heroku because of the dead simple workflow that would allow us to spend time developing features instead of maintaining the infrastructure. This may sound like a cliché, but boy was it a good decision. The platform is rock solid, deployments are a bless and the add-on system is just one of the best time savers you can get.
We know OpsWorks (or earlier Scalarium) from our full-time job, and we know how cool it is. But we also know that it requires a lot of time and additional effort to keep things running.
This may pay off if you run a company which can afford it, but you should think about it twice if you have limited resources (and other, more important things to do!).
Even now, after we have launched, we still see no reason why we should move from Heroku to OpsWorks (or another platform). We have made some optimizations and clever (to us) decisions to avoid running into scalability problems. Maybe we will think about migrating once we get a ton more clients and even more traffic. It is cheaper to just add some dynos than spending time on server administration.
In the end, it's all about making the right decision, so don't hurry and if you think Heroku is too expensive for your business, maybe you are not making enough revenue from your customers. On the other hand, if you have the money and time, than go for it.
Re: I left Heroku for OpsWorks and shaved 40% off response times
#10While 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…
Agree with most of what you say, but adding dynos increases concurrency but doesn't do anything to reduce response times. Sometimes you just need a faster box.