
Autoscaling on AWS - mqzaidi
http://qzaidi.github.io/2013/06/21/autoscaling-with-aws/
======
mathrawka
I have found that using a ubuntu base AMI and salt
([http://saltstack.com/community.html](http://saltstack.com/community.html))
makes things much easier to manage. His suggestion of having node.js and nginx
baked into the AMI is a big pain when you need to upgrade node.js or nginx
(hello security update!). Using something like salt (or puppet or chef) would
make this much easier.

But in general, I agree with the article.

~~~
mqzaidi
We enable auto applying security updates in the AMI, and the first thing the
provisioning script does is update packages. That said, I would definitely
want to explore alternatives - not needing to update while provisioning will
take a few seconds off the provisioning time.

~~~
mnutt
What if you rebuilt the AMI every time you deployed?

~~~
crb
That's what Netflix do: [http://techblog.netflix.com/2013/03/ami-creation-
with-aminat...](http://techblog.netflix.com/2013/03/ami-creation-with-
aminator.html)

------
damian2000
I'm probably not understanding something but couldn't you use Puppet or Chef
for your manual provisioning tasks?

------
thejosh
What CSS/Framework/whatever are you using for that metro-style dashboard?

~~~
shimms
Looks like Dashing from Shopify:

[http://shopify.github.io/dashing/](http://shopify.github.io/dashing/)

~~~
robotmay
Dashing is a great thing to play around with in the evening. I've got a bunch
of custom data sources I should really open source for other people, like
Heroku dyno counts etc.

------
contingencies
Not to detract from this article explicitly on the subject of AWS, but ... if
you are relying on _any_ single cloud provider then you are probably not going
to scale beyond a certain point, since it means that reliability (ie.
heterogeneity - re: cloud providers, physical/logical points of presence,
legal jurisdictions, etc.) is not all that important to you. At a certain
point, a cloud provider neutral approach is called for.

~~~
morganK
Not that simple. Having only one cloud provider allow you to make the most of
it.

Once you have two providers, you are forced to only use the features offered
by each of them and use an abstract layer (API agnostic dev).

Plus, AWS offers a wide range of strategies to ensure the availability of its
infrastructure (Availability Zone, Regions, CDN etc.)

~~~
contingencies
_Once you have two providers, you are forced to only use the features offered
by each of them and use an abstract layer (API agnostic dev)._

Abstraction layers don't necessarily need to produce lowest common denominator
results.

 _Plus, AWS offers a wide range of strategies to ensure the availability of
its infrastructure (Availability Zone, Regions, CDN etc.)_

You still wind up vulnerable to quirks of the single provider though! For
example, account freeze for whatever reason (financial quirks, legal issues,
regulatory change) any multi-site failures (eg. financial, operational, legal,
security) at that provider.

~~~
randallsquared
> Abstraction layers don't necessarily need to produce lowest common
> denominator results.

Except in the special case that you can build the functionality not provided
by using other functionality that is, I think they do, since otherwise it's
leaking. A leaky abstraction is often worse than none.

~~~
contingencies
I think your assumption is that cloud providers with different features cannot
be abstracted without making the whole abstraction 'leaky'.

While your perspective may hold for a traditional, rigid, single-layer,
abstraction layer with the most simplistic, binary-level feature presence, it
does not hold for better formed solutions. From
[https://en.wikipedia.org/wiki/Abstraction_layer](https://en.wikipedia.org/wiki/Abstraction_layer):
_All problems in computer science can be solved by another level of
indirection_ (David Wheeler).

Some real world differences between cloud providers: available hardware,
available installation images (OS images), available bandwidth, available
logical location on the internet, available physical location (legal
jurisdiction, etc.), scale-out time, cost model.

How do you conceive of these differences, and then deploy arbitrary services
to an arbitrary number of individual instances running unique combinations of
cloud provider specific features on unique cloud-provider deployed OS images
in parallel? There are various approaches, but it's not that hard to come up
with a functional set of abstractions. Think about it.

------
imperialWicket
Great points. Something like logstash for logging (which supports
graphite/statsd type output) is a nice addition to the logging setup.

Also, for some apps deploying code during instance launch can be time
consuming. Depending on your monitors and auto scale config, this might be
acceptable. For some it may be appropriate to put code right in the ami and
only ever deploy via new ami.

------
seldo
This is good as far as it goes -- nice to see further corroboration that EBS
is not always the best solution.

What I'd really like to see is details of how the traffic monitoring works,
how you calculate how much extra capacity to spin up, and how quickly you can
react to load events.

------
gkop
It's unhelpful to needlessly abbreviate ordinary words, like "infra" for
"infrastructure" in the first paragraph.

~~~
mqzaidi
You are right - committed a fix, but looks like github is taking longer to
rebuild the pages.

------
dmourati
Lost me at NFS.

~~~
bdunbar
How does your organization mount volumes found on another host?

~~~
dmourati
S3/EBS at the moment. MogileFS/SMB in the past though mogile and S3 are more
properly referred to as object stores.

~~~
bdunbar
Ah. I'm new to AWS, had not yet explored 'storage' options.

I guess I'd been thinking of AWS as being 'vmware' but more so, without
thinking hard about how it could be different.

