5 Quick Wins for the Cloud
Denunciar
RightScaleSeguir
8 de Sep de 2011•0 gostou•1,174 visualizações
0 gostaram
Seja o primeiro a gostar disto
mostrar mais
visualizações
Vistos totais
0
No Slideshare
0
De incorporações
0
Número de incorporações
0
Check these out next
5 Quick Wins for the Cloud
8 de Sep de 2011•0 gostou•1,174 visualizações
0 gostaram
Seja o primeiro a gostar disto
mostrar mais
visualizações
Vistos totais
0
No Slideshare
0
De incorporações
0
Número de incorporações
0
Baixar para ler offline
Denunciar
Tecnologia
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.
RightScaleSeguir
Recomendados
Business Continuity in The CloudCloudEndure
Best Practices for Data Center Migration Planning - August 2016 Monthly Webin...Amazon Web Services
AWS Cloud Disaster Recovery Plan Checklist - Are you ready?CloudEndure
Disaster Recovery of on-premises IT infrastructure with AWS Amazon Web Services
Oracle Peoplesoft on AWS: A quick introductionTom Laszewski
Enterprise Disaster Recovery Strategies by CloudEndureAmazon Web Services
5 Quick Wins for the Cloud
- Provides IT and business agility
- Highly scalable resources required for test
- 30% to 50% of all servers dedicated to test
- Always place (at least) one of each component (load balancers, app servers, databases) in at least two Availability Zones (AZs)
- Maintain sufficient capacity to absorb AZ / cloud failures
- Reserved Instances – guarantee capacity is available in a separate region/cloud
- Replicate data across AZs and backup or replicate across clouds/regions for failover
- Setup monitoring, alerts and operations to identify and automate problem resolution or failover processing
- Minimal additional cost
Notas do Editor
- 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 & 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…