Downloaded 42 times
Uploaded byRightScale
5 Quick Wins for the Cloud
The document outlines five quick wins for leveraging cloud technology, which include moving development and testing to the cloud, implementing configuration automation, enhancing monitoring and alerting, utilizing auto-scaling, and ensuring high availability architectures. Each win presented aims to improve efficiency, reduce costs, and provide scalability for businesses. The presentation also emphasizes the importance of cloud management automation for achieving agility and better resource utilization.
More Related Content
Similar to 5 Quick Wins for the Cloud
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
5 Quick Wins for the Cloud
- 1. 5 Quick Winsfor the CloudSeptember 8, 2011Watch the video of this webinar
- 2. Your Panel TodayPresentingBrianAdler, Professional Services Architect, RightScale
- 3. Rafael H. Saavedra,VP Engineering, RightScaleQ&A Will Eschen, Account Manager, RightScalePlease use the “Questions” window to ask questions any time!
- 4. AgendaQuick Win #1– Development & TestQuick Win #2 – Configuration AutomationQuick Win #3 – Monitoring and AlertingQuick Win #4 – Auto-Scaling ArchitecturesQuick Win #5 – High-Availability ArchitecturesTakeawaysQuestions & AnswersPlease use the “Questions” window to ask questions any time!
- 5. 5 Quick Winsfor the CloudQuick Win #1Development & Test
- 6. Market ForcesShorter releasecyclesMore agile, streamlined product developmentGeographically distributed workforcesNeed for simple deployment mechanisms
- 7. Lifecycle ChallengesLimited, sharedresourcesLead time for procuring and provisioning equipmentMaintaining consistent environments throughout the lifecycleMaintaining multiple environments in parallelDistributed teams and team members
- 8. Dev & Testa top choice to move to the cloud
- 9. Provides IT and business agility
- 10. Highly scalable resourcesrequired for test
- 11. 30% to 50%of all servers dedicated to test
- 12. Most test serversrun at less than 10% utilizationWhy Cloud? Source: RightScale Customer Survey
- 13. Development and Testin a RightScale Managed Cloud Available ResourcesMore creativityImproved qualityLess reworkFaster time to customerHigher utilizationProvisioning and Configuration Control
- 14. Available, Easily ProvisionedDev & Test Resources
- 15. 5 Quick Winsfor the Cloud Quick Win #2Configuration Automation
- 16. Manage Systems, notServers Improve productivity and create business agilityLaunch entire deploymentsLaunch new servers “in context”Monitor and respond to deployment-wide eventsPerform deployment-wide maintenanceEasily clone entire deployments for test & dev or new customers11
- 17. Images vs. RightScaleServerTemplatesBig & opaqueComplex to reproduceStaticNot cloud-portableSlow workflow
- 18. Not cloud-agileModular &flexibleReproducible & maintainableDynamic & agilew/ MCI - Multi-cloud enabledDev-like workflow
- 19. Dynamic configurationVirtual MachineImagesRightScale ServerTemplates
- 20. Modular and variable-basedBuiltwith re-usable scriptsServerTemplates and scripts are version controlledDeployments* can be archived* Logical groupings of servers. RightScale’s ServerTemplate Methodology
- 21.
- 22. Don’t Reinvent theWheel!Use the marketplace.Find what you needBrowse examplesUse Diff Partners!Advanced Search:Search by title AND description. Search by cloud. Search by category.Tip!
- 23. To Create, Recordthe Steps You TakeWork on the instance.Copy successful commands to new RightScripts.Extract variable information.Attach needed files, or compilations as archives.
- 24.
- 25.
- 26. 5 Quick Winsfor the Cloud Quick Win #3Monitoring & Alerting
- 27. Server MonitoringRightScale monitorsover 80 default real-time metrics for compute, database, networking and load balancing on Linux and Windows.Default metrics include:Servers: CPU (10), Disk (6), Memory (9), Network (3), System (1)Applications: Processes (6)Web Servers: Apache (15), IIS (5)Databases: MySQL (21), SQL Server (16)Users can create custom monitoring plug-ins for user-defined metrics and view graphs of these metrics on the RightScale dashboard.
- 28. Cluster MonitoringIndividual graphsGoodfor a dozen serversDisplays all standard graphs with full detailStacked graphsDisplays the contribution of many servers to a totalGreat to see the sum and variability of activity in a clusterDifficult to make out individual serversExamples: requests/sec, cpu busy cycles, I/O bytes/secHeat mapsDisplays a bar for each serverGreat to see uneven distribution across serversGreat to quickly spot performance problems across many serversDifficult to read absolute values or see the total cluster activity
- 29. Cluster MonitoringCluster monitoring:one graph per server
- 30. Stacked GraphsEach colorband shows contribution of one serverServers are stacked on top of one another
- 31. Heat MapsEach horizontalstrip shows one serverThe color shows how “hot” the server is running
- 32. Heat Map with100 Servers
- 33. Alerts & Escalationsfor AutomationAlerts provide minute by minute monitoring of conditionsAlerts are tracked through an escalation process that determines actions as time passes if the alert is unresolvedActions during escalation can send emails, restart servers, run scripts, launch additional servers and vote to scale up/scale down
- 34. 5 Quick Winsfor the Cloud Quick Win #4Auto-Scaling
- 35.
- 36. Classic IT Problem– Solved
- 37.
- 38. 5 Quick Winsfor the Cloud Quick Win #5High Availability Architectures
- 39. General HA BestPracticesAvoid single points of failure
- 40. Always place (atleast) one of each component (load balancers, app servers, databases) in at least two Availability Zones (AZs)
- 41. Maintain sufficient capacityto absorb AZ / cloud failures
- 42. Reserved Instances –guarantee capacity is available in a separate region/cloud
- 43. Replicate data acrossAZs and backup or replicate across clouds/regions for failover
- 44. Setup monitoring, alertsand operations to identify and automate problem resolution or failover processing
- 45. Design stateless applicationsfor resilience to reboot / relaunchMulti-Availability Zone DeploymentsConsider 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.Place Slave databases in one or more AZs for failover.Consider local storage for additional slave database to remove dependency on attached volume (Use LVM snapshots to create backups) Snapshot EBS volume for backups so the database can be readily recovered within the region.
- 46. Multi-Cloud Warm DisasterRecoveryStaged Server Configuration, pre-staged data and running Slave Database ServerGenerally recommended DR solution
- 47.
- 48. Allows fairly rapidrecovery5 Quick Wins for the CloudTakeaways
- 49. Cloud ManagementAutomationCloud ManagementAutomatedAppsAutomated Infrastructure = Automated Cloud = RightScaleCloud InfrastructureManual AppsAutomated Infrastructure = Manual CloudTraditional InfrastructureManual AppsManual Infrastructure = Slow & ExpensiveAbstraction
- 50. Next Steps –Check Out Deeper Dive Contenthttp://www.rightscale.com/info_center
- 51. Next Steps –Get First Hand ExperienceTry Free Edition with LAMP All-in-OneCheck out the configuration management, monitoring & alertingwww.rightscale.com/FreeContact us for a VIP trial for auto-scalingand high availability(866) 720-0208 – sales@rightscale.comRun through tutorials and examplessupport.rightscale.comNext up in the Getting Started series:September 15From Zero to Cloud in 60 MinutesElon Bar-Evan, Technical Trainerwww.rightscale.com/getting-started
Editor's Notes
- #6 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.
- #7 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 & 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.
- #8 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.
- #9 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.
- #10 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.
- #14 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??
- #16 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.
- #17 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.
- #18 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.
- #19 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??
- #22 The cluster monitoring is very powerful in that it provides different types of views into the operation of large clusters of servers
- #23 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
- #24 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
- #25 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
- #26 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…