Cloud Front Office

There Goes the Job of the DB Admin! Or Does it? Amazon Launches Database Cloud Service #cloudcomputing

I'm a big fan (and user) of cloud computing because of the potential efficiencies it brings to the enterprise IT operating model. So this announcement, via www.techcrunch.com, from Amazon is interesting.

Amazon has launched a hosted relational database service, Amazon RDS, as part of the suite of services available at AWS. The new service is a hosted MySQL database instance with the full capabilities and access rights as a normal self-hosted DB.

As a hosted solution, instances are easily created and available almost immediately. Pricing stars at $0.11c per hour for the smallest scale specification, and is available now on the AWS site.

So my question is: does the adoption of this cloud service remove the need for a database administrator? Because if it does,

it's a radical change to the IT operating model. If it doesn't, then it's more complicated to find value because I still need to have a DB admin.

What do you think?

Cloudy inquiry trends from CloudPundit.

When Gartner's clients start asking about cloud computing, a real market is about to appear.

Organizations have really absorbed the hype — they genuinely believe that shortly, the cloud will solve all of their infrastructure issues. Sometimes, they’ve even made promises to executive management that this will be the case. Unfortunately, in the short term (i.e., for 2010 and 2011 planning), this isn’t going to be the case for your typical mid-size and enterprise business. There’s just too much legacy burden. Also, traditional software licensing schemes simply don’t work in this brave new world of elastic capacity.

The enthusiasm, though, is vast, which means that there are tremendous opportunities out there, and I think it’s both entirely safe and mainstream to run cloud infrastructure pilot projects right now, including large-scale, mission-critical, production infrastructure pilots for a particular business need (as opposed to deciding to move your whole data center into the cloud, which is still bleeding-edge adopter stuff). Indeed, I think there’s a significant untapped potential for tools that ease this transition. (Certainly there are any number of outsourcers and consultants who would love to charge you vast amounts of money to help you migrate.)

via cloudpundit.com

Meet Your New Cloud, Same as the Old Cloud

This is ugly. Saas really requires a new discipline if it's going change internal apps. This story from www.networkworld.com makes it really clear why

Even senior developers can get lost in the weeds trying to figure out how a feature can be, or might have been implemented, in Force.com. Typical "gotchas" include:

* With numerous configuration options and powerful programming tools there are many ways to implement the same features. Configuration experts and developers run the risk of reinventing the wheel if they do not collaborate closely on solution design.

* Force.com deployment tools do not currently support critical items such as data sharing rules, picklist fields on standard data objects, lead and sales processes, and the management role hierarchy.

* Apex unit tests are impacted by actual org data, so code that passes unit test requirements in the sandbox may not deploy. For example, data queries on objects with more than 100K of data require querying an external ID field. Unit tests that pass in a sandbox can fail in production, killing your deployment.

Survey says! Lack of management solutions creates hurdle to Cloud Computing #cloudcomputing

Interesting survey

The survey found that, while adoption is increasing, CIOs are concerned about how to manage and control applications and resources in Cloud environments. More than half worry about a lack of cost control (57 per cent) and more than a third (35 per cent) fret over scalability. But the biggest concern is being locked-in to one vendor for Cloud services, according to 63 per cent of organizations. The results show a need for more sophisticated tools to monitor and control Cloud usage and the movement of applications from Cloud to Cloud. Over half of enterprises surveyed (53 per cent) also say introducing government standards and legislation to control Clouds would boost adoption rates.

via www.zeus.com

Do Clouds Need Admins? Yes.

Recommended reading.

The programmer-managed infrastructure suffers from a death by a thousand cuts. The programmer is competent with technology and fully capable of setting up a system that can support the application being built. The programmer, however, lacks a detailed understanding of ongoing infrastructure management. Consequently, the programmer-managed infrastructure ultimately leads to an environment incapable of adjusting to changing demands and potentially opens vulnerabilities to hackers through discreet channels.

via broadcast.oreilly.com

Reading: Is Virtualization Enabling Legacy Sprawl – Another Y2K in the Making? #Cloudcomputing

I read this with interest because I'm seeing the danger in my own use of Amazon EC2 services:  Instances go up, but unless you are very determined, they don't come down on their own and every month they cost money.

Just a Thought – Is VMware Enabling Legacy Sprawl – Another Y2K in the Making?

One of the hidden beauties of any virtualized state is the clear disaggregation of hardware and software, the logical separation of traditionally tightly coupled environments, allowing us much greater flexibility in deciding what applications to run where, and for what reasons.  This flexibility in and of itself is a good thing, and we all benefit from it, but I suspect that if we’re not careful in how we use virtualization some apparently intelligent decisions today may in fact turn out to be significant problems in the future.

via blogs.gartner.com

Data Center Dialog: Multiple virtualization vendors in one IT shop? If so, the management challenge changes

Recommended.

Why would organizations want so many types of server virtualization in house? ESG's Stephen O'Donnell blogged that he didn't think this was a result of maturing products from Citrix and Microsoft, but rather because of licensing moves by vendors and license management practices by customers. ESG was also running a second poll while I was viewing their survey results, asking "Why is your organization running more than one hypervisor (e.g., Citrix/Xen, KVM, Microsoft Hyper-V, VMware ESX)?" The most common answer when I looked (24%) said that pressure from people like Oracle and Microsoft is pushing them to support multiple hypervisors. 13% say it's just departments doing their own thing. Both contribute, I'm betting.

Another reason is likely to be acquisitions, something that's becoming more common with the downturn. Sure, you didn’t set out from the start with more than one hypervisor vendor, but mergers tend to mean you get plenty more than you bargained for. Why should server virtualization be any different?

via datacenterdialog.blogspot.com

And beyond that, people will still need physical hardware. And they'll add cloud services as well. This is what newScale tools are all about.

Bazillion Cloud Servers up and Running. Maybe Not. But We're "Wasting" Servers with Singular Delight

So how real is cloud computing? Pretty real by the number of servers being deployed by Amazon, reports Bernard Golden in an excellent CIO article. 

I don' know what the number is and it's probably a lot less than what the article implies, yet it is a staggering number. But there are some differences worth discussing. More after the quote.

Tue, September 29, 2009 — CIO — There's been a lot of discussion the past couple of days about an analysis by Guy Rosen, in which he estimates that Amazon Web Services (AWS) is provisioning 50K EC2 server instances per day. He created this estimate by examining EC2 resource IDs (if you read his post, you'll see how he broke down resource IDs to understand their meaning) and doing a time-series analysis on how much the IDs are incremented per hour. From this analysis, Rosen concluded that AWS is provisioning around 50,000 EC2 instances per day.

At newScale we have been using Amazon EC2 for about year. During that time, we have spun up lots of instances. We also shut them down when no longer needed. So that leads to a large number of instances I suppose, as the article implies, but a lower total number of actual servers running all the time.  Since our software is entirely web-native, it's easy to give one of our customers a new version, trial, proof-of-concept, dev, qa, and production servers in the cloud. This bypasses the months of waiting for hardware.

The other thing is that we tend to "waste" servers on purpose. For example, we have a bunch of images, each specialized for certain workloads. It's easier, and more convenient to spin up two or three images that are purpose built rather than spending a day or two installing SQL, Oracle, Java, and our software on a server. In other words, I'm wasting servers, because labor hours are precious and scarce. That's a theme that I've observed with other companies using cloud computing. 

It's a bit like what happened with CPU power: programmer resources and time are expensive, so we use higher level languages like Java rather than Assembly and "waste" processor. I remember when Windows took off -- people were concerned that all those "graphics" were wasting transistors. Turns out we didn't have to worry.

In the cloud, if I spin up 20 servers this week, and shut them down in a couple of days, and then spin up them later, I only pay for what I consume.  I couldn't do that with physical servers, even virtualized. 

Working with some amazing sys admins that come from traditional hosting, it's been a hard change at first. Traditionally, server uptime and server scarcity is what they care about. In my project, I care about their time.

So what's the key to this magic?  We've had to do three things:

1) Establish clear standards, policies and images.  For example, only use Small Windows with SQL Express for these type of workloads. Here are the two images that fit that kind of scenario.

2) Tight control over the lifecycle to prevent sprawl.  There are lot of parts to it, but all servers have an expiration date as well as other attributes that allows us to map it to customers, groups and usage. And a draconian termination policy: servers that are orphaned, get terminated.

3) Put some controls on entitlement: who can order, what level, how do we account for expenses.

At first, the Amazon console was good enough, but around 5 servers and 3 internal requesters, the ease of use became a problem leading to cloud sprawl.

We are about to probably quintuple our usage of cloud. So we are setting up all of this in our service catalog and our service lifecycle manager. I'll report more on our journey, if there's interest.