Fowa Miami 09 Cloud Computing Workshop


Published on

Slides for an introductory workshop on cloud computing for a web app developer audience at FOWA Miami 09 (

Published in: Technology, Self Improvement
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Fowa Miami 09 Cloud Computing Workshop

    1. How to build your app quickly (and cheaply?) using the Cloud
    2. Intro (Admin, facilities, who I am)
    3. Agenda <ul><li>Overview </li></ul><ul><li>Walk-through deployment on PaaS and IaaS </li></ul><ul><li>Break </li></ul><ul><li>Considerations </li></ul><ul><ul><li>Costs / Economics </li></ul></ul><ul><ul><li>Architecture </li></ul></ul><ul><li>Discussion </li></ul>
    4. Goals for the workshop
    5. Cloud computing. WTF?
    6. WAN (Frame Relay, ISDN, etc.) Router Router LAN A LAN B
    7. For this workshop, it means: elastic compute resources, charged for like a utility
    8. Why bother?
    9. What’s a “web app”?
    17. It’s more than static content.
    18. So that means, it’s about any and all commercial web sites, right?
    19. No. Don’t think so.
    20. Griefer alert: is this just flamebait?
    21. No. In the context of cloud computing, it makes a difference.
    22. A big difference.
    23. Apps do something.
    24. Content doesn’t.
    25. Cloud computing is about doing something.
    27. “ Microsoft is adding 10k servers a month to their infrastructure”
    28. “ That’s one Facebook per month”
    29. Amazon talks a lot about the demand…
    30. Animoto went from 50 to 3400 Amazon virtual servers in two days
    32. The New York Times converted 4TB of TIFFs to PDFs in a day. For $240
    34. And Amazon shows everyone who will sit still for more than 5 seconds the following picture:
    36. Assumption: Mom+Pop ISP ™ cannot compete with this.
    37. Are Mom+Pop doomed?
    38. Ultimately, that depends on you, the developers of web apps.
    39. It’s going to depend on decisions you make about architectural and engineering concerns.
    40. Architecture is about making design choices. Engineering is about knowing your materials.
    41. Making use of the Cloud is an architectural and engineering challenge.
    42. So what are the architectural choices? What are the materials?
    43. SADIST-PIMP SPI (SaaS, Paas, IaaS)
    45. But wait! Once that’s sorted, you have to consider contextual dimensions…
    46. The Radeztsky Cube
    48. IOW, your choices are influenced by whether you are integrating established apps, or writing a green-field app….
    49. And whether your architecture will be entirely in the public Cloud, or a mix of public and private resources.
    50. For the sake of this workshop, we’re going to refer to the SPI model…
    51. SPI Model SaaS PaaS IaaS
    52. We’re going to assume a green-field app, deployed entirely on the public Cloud…
    53. We’re going to focus on the scenario of “your code, running elsewhere” – not so much on mashups and re-use of SaaS
    54. And we’re going to examine the question of PaaS vs. IaaS for that app.
    55. Goals for the workshop
    56. OK. So what is PaaS?
    57. Platform As A Service
    58. Some examples: Google App Engine, Bungee,, Heroku
    59. Characterized by…
    60. Constraints on language and design
    61. A high level programming model
    62. A specific model of multi-tenancy
    63. Takes care of low level concerns
    64. Google App Engine
    70. That’s it.
    71. Constraints on language and design (Python + BigTable + Goog Svcs)
    72. A high level programming model (The WebApp (or other Python) framework, Datastore APIs, Memcache, etc.)
    73. A specific model of multi-tenancy (Google’s BigTable + GFS platform)
    74. Takes care of the low level concerns (Scales for you (up and down), distribution across cluster nodes, load balancing, replication of data, etc. )
    75. Pretty cool.
    76. Infrastructure As A Service
    77. Characterized by…
    78. No constraints on language or design
    79. A high level architectural model
    80. A specific model of multi-tenancy
    81. Takes care of very few low level concerns
    82. This is a LOT more work. ;)
    83. Amazon Web Services
    84. Amazon Web Services <ul><li>Elastic Compute Cloud (EC2) </li></ul><ul><li>SimpleDB </li></ul><ul><li>Simple Storage Service (S3) </li></ul><ul><li>Simple Queue Service (SQS) </li></ul><ul><li>EC2 Elastic Block Store (EBS) </li></ul><ul><li>Other stuff… </li></ul><ul><ul><li>Cloudfront </li></ul></ul><ul><ul><li>DevPay </li></ul></ul><ul><ul><li>Flexible Payments Service (FPS) </li></ul></ul><ul><ul><li>Mechanical Turk </li></ul></ul><ul><ul><li>Alexa </li></ul></ul>
    85. By and large, “Amazon” means “EC2”
    86. EC2 is the only AWS service that one deploys to
    87. You just use the other services – whether from an EC2 instance or anywhere else on the Web is irrelevant
    88. The core “unit” of EC2 is the Amazon Machine Image – AMI
    89. An AMI is a virtual machine image – a VM
    90. A VM is just a (very large) file. Like a live ISO disk image. Typically, it is some distro of Linux.
    91. Amazon uses Xen, an open source VM system
    92. The key to IaaS is that you can use any app architecture you like
    93. The drawback with IaaS is that you therefore have to design your own app architecture
    94. Generally speaking, this is the same task (with the same effort) that you would need for physical hardware hosted at an ISP
    95. App servers, load balancers, databases, clusters, replication, networking…
    96. You sort it out yourself
    97. With Amazon, this begins with obtaining your credentials
    99. Then you download the command line tools and set them up…
    101. You use the tools to proceed through the AMI workflow
    103. AMI ID
    105. <ul><li>Create keypair </li></ul><ul><ul><li>Save the private key locally </li></ul></ul><ul><ul><li>ec2-add-keypair <descriptive keypair name> </li></ul></ul><ul><li>Launch selected instance </li></ul><ul><ul><li>Using AMI ID and keypair name </li></ul></ul><ul><ul><li>ec2-run-instances <AMI ID> -k <keypair name> </li></ul></ul><ul><ul><li>Returns the Instance ID </li></ul></ul><ul><li>Examine the running instance </li></ul><ul><ul><li>ec2-describe-instances <instance ID> </li></ul></ul>
    106. …
    107. Let’s pick that apart…
    108. … Reservation ID
    109. … AWS Access Key ID
    110. AWS Access Key ID
    111. … Security Group ID
    112. … Instance ID
    113. … AMI ID
    114. … External DNS host name
    115. … Internal DNS host name
    116. … Current state of the instance
    117. … Keypair name
    118. … AMI Launch Index
    119. … Instance type
    121. … Launch time
    122. … Availability Zone ID
    123. Availability zones are a bit complicated…
    125. Other IaaS providers may (or may not) have similar capabilities
    126. The point is that, unlike GAE, here is yet another detail that you need to think about
    128. <ul><li>Open network access to the instance </li></ul><ul><ul><li>ec2-authorize <security group name> -p <port number> </li></ul></ul><ul><ul><li>Can include options like restricting access to a specific (public) IP address </li></ul></ul><ul><ul><ul><li>-s <IP address/CIDR subnet range> </li></ul></ul></ul><ul><ul><ul><li>Eg. “-s your_public_IP_address/32”* for just your host </li></ul></ul></ul><ul><ul><li>At a minimum, you need to configure port 22 for SSH access </li></ul></ul><ul><li>Connect to the instance with SSH </li></ul><ul><ul><li>ssh –i <private keyfile> root@<public DNS host name> </li></ul></ul><ul><ul><li>Note: with “ec2-get-console-output”, you can get (among other things) the SSH host key fingerprint, before logging on with SSH. At login, you can compare to be sure there’s no “man in the middle” </li></ul></ul><ul><li>Begin modifying the instance </li></ul>
    129. Once you’ve modified the image, you “bundle” it (which is a kind of snapshot), upload the bundle to S3, and register it with EC2
    130. There are hundreds of publicly available AMIs for use as templates
    131. And, finally, with some set of your own AMIs, you can begin running instances of your app
    132. And that brings us to the runtime considerations…
    133. AKA – how does your app scale horizontally?
    134. A brief scalability refresher: vertical scalability is “get a bigger box”
    135. Horizontal scalability is “add more copies of the same box”
    136. To put it bluntly, if your app can't efficiently scale in a horizontal fashion, you’re wasting your time on the Cloud
    137. On GAE, under the covers tech like BigTable, GFS and the legendary Map/Reduce are taking care of this for you
    138. In an IaaS context like AWS, you have to solve the problem yourself
    139. EC2 has a SOAP API that you can invoke – whether you do so from outside EC2, or from within a running AMI is irrelevant
    140. Invoking the EC2 API to launch and terminate instances from a running instance gives you the ability to create dynamic horizontal scalability
    141. Your load balancer AMI could start extra instances of your web server AMI to meet demand…
    142. And turn them back off, when demand subsides
    143. And there are numerous ways to exploit this capability
    144. From RightScale to Scalr to Gigaspaces, Hadoop, Terracotta and countless others
    145. Combined with the other elements of AWS, like S3, SQS, EBS and SimpleDB, you can design a system that competes favorably with GAE
    146. This is what “elastic” means
    147. To repeat: this is a LOT more work. ;)
    148. No constraints on language or design (AMIs can be any Linux or Windows server platform, and your app can be anything that runs on those platforms)
    149. A high level architectural model (The core services of AWS provide a foundation, and do constrain your design – for example, you need horizontal scalability)
    150. A specific model of multi-tenancy (AMIs are securely isolated from one another, but the underlying hardware is all shared)
    151. Takes care of very few low level concerns (You roll your own)
    152. Before we wrap up “deploying to AWS”, however, let’s look at some alternatives to the command line tools from Amazon
    153. In terms of managing running instances, and the overall configuration of things, AWS provides its own Web UI
    159. An ecosystem of 3 rd party providers has emerged around AWS
    160. Some of them are specialized in managing VMs
    173. There are other vendors offering similar services, eg. rPath
    174. And there is a spectrum between the simplicity of GAE and the complexity of AWS…
    175. Let’s take a look at Elastra, for example
    183. Finally, to wrap up our quick overview of IaaS, let’s look at Rightscale…
    192. Goals for the workshop
    193. But first, a short break… (Jeopardy theme song plays)
    194. Goals for the workshop
    195. What are some of the questions you need to answer, to decide between PaaS and Iaas?
    196. How quickly do you need to go to market?
    197. How fast do you need to iterate versions of the app?
    198. What are your pre-existing platform needs, if any?
    199. What are your security, compliance, regulatory requirements?
    200. What is your capacity for system architecture and design work?
    201. SPI Model Freedom FROM Considerations Freedom TO Differentiate SaaS PaaS IaaS
    202. SPI Model POWER of speed and agility POWER to control SaaS PaaS IaaS
    203. Goals for the workshop
    204. What do things really cost?
    205. Simple LAMP app. 1 box as a load balancer / proxy, 4 web server boxes, and one larger box for a database server
    206. $84 / month (6 x Giant)
    207. $900 / month (1 x Biz1 + 4 x Biz1 + 1 x Enterprise II)
    208. So, let’s see what the equivalent setup costs on AWS…
    209. Now, AWS bills in units of things like server hours, IOs per month, GB of storage and bandwidth actually used, etc.
    211. 24 hours × 30 days = ---------------------- 720 hours in a month ---------------------- 720 hours × 5 small AWS Instances = ---------------------- 3600 hours ---------------------- + 720 hours of a large AWS instance + 5000 GB network bandwidth + 3200 GB disk space (added to the default space on the instances) + 50 mil. IORs + 30 daily backups ---------------------- roughly equivalent to 1+1 …
    212. $2233 / month
    214. Despite best efforts, this is still quite imprecise, and apples vs. oranges, but…
    215. Even more importantly…
    216. This is an incredibly stupid way to set up and use AWS
    217. $528/ month
    218. Still not “cheap”, though…
    219. That’s because the key to “elastic computing” isn’t being able to turn on servers at will…
    220. It’s about being able to turn them off .
    221. Let’s rewind to the an earlier part of this discussion…
    222. What’s a web app?
    223. Whatever it is, we said “it’s not static content”…
    224. And I said that makes a big difference
    225. Why is that? Well, the unwritten social contract of the ‘Net says: “you can’t turn static content off”
    226. Apps do something
    227. But they generally don’t do it 24x7
    228. Slicing and dicing your design to strictly demarcate static content from active has always been a Good Idea ™
    229. In a cloud computing context, it’s not just a good idea – it’s imperative
    230. What are your usage patterns? When are your peak loads, on average?
    231. What can you turn off?
    232. And you have to be clever about it…
    233. Your production usage may not even be the place you can save the most money…
    234. Consider: you want to develop the next version of your app
    235. You need resources for your developers to do that, and you need a place for them to test
    236. So, maybe you wind up renting 3 more servers from 1+1 – $300 / month
    237. But, when you examine usage patterns, you find that your developers are only using the boxes for 3 hours each day
    238. $17/ month
    239. Perhaps even more importantly, you’ve made no commitment here – once your dev / test phase is over, so are the costs
    240. Calculating costs is complex, and entirely context dependent
    241. There are significant potential savings, but only if you’re clever
    242. Goals for the workshop
    243. Since we worked out, sometime in the early ‘90s, what the architecture of a “client / server” system design looked like…
    244. There's been a general consensus about a sort of a canonical architecture for so-called “N-tier systems”
    245. Presentation Service Facáde Application Logic Data Persistence
    246. Web Server App Server Database Server
    247. So, we’ve talked about the need for horizontal scalability in the Cloud
    248. What does that imply?
    249. Well, as already suggested, among other things, parallelism
    250. Parallelism has significant consequences
    251. It leads one to try to avoid stateful interactions
    252. To prefer asynchronous communications (messages)…
    253. One finds oneself on the front lines of the REST War ™ – the battle of the RESTafarians vs. the established IT Universe
    254. And it forces one to think strange things about optimal patterns of storing and accessing data
    255. Like sharding one’s data to meet resource demands
    256. Questions like “is two-phase commit a feature? Or a bug?” begin to seem important
    257. New terms, like CAP, Paxos and BASE creep into conversations about “eventual consistency”
    258. This was happening anyway, driven by the clash of Web architecture with the established IT universe
    259. Cloud computing’s possibilities are accelerating the process
    260. There is an emerging consensus about what the consequences of all this are for app architectures
    261. “ The canonical cloud architecture that has evolved revolves around dynamically scalable CPUs consuming asynchronous, persistently queued events.”
    263. <ul><li>Use scalable ingredients </li></ul><ul><ul><li>Eg. Hadoop on EC2 </li></ul></ul><ul><li>Keep ingredients loosely coupled </li></ul><ul><ul><li>All communication via persistent messaging </li></ul></ul><ul><li>Assume constant failure </li></ul><ul><ul><li>Design things to persist state, restart from last known good, and continue their own tasks even if all around them fail </li></ul></ul><ul><ul><li>Consider things like re-tries with exponential back-off </li></ul></ul><ul><ul><li>Build IN redundancy </li></ul></ul><ul><li>Learn about things like the POSA Blackboard pattern, tuplespaces, and Map / Reduce </li></ul>
    264. Read this book!
    265. And if your needs / budget require or can accommodate it, consider RAIC
    266. Redundant Array of Independent Cloud providers
    268. Why bother?
    269. Web Server App Server Database Server
    270. Mainframe
    273. gblnetwkr Consumerization
    274. gblnetwkr
    275. Join the conversation: … and please come talk to us, as well … Thanks!