Intro Cloud Computing
•Transferir como PPTX, PDF•
3 gostaram•613 visualizações
This document provides an introduction to cloud computing, including definitions, history, and key concepts. It discusses how cloud computing moves computing away from desktops and onto centralized servers accessed over the internet. The document outlines several industry definitions of cloud computing and discusses the evolution of computing models from distributed to centralized approaches. It also summarizes some of the main issues, opportunities, and technical aspects of cloud computing such as multi-tenancy, scalability, and service models.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (17)
Semelhante a Intro Cloud Computing
Semelhante a Intro Cloud Computing (20)
Mais de DSK Chakravarthy
Último
Último (20)
Intro Cloud Computing
- 1. Introduction to ‘Cloud Computing’ చక్రవర్తి 9/19 - 2009
- 2. Expertise level Using Computer for email Use computer for programmingsince 0 to 2 yrs 2 to 4 yrs 4 yrs and Above Will learn later I’m here because of my friend / philosopher / blah .. blah .. ఏదో.. టైమ్పాస్
- 3. What, How and Why Do I care Why do I care I don’t care .. కెరీర్ఇంకామొదలవ్వలేదు, ఇప్పుడెందుకు?
- 5. Agenda The hype – stats Industry definitions History – a review of computing Issues that matter Origin Grid vs Cloud Details
- 6. The hype Cluster Computing Cloud Computing Grid Computing
- 7. The hype
- 10. definitions
- 11. .. Moving computing and data away from the desktop and the portable PC and simply displaying the results of computing that takes place in a centralized location and is then transmitted via the internet on the user's screen .. - John Makroff
- 12. .. a computing paradigm shift where computing is moved away from personal computers or an individual application server to a "cloud" of computers .. - Wikipedia
- 13. .. the idea of relayin on Web-based applications and storing data in the "cloud" of the internet - MIT Technology Review
- 14. .. it starts with the premise that the data services and architecture should be on servers, We call it cloud computing - they should be in a 'cloud' somewhere.. - Eric Schmidt
- 16. Common implies multi-tenancy, not single or isolated tenancy
- 17. Utility implies pay-for-use pricing
- 18. onDemand implies ~infinite, ~immediate, ~invisible scalability
- 19. Alternatively, a “Zero-One-Infinity” definition:**0On-premise infrastructure Acquisition cost Adoption cost Support cost 1Coherent and resilient environment – not a brittle “software stack” Scalability in response to changing needIntegratability/Interoperability with legacy assets and other services Customizability/Programmability from data, through logic, up into the user interface without compromising robust multi-tenancy * Joe Weinman, Vice President of Solutions Sales, AT&T, 3 Nov. 2008 ** From The Jargon File: “Allow none of foo, one of foo, or any number of foo”
- 20. .. the trend towards online services that run in a web browser and store users information in a provider's data center .. - చక్రవర్తి
- 21. location
- 22. location computations & data are not in the place they used to be in..
- 23. location why does it matter? a bunch of geeky stuff..
- 24. possession implies control control implies power
- 25. history of computing, how is changed
- 27. history of evolution of computing
- 33. Distributed Rich user Interface User Autonomy Centralized Low Cost Expert Management
- 34. Client Client Client Server Client Server – 80s & 90s Client
- 35. Server Client
- 36. Server Client
- 38. ASP.NET JavaScript XML C# HTML SQL Data Store Intermediary Application – Cloud Implementation Strategy
- 41. Data Integration is hard Expensive Infrastructure
- 42. Data Integration Adds meaning
- 43. Data Integration is hard InvisibleHard to quantify Discounted
- 44. Financial & Logistics Challenges
- 45. Cost v. Benefit Time (Cost v. Benefit)
- 46. Traditional Software Purchase Purchase software Purchase hardware Create migration plan Configure systems Configure networks Find space in data center Setup development & test Configure databases More…
- 47. The Easy Way Get a login
- 48. Data Integration is hard Costs don’t match benefits
- 49. How do we make integration easier, and deliver benefits more quickly?
- 51. How do we make integration easier, and deliver benefits more quickly? Cloud computing is a way to make integration easier, and deliver benefits more quickly
- 52. integration^ Turn a commodity into a utility Necessary, but not differentiating
- 53. Not everything’s a commodity
- 54. Web Server Farms. Commodity.
- 55. Much Enterprise Software. Commodity
- 57. Messaging. Maybe not a commodity.
- 58. What if… we just gave IT a platform to create their own data models, interfaces, and processes on a dynamic infrastructure [that met corporate requirements] & simply existed as needed?
- 59. Results in elevated IT relevance
- 60. Other Results… Focus on integration will evolve to a more disciplined approach Match expenses to benefits Enable new classes of applications
- 61. Best Practices
- 62. Mediation. A secret weapon.
- 63. Service Level Management. Don’t even start with “my piece is working fine!”
- 64. Security. It’s not (only) what you think it needs to be.
- 65. Build a culture of collaboration.
- 66. Example: Google Apps Cloud Platform (Apps Engine) Cloud Services (Word Processing) Cloud Client (Mozilla Firefox) Cloud hardware (Apps Server) Cloud storage (BigTable DB) BigTable Cloud Application (Google Docs)
- 68. Implications possession of data
- 69. privacy our data is hold by 3rd party
- 70. security portability and preservation
- 72. market power
- 73. how big is the problem?
- 74. location
- 76. Origin “.. Comes from the early days of the Internet where we drew the network as a cloud… we didn’t care where the messages went… the cloud hid it from us” – Kevin Marks, Google First cloud around networking (TCP/IP abstraction) Second cloud around documents (WWW data abstraction) The emerging cloud abstracts infrastructure complexities of servers, applications, data, and heterogeneous platforms (“muck” as Amazon’s CEO Jeff Bezos calls it)
- 77. 3 Cloud Service Models Cloud Software as a Service (SaaS) Use provider’s applications over a network Cloud Platform as a Service (PaaS) Deploy customer-created applications to a cloud Cloud Infrastructure as a Service (IaaS) Rent processing, storage, network capacity, and other fundamental computing resources To be considered “cloud” they must be deployed on top of cloud infrastructure that has the key characteristics
- 79. 4 Cloud Deployment Models Private cloud enterprise owned or leased Community cloud shared infrastructure for specific community Public cloud Sold to the public, mega-scale infrastructure Hybrid cloud composition of two or more clouds
- 80. Common Cloud Characteristics Cloud computing often leverages: Massive scale Virtualization Non-stop computing Free software Geographic distribution Service oriented software Autonomic computing Advanced security technologies
- 81. is this GRID Computing?
- 84. Grids imply dynamic arrival/departure
- 85. Electrical analogy has limits: CPU cycles aren’t substitutable
- 86. Most clouds are not “compute clusters”
- 87. Clusters are typically monocultures: just one type of node
- 88. Applications may require tuning to a particular cluster size
- 89. Some clouds are servers in virtual slices
- 90. Virtualized servers can be quickly provisioned
- 91. Spin-up of instances = new management task
- 92. Hardware gets cheaper, management…not so much
- 93. Enterprise cloud computing implies API leverage
- 94. Immediate focus on function; immediate delivery of value
- 96. User Interface Logic Database The technical part : Why multi-tenant matters Build strategic applications Customize any aspect Upgrade when convenient Retain IP ownership Your Clicks Your Code Metadata representations: Partitioned data, logic and customizations for multiple customers Coherent Code Base and Managed Infrastructure
- 97. PaaSTaxonamy : Proliferating Platforms PaaS for theInquiring Developer “Servers as a Service” PaaS as anApplication Framework UI as a Service Virtual Servers Virtual Servers Virtual Servers Logic as a Service Virtual Servers Virtual Servers Integration as a Service Python App Server Database as a Service Database as a Service Database as a Service Infrastructure as a Service Infrastructure as a Service Infrastructure as a Service ~Familiar Developer Model Rapid Scalability Offering Innovative Technology Supports Large-Scale SaaS Deep-Dyed Multitenancy
- 99. Thank you
Notas do Editor
- Infrastructure Integration includes networks, servers, app servers, data bases, web servers, and in my mind, even application installation. These are well defined, usually have their own staff… and they take up a large part of budget/effort, but because they are visible, for the most part, they are accounted for (time-wise). Unfortunately, as we all know, this is just the “setup”… next, you have the magic… The magic of DATA integration
- This is the POINT behind all the infrastructure integration efforts. If not for teasing out information about our data in a way that’s usable, we wouldn’t do any of the other stuff. The other stuff is just necessary evil. It’s the boat ride you have to take to the dive site… it might make you queasy, but you can deal with it because once you get there, you’ll see some neat stuff.
- It’s Data integration that’s hard (and expensive). And, importantly, it’s hard to explain to others, so they discount it.
- This is really less of a definition, and more of putting an edge around a concept. And, that edge doesn’t fully surround the concept, only it gives it some shape.
- This is not really a definition, but it does help keep our eyes on the prize and measure the success we have with it. I prefer to think of it as…
- Of course, I’ve still not defined anything. Just trying to put some parameters around it. I defined integration earlier, now I’m saying turn commodity integration (defined as necessary, but not differentiating) into a utility.
- Talk about thinking outside the box. If email is commodity, everything below it in the infrastructure stack is too. And, of course, this is a great example, in some cases, perhaps email is not a commodity. Perhaps there are some Outlook customizations for sales force automation, ACT plugins or whatever, that makes email a tool instead of a commodity. But, even then, it illustrates the point… using salesforce.com, and email, you want to bring that information together. The more you can do that… the more relevant IT will be. Yet, when each app is a closed silo, where the efforts are on integration rather than connectivity, it becomes a real challenge to leverage the cross-app data and relationships.
- Not talking about ESB- or inter-app style messaging. I’m talking about email messaging. There are messages that are part of the conversation everywhere. But they lose context in email. Yeah, maybe there is a link back to relevant information, but it’s very very basic integration that doesn’t even server technical users well. We want to bring information together. Best example I can think of, however trivial, are those silly facebook messages that say “you have an email” but, I can’t respond, I need to go to facebook and respond. I have messages all over the place, there is no reason why Facebook, LinkedIn, Twitter, Email, Progress, and all these places have different places where I have to go and bring this information together manually.Now, this (messaging) is maybe not important to my enterprise, but other similar things are. How about, customer information. There is customer information all over the place, in the sales force automation system, in the provisioning system, in shipping, maybe in contracts administration, etc. Maybe in multiple places. It’s not just about Master Data Management, and having a uniform customer record (that’s hard too), but it is about having a view on my relationship with the customer so I can make better business decisions.
- If all IT does is integrate (data and processes), it will have to become more disciplined, and there will be time to do so. I believe clouds help us get rid of the low level things IT focus on, to help us raise the bar and focus on what’s important.New classes of applications: Really more mashup-like, rapidly created, possibly with short lifespans, that help users synthesize and visualize relevant data and events so they can better execute the business. Data is no longer locked into the silo. In fact, silos simply disappear and we have a full federation of services.
- This is really less of a definition, and more of putting an edge around a concept. And, that edge doesn’t fully surround the concept, only it gives it some shape.
- Visibility, protect from change, service level management.
- When I was working at Radianz, I was responsible for delivering a middleware layer on top of a shared network. Forget the technology. One of the big problems was around culture and contracts. If the network was up, but the middleware service was down, it was down from the customer perspective, and they’d want a refund. However, the network people were bonused on network uptime, not on middleware uptime, so they didn’t look at it the same way. Then, our customer support needed to be trained not to say “well, the network is up” to the customer, why would the customer care? It wasn’t working from their perspective. This is a hard problem, least so with respect to technology.
- Security needs to change to application or message layer security. Today we rely too heavily upon network layer efforts, and frankly, it’s just not secure enough. We know that, but it’s hard to change. I believe this resistance to change will hinder cloud efforts.