Cloud Computing: The Hard Problems Never Go Away

Cloud Computing: The Hard Problems Never Go Away By Doug Tidwell, Cloud Computing Evangelist, IBM

Agenda • A few (a very few) words about the cloud • The hard problems (Boo!) • Vendor lock-in and the Simple Cloud API • Next steps / Resources 2

A few words about the cloud 3

Before the cloud • If you wanted to start an enterprise, you needed an IT shop. • Massive costs in hardware, software, power, administrative staff • Prohibitive cost to entry 4

What if... • You could have unlimited computing resources? All the processing power you want All the data storage you want Data mining whenever you want • Cloud computing will be the biggest change to our industry since the rise of the Internet. 5

The cloud •Cloud computing . . . is a style of computing where IT-related capabilities are provided ‘as a service,’ allowing users to access technology-enabled services ‘in the cloud’ without knowledge of, expertise with or control over the technology infrastructure that supports them. From Wikipedia •Everybody has a slightly different idea of what cloud computing really is. 6

The cloud is here to stay • Extremely stupid idea of assuming the entire planet just can not be bothered with their own data (nor the security thereof). As always there will be some who think they 'need' this. I hope this whole cloud [stuff] just goes away. Logistically speaking it will never be anything but a waste of money. Posted by ___@gmail.com, who apparently just can not be bothered with their own email (nor the security thereof). 7

Cloud characteristics • Rapid elasticity • Measured service • On-demand self-service • Ubiquitous network access • Location-independent resource pooling Source: NIST Working Definition of Cloud Computing, http://csrc.nist.gov/groups/SNS/cloud-computing/ 8

Cloud services • There are four basic things people are doing in the cloud: The application in the sky The hard drive in the sky The database in the sky The machine in the sky 9

The hard problems never die No matter how badly we want them to 10

The hard problems never die • Whenever the industry embraces a technology, there’s always the exhilaration of doing something new. • Unfortunately, we still have to deal with the hard problems like security, maintenance, lifecycle management, and so forth. We still have to build flexible applications that respond to changes in the business environment. We still have to share data and business processes with our partners. We’re not going back to building silos just because the cloud is here. • SOA isn’t going away just because the cloud is here. 11

Cloud computing requirements • Management and governance • Transactions and concurrency • Identity • Federated identity • Security • Location awareness • Avoiding vendor lock-in Common APIs for cloud storage, cloud databases, cloud middleware • Common VM image format 12

Cloud computing requirements • Data and application federation • SLAs • Lifecycle management • Open client • Metering and monitoring • Deployment 13

Governance is hard • Similarities between SOA and the cloud: Both started bottom-up Both started with massive hype Both don’t work without governance • You need an architect, a blueprint, and an executive who is both enlightened and powerful. • SOA and cloud computing aren’t simply coding issues. 14

Transactions and concurrency • Many enterprise applications require transactions and concurrency. There needs to be only one copy of the data Any changes to the data have to be synchronized • This is very difficult to scale. 15

Cloud storage • Most cloud storage systems, such as Amazon’s S3, are designed as distributed, redundant systems. Your data is stored on more than one disk in more than one place. If one part of the system goes down, the rest of the system keeps going. “There should never be a single point of failure” is a stated design goal. • You can’t think of cloud storage as just another hard drive. 16

Cloud storage is not just a hard drive • Once you create an object, it can’t be modified. You can delete it or replace it, but you can’t modify it. (In S3, you can’t even move it.) • It takes time for changes to make their way throughout the system (propagation latency). If you just put an object into S3, you can’t be sure that it will be available right away. If you get an object from S3, you can’t be sure that it’s the latest version. 17

Cloud storage is not just a hard drive • Read and write requests will fail occasionally. Your application should handle that gracefully. Trying the request a second time usually does the trick. Delete requests sometimes fail as well. 18

Cloud storage • All of this is by design. These design decisions mean that S3 is extremely scalable and reliable. But these design decisions also mean that S3 doesn’t work like another hard drive. • The right answer, as always, is to understand your choices, understand your needs and pick the technology that works best for you. 19

Cloud databases • Cloud databases have similar design points. Datasets are distributed for reliability Some cloud databases support schemas, some don’t Some cloud databases support joins, most don’t Some cloud databases are relational, almost all aren’t Some cloud databases are transactional, some aren’t 20

“Database” ≠ RDBMS • Amazon’s SimpleDB is built around domains. Each domain has some number of items; each item has some number of attribute / value pairs. No schema support No queries across domains • These design decisions make SimpleDB fast, scalable and, well, simple. But our previous discussions of propagation latency and I/O errors apply here, too. 21

A wee quiz • Is this a good idea? count() • How about this? avg() • Or one of these? sum(), min(), max() 22

A wee quiz • The answer: It depends. SimpleDB automatically indexes your datasets, so the count() operation is efficient. But everything is a string, so avg(), sum(), min(), and max() aren’t supported. Even if they are supported, they often aren’t efficient. If records have to be retrieved from multiple servers in multiple data centers just to calculate an average, that can take a long time. 23

Database design • Many of us have learned over the years how to normalize an SQL database. But in the cloud, if the dataset is scattered across multiple machines in multiple data centers and you can’t do joins across tables, you have to do things differently. • A denormalized database contains redundant data and often does calculations at write time, not at read time. A denormalized database is different from a poorly-designed database that was never normalized to begin with. 24

Denormalizing your database • The goal of a traditional, normalized relational database is to put each piece of data into the system once and only once. Building an application to use the data in a different way doesn’t require changes to the database. (Hopefully.) • With a denormalized database, the goal is to copy pieces of data to minimize queries and processing power. Building an application to use the data in a different way might require changes to the database. Updating data might require making the same change in multiple places. 25

Reliability • If I have less physical control over my infrastructure, it’s vital that the cloud be reliable as possible. Some providers have SLAs that guarantee uptime and responsiveness. Some providers deliver private clouds via hosted or colocated data centers. • Reliability isn’t a new problem, but the cloud gives us someone else to blame. 26

Security • If I’m storing my data elsewhere, security as crucial as ever. • If I’m running my applications elsewhere, security is as crucial as ever. Some cloud providers offer greater security, access to their facilities, customized backup and recovery procedures, data destruction, etc. • Cloud computing doesn’t introduce any new security issues. It doesn’t make them easier to solve, but it doesn’t create any new ones. • You can reuse much of your existing security infrastructure. 27

Identity • Identity management, particularly federated identity management, is crucial for cloud computing. Technologies such as LDAP, OpenID, OAuth, etc. can be useful here. • You can reuse much of your existing authentication infrastructure. 28

Regulatory issues • Many enterprises can’t use a public cloud at all. Laws prohibit certain types of data from being stored off-premises. • The private cloud is an important architectural pattern being used in many enterprises. • Location awareness is a key concern for many (potential) cloud users. • Data retention and data destruction are important also. 29

Vendor lock-in 30

Vendor lock-in • If there’s a new technology, any talented programmer will want to use it. Maybe the shiny new thing is appropriate for what we’re doing. Maybe not. We’re probably going to use it anyway. • The challenge is to walk the line between using the newest, coolest thing and avoiding vendor lock-in. 31

The Simple Cloud API • A joint effort of Zend, GoGrid, IBM, Microsoft, Nirvanix and Rackspace But you can add your own libraries to support other cloud providers. • The goal: Make it possible to write portable, interoperable code that works with multiple cloud vendors. • simplecloud.org/ • An article on the Simple Cloud API was published on the developerWorks Open Source zone today: bit.ly/1bSkTx There’s also a Simple Cloud podcast at dW. 32

The Simple Cloud API • Covers three areas: File storage (S3, Nirvanix, Azure Blob Storage, Rackspace Cloud Files) Document storage (SimpleDB, Azure Table Storage) Simple queues (SQS, Azure Table Storage) • Uses the Factory and Adapter design patterns A configuration file tells the Factory object which adapter to create. 33

Vendor-specific APIs • Listing all the items in a Nirvanix directory: •$auth = array('username' => 'your-username', 'password' => 'your-password', 'appKey' => 'your-appkey'); $nirvanix = new Zend_Service_Nirvanix($auth); $imfs = $nirvanix->getService('IMFS'); $args = array('folderPath' => '/dougtidwell', 'pageNumber' => 1, 'pageSize' => 5); $stuff = $imfs->ListFolder($args); 34

Vendor-specific APIs • Listing all the items in an S3 bucket: •$s3 = new Zend_Service_Amazon_S3 ($accessKey, $secretKey); $stuff = $s3->getObjectsByBucket($bucketName); 35

The Simple Cloud API • Listing all the items in a {Nirvanix directory | S3 bucket}: •$credentials = new Zend_Config_Ini($configFile); $stuff = Zend_Cloud_Storage_Factory::getAdapter ($credentials)->listItems(); 36

Where we go from here It’s still early 37

Issues with the Internet • “It’s not secure.” • “I don’t want to lose control of my infrastructure.” • “I don’t know how reliable it is.” • “I don’t know if my partners are going to use it.” • All of these were important, legitimate issues. With VPNs and other technology, the industry solved these problems. 38

Issues with the cloud • “It’s not secure.” • “I don’t want to lose control of my infrastructure.” • “I don’t know how reliable it is.” • “I don’t know if my partners are going to use it.” • All of these are important, legitimate issues. We’ve got some work to do, but the massive economic incentives mean someone will find a way to solve these problems. 39

The hype, one more time •Cloud computing will be the biggest change to our industry since the rise of the Internet. 40

Resources Useful stuff 41

Other cloud sessions • Cloud Computing with VMWare, Akhil Sahil 11:15 – 12:15 Wednesday • PHP and the Cloud, Ivo Jansch 2:45 – 3:45 Wednesday • PHP and Platform Independence in the Cloud, Wil Sinclair 9:15 – 10:15 Thursday 42

Cloud Computing with the Zend Framework • A series of articles from the IBM developerWorks Open Source zone: Using Amazon S3 with Zend, September 22 • ibm.com/developerworks/opensource/library/os-php-cloud1/ Using Amazon EC2 with Zend, October 13 • ibm.com/developerworks/opensource/library/os-php-cloud2/ 43

Principles of openness 1. Cloud providers must work together to ensure that the challenges to cloud adoption are addressed through open collaboration and the appropriate use of standards. 2. Cloud providers must not use their market position to lock customers into their particular platforms and limiting their choice of providers. 3. Cloud providers must use and adopt existing standards wherever appropriate. The IT industry has invested heavily in existing standards and standards organizations; there is no need to duplicate or reinvent them. 44

Principles of openness 4. When new standards (or adjustments to existing standards) are needed, we must be judicious and pragmatic to avoid creating too many standards. We must ensure that standards promote innovation and do not inhibit it. 5. Any community effort around the open cloud should be driven by customer needs, not merely the technical needs of cloud providers, and should be tested or verified against real customer requirements. 6. Cloud computing standards organizations, advocacy groups, and communities should work together and stay coordinated, making sure that efforts do not conflict or overlap. 45

The principles in action • The Cloud Computing Use Cases Google group has a white paper of common use cases. • The identified use cases will be used as input to various standards efforts. • Join us at groups.google.com/group/ cloud-computing-use-cases. • Version 1 of the paper is available at bit.ly/1FXRAH. bit.ly/1FXRAH 46

Developer requirements • Scalable Database • Centralized Logging • Scalable Session Management • Identity Management • Robust Storage • Raw Compute / Job Processing • Messaging – Pub-Sub • Service Discovery • Messaging – Point-to-Point • SLAs • Mail • Caching What else? 47

Thanks! By Doug Tidwell, Cloud Computing Evangelist, IBM dtidwell@us.ibm.com

Cloud Computing: The Hard Problems Never Go Away

by ZendCon

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 28

Statistics