Amazon certainly makes a lot of things easier. For example, you still have to manually back up your database and files, but the storage of those files are simplified (S3, which is arguably one of the safest places to store files in terms of durability).
Things like dealing with software failures, updating stack versions, configuring DB, are pretty much the same with EC2 as they are with dedicated hosting. There are Amazon products that help (Cloud Monitoring service) but mostly you will be doing it yourself the same way you would on your own hardware. Being a cloud VM hosts, some of these things are more convenient to handle than if you were on your own hardware. For example, everything can be done from the EC2 API, so you can programmically spin up/down instances (machines) as things go down to keep everything working. But of course you need to set up this failover/auto-scaling system yourself (the API just lets you control the infrastructure).
This is the case with IaaS services like EC2 and Rackspace (you only get bare VMs with some extras), but if you move to a more hand-holding PaaS service such as Heroku, where you get the entire deployment system and failure handling system, then your software stack management and failovers are mostly handled by the service provider. Of course these services cost a lot more for equivalent amount of compute power than IaaS services.
I see, sounds mostly similar to just renting a VPS from one of a variety of providers then in that it doesn't dispense with ops stuff.
I did evaluate S3 for backups for one project , but concluded that an rsync script would be simpler and more portable.
In the case of things like heroku, how are software updates handled?
Do you contact them and say "I want to update to rails version x.x , do it and run these automated tests" or do they just do everything on a schedule?
In other words, if you want an extra feature that is only present in a newer version is this possible? Also what I would worry about it them doing a random upgrade at an inconvenient time (like during a launch of something) and it breaking something subtle.
Yeah EC2 is basically a VPS rental, but with a number of services surrounding it to help with ops. So it is more convenient than a pure VPS service, but by no means "takes care" of ops for you.
With Heroku you use files to specify your dyno configurations, and in the runtime file you can explicitly set the version of software to use. Heroku will read the file and take care of everything for you. Whether the version switch breaks your application code or not you have to test out on a dev dyno first, there is no way Heroku can help you with that. They will not touch installed software versions without your explicit consent. They might change the default runtime software versions though, so you should always explicitly state the version you want.
> I see, sounds mostly similar to just renting a VPS from one of a variety of providers then in that it doesn't dispense with ops stuff.
At this level, it pretty much is. I steer clear of AWS because it's relatively expensive for what you get unless you need the ability to rapidly scale (and you're paying in advance for that flexibility).
Comments
Amazon certainly makes a lot of things easier. For example, you still have to manually back up your database and files, but the storage of those files are simplified (S3, which is arguably one of the safest places to store files in terms of durability).
Things like dealing with software failures, updating stack versions, configuring DB, are pretty much the same with EC2 as they are with dedicated hosting. There are Amazon products that help (Cloud Monitoring service) but mostly you will be doing it yourself the same way you would on your own hardware. Being a cloud VM hosts, some of these things are more convenient to handle than if you were on your own hardware. For example, everything can be done from the EC2 API, so you can programmically spin up/down instances (machines) as things go down to keep everything working. But of course you need to set up this failover/auto-scaling system yourself (the API just lets you control the infrastructure).
This is the case with IaaS services like EC2 and Rackspace (you only get bare VMs with some extras), but if you move to a more hand-holding PaaS service such as Heroku, where you get the entire deployment system and failure handling system, then your software stack management and failovers are mostly handled by the service provider. Of course these services cost a lot more for equivalent amount of compute power than IaaS services.
I see, sounds mostly similar to just renting a VPS from one of a variety of providers then in that it doesn't dispense with ops stuff.
I did evaluate S3 for backups for one project , but concluded that an rsync script would be simpler and more portable.
In the case of things like heroku, how are software updates handled? Do you contact them and say "I want to update to rails version x.x , do it and run these automated tests" or do they just do everything on a schedule?
In other words, if you want an extra feature that is only present in a newer version is this possible? Also what I would worry about it them doing a random upgrade at an inconvenient time (like during a launch of something) and it breaking something subtle.
Yeah EC2 is basically a VPS rental, but with a number of services surrounding it to help with ops. So it is more convenient than a pure VPS service, but by no means "takes care" of ops for you.
With Heroku you use files to specify your dyno configurations, and in the runtime file you can explicitly set the version of software to use. Heroku will read the file and take care of everything for you. Whether the version switch breaks your application code or not you have to test out on a dev dyno first, there is no way Heroku can help you with that. They will not touch installed software versions without your explicit consent. They might change the default runtime software versions though, so you should always explicitly state the version you want.
> I see, sounds mostly similar to just renting a VPS from one of a variety of providers then in that it doesn't dispense with ops stuff.
At this level, it pretty much is. I steer clear of AWS because it's relatively expensive for what you get unless you need the ability to rapidly scale (and you're paying in advance for that flexibility).