Deploy to Linode and wait or go direct to AWS?
7 comments
What are the reasons you think AWS is your ultimate destination instead of Linode?
My advice would be to use a DevOps tool like Puppet or Chef to create recipes to make deploying new infrastructure as painless as possible. If you take it far enough, it could completely build your new infrastructure in a new datacenter, but even in its simplest form it will help you when it comes time to migrate. Spooling up more nodes in your current datacenter to handle spikes in traffic becomes much easier, too.
My advice would be to use a DevOps tool like Puppet or Chef to create recipes to make deploying new infrastructure as painless as possible. If you take it far enough, it could completely build your new infrastructure in a new datacenter, but even in its simplest form it will help you when it comes time to migrate. Spooling up more nodes in your current datacenter to handle spikes in traffic becomes much easier, too.
Main advantage I see to AWS is the ability to scale up and down easily but it might take a little while before we have such need.
A friend has been talking to my lead dev quite a bit about Chef. I'll spin it to him again.
A friend has been talking to my lead dev quite a bit about Chef. I'll spin it to him again.
Long-term, it seems wise to just go AWS. The difference of learning AWS versus deploying right now in Linode (if you have experienced web server engineers) is negligible. I'd say even 30-40 hours worth of learning/testing can get you up and running in AWS.
Also, you have to think about possible downtime migrating from Linode to AWS (or increasing your Linode resources) or setting up a mechanism for no-downtime.
I agree with what you say here: "go directly to AWS, take the extra time to set it up and be done with it." To me, if the initial time/resource cost is negligible (which in this case, IMHO, it is), I'm going for the permanent solution instead of what seems to be a stop-gap solution. Less headaches, more time to devote to other parts of your start-up at a time of growth where your time and resources will be scarce, and fewer things to worry about. I'd rather pay the time up front when I'm still starting out, rather than later where it will be more difficult and most probably more costly.
This applies only because you already know AWS is the end-game. Otherwise, I'd just launch in Linode first since it's quick and I (and you) know how it works already, then deal with scaling later when you actually know you need to scale.
And don't knock Linode; it can take a beating.
Also, you have to think about possible downtime migrating from Linode to AWS (or increasing your Linode resources) or setting up a mechanism for no-downtime.
I agree with what you say here: "go directly to AWS, take the extra time to set it up and be done with it." To me, if the initial time/resource cost is negligible (which in this case, IMHO, it is), I'm going for the permanent solution instead of what seems to be a stop-gap solution. Less headaches, more time to devote to other parts of your start-up at a time of growth where your time and resources will be scarce, and fewer things to worry about. I'd rather pay the time up front when I'm still starting out, rather than later where it will be more difficult and most probably more costly.
This applies only because you already know AWS is the end-game. Otherwise, I'd just launch in Linode first since it's quick and I (and you) know how it works already, then deal with scaling later when you actually know you need to scale.
And don't knock Linode; it can take a beating.
no knocking Linode, I know it's good. But it's hard to see re-deployment as anything else that lost cycles at the point we're at. I hope we won't need 30 hours to be up and running on AWS though.
I actually have this debate with myself every time I think that I am close to the point of deploying my work (heh, that's another story). But every time I do the calculation, I just don't get how AWS would be more beneficial to me vs sticking with Linode. AWS' pricing would be much more than Linode's model. So for a while, I think I am set on this resolve:
Using Linode for my app and host static files on S3 and maybe another cloud provider like Rackspace for failover in case the clouds go down.
I am hoping that I would have a luxury problem once my app is doing well. When I have that kind of traction, it's a different story. But until then, it's more logical to stick with a VPS.
By the way, are you making updates to your production site frequently? Your carousel isn't working correctly yet.
I know you use django (from another post I think). Have you thought about using social network login? I used django-allauth and it has been working very well for me. Good luck!
Using Linode for my app and host static files on S3 and maybe another cloud provider like Rackspace for failover in case the clouds go down.
I am hoping that I would have a luxury problem once my app is doing well. When I have that kind of traction, it's a different story. But until then, it's more logical to stick with a VPS.
By the way, are you making updates to your production site frequently? Your carousel isn't working correctly yet.
I know you use django (from another post I think). Have you thought about using social network login? I used django-allauth and it has been working very well for me. Good luck!
We push to production 3-4 times a day.
You mean the carrousel on the home page ? I'll take a look. That page hasn't really been touched since we started developing and needs a complete makeover. Thanks for the heads up !
We currently our own LinkedIn login to create account as we use their API to match candidates and jobs. Next step is to add Facebook and Twitter as alternative login.
We were thinking to go with django social-auth to cover al bases. http://uswaretech.com/blog/2009/08/django-socialauth-login-v...
Had you compared it to allauth ? I'll take a look, hadn't seen that one.
thxs !
We currently our own LinkedIn login to create account as we use their API to match candidates and jobs. Next step is to add Facebook and Twitter as alternative login.
We were thinking to go with django social-auth to cover al bases. http://uswaretech.com/blog/2009/08/django-socialauth-login-v...
Had you compared it to allauth ? I'll take a look, hadn't seen that one.
thxs !
I think you should go with Linode first and when you hit the upper limit, you can move to EC2 or dedicated servers.
AWS is somewhat expensive and doesn't deliver the same performance as Linode type hosts.
The only advantage to EC2 is the insane flexibility it allows (i.e. dynamically spawn new nodes based on traffic)
To start off, I'd go with Linode or Rackspace. Keep it simple. Worry about scaling later.
AWS is somewhat expensive and doesn't deliver the same performance as Linode type hosts.
The only advantage to EC2 is the insane flexibility it allows (i.e. dynamically spawn new nodes based on traffic)
To start off, I'd go with Linode or Rackspace. Keep it simple. Worry about scaling later.
go with both.
As has been demonstrated, any cloud can go out of service.
Being on both Linode and EC2 spreads your risk across different services. Chance of them both being down is significantly smaller than either one of them being down.
true. We already have some environment on WebFaction so we'll probably keep it for such case.
What type of traffic volume do you expect to see in the first month and year?
all depends when I can truly divide my time between the marketing hat and dev hat. I think any prediction would be wrong.
The reason you should go with Linode (or any other dedicated or VPS host) over a cloud solution is if you can predict your growth. Cloud solutions are useful for rapid scaling, but tend to be overly expensive over long periods of time. Traditional servers are harder to scale quickly (arguably) but end up being cheaper usually.
I know this been asked a gazillion time in different form but ...
we''re about to launch our startup (matchFWD) and need a true hosting solution. We're tempted to go with Linode as it's cheap and easy to set-up and deal with the fact that we'll need more in a few months when it's time... or go directly to AWS, take the extra time to set it up and be done with it.
Any advice and experience with either approach ?
Thanks,