uncompiled.com

“I believe if you set it up correctly, the cloud can be as secure as anything else,” says the CTO of a financial services startup. “But we don’t want to have to waste time communicating to potential customers that the public cloud is secure. It’s a conversation you don’t want to have.”

As a result, this CTO’s company, which had deployed its applications on top of Amazon’s Web service offering, is bugging out of the public cloud and into a private co-location facility. While he believes his team can configure the Amazon service to be just as secure as the on-site option, and the cloud’s low startup costs and rapid deployment benefits are attractive, he had to ask: Could the model cost us business?
No matter how many times public cloud providers assert–often correctly–that data is well-protected on their servers, they just can’t shake the insecurity rap. And that means CIOs need to ask not just whether the cloud makes business sense, but whether their customers will see it that way. They may not: Security tops the list of cloud worries in every InformationWeek Analytics cloud survey we’ve deployed. In our 2010 Cloud GRC Survey of 518 business technology professionals, for example, respondents who use or plan to use these services are more worried about the cloud leaking information than they are about performance, maturity, vendor lock-in, provider viability, or any other concern.

That doesn’t mean businesses are shunning the cloud. Of those respondents who do use or plan to use these providers, within the next two years, 20% say up to half of their IT services will come from the cloud; an additional 45% say a quarter of their IT services could be delivered that way. The benefits, such as lower deployment costs and faster time to market, are just too attractive, particularly in today’s business climate of stagnant budgets and staffing uncertainty. Still, your customers have legitimate questions about running applications in the cloud, whether on infrastructure-as-a service (IaaS) or platform-as-a-service (PaaS) environments. IT must help the business be prepared with good answers to the two main questions we raise, and others specific to the product. It may make the difference between winning business and losing confidence.

First, customers will look for assurance that an application that runs on PaaS is as secure as an application that runs behind an on-premises firewall. The answer will normally be “No–unless it is.” It’s an irritating response, but that’s because cloud security is frustrating. Here’s the breakdown.

A Web application you develop and deploy in a PaaS environment is no more–and no less–secure than a Web app you develop and deploy yourself. The basic principles of secure application development don’t change because of the cloud. “Cross-site scripting is still cross-site scripting. There’s not much difference whether it’s in-house or PaaS,” says Brian Chess, chief scientist and co-founder of Fortify Software, an application security testing company. The upshot? Developers must be trained to write secure software, regardless of where that software runs. Applications must be tested regularly to ensure that the inevitable vulnerabilities are found and remediated. Building and running an application on top of Windows Azure, Google App Engine, or Engine Yard doesn’t excuse an organization from following these principles.

Source

There’s a new kid in town when it comes to open source code in the cloud. It’s Rackspace’s OpenStack, based on both Rackspace’s and NASA Nebula’s existing cloud engines. Wasn’t there already sufficient open source code in play? Why do we need this initiative on top of those already afoot? Actually, we need 3-4 such initiatives.

Rackspace convened a group of interested companies the week of July 12 and asked them if they would help build a stack of open source software that would power a more uniform, future cloud environment. This move had one target, Amazon Web Services EC2, which has run away with the cloud infrastructure market.

Isn’t there already open source code opening up EC2? There is, from Eucalyptus Systems, which did a sterling job of duplicating basic Amazon functionality in its set of compatible interfaces. The Eucalyptus interfaces duplicate basic Amazon functionality, such as ‘load this workload onto a virtual server,’ and then builds them out into cloud infrastructure — for the enterprise private cloud. Eucalyptus Enterprise Edition is a commercial product meant to capitalize on what Eucalyptus open source code created.

The Rackspace initiative is different, and Eucalyptus Systems CEO Marten Mickos said as much when he responded to an InformationWeek query. It “aims at a cloud with a million nodes. It is an entirely non-commercial initiative,” he said. By “aimed at a million nodes,” he means OpenStack, unlike Eucalyptus, is a code project aimed at major cloud suppliers of the future (which, of course, will be commercial initiatives). The project itself isn’t aimed at producing code to be sold as a commercial product so much as providing a cloud infrastructure to be shared across many cloud suppliers.

I found Thorsten von Eicken, CTO of RightScale, which front ends both Rackspace and EC2, the most zeroed in on this new development. In a July 18 blog, he said: “RackSpace has committed itself to a true open source project, meaning that it’s not just source code thrown over the wall into the open, but also an open design process, an open development process and an open community.”

The Rackspace-sponsored meeting lead to a session on OpenStack requirements, with Rick Clark, senior manager of software product development at Rackspace, “managing the requirements gathering very openly,” wrote von Eicken. “I expect we will see a good number of companies contributing code to this project.”

The companies participating at what Rackspace termed its Design Summit were: AMD, Intel, Dell, Citrix Systems, NTT Data, RightScale, Zenoss, Autonomic Resources, SoftLayer, Opscode, CloudSwitch, Cloudscaling, Cloud.com, Cloudkick, enStratus, FathomDB, iomart Group, Limelight, Nicira, Peer 1, Puppet Labs, Riptano, Scalr, Sonian, Spiceworks and Zuora.

The strength of this group is that it has the expertise to cover many bases. The weakness is that it may or may not have the ability to keep a strict focus, keep members engaged, keep code coming over a long period of time. Even if it meets those goals, it may not appeal to all cloud suppliers, who for reasons of their own may adopt a more Amazon-like approach or simply their own approach.

This is open source by and for the benefit of a group of vendors, who wish to supply components to the future cloud and know they will not be able to do so if Amazon’s EC2 is the only player. That’s a little different from the wide open Linux project, which attracted skilled developers whose efforts were then adopted by thousands of other skilled developers on an independent basis. Whatever OpenStack produces, there’s no guarantee that a majority of open source developers, nevermind a majority of cloud suppliers, will adopt it.

But we need the OpenStack project. The open source projects keep Amazon honest, keep it innovating and pushing the cloud frontier forward rather than letting others get there first. We need an alternative to Amazon as well, lest the dominant supplier become so dominant that it can dictate the market. We need more than one alternative.

We now have Eucalyptus and OpenStack injecting code directly to the future cloud market, with different target users in mind. One way to insure we don’t end up in a cloud era that resembles the age of IBM mainframe domination or Microsoft desktop domination is to create and sustain these alternatives.

“Having many fragmented cloud efforts doesn’t really help build a compelling alternative to Amazon,” warns von Eicken.

That’s right, but in the long run, the cloud isn’t just one thing. There will be many variations to the sets of services that it offers and business models that it employs. These services will be built out more rapidly if providers can share infrastructure components and customers can move with ease from one cloud to another.

By putting its weight behind this stack, Rackspace at a stroke has generated a possible basis for competition with EC2 — a future environment shared across a wide range of providers. Whether that eventuality ever materializes remains to be seen, but I see no technical barrier standing in the way.

“The bottom line is, we believe this to be a potentially game changing event,” wrote von Eicken. If the desire to produce code by this set of vendors is matched by a desire to use the code by an even broader one, then, yes, we will have just witnessed a game changing event.

For more thoughts on open source in cloud computing, see Zenoss engineer Mark Hinkle’s presentation on Linux, Open Source and Socialized Software at the O’Reilly Open Source Conference in Portland, Ore.

Source

You can now use the Linux kernel of your choice when you boot up an Amazon EC2 instance.

We have created a set of AKIs (Amazon Kernel Images) which contain the PV-Grub loader. This loader simply chain-boots the kernel provided in the associated AMI (Amazon Machine Image). Net-net, your instance ends up running the kernel in the AMI instead of the kernel specified in the boot process.

You need to install an “EC2 compatible” kernel and create an initrd (initial RAM disk) as part of your AMI. You also need to create a menu (/boot/grub/menu.lst) for the Grub boot loader. Once you’ve done this you can create the AMI and then launch instances by using one of the PV-Grub “kernels” as described above. You may find this document to be helpful if you want to learn more about the Linux boot process.

To be compatible with EC2, a Linux kernel must support Xen’s pv_ops (paravirtual ops) infrastructure with XSAVE disabled or the Xen 3.0.2 interface. The following kernels have been tested and/or have vendor support:

Fedora 8-12 Xen kernels
SLES/openSUSE 10x, 11.0, and 11.1 Xen kernels
SLES/openSUSE 11.x EC2 Variant
Ubuntu EC2 Variant
RHEL 5.x
CentOS 5.x
Other kernels may not start reliably within EC2. We’re working with the providers of popular AMIs to make sure that they will start to use PV-Grub in the near future.

You can read more about this in our “Enabling User Provided Kernels in Amazon EC2″ document.

– Jeff;

Source

We want to make it easier and more economical for you to build fault-tolerant, highly-scalable applications using the Amazon Simple Queue Service (SQS).

Effective July 1st, 2010, your first 100,000 requests to SQS each month will incur no usage charges. We’ll also provide you with 1 GB per month of outbound data transfer at no charge.

We’ve made SQS more flexible by giving you more control of the maximum message size and the message retention time:

Maximum Message Size – Up until now, SQS messages were limited to 8 kB. This is now a user configurable limit, with a maximum value of 64 kB.

Message Retention Time – Up until now, the message retention time for all SQS queues was four days. This is now a user configurable value with valid values ranging from one hour to two weeks.

Source

“We are excited to announce that Amazon CloudWatch has added monitoring support for all Amazon EBS volumes for no additional charge. This monitoring provides performance metrics for your Amazon EBS volumes on bandwidth, throughput, latency and queue depth accessible via the AWS CloudWatch API or the AWS Management Console.
For information on the metric schema and the graphs available through AWS Management Console, please see EC2 Users Guide: Monitoring Your Instances and Volumes.

Sincerely, The Amazon EC2 team”

Source

About 10 years ago I remember reading a section in my Computer Science textbook about data transfers across large distances. This was back when regular users had dial-up modem connections and rich companies had dual-bonded ISDN links. Those were the days!

Anyway, there was one paragraph which stuck in my mind: if you want to send a lot of data somewhere and you don’t care about the latency, the easiest solution is to pack a truck full of tapes and drive to the destination.

And today, despite the death of dial-up, that’s exactly what Amazon is doing! Instead of uploading data to Amazon’s S3 cloud storage via ‘slow’ Internet links, you can now mail a tape or hard drive to one of Amazon’s data centres in Seattle, Virginia, or Dublin. It’s called AWS Import/Export, and to use it you pay a one-off fee of $80 per storage device plus $2.49 per hour while the data is sent into the cloud. There’s a calculator, if you want to work out the price savings of using the snail-mail system instead of the Internet.

To me this sounds a lot like a stop-gap solution: we’re moving vast amounts of data into the cloud, performing more and more tasks remotely, but Internet connection speeds aren’t keeping up! We’re heading towards a day when the Internet is effectively just an extension of our local storage, our LAN — and for that to happen, we need LAN-like links to the Internet!

Source

We continue to enhance Amazon CloudFront at a rapid pace. Here’s the latest and greatest:

We’ve added a new edge location in New York City. This location will provide even better performance to users requesting your content from New York and the northeastern United States.

We’ve reduced pricing for CloudFront HTTP requests by 25%. The prices now start at $0.0075 per 10,000 requests.

You can now deliver content over an HTTPS connection by replacing the “http:” with “https:” in the links to your CloudFront content.

You can configure any of your CloudFront distributions so that the content must be accessed by an HTTPS connection.

The first three items should be pretty much self-explanatory, so let’s take a look at the fourth…

You can now configure an Amazon CloudFront distribution such that access to the Amazon S3 objects represented by the distribution is limited to HTTPS connections. You can do this to protect your content as it travels from a CloudFront edge location to your client application, or to avoid the dreaded “mixed content” warning issued by many web browsers.

To configure your distribution in this matter you simply set the distribution’s RequiredProtocols attribute to the value “https”. If you do not set this attribute, the contents of the distribution will be accessible via both HTTP and HTTPS. You cannot currently make HTTPS requests via a CNAME.

The following third-party applications provide simple tools to set up your distributions for HTTPS access:

CloudBuddy Personal
CloudBerry S3 Explorer
Bucket Explorer
These third-party tools are provided by companies unaffiliated with AWS.

– Jeff;

Source

“I’ve got a cool new Amazon S3 feature to tell you about, but I need to start with a definition!

Let’s define durability (with respect to an object stored in S3) as the probability that the object will remain intact and accessible after a period of one year. 100% durability would mean that there’s no possible way for the object to be lost, 90% durability would mean that there’s a 1-in-10 chance, and so forth.

We’ve always said that Amazon S3 provides a “highly durable” storage infrastructure and that objects are stored redundantly across multiple facilities within an S3 region. But we’ve never provided a metric, or explained what level of failure it can withstand without losing any data.

Let’s change that!

Using the definition that I stated above, the durability of an object stored in Amazon S3 is 99.999999999%. If you store 10,000 objects with us, on average we may lose one of them every 10 million years or so. This storage is designed in such a way that we can sustain the concurrent loss of data in two separate storage facilities.

If you are using S3 for permanent storage, I’m sure that you need and fully appreciate the need for this level of durability. It is comforting to know that you can simply store your data in S3 without having to worry about backups, scaling, device failures, fires, theft, meteor strikes, earthquakes, or toddlers.

But wait, there’s less!

Not every application actually needs this much durability. In some cases, the object stored in S3 is simply a cloud-based copy of an object that actually lives somewhere else. In other cases, the object can be regenerated or re-derived from other information. Our research has shown that a number of interesting applications simply don’t need eleven 9′s worth of durability.

To accommodate these applications we’re introducing a new concept to S3. Each S3 object now has an associated storage class. All of your existing objects have the STANDARD storage class, and are stored with eleven 9′s of durability. If you don’t need this level of durability, you can use the new REDUCED_REDUNDANCY storage class instead. You can set this on new objects when you store them in S3, or you can copy an object to itself while specifying a different storage class.

The new REDUCED_REDUNDANCY storage class activates a new feature known as Reduced Redundancy Storage, or RRS. Objects stored using RRS have a durability of 99.99%, or four 9′s. If you store 10,000 objects with us, on average we may lose one of them every year. RRS is designed to sustain the loss of data in a single facility.

RRS pricing starts at a base tier of $0.10 per Gigabyte per month, 33% cheaper than the more durable storage.

If Amazon S3 detects that an object has been lost any subsequent requests for that object will return the HTTP 405 (“Method Not Allowed”) status code. Your application can then handle this error in an appropriate fashion. If the object lives elsewhere you would fetch it, put it back into S3 (using the same key), and then retry the retrieval operation. If the object was designed to be derived from other information, you would do the processing (perhaps it is an image scaling or transcoding task), put the new image back into S3 (again, using the same key), and retry the retrieval operation.

We expect to see management tools and toolkits add support for RRS in the very near future.

You can use either storage class with Amazon CloudFront, of course.

I anticipate many unanticipated uses for this cool new feature; please feel free to leave me a comment with your ideas.

– Jeff;”

Source

“Amazon RDS simplifies many of the common tasks associated with the deployment, operation, and scaling of a relational database. You don’t have to worry about acquiring and installing hardware, loading an operating system, installing and configuring MySQL, or managing backups. In addition, scaling the processing power or storage space available to your database is as simple as an API call.

When we rolled out Amazon RDS last October, we also announced plans to have a “High Availability” option in the future. That option is now ready for you to use, and it’s called “Multi-AZ Deployments.” AZ is short for “Availability Zone”; each of the four AWS Regions is comprised or two or more such zones, each with independent power, cooling, and network connectivity.

[...]

t is really easy to benefit from the enhanced availability and data durability provided by a DB Instance deployment that spans multiple Availability Zones. All you need to do is supply one additional parameter to the CreateDBInstance function and Amazon RDS will take care of the rest.

To be more specific, when you launch a DB Instance with the “Multi-AZ” parameter set to true, Amazon RDS will create a primary in one Availability Zone, and a hot standby in a second Availability Zone in the same Region. Data written to the primary will be synchronously replicated to the standby. If the primary fails, the standby becomes the primary and a new standby is created automatically. Amazon RDS automatically detects failure and takes care of all of this for you. The entire failover process takes approximately about five minutes. In addition, existing standard DB Instance deployments can be converted to Multi-AZ deployments by changing the Multi-AZ parameter to true with the ModifyDBInstance function (a hot standby will be created for your current primary).

When automatic failover occurs, your application can remain unaware of what’s happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your MySQL client library should be able to close and reopen the connection in the event of a failover. If your application needs to know that a failover has occurred, you can use the function to check for the appropriate event.

If you have set up an Amazon RDS DB Instance as a Multi-AZ deployment, automated backups are taken from the standby to enhance DB Instance availability (by avoiding I/O suspension on the primary). The standby also plays an important role in patching and DB Instance scaling. In order to minimize downtime during planned maintenance, patches are installed on the standby and then an automatic failover makes the standby into the new primary. Similarly, scaling to a larger DB Instance type takes place on the standby, followed by an automatic failover.

Multi-AZ deployments also offer enhanced data protection and reliability in unlikely failure modes. For example, in the unlikely event a storage volume backing a Multi-AZ DB Instance fails, you are not required to initiate a Point-in-Time restore to the LatestRestorableTime (typically five minutes prior the failure). Instead, Amazon RDS will simply detect that failure and promote the hot standby where all database updates are intact.
Putting it all together, this new feature means that your AWS-powered application can remain running in the face of a disk, DB Instance, or Availability Zone failure. Once again, you can focus on your application and let AWS handle the “dirty work” for you.

While you cannot use the synchronous standby in a Multi-AZ deployment to serve read traffic, we are also working on a Read Replica feature. This feature will make it easier to take advantage of MySQL’s built-in asynchronous replication functionality if you need to scale your read traffic beyond the capacity of a single DB Instance. You’ll be able to provision multiple “Read Replicas” for a given source DB Instance.

– Jeff;”

Source

The federal government has moved Recovery.gov, the Web site people can use to track spending under last year’s $787 million economic stimulus package, to Amazon’s Elastic Compute Cloud infrastructure-as-a-service platform, the Recovery Accountability and Transparency Board announced Thursday.

The move marks a milestone for the Obama administration’s cloud computing initiative. Federal CIO Vivek Kundra said in a conference call with reporters it is the first government-wide system to move to a cloud computing infrastructure. It’s also the first federal government production system to run on Amazon EC2, Kundra said.

Cloud computing has been one of Kundra’s top priorities since becoming federal CIO in March 2009. In next year’s IT budget requests, for example, federal agencies will have to discuss whether they’ve considered cloud computing as an alternative to investing in on-premises IT systems.

The recovery board expects to save about $750,000 over the next two years — $334,000 this year and $420,000 in 2011 — by running Recovery.gov on EC2. This represents about 10% of the total $7.5 million the board has spent overall on the site so far, including development costs. “Significantly” more savings are expected over the long term, according to the recovery board.

Numerous technologies including deduplication may have a role to play in managing burgeoning corporate storage requirements

Those savings will allow the recovery board to place more emphasis on uncovering and preventing waste, fraud, and abuse, recovery board chairman Earl Devaney said on the conference call. In addition, they will free up resources to allow Recovery.gov’s prime contractor, Smartronix, to focus on features and functionality instead of having to worry about keeping servers up and running.

“As the world’s largest consumer of information technology and as stewards of taxpayer dollars, the federal government has a duty to be a leader in pioneering the use of new technologies that are more efficient and economical,” Kundra said in a blog post aimed squarely at federal agencies. “By using cloud services, the federal government will gain access to powerful technology resources faster and at lower costs. This frees us to focus on mission-critical tasks instead of purchasing, configuring, and maintaining redundant infrastructure.”

Devaney said that the decision to go with Amazon EC2 to host the site was one made Smartronix, but that the decision to move to the cloud for Web hosting was made by the recovery board. “We had been having conversations with Smartronix about this for a while,” he said.

Security has been and remains one of the primary concerns holding federal agencies back from considering cloud computing. Before moving Recovery.gov to Amazon EC2, the recovery board sought and received assurances from Amazon that none of the Recovery.gov data would be stored in foreign countries, and went through the certification and accreditation required to be compliant with the Federal Information Security Management Act, which regulates federal cybersecurity.

In fact, the recovery board’s press release says that by running the site on EC2, Recovery.gov’s security has actually improved by adding “greater protection against network attacks and real-time detection of system tampering.”

While NASA and other agencies have been testing EC2, Kundra said that Recovery.gov is the first production system running on Amazon Web Services.

“Building on AWS enables Recovery.gov to reap the benefits of the cloud — including the ability to add or shed resources as needed, paying only for resources used and freeing up scarce engineering resources from running technology infrastructure — without sacrificing operational performance, reliability, or security,” Adam Selipsky, VP of Amazon Web Services, said in a statement.

Other agencies have begun moving some IT systems to the cloud as well. For example, in April, the Department of Health and Human Services decided to use Salesforce.com for CRM in support of the implementation of electronic health records systems. The Department of Energy, Department of Interior, and General Services Administration are all considering moving to cloud-based e-mail.

However, the cloud transition remains in early stages. “This shift is not going to happen overnight, but this move represents one of the first bricks in the foundation,” Kundra said.

Source