Wednesday, March 27, 2013

parlor games: sizing AWS with "terrible math (tm)"

People have been playing this parlor game for years I wanted to follow up on my last post about potentially 3.7 million hosts to play a game to see how many there actually are. I borrowed from the great work over at www.ec2instances.info, many thanks to @powdahound for a quick flash of inspiration.

Caveat: this has absolutely *nothing* to do with my day job, it is all based on purely fictitious (and dubious) math.  The only parts here that are even slightly correct were lifted from random public sources.  Everything below is a pure construct for fun and pleasure only, do not use these numbers to advise your stock broker, set career goals, or make any decision about anything what so ever!

Enjoy :-)

NameDRAM (GB)STORAGE (GB)BITSAPI NAME/hour (linux)/hour (windows)
Micro0.6032/64-bitt1.micro$0.02$0.02
M1 Small1.716032/64-bitm1.small$0.06$0.12
M1 Medium3.7541032/64-bitm1.medium$0.12$0.23
High-CPU Medium1.735032/64-bitc1.medium$0.14$0.28
M1 Large7.585064-bitm1.large$0.24$0.46
High-Memory Extra Large17.142064-bitm2.xlarge$0.41$0.57
M1 Extra Large15169064-bitm1.xlarge$0.48$0.92
M3 Extra Large15064-bitm3.xlarge$0.50$0.98
High-CPU Extra Large7169064-bitc1.xlarge$0.58$1.14
High-Memory Double Extra Large34.285064-bitm2.2xlarge$0.82$1.14
M3 Double Extra Large30064-bitm3.2xlarge$1.00$1.96
Cluster Compute Quadruple Extra Large23169064-bitcc1.4xlarge$1.30$1.61
High-Memory Quadruple Extra Large68.4169064-bitm2.4xlarge$1.64$2.28
Cluster GPU Quadruple Extra Large22169064-bitcg1.4xlarge$2.10$2.60
Cluster Compute Eight Extra Large60.5337064-bitcc2.8xlarge$2.40$2.97
High I/O Quadruple Extra Large60.5204864-bithi1.4xlarge$3.10$3.58
High Memory Cluster Eight Extra Large24424064-bitcr1.8xlarge$3.50$3.83
High Storage Eight Extra Large117480064-biths1.8xlarge$4.60$4.93
(ref: http://www.ec2instances.info/)

Makes for a nice picture, M3 double extra has a bit of what I've decided to call a "redmond bump", but you can see the server/complexity price performance model pretty well here. Although I do prefer me some straight lines for financial models... heh



So if we take the following averages over all instances, with application of "bad math", but not yet patent pending "terrible math (tm)", we are working up to a new level of "awesome sums" shortly, pay attention that bit comes next and is loaded with "awesome" ;-):

                        Linux   Windows
Ave. inst. cost         $1.28   $1.65
Median inst. cost       $0.70   $1.14

And think daft thoughts, assuming a 1:1 mapping of all public space based on a total number of hosts based of 3,702,664 from my previous epic one liner... also assuming a 1:1 mapping of all private to public hosts, ignore S3, and generally assume even more than we are stating we are assuming :-)

                                     /hour             /year
Average Linux                   $4,733,239   $41,490,672,122
Average Windows                 $6,092,939   $53,409,548,382

Median Linux                    $2,591,865   $22,719,794,382
Median Windows                  $4,221,037   $37,000,807,994
 
Warning! fake math, average 
of averages, of averages...     $4,409,770   $38,655,205,720


So in theory, EC2 alone could represent between $22B and $53B a year!  Or $4MM/hour!

Random unconfirmed reports from the internet show AWS as $2B/yr, so factor this against a potential $38B... @ 3,700,000 maximum potential servers (from IP space).... gives (drum roll please!), oh and if you are playing along at home, this is the bit when the math goes from bad to "extremely suspect" and onwards to patent pending "terrible math (tm)"!

so, with logical consequence, # servers in AWS  

194,877

he he he, ho, ho ho!

I'm guessing that we should all just quit guessing! Although it is super fun!

The real facts are that no matter how you look at the numbers for public cloud (and in particular AWS), they are all enormous, staggering and vast. Even more so when you look at the sheer range of capability on offer, it is just fascinating. The only numbers in this game that continue to be small (and the only ones you really need to care about!) are the $/instance/hour.

And yet, these numbers continue to become ever, ever smaller each and every day. Plus [even with "terrible math(tm)"] there are clearly a lot of servers out there. Basically, this is awesome great news for everyone needing to run science and computation at scale and for short $. That's the really cool part of this parlor game!

And that, oh yes - that is the bit that I do use in the day job :-)

p.s. comments about issues with "terrible math (tm)" will be met with mild amusement

Monday, March 25, 2013

how big is the public cloud?

Fun question came up today about cloud resources and IP adresses. Totally randomly, I also spotted a tweet by my pal Pax, and decided to put two and two together to come up with new values of four!


So I decided to get a little crazy!

jcuff@jcuff-virtualbox:~/netaddr$ wget -qO - https://forums.aws.amazon.com/ann.jspa?annID=1701 | grep -Eoh "[0-9.]+{4}/[0-9]+" | xargs -I % ./size.py % | awk '{print sum=sum+$2}' | tail -1

3,702,664

So enough for over 3.7 million public hosts all thanks to netaddr and a pointer from my pal Pax. Oh, here's the code, remember there are always 2 less hosts per "ip.size" so chopped off two...


jcuff@jcuff-virtualbox:~/netaddr$ cat size.py
#!/usr/bin/python
import sys
from netaddr import *
import pprint
ip = IPNetwork(sys.argv[1])
print sys.argv[1], ip.size-2


And the raw output:

jcuff@jcuff-virtualbox:~/netaddr$ wget -qO - https://forums.aws.amazon.com/ann.jspa?annID=1701 | grep -Eoh "[0-9.]+{4}/[0-9]+" | xargs -I % ./size.py %
72.44.32.0/19 8190
67.202.0.0/18 16382
75.101.128.0/17 32766
174.129.0.0/16 65534
204.236.192.0/18 16382
184.73.0.0/16 65534
184.72.128.0/17 32766
184.72.64.0/18 16382
50.16.0.0/15 131070
50.19.0.0/16 65534
107.20.0.0/14 262142
23.20.0.0/14 262142
54.242.0.0/15 131070
54.234.0.0/15 131070
54.236.0.0/15 131070
54.224.0.0/15 131070
54.226.0.0/15 131070
54.208.0.0/15 131070
54.210.0.0/15 131070
50.112.0.0/16 65534
54.245.0.0/16 65534
54.244.0.0/16 65534
54.214.0.0/16 65534
204.236.128.0/18 16382
184.72.0.0/18 16382
50.18.0.0/16 65534
184.169.128.0/17 32766
54.241.0.0/16 65534
54.215.0.0/16 65534
79.125.0.0/17 32766
46.51.128.0/18 16382
46.51.192.0/20 4094
46.137.0.0/17 32766
46.137.128.0/18 16382
176.34.128.0/17 32766
176.34.64.0/18 16382
54.247.0.0/16 65534
54.246.0.0/16 65534
54.228.0.0/16 65534
54.216.0.0/15 131070
54.229.0.0/16 65534
175.41.128.0/18 16382
122.248.192.0/18 16382
46.137.192.0/18 16382
46.51.216.0/21 2046
54.251.0.0/16 65534
54.254.0.0/16 65534
54.255.0.0/16 65534
54.252.0.0/16 65534
54.253.0.0/16 65534
175.41.192.0/18 16382
46.51.224.0/19 8190
176.32.64.0/19 8190
103.4.8.0/21 2046
176.34.0.0/18 16382
54.248.0.0/15 131070
54.250.0.0/16 65534
177.71.128.0/17 32766
54.232.0.0/16 65534
54.233.0.0/18 16382

I make no apologies for the abuse of xargs and python in the making of this movie!

Update: this has been done before, but never with such epic one liners ref:

http://gigaom.com/2012/04/20/just-how-big-is-the-amazon-cloud-anyway/ :-)

Saturday, March 9, 2013

of the pulling of plugs and dead fios connections...

Oh no!  The internet is down!!!

So we have had FiOS for about five years now. It's been great until today. We have a business line, pay good money for it, and it has worked mostly fine, and I've never had to call support until today. More of that later on...

First sign, the TiVo was not connecting... rotroh! How are we going to survive!  I thought nothing much of it, there were after all multiple recorded episodes of Bearing Sea Gold to be watched! :-)

I did eventually surface, and do the regular reboot house routine - power off wifi, pull the little green glass fiber optic. Doh! Still nothing much going on there, still dead, they are probably working on something, no biggy. Went shopping and decided to generally get on with my life.

Came back from the shopping mission and started to look at why things were busted. Very odd, the wifi/wan box actually had an IP address, but things were very still much fail, IPs could resolve, but traffic was like molasses or non existent.  This *has* to be an upstream problem I thought to myself...

Decided to call Verizon - in retrospect that was my first big mistake.

An hour plus of back and forth and many powering off and on of "the router" resulted in nothing more than the technician managing to release my DHCP address. I knew I had IP connectivity, that was not the issue, the network was clearly broken...

I'm not a CCIE, but I know that this response from a ping ain't right! Me trying to explain this to the technician was probably worth hearing, and could make for a good comedy sketch at some point, but I digress... :-)

jcuff-air:~ jcuff$ ping www.google.com
PING www.google.com (173.194.75.103): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=120.565 ms
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.475 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.661 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.671 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.677 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.684 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.693 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.699 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=122.705 ms (DUP!)

[SNIPPED 80 LINES]

64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=133.318 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=133.322 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=133.326 ms (DUP!)
64 bytes from 173.194.75.103: icmp_seq=1 ttl=250 time=133.422 ms (DUP!)
Request timeout for icmp_seq 2
^C
--- www.google.com ping statistics ---
4 packets transmitted, 1 packets received, +73 duplicates, 75.0% packet loss
round-trip min/avg/max/stddev = 120.565/128.757/133.422/3.811 ms


Ok, so clearly this is wrong.  What really got me (as I was clearly reaching the end of my tether) at the end of a very long phone call to Verizon, having been passed through five departments, each separately asking me for my details, then each also could not find them!  That part alone was particularly awesome, I just do so love repeating myself!

Then finally the awesome service desk tells me...

"Apple" products are not supported!





I hung up.

A nice cup of tea and a sit down later, I decided to take matters into my own hands....

First up... this bad boy:



I'm clearly throwing all caution to the wind here, I'm not qualified... never have been. "Telco Use Only Do Not Remove"... well it is in my house, so I'm pulling the plug.

Next up, I pull the wire on the battery, the machine is beeping quite a lot now because of the removed "Telco Use Only" plug!  I picked the red wire you can see here, hoping it will stop the beeping!



Gave it a tug, and all the lights went out.  I also pulled the fiber optic just incase for added awesomeness.  I'm not qualified, but I've been known to know a little bit about how computers and networks "work".  Then I went off to finish my tea... and left this thing to understand the jolly good lesson I'd just taught it!

As I drink my tea, I'm thinking about how to make double sure that this is going to work.  So I plugged a laptop right into the network jack on the terminal adapter, (by passing any possibly crappyness in the home network, I did wire it after all!) quickly cloned the MAC address from the airport express... I'm not going back to call them again to release the MAC!  ifconfig to the rescue!

jcuff-air:~ jcuff$ ifconfig en0 ether aa:ff:ee:ff:ee:aa

Ok - now time to put the battery back in, reconnect the glass fiber connection (green), plug back in the "naughty boy - do not remove!" plug back into the wall...

Oh look, see what on earth do we have here?  Oh yes, a fully functioning internet!

jcuff-air:~ jcuff$ ping www.google.com
PING www.google.com (173.194.75.99): 56 data bytes
64 bytes from 173.194.75.99: icmp_seq=0 ttl=250 time=35.918 ms
64 bytes from 173.194.75.99: icmp_seq=1 ttl=250 time=40.758 ms
64 bytes from 173.194.75.99: icmp_seq=2 ttl=250 time=39.774 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 35.918/38.817/40.758/2.089 ms
jcuff-air:~ jcuff$ 

Disconnected the laptop, plugged the Airport Express back in - all better!

Something in that terminal adapter (Verizon's equipment) clearly got messed up, not that Verizon could tell me.  They were much more concerned that I had an unsupported "router", when in fact it was their equipment that was funky.

Hope this helps any other wayward souls on the internet.

Pull plugs first, ask questions later :-)




[any opinions here are all mine, and have absolutely nothing to do with my employer]
(c) 2011 James Cuff