5 Quick Wins for the Cloud<br />September 8, 2011<br />Watch the video of this webinar<br />
Your Panel Today<br />Presenting<br /><ul><li>Brian Adler, Professional Services Architect, RightScale
Rafael H. Saavedra, VP Engineering, RightScale</li></ul>Q&A <br />Will Eschen, Account Manager, RightScale<br />Please use...
Agenda<br />Quick Win #1 – Development & Test<br />Quick Win #2 – Configuration Automation<br />Quick Win #3 – Monitoring ...
5 Quick Wins for the CloudQuick Win #1<br />Development & Test<br />
Market Forces<br />Shorter release cycles<br />More agile, streamlined product development<br />Geographically distributed...
Lifecycle Challenges<br />Limited, shared resources<br />Lead time for procuring and provisioning equipment<br />Maintaini...
<ul><li>Dev & Test a top choice to move to the cloud
Provides IT and  business agility
Highly scalable resources required for test
30% to 50% of all servers dedicated to test
Most test servers run at less than 10% utilization</li></ul>Why Cloud? <br />Source: RightScale Customer Survey<br />
Development and Test in a RightScale Managed Cloud <br />Available Resources<br />More creativity<br />Improved quality<br...
Available, Easily Provisioned Dev & Test Resources<br />
5 Quick Wins for the Cloud Quick Win #2<br />Configuration Automation<br />
Manage Systems, not Servers Improve productivity and create business agility<br />Launch entire deployments<br />Launch ne...
Images vs. RightScale ServerTemplates<br />Big & opaque<br />Complex to reproduce<br />Static<br />Not cloud-portable<br /...
Not cloud-agile</li></ul>Modular & flexible<br />Reproducible & maintainable<br />Dynamic & agile<br />w/ MCI - Multi-clou...
Dynamic configuration</li></ul>Virtual Machine Images<br />RightScale ServerTemplates<br />
Modular and variable-based<br />Built with re-usable scripts<br />ServerTemplates and scripts are version controlled<br />...
LAMP ServerTemplate Example<br />
Don’t Reinvent the Wheel!<br />Use the marketplace.<br />Find what you need<br />Browse examples<br />Use Diff  <br />Part...
To Create, Record the Steps You Take<br />Work on the instance.<br />Copy successful commands to new RightScripts.<br />Ex...
Consistent, Reusable Configurations<br />
Consistent, Reusable Configurations<br />
5 Quick Wins for the Cloud Quick Win #3<br />Monitoring & Alerting<br />
Server Monitoring<br />RightScale monitors over 80 default real-time metrics for compute, database, networking and load ba...
Cluster Monitoring<br />Individual graphs<br />Good for a dozen servers<br />Displays all standard graphs with full detail...
Cluster Monitoring<br />Cluster monitoring: one graph per server<br />
Stacked Graphs<br />Each color band shows contribution of one server<br />Servers are stacked on top of one another<br />
Heat Maps<br />Each horizontal strip shows one server<br />The color shows how “hot” the server is running<br />
Heat Map with 100 Servers<br />
Alerts & Escalations for Automation<br />Alerts provide minute by minute monitoring of conditions<br />Alerts are tracked ...
5 Quick Wins for the Cloud Quick Win #4<br />Auto-Scaling<br />
Classic IT Problem<br />
Classic IT Problem – Solved<br />
Auto-Scaling Arrays<br />
5 Quick Wins for the Cloud Quick Win #5<br />High Availability Architectures<br />
Upcoming SlideShare
Loading in …5
×

5 Quick Wins for the Cloud

1,154 views

Published on

RightScale Webinar: So you want to move to the cloud... but you’re not sure what that means, or where you would even start. Or you want to get your feet wet with a proof-of-concept project before you bring out the big guns. We asked Brian Adler, our Professional Services Architect who works directly with customers on cloud projects every single day, to select five cloud projects that you can get started with (and complete!) quickly. In this webinar, Brian and Rafael Saavedra, our VP of Engineering, will walk you through those five projects and will help you demonstrate success in the cloud now.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,154
On SlideShare
0
From Embeds
0
Number of Embeds
32
Actions
Shares
0
Downloads
37
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Kevin kicks this off with what Zend is seeing. Leon talks about IBM global companies and their distributed workforce and outsourced developers.Betsy to add in: In our research, we found that development organizations were much more interested in improving development and test agility than cost reduction. While the cost reduction was a great benefit, getting higher quality software into the hands of users faster was their primary concern. And if not already stated, Every company – small or large – even companies that have not fully embraced agile development - are compressing each stage in the release cycle.
  • Here are some specific dev and test challenges we’ve heard from our prospects and customers – and they were surprisingly consistent across industry and co size. Rarely are there enough resources available for experimentation and testing, and equipment is shared and must be configured and re-configured each time a new project or task starts. In many companies it takes as long as 3-5 weeks to procure and provision new equipment, so development organizations must plan ahead or risk delaying projects. Maintaining consistent environments is another persistent challenge. As code moves through development, test, staging and production, configuration changes rarely make it back into earlier stages. If software is to be run in multiple production environments, then each environment needs to be configured and tested. And to troubleshoot problems found in production requires reproducing past environments – easier said than done. Whether the task falls to development, QA or operations, maintaining and reproducing environments is time-consuming and error-prone. Finally, distributed teams just exacerbate the other challenges. Limited resources – In almost every phase, limited hardware poses problems. In architecting new systems there are rarely enough resources to experiment with alternative architectures or new technologies. For developers, limited resources usually means sharing hardware for testing. Testers rarely have enough hardware or time to do all the testing they would like to do - full performance and load testing, testing on complete production architectures, or testing disaster recovery scenarios. And, delays in development often puts pressure on testers to do their work faster to still reach the same deadline. The inability to spin-up additional testing resources at these times causes quality to suffer. The result is that errors are found later in the cycle where they are more expensive to fix. Limited equipment also means staff are constantly provisioning, tearing down, and re-provisioning the same equipment. It takes time, and if environments are not completely wiped clean, additional errors are potentially introduced. Time to procure and provision equipment - As the load on IT departments increases and the release cycles shorten, the wait for equipment to be procured and provisioned takes time away from valuable work. One customer stated it took 3-5 weeks to procure and provision new hardware. Maintaining consistent environments – As code moves through development, test, staging and production, changes to configurations in one stage rarely make it back into earlier stages. As new code is implemented from environments that haven’t been updated, the same errors are re-introduced. Maintaining multiple environments – As if maintaining one consistent environment across many servers isn’t hard enough, most software requires testing on several different types of configurations – different versions of stacks, for different end user environments – one for each possible production scenario. For example, a software company may need to test their software on different operating systems or alongside various software packages. Most companies need to clone production environments to debug problems without impacting the current users.Whether it happens in development or QA - maintaining &amp; reproducing environments is a time consuming task. If the task is distributed across multiple administrators, the coordination of changes made becomes challenging. If the task is consolidated under one administrator, there is a limit to the number of different environments s/he can reliably maintain.Distributed teams or team members – add collaboration requirements and exacerbate all of the issues mentioned.
  • Would be great if you can focus on the need for agility in the larger development life cycleWithin that, testing needs lots of resources for short periods of time – that’s what drives the 30% of IT resources with only 10% utilization. Would be great to add that even with that 30%, they don’t feel like they have enough.
  • What we will show you in the rest of this presentation is how with a RightScale-managed cloud, you can take advantage of the virtually infinite resources available in the cloud, easily provision them, and maintain consistent configurations through the software life cycle. With adequate resources available you can be more creative and do more testing:New architectures can be tried, new product ideas can be prototyped, and new technologies evaluatedMore testing can be done in development and QA, increasing the quality and reliability of your softwareMultiple tests can be run in parallel reducing time to market Separate user acceptance environments can be set up – so you don’t have to stop working while users try out new featuresWith easy provisioning and configuration control:Less time spent configuring and reproducing environments, Environments are consistent, errors aren’t reintroduced, so less reworkAll thismeans reduced cycle times and faster time to customer – whether those are internal or external customers.And of course with cloud computing you only pay for what you use, improving the utilization of capital.
  • Let’s look a little deeper into the specific RightScale Dev and Test Solution Pack. First, it delivers … available, easily provisioned resources. Developers can launch all-in-one environments where a single machine runs the entire stack (OS, App Server + Database) through an easy-to-use self-service portal. Testers can spin up simple 3-tier (4 server) environments where tier 1 is the load balancer, tier 2 is comprised of a couple of app servers and tier 3 is a single database server. This configuration is a base configuration with no high-availability or high-reliability. And then when they are no longer needed, they can shut them down. What is unique about RightScale’s solution is that as software moves into staging and production, the operations team can use the full power of RightScale to monitor, manage, and automate the production system. Because RightScale works with Infrastructure as a Service cloud providers, they have control over all levels of infrastructure. It’s not a black box like is the case in many PaaS offerings. They can completely control system behavior – how the infrastructure supporting applications or databases scales, how databases are backed up - as well has more easily troubleshoot problems.
  • The RightScale ServerTemplate methodology supports creating and re-using many of the same components through out the lifecycle. Let’s look a little more closely at how it does that. A ServerTemplate defines the software stack and behavior of a provisioned cloud server. Each ServerTemplate contains a base machine image and a set of scripts. Typically, the base machine image installs both the operating system and the lightweight RightScale agent, RightLink, which enables and manages communication with the RightScale Cloud Management Platform. After the server boots up using this machine image, RightScale runs all the startup scripts specified to install the required software. While the server is running, the systems administrator is free to run any of the operational scripts through RightScale. And, when the user terminates the server, termination scripts are used to gracefully shut down the server.ServerTemplates reference re-usable scripts. Because both the ServerTemplates and the scripts are version controlled, and because deployments can be cloned and archived, any changes are easily tracked and propagated. These features provide all the power a systems administrator needs to easily manage, maintain and reproduce multiple environments.Maybe have URI show one??
  • You might just find exactly what you need.Or you can find snippets of what you need and build it and test it. Finally, we have partners that have put up a lot of the software for you. And they build test it everyday. Open Diff in new tab.Clone LAMP all in one. Rename to Wordpress. Bookmark.Remove continuous backups.Add APP Wordpress configure to bottom of template.Set default inputs on new template.
  • You might just find exactly what you need.Or you can find snippets of what you need and build it and test it. Minimize external dependencies by attaching files or anything you need to compile as a .tar.Finally, we have partners that have put up a lot of the software for you. And they build test it everyday.
  • Second, the solution pack helps organizations maintain consistent, reproducible configurations throughout the software lifecycle. The RightScale platform uses ServerTemplates to configure servers and then groups of ServerTemplates, or what we call Deployments, to launch multi-server, multi-tier environments. Because ServerTemplates are modular, consisting of a number of scripts that are executed, it is easy to repackage the same scripts and ServerTemplates into the configurations necessary for each stage. Any changes made to scripts or templates or deployments can be easily reflected across stages. And the components are version controlled or archived, so it’s easy to recreate past environments.
  • Hereis an example of how a set of scripts and ServerTemplates can be used to create several different environments. As a reference architecture is specified, the first set of components are created. Pre-configured components from the RightScale Library can be used “as is” or customized, or a systems administrator can create his own from scratch or leverage an existing library of scripts and cloud machine images. The individual components can be re-used for each type of environment needed throughout the development lifecycle. Any changes made to scripts or templates are version controlled or archived and can be easily replicated.Maybe have URI show one??
  • The cluster monitoring is very powerful in that it provides different types of views into the operation of large clusters of servers
  • Walk through ofhow it works: in any deployment, go to the monitoring tab select servers select metric to plot familiar controls to switch time period and graph size displays one graph per server, here core1.rightscale.com through core8.rightscale.com in this example the graphs show cpu utilization for the past week, where blue is busy time and green is idle
  • Individual graphs only work for so many servers, they also don’t show what is happening as an aggregateStacked graphs stack the contribution of each server on top of one anotherWalk through what the graph shows
  • Stacked graphs are great to see the aggregate, but it is often difficult to see abnormal server behaviorHeat maps show many servers on one graph by plotting one horizontal bar per serverThe time axis is the same for all servers and it is shown at the bottom of the graphThe color of the bar shows the value of the metric for the serverWalk through the graphIt’s easy to see that there are 6 servers sharing the load, and two servers that are different
  • At scale this is how all this looks and comes togetherThis example is real, it shows an incident we had with our monitoring cluster a few months agoThis heat map shows 100 servers out of one of our monitoring clusters (we want to be vague here…)When there are more than 100 servers, the heat map shows a sampling of 100Describe the sampling: most recently launched, longest running, some of each server template, rest randomStory:This heat map plots I/O wait for our monitoring servers on a day where we suddenly received a number of alerts for a few serversThe heap map shows these servers clearly as red bands starting between 7am and 8amSo we could clearly see that something was going on with a small number of servers and that it started more or less at the same time on all themTo see what happened in aggregate, we can switch graph type…
  • 5 Quick Wins for the Cloud

    1. 1. 5 Quick Wins for the Cloud<br />September 8, 2011<br />Watch the video of this webinar<br />
    2. 2. Your Panel Today<br />Presenting<br /><ul><li>Brian Adler, Professional Services Architect, RightScale
    3. 3. Rafael H. Saavedra, VP Engineering, RightScale</li></ul>Q&A <br />Will Eschen, Account Manager, RightScale<br />Please use the “Questions” window to ask questions any time!<br />
    4. 4. Agenda<br />Quick Win #1 – Development & Test<br />Quick Win #2 – Configuration Automation<br />Quick Win #3 – Monitoring and Alerting<br />Quick Win #4 – Auto-Scaling Architectures<br />Quick Win #5 – High-Availability Architectures<br />Takeaways<br />Questions & Answers<br />Please use the “Questions” window to ask questions any time!<br />
    5. 5. 5 Quick Wins for the CloudQuick Win #1<br />Development & Test<br />
    6. 6. Market Forces<br />Shorter release cycles<br />More agile, streamlined product development<br />Geographically distributed workforces<br />Need for simple deployment mechanisms <br />
    7. 7. Lifecycle Challenges<br />Limited, shared resources<br />Lead time for procuring and provisioning equipment<br />Maintaining consistent environments throughout the lifecycle<br />Maintaining multiple environments in parallel<br />Distributed teams and team members<br />
    8. 8. <ul><li>Dev & Test a top choice to move to the cloud
    9. 9. Provides IT and business agility
    10. 10. Highly scalable resources required for test
    11. 11. 30% to 50% of all servers dedicated to test
    12. 12. Most test servers run at less than 10% utilization</li></ul>Why Cloud? <br />Source: RightScale Customer Survey<br />
    13. 13. Development and Test in a RightScale Managed Cloud <br />Available Resources<br />More creativity<br />Improved quality<br />Less rework<br />Faster time to customer<br />Higher utilization<br />Provisioning and Configuration Control<br />
    14. 14. Available, Easily Provisioned Dev & Test Resources<br />
    15. 15. 5 Quick Wins for the Cloud Quick Win #2<br />Configuration Automation<br />
    16. 16. Manage Systems, not Servers Improve productivity and create business agility<br />Launch entire deployments<br />Launch new servers “in context”<br />Monitor and respond to deployment-wide events<br />Perform deployment-wide maintenance<br />Easily clone entire deployments for test & dev or new customers<br />11<br />
    17. 17. Images vs. RightScale ServerTemplates<br />Big & opaque<br />Complex to reproduce<br />Static<br />Not cloud-portable<br /><ul><li>Slow workflow
    18. 18. Not cloud-agile</li></ul>Modular & flexible<br />Reproducible & maintainable<br />Dynamic & agile<br />w/ MCI - Multi-cloud enabled<br /><ul><li>Dev-like workflow
    19. 19. Dynamic configuration</li></ul>Virtual Machine Images<br />RightScale ServerTemplates<br />
    20. 20. Modular and variable-based<br />Built with re-usable scripts<br />ServerTemplates and scripts are version controlled<br />Deployments* can be archived<br />* Logical groupings of servers. <br />RightScale’s ServerTemplate Methodology<br />
    21. 21. LAMP ServerTemplate Example<br />
    22. 22. Don’t Reinvent the Wheel!<br />Use the marketplace.<br />Find what you need<br />Browse examples<br />Use Diff <br />Partners!<br />Advanced Search:<br />Search by title AND description. Search by cloud. Search by category.<br />Tip!<br />
    23. 23. To Create, Record the Steps You Take<br />Work on the instance.<br />Copy successful commands to new RightScripts.<br />Extract variable information.<br />Attach needed files, or compilations as archives.<br />
    24. 24. Consistent, Reusable Configurations<br />
    25. 25. Consistent, Reusable Configurations<br />
    26. 26. 5 Quick Wins for the Cloud Quick Win #3<br />Monitoring & Alerting<br />
    27. 27. Server Monitoring<br />RightScale monitors over 80 default real-time metrics for compute, database, networking and load balancing on Linux and Windows.<br />Default metrics include:<br />Servers: CPU (10), Disk (6), Memory (9), Network (3), System (1)<br />Applications: Processes (6)<br />Web Servers: Apache (15), IIS (5)<br />Databases: MySQL (21), SQL Server (16)<br />Users can create custom monitoring plug-ins for user-defined metrics and view graphs of these metrics on the RightScale dashboard. <br />
    28. 28. Cluster Monitoring<br />Individual graphs<br />Good for a dozen servers<br />Displays all standard graphs with full detail<br />Stacked graphs<br />Displays the contribution of many servers to a total<br />Great to see the sum and variability of activity in a cluster<br />Difficult to make out individual servers<br />Examples: requests/sec, cpu busy cycles, I/O bytes/sec<br />Heat maps<br />Displays a bar for each server<br />Great to see uneven distribution across servers<br />Great to quickly spot performance problems across many servers<br />Difficult to read absolute values or see the total cluster activity<br />
    29. 29. Cluster Monitoring<br />Cluster monitoring: one graph per server<br />
    30. 30. Stacked Graphs<br />Each color band shows contribution of one server<br />Servers are stacked on top of one another<br />
    31. 31. Heat Maps<br />Each horizontal strip shows one server<br />The color shows how “hot” the server is running<br />
    32. 32. Heat Map with 100 Servers<br />
    33. 33. Alerts & Escalations for Automation<br />Alerts provide minute by minute monitoring of conditions<br />Alerts are tracked through an escalation process that determines actions as time passes if the alert is unresolved<br />Actions during escalation can send emails, restart servers, run scripts, launch additional servers and vote to scale up/scale down<br />
    34. 34. 5 Quick Wins for the Cloud Quick Win #4<br />Auto-Scaling<br />
    35. 35. Classic IT Problem<br />
    36. 36. Classic IT Problem – Solved<br />
    37. 37. Auto-Scaling Arrays<br />
    38. 38. 5 Quick Wins for the Cloud Quick Win #5<br />High Availability Architectures<br />
    39. 39. General HA Best Practices<br /><ul><li>Avoid single points of failure
    40. 40. Always place (at least) one of each component (load balancers, app servers, databases) in at least two Availability Zones (AZs)
    41. 41. Maintain sufficient capacity to absorb AZ / cloud failures
    42. 42. Reserved Instances – guarantee capacity is available in a separate region/cloud
    43. 43. Replicate data across AZs and backup or replicate across clouds/regions for failover
    44. 44. Setup monitoring, alerts and operations to identify and automate problem resolution or failover processing
    45. 45. Design stateless applications for resilience to reboot / relaunch</li></li></ul><li>Multi-Availability Zone Deployments<br />Consider distributed NoSQL databases with the same distribution considerations. Spread primary and replica nodes across multiple AZs. Place as many as you need for required resiliency.<br />Place Slave databases in one or more AZs for failover.<br />Consider local storage for additional slave database to remove dependency on attached volume (Use LVM snapshots to create backups) <br />Snapshot EBS volume for backups so the database can be readily recovered within the region.<br />
    46. 46. Multi-Cloud Warm Disaster RecoveryStaged Server Configuration, pre-staged data and running Slave Database Server<br /><ul><li>Generally recommended DR solution
    47. 47. Minimal additional cost
    48. 48. Allows fairly rapid recovery</li></li></ul><li>5 Quick Wins for the Cloud<br />Takeaways<br />
    49. 49. Cloud Management<br />Automation<br />Cloud Management<br />Automated Apps<br />Automated Infrastructure<br /> = Automated Cloud<br /> = RightScale<br />Cloud Infrastructure<br />Manual Apps<br />Automated Infrastructure<br /> = Manual Cloud<br />Traditional Infrastructure<br />Manual Apps<br />Manual Infrastructure<br /> = Slow & Expensive<br />Abstraction<br />
    50. 50. Next Steps – Check Out Deeper Dive Content<br />http://www.rightscale.com/info_center<br />
    51. 51. Next Steps – Get First Hand Experience<br />Try Free Edition with LAMP All-in-One<br />Check out the configuration management, monitoring & alerting<br />www.rightscale.com/Free<br />Contact us for a VIP trial for auto-scalingand high availability<br />(866) 720-0208 – sales@rightscale.com<br />Run through tutorials and examples<br />support.rightscale.com<br />Next up in the Getting Started series:September 15<br />From Zero to Cloud in 60 Minutes<br />Elon Bar-Evan, Technical Trainer<br />www.rightscale.com/getting-started<br />

    ×