Downloaded 49 times
![Role SpecificationmachineRole extends HadoopVMRole { description "A basic machine with SmartFrog installed";vmPrefix "vm";bootAutoVol "vol-0-1-47"; min 0;recommendedMin 0; links extends Compound { "HTTP port 80" ["http", 80, "/"]; "HTTP port 8080" ["http", 8080, "/"]; }}](https://image.slidesharecdn.com/newrolesforthecloud-100317151134-phpapp02/75/New-Roles-In-The-Cloud-20-2048.jpg)
Uploaded bySteve Loughran
New Roles In The Cloud
The document discusses the transformative impact of cloud computing on application delivery, design, and team dynamics, highlighting the shift from traditional server-side architectures to agile, scalable solutions. It emphasizes the elimination of hardware purchasing based on predicted loads and the necessity for applications and teams to adopt more flexible roles in cloud environments. It also touches on the implications for hardware vendors and the need for dynamic services and agile applications that can adapt to changing conditions.
More Related Content
More from Steve Loughran
New Roles In The Cloud
- 1. NEW ROLES INTHE CLOUDSteve LoughranHP LaboratoriesMarch 2010
- 2. Cloud computing willchange how applications are delivered
- 3. how applicationsare designed
- 4. how teamsworkCLASSIC SERVER-SIDE APPLICATIONSArchitect designs the applicationDevelopers code and test on local machinesOperations buy and configure production machinesDevelopers get blame for things not workingOperations get blame for security & availability problemsGetting predictions of demand wrong can kill your project
- 5. CLOUD COMPUTING ELIMINATESBuyinghardware based on predicted load2+ week lead time on new hardware, storageHigh AvailabilityHomogeneityStatic machine names, addresses and capabilitiesStable machinesA fast private networkSomeone in the datacentre who cares about you
- 6. IMPLICATIONS FOR HARDWAREVENDORS(servers, routers, storage, ... )No. of major accounts drops to? 5? 10? Less?Power consumption becomes a key concernNetwork: power, agile routing, bandwidth, throttlingServers: power, VM-hosting, uniformity, no-extra features
- 7.
- 8. WHAT HAS GONE?HighAvailability through hardwareStatic hostnames, network addresses, rDNS, multicast IPMaybe: SQL databases
- 9. APPLICATIONS MUST BEAGILEDirectory, database or CM service to configureApplications to rebind on loss of server connectivityUse dynamic DNS services; don’t cache IPAddrsDon’t expect HDD content to last on a single diskRestart VMs on any app failureNothing is static. Nothing lasts.
- 10. HADOOP’S ASSUMPTIONSMaster nodesdon’t move Workers can spin for themFailed workers get blacklistedSingle, static hostnamesCache all DNS entriesDisks don't move between hostsDifferent strategies are needed
- 11.
- 12. CLASSIC TEAM ROLESBusinessDevelopmentArchitectureOperationsDevelopment
- 13. THE OLD PROCESSBusinessDevelopmentArchitectureDesignDevelopmentStagingLiveOperationsCodeTest
- 14. CLOUD-HOSTING BLURS THEROLESArchitectureDesignBusiness DevelopmentDevelopmentCodeTestOperationsStagingLive
- 15. CLOUD ARCHITECTDesign anagile, HA application from cloud services and VMsAgile ApplicationScale up under loadScale down when quietNo known SPOFDeploys with VMs
- 16. CLOUD OPERATIONSCreate theVMs, manage and monitor staging and productionInstrumentationReconfigurationMonitoringReportingDatamining
- 17. ROLES IN CLOUDAPISDifferent team roles need different rights and different service interfaces
- 18. ROLES IN THECLOUD
- 19.
- 20. Role SpecificationmachineRole extendsHadoopVMRole { description "A basic machine with SmartFrog installed";vmPrefix "vm";bootAutoVol "vol-0-1-47"; min 0;recommendedMin 0; links extends Compound { "HTTP port 80" ["http", 80, "/"]; "HTTP port 8080" ["http", 8080, "/"]; }}
- 21.
- 22. HADOOP CLUSTER:MASTER +WORKER
- 23.
- 24. LIST HOSTS INA ROLEActions: Add a worker, delete all in role “worker”
- 25.
- 26.
- 27. Benefits over (VMtype, disks+)Infrastructure can do some late binding install/deploy
- 28.
- 29. Web, IDE, buildtools, ...
- 30. “Role” CPU/network historycan aid placement
- 31. Other templates: network,aggregate clustersQ&A
Editor's Notes
- #2 17 March 2010 HP Confidential
- #4 This is how things are today. Set up for conflict. The big one is developers "ship code that is functional" and ops "run secure services". 17 March 2010 HP Confidential
- #5 What does all this mean? You don’t need to predict your customer load in advance, though you had better hope your supplier can offer a service to match You don’ t have to wait a few weeks for some order of hardware to get delivered. You can’t buy HA kit: RAID, L7 routers, other nice things, to address availability. You need to design these in You can’t be sure your machines will stay around, that when they come back their names and IP Addresses may change You don’t have someone with a pager in the room who will track down network problems for you 17 March 2010 HP Confidential
- #6 17 March 2010 HP Confidential
- #9 We really need to rethink how to design apps in this world, the old ways don’t. When a VM goes, so does any transient HDD. When a machine gets terminated and re-instantiated, it can have different hostname and address. Nor can that server deal with machines moving around. Which is a pity as the simplest way to deal with app trouble is to reset the VM. No need to worry about what its previous state March 17, 2010 HP Confidential
- #10 These are where Hadoop contains assumptions that are valid in the physical datacentre, but which don't work in a virtual world. 17 March 2010 HP Confidential
- #11 What does i t mean for teams March 17, 2010 HP Confidential
- #12 Here are some of the classic roles of back-end projects. There’s also graphic designers, marketing, content generation, etc. But this is the code side. Everyone’s job is hard. Biz dev: make sure the idea is good, predict demand , get the ops team to work with Arch and Finance to get machines to meet the demand Architecture: design something that works in the machines that ops will bring up Developers: code and test the app, produce something that works 17 March 2010 HP Confidential
- #13 Even if you design/code/test in a cycle, going live creates problems. Different systems, different networks, etc. Staging is meant to simplify this with a setup that mimics production, but it still has different users . March 17, 2010 HP Confidential
- #14 Once you stop needing a physical cluster of machines to test on, you can give every developer a virtual cluster which mimics that in production. 17 March 2010 HP Confidential
- #17 Developers shouldn’t be creating the machine configurations; that’s a job for the architect and ops Biz dev/management may be allowed to bring up machines, but they must be stopped from damaging anything March 17, 2010 HP Confidential
- #18 Developers shouldn’t be creating the machine configurations; that’s a job for the architect and ops Biz dev/management may be allowed to bring up machines, but they must be stopped from damaging anything March 17, 2010 HP Confidential
- #21 This for everyone to create machines. You can only create machines in roles you have the right to. This is more than a constrained image, much more of the config is locked down: VM, networking, dynamic options. March 17, 2010 HP Confidential
- #22 I’ve cheated and added some Hadoop-specificness in the web front end; you can create Hadoop workers and it knows to create the Master first, and passes the master hostname down so that the workers bond properly. This use case needs to be made generic March 17, 2010 HP Confidential
- #23 This is a fairly weak Web UI but it’s designed to feed into portals. It also happens to test easily. 17 March 2010 HP Confidential
- #28 17 March 2010 HP Confidential