Here’s my notification email:

Dear Ken,
You were recently selected as a candidate for publication in the prestigious Top 100 Leaders of 2012 Magazine. It is my distinct pleasure to inform you that your candidacy has been reviewed and approved by a special committee and that your biography may soon be featured in this extraordinary, professional magazine.

Only the most accomplished and distinguished men and women are considered for this honor and there is NO COST or obligation to be listed.

After confirming your acceptance, your space within the magazine will be reserved. Our professional writers will then craft an articulate, interesting and informative biography that will be both a treasured legacy and an impressive addition to your professional resume.

Only your prompt response is required to ensure your inclusion.

Please VISIT HERE
to accept this invitation to appear in the Top 100 Leaders of 2012 Magazine (and receive your professionally written biography).

Our registration deadline is October 31st, 2012. We must receive this verification on or before that date to include you in the magazine.

On behalf of our Selection Committee, it is a pleasure to welcome you and to share and celebrate your many personal, professional and academic achievements.

Respectfully,

Ashley Wright
Executive Director

The Top 100 Magazine
23-35A Steinway Street
Astoria, NY 11105, USA

I just can’t contain myself – the honor of being selected is overwhelming … I, I think I’m going to cry.

What a scam! I bet this magazine really does exist – and that they truly would list me in it. But I’ll also bet that the circulation for this magazine is limited to the poor saps who agree to have their information included. And they spend only $100 or so for each copy (and you’ll want to have lots of copies to hand out to your friends and associates!!) — but, hey, it beats the Nigerian money laundering “opportunities”!

If any of you would like to be included in this magazine, I’m sure Ashley would be more than happy to add your name to the Top 100 Leaders of 2012 list!

1. Cloud 101: What is Cloud Computing?
2. Cloud 101: The Three Service Models
3. Cloud 101: The Four Deployment Models

An interesting question: “Is Cloud Computing right for your organization?”

A simple answer: “Yes.”

If only it were that simple! If you’ve been following along with my “Cloud 101″ series, you now understand that “Cloud Computing” is not a one size fits all offering. There are multiple service models and multiple deployment options, and they can be mixed and matched in any combination. Not only that, within each service model there are many configuration options – take IaaS as an example.

Within the Infrastructure as a Service service model, you have “self-managed IaaS”, “lightly managed IaaS”, and “complex managed hosting”. You have the ability to deploy IaaS on physical hardware, you can use:

• VMware with vCloud Director
• Hyper-V with the System Center management suite
• Xen with OpenStack
• Amazon Web Services
• RackSpace
• GoDaddy
• Terremark
• Many, many more options!

The options listed above include private, community, and public offerings. You can mix and match for a hybrid solution. In short, there are countless options for deploying each of the different service models.

So…with that said, is there an option that’s right for your organization?

In my opinion, there is. It’s just a matter of identifying which option matches your needs. I’ll give a few example use cases to help you see what I mean. There’s no way I can cover everything – there are literally thousands of situations that could justify the use of Cloud Computing in your organization. Here are some to get you thinking about the needs within your organization (these are all viable reasons to use PUBLIC cloud!):

• Development and Test environments
  This is where many organizations started their virtualization journey. It’s also a great place to begin your Cloud Computing journey. In “legacy” data centers, dev/test environments take a long time to stand up. There’s the long lead times for procurement, the installation & configuration, and then the “hand-off” to the dev/test team. In efficient organizations, this could happen within a month. Frequently, it was three months or longer. Virtualization helps. With virtualization, you can deploy VMs from templates and have an environment up and running in a matter of a few minutes to a few days. But with virtualization, you’re still responsible for maintaining the infrastructure and doing the necessary capacity planning to make sure you have enough infrastructure to meet the demands. Additionally, with a virtualized environment, you still have IT staff playing the role of intermediary/facilitator. Virtualization does not provide a self-service portal where an authorized user can go and fill out a request form and (assuming they have enough room in their budget) have a dev/test environment up and running in a few minutes — without your IT staff having to lift a finger.
• Public facing website
  It’s a public facing website – you don’t have anything on it that is critical, do you? Why host it internally? Why use that bandwidth to feed static content about your company when you could be using it instead to process business transactions for your company? Why have YAOS (yet another OS) for your IT staff to have to manage? Along with the web platform on top of that. Let someone else do it for you. If you do it correctly, you might even save money in the process!
• Electronic product delivery
  Think Netflix, iTunes, and the like. Your product is really pretty static. You’re shipping electronic “bits” to your customers who are (hopefully) widely distributed throughout the country or the world. This is a perfect use case for a Content Delivery Network (CDN), which falls into the category of IaaS.
• Highly variable workloads
  If you have any task that uses a highly variable workload (i.e. busy at certain times, but doing nearly nothing at other times), do you want to have to purchase enough infrastructure to support the heaviest need? Wouldn’t it make more sense to run it in a Cloud environment where you can scale up or down as needed – and pay for the infrastructure only when you use it? Think IRS (or TurboTax, TaxAct, etc.) at tax time or pretty much any e-tailer over the holiday season.
• Email
  One of the most basic of business needs, yet so frequently mismanaged. Do you really need to host your email in-house? For some of you, the answer will be yes, but for a large percentage, if you are truly honest with yourself, the answer will be no.
• Disaster recovery
  You do have a disaster recovery plan, right? You could tell me – in the next 30 minutes – exactly who is going to do what when your data center is hit by a tornado, flood, or power outage, couldn’t you? And you’ve tested your plan to make sure it works (and not just once!), right? If you’re like a very large percentage of businesses out there, the answer is a resounding “NO WAY!”. Did you know that 70% of small firms that experience a major data loss go out of business within a year? The costs of “traditional” disaster recovery” approaches are prohibitive for many small businesses, and painful for pretty much every business. Using Cloud-based services can significantly reduce the cost and dramatically improve your ability to respond – and recover – after a disaster strikes.

That’s just a small sample of the many reasons you might want to use public Cloud Computing. Private Cloud Computing can offer a totally different set of use cases. Rather than giving specific examples, let me just say this:

Private Cloud Computing can be used to support any IT need. You may (probably will) have to modify some/many of your IT policies and procedures, but private cloud can add value.

I’m sure I’ll get some pushback on that statement, but it’s the truth! The biggest thing to keep in mind is that, in order to get the most bang for the buck out of Cloud Computing, you have to standardize and automate. Going through the process of standardizing and automating will significantly enhance your IT staff’s ability to meet consumer demand.

What it really boils down to is this:

If you don’t have a really good reason to not use Cloud Computing, you should be using it! Even if you have “sensitive data”, you can host it in a private cloud. The benefits derived through the use of Cloud Computing are substantial. You may not save money (in fact, at times it’s more expensive to use Cloud Computing – your mileage may vary!); however, you will gain flexibility, agility, scalability, and survivability, assuming you take the time to do it right.

OK, that wraps this edition. There is one more to go in the Cloud 101 series. Next time around, we’ll talk about your organization is ready for Cloud Computing. Stay tuned, it should be fun !

• Cloud 101: What is Cloud Computing?
• Cloud 101: The Three Service Models

If you’ve not yet read those posts, now would be a good time to skip back and take a quick pass through them.

In this edition, I’m going to talk about the four Cloud Computing deployment models. As a quick reminder, I’m basing this discussion on the NIST definition of Cloud Computing, so the four deployment models are:

1. Private Cloud
2. Community Cloud
3. Public Cloud
4. Hybrid Cloud

NIST does a pretty good job of defining these models, but I want to try to give a little more context to each:

1. Private Cloud: The private cloud deployment model represents a model where a single organization stands up cloud capacity and ONLY members of that organization are allowed to consume that capacity. This is a common model for Governments and large enterprises. The primary reasons you would want to create a private cloud are:
   1. Security concerns. Many organizations are not comfortable putting their workloads into a shared computing environment. Heck, there are still a lot of users out there who aren’t comfortable having multiple VMs sharing the same hypervisor, so it’s no surprise there’s concern about clouds! I’m not trying to minimize this concern – it is a very valid one. When you deploy into a public cloud (discussed below), you’re handing over the control of the infrastructure to someone else. What’s to prevent them from doing something you don’t want them to do with your stuff?
   2. Data sovereignty concerns. Along the same lines as the security concerns above, there is a valid concern with data sovereignty. Data sovereignty deals with the ability of the data owner to know – and control – where their data is stored and who has access to it. This can be extremely important when dealing with sensitive data or data that is regulated. For example, you may have government regulations that require that any Personally Identifiable Information (PII) about your financial customers not be stored outside the boundaries of your country.
   3. FUD. Fear, Uncertainty, and Doubt – a.k.a. FUD. It’s amazing how much this little three-character mnemonic retards individuals & organizations ability to adapt to new technologies or business processes! Often, private clouds are created simply because the organization’s leadership doesn’t understand Cloud Computing well enough to recognize that there are secure, viable, cost-effective alternatives.
   4. It’s better than no cloud. Face it, private cloud is frequently a stepping stone toward one of the other deployment models.

   Private cloud is often the first place an enterprise (officially) looks for cloud computing. I added the (officially) parenthetical because – just as with virtualization – there are often skunkworks activities within the enterprise that are using public cloud because it’s easier to get the level of service needed externally rather than from internal IT. This “consumerization of IT” is a topic for another day…

   Dipping the enterprise toe into Cloud Computing via a private cloud does have significant merit. As I’ve mentioned elsewhere, the path to cloud is not easy. It requires organizations to modify policies and procedures. It requires staff members to adapt their ways of thinking. Private cloud can serve as a foundation on which to build robust approaches to Cloud Computing that can then be used to support a transition to community, hybrid or public clouds.

2. Community Cloud: A community cloud is a Cloud Computing environment that’s not dedicated to a single organization, and yet, it’s not available to anyone who comes along. A community cloud is implemented to support the Cloud Computing needs of a group of related organizations (e.g. fire departments, government agencies, community swimming pools). Much like a “credit union” in the United States, you must meet certain criteria to be eligible to consume the services of a community cloud. The primary advantages of a community cloud are:
   1. Security: In most cases, part of the procedure for being granted membership in the community is undergoing a review of an organization’s security posture. Since all members of the community (i.e. all users of the community cloud) have been “certified” to meet a specific set of requirements, there can be a fairly high degree of confidence that everyone is going to play by the same rules. It also means that one of the requirements could be that all data centers participating in the community cloud reside within a particular jurisdiction – addressing, at least partially, data sovereignty concerns.
   2. Scale: It is likely that a community cloud will be larger than a private cloud. This will enable more effective utilization of the resources in the cloud and provide more leverage when purchasing assets for inclusion within the cloud. The principle benefit of scale is the ability to drive down costs. Typically, the bigger the cloud, the lower the cost for providing a unit of capacity.
   3. Common practices: Frequently, when signing up for a community cloud, you are agreeing to abide by a set of common practices that are adhered to by all members. Hopefully, these will be practices that have been proven through multiple iterations and many prying eyes. Adapting your internal processes to match these community cloud practices may improve your organizational efficiencies.

   While there are many benefits to community clouds, it’s one of the less common implementations of Cloud Computing. I’m assuming this is because it’s challenging to get organizations to cooperatively work together for risk of giving up the “crown jewels”. In any case, you probably won’t run into community clouds too frequently.

3. Public Cloud: This is the one you’re probably most familiar with. This is the Amazon, Google, Dropbox, and Box clouds that many of you are already using. It’s a cloud that anyone can use, all you need is an email address and – in some cases – a credit card. Public cloud implementations are, by far, the largest cloud implementations around. This scale enables them to achieve massive economies which private & community clouds just can’t match. This scale is what allows Amazon and RackSpace to provide IaaS at price points that can’t be beaten. So…why would you want to deploy your workloads onto a public cloud infrastructure? Here are a few reasons:
   1. Price: It’s nearly impossible to deliver IT services at a lower cost than a public cloud provider. They purchase (or build) so much capacity that they get volume discounts that would make Sam Walton turn green with envy. They’ve also mastered the art of automation. When you go to a public cloud portal and place an order, there is NO human intervention to provision your service instance. To give you an idea of the magnitude of the automation, an enterprise with a highly virtualized environment is potentially achieving a server to admin ratio of 500 to 1. Google is reported to have a ratio of about 10,000 to 1. [Computerworld, 2010]. Now I’m the first to admit that this is comparing apples to oranges – the enterprise admin has to worry about more than just provisioning an empty VM or a pre-defined software stack for their consumer to use – but it gives you some insight into how economies of scale tied with advanced automation capabilities tilt the table in your favor.
   2. Scalability: “Not everyone realizes that on any given day AWS adds enough new server capacity to support Amazon’s entire global infrastructure in the company’s fifth full year of operation, when it was a $2.76B annual revenue enterprise.” [James Hamilton, VP & Distinguished Engineer, Amazon Web Services]
      Who reading this can make that same claim? I don’t know how many servers it took Amazon to run their business when they had a piddly little $2.76B annual revenue number, but I can bet that it was several thousand. When you’re purchasing that much compute (and the associated networking, storage, and management infrastructure), you can get a volume discount! Public cloud vendors have enough capacity that the typical consumer can just assume it’s infinite. Companies like Netflix and Zynga rely on that scalability to enable them to meet a highly variable workload – you can, too.
   3. Flexibility/Agility: Do you need 10 servers today, 1,000 servers tomorrow, and 10 next week? If so, then you need public cloud. Public cloud enables you to spin up (very quickly) whatever capacity you need, use it for as long as you need it, and then turn it off (and stop paying for it) when you’re done. To accomplish this in-house with traditional IT services, or even with a private cloud, you would have to go out and buy that capacity, even though you need it for only one week. This is the “killer feature” of public cloud. This is what enables you to test your new product release in an environment that mirrors that of your largest customer – rather than having that customer be your test bed. It’s what allows you to crunch massive data sets once a year (or once a quarter) using enough compute capacity to get through the job in hours rather than days or weeks (or not at all).

   Public cloud offers tremendous benefits in price, scale, and flexibility. If there’s a way you can use it, you should :^}.

4. Hybrid Cloud: As the name implies, hybrid cloud is a combination of two or more of the deployment models discussed above. In all honesty, this is where I see a large percentage of enterprises living in the “near” future. I’ll talk more about this in my next post…

That wraps up this, my third, article in my “Cloud 101″ series. I’ve got two more articles in the pipeline:

1. Is Cloud Computing right for your organization?
2. Is your organization ready for Cloud Computing?

Thanks again for sticking with me. I hope you’re getting something out of these articles!

AFCEA Bethesda Chapter Presents
Cloud Lifecycle Management -
Plan. Acquire.Sustain.Adapt.

White Paper Compiliation

Cloud computing offers the next level of IT capabilities to agencies. When you implement cloud computing, you can adapt to changes in demand and requirements much more quickly than with traditional computing technologies. However, for all of the advantages that cloud promises, there’s a downside. There are significant risks associated with cloud computing; the obvious risks of security, data sovereignty, fault tolerance, disaster recovery, etc. – and some not‐so‐obvious risks.

There is a significant risk of getting trapped in a particular cloud implementation. This is true whether your cloud is providing Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS), but the risk increases as you progress from delivering IaaS to PaaS and SaaS.

With IaaS, the largest risk comes from being tied to a particular hypervisor. While today there is one predominant hypervisor in the marketplace, there are many alternatives available – and they’re rapidly gaining market share. In fact, one of the largest, most well‐known cloud providers does not use the market‐leading hypervisor to enable their infrastructure. There are currently two virtual disk formats that are in widespread use: .vmdk and .vhd. Other formats exist, but these are the predominant formats, and it is highly unlikely that there will be a convergence any time soon. To prevent hypervisor lock‐in, there needs to be wide‐spread adoption of standardized disk formats. The Open Virtualization Format (OVF) is a step in the right direction, but OVF merely provides metadata that describes how to construct a virtual machine (networks, CPUs, RAM, etc.) and provides a record that describes the capacity and format of the virtual disks. The standard does not require a specific disk format – or even that the format specified be able to be  converted to a standardized format. All in all, IaaS provides the least opportunity for lock‐in, mainly because there are fewer areas where standards are important.

Moving a step up the cloud hierarchy brings us to PaaS. With Platform as a Service, the cloud service provider incorporates additional capabilities into their offering to enable customers to make more efficient use of the cloud resources. These capabilities often include things such as database, security, scalability and messaging services. The inclusion of these services can greatly simplify the development of applications, but they can also serve to keep you tied to the provider’s underlying platform. Imagine you have developed your mission‐critical line of business application to make full utilization of the cloud provider’s extensions. Now, imagine that the provider goes out of business or otherwise becomes unable to meet your demands – or, perhaps, you become dissatisfied with the level of service or the price  ou’re required to pay in a few years. How do you move to an alternative PaaS provider?

Without standards for these critical middleware services, you may soon find yourself at the mercy of your cloud service provider, with no real way to escape without devoting a lot of additional, unbudgeted time, resources, and funding in the effort.

This is true even if your cloud is purely private, with all functionality contained inside your organization. In that case, you may be your own provider, and your users could very well be the ones displeased with the quality or inflexibility of your private cloud. How will you ensure that you have an exit strategy for your own implementation?

Finally, let’s take a look at SaaS. This is the “holy grail” of cloud computing. With SaaS, you turn over complete control of the infrastructure, all the way up through the application, to your cloud hosting provider (or you assume complete control if you offer your own private cloud). SaaS becomes a “black box” for your users. With SaaS, the days of implementing customized business processes via extensive customization are gone. That’s both good and bad: it’s good because it enables much more rapid implementation of automation systems; it’s bad because your organization loses much of the ability to fine‐tune services beyond what’s already been decided as part of the SaaS implementation.

With the current lack of standards at each of the cloud tiers, maintaining a high degree of flexibility is a challenge. The chances of becoming “cloud locked” are extremely high. Once you commit to a particular cloud vendor, it can be extremely costly and difficult to pull your systems and data to move to another provider to take advantage of unique capabilities or more favorable pricing models. The implementation and wide‐spread adoption of standards at each of the tiers in the cloud hierarchy is essential to ensure the portability of workloads and data among a variety of cloud providers.

Until standards for IaaS, PaaS, and Saas become pervasive among a majority of cloud providers, you may want to consider implementing a private cloud so as to reduce the risk of lock‐in. You won’t eliminate the risk that your own decisions might not work out, but you won’t be at the mercy of anyone but yourself if you need to re‐think your design or move in a different direction.

1. Infrastructure as a Service (IaaS)
2. Platform as a Service (PaaS)
3. Software as a Service (SaaS)

The basic thing that separates these three service models is “who’s responsible for what?”. As you can see in Figure 1, the further “up” the stack you go, the greater the responsibility assumed by the cloud service provider.

Figure 1: Cloud Service Models

What this Figure 1 tells us is that for:

• Infrastructure as a Service (IaaS), the Cloud Provider is responsible for everything up to, but not including, the operating system and the Cloud Consumer is responsible for everything from the operating system up through the rest of the stack.
• Platform as a Service (PaaS), the Cloud Provider  is responsible for everything up through the middleware & development environment and the Cloud Consumer is responsible for everything from the application up through the rest of the stack.
• Software as a Service (SaaS), the Cloud Provider  is responsible for everything up through the application and the Cloud Consumer is responsible for the application configuration, personalization, and application data.

One thing to notice here is that, in all cases, the Cloud Provider is responsible for the physical infrastructure (which will likely include a hypervisor to support the creation of virtual machines), and the Cloud Consumer is responsible for application configuration, personalization, and data. You’ll also notice in the diagram that, from the Cloud Provider perspective, SaaS “sits on” PaaS which sits on IaaS. I want to note that this is certainly a viable configuration (i.e. a PaaS Cloud Provider could deploy their PaaS capability onto their own – or someone else’s – IaaS infrastructure & SaaS can run on PaaS), but it’s not the way it has to be. In fact, that’s not usually the optimal way to run PaaS or SaaS. The reason for that is because an IaaS infrastructure is optimized to run a wide range of generic workloads. If you know in advance what the characteristics of your workload are (which, if you’re deploying PaaS or SaaS, you have a pretty good idea), you can tune your infrastructure to best meet the demands of that workload. For example, if you were offering a SaaS logging service, you would want to optimize your storage infrastructure for streaming writes, whereas if you were offering a database as a part of your PaaS offering, you would want to optimize your storage based on the I/O patterns specific to the database system you were using. In any event, simply understand that the models can but don’t have to be stacked on top of one another.

Another way to conceptualize the three models is to look at the likely consumers of each. They really are targeted at very different users!

• Infrastructure as a Service (IaaS), the typical consumer for an IaaS offering is a system administrator. If you refer back to Figure 1, you’ll see that this makes sense. With IaaS, the consumer is responsible for the operating system and everything above it. This is very much the way that many data centers operate in a “traditional” IT shop, with the “data center” team providing ping, power, and pipe to the system administrator. This is also one of the reasons that I view IaaS pretty much as a better way of doing what we’ve been doing for the last 20 years!
• Platform as a Service (PaaS), with PaaS, the target audience is either the application developer or the application hoster. Platform as a Service implies that the Cloud Provider is responsible for everything up to the application environment. This includes middleware (such as JBOSS, Spring, STRUTS, the .Net framework) and all the app developer has to do is start writing code – the hoster simply installs the app and turns around and offers it to his customers as PaaS. Since the Cloud Provider manages all the underlying components, the developer doesn’t have to worry about whether everything is configured correctly – it was built using the same automated system the other instances in the cloud were built with.
• Software as a Service (SaaS), the Cloud Provider  is responsible for everything up through the application and the Cloud Consumer is responsible for the application configuration, personalization, and application data. SaaS is the “holy grail” of cloud computing because it allows the business consumer to focus on the application, which is where their business processes and everything that makes them unique lives. It also allows the Cloud Provider to focus on the infrastructure and compete with other Cloud Providers based on price and performance.

The target consumer for each service model, along with the Cloud Provider responsibilities is summarized in

That pretty much wraps up the NIST view of the three different service models. And now, just when you begin to think you’re getting a handle on all this, Gartner has to go throw a wrench in the works. Apparently, they aren’t content with the NIST definitions, so they came up with the following “additions” to the IaaS category:

• Self-managed IaaS, for cost-effective agile replacement of traditional data center infrastructure.
• Lightly managed IaaS, for customers who wish to primarily self-manage but want the provider to be responsible for routine operations tasks.
• Complex managed hosting, for customers who want to outsource operational responsibility for the infrastructure underlying Web content and applications.
  **Gartner Magic Quadrant for Cloud Infrastructure as a Service and Web Hosting

According to these definitions, the NIST incarnation of IaaS is what Gartner refers to as “Self-managed IaaS”. The “Complex managed hosting” sounds an awfully lot like the NIST version of PaaS.

I hope that last little bit does not serve to confuse. I simply wanted to present it because you will see and/or hear these terms when people talk about Cloud and I wanted to make sure that you were familiar with them.

Thanks for sticking with me through this second installment. The next post in the series, Cloud 101: The Four Deployment Models, is about the different deployment models:

• Private Cloud
• Community Cloud
• Public Cloud
• Hybrid Cloud

And after that, we’ll talk about whether cloud computing is right for you, so stay tuned!

Thanks,
KLC

vKen.Cline does virtual

As you read through the NIST definition, you’ll notice that it talks about essential characteristics, service models, and deployment models. There’s pretty much nothing about technology. That’s worth paying attention to! I’ll cover a couple of the essential characteristics here, I think a few are pretty obvious.

Cloud computing is a paradigm shift in how IT is exposed to the consumer

On-demand self-service: the first of NIST’s essential characteristics. There’s a reason it’s first – in my opinion, it is the most important of the five essential characteristics. There are nine words in this definition that really drive home the essence of cloud: “unilaterally provision … as needed automatically without requiring human interaction“. This is why most environments that have been virtualized are not “clouds”. A virtualized environment can frequently satisfy the other four characteristics, but this on-demand self-service piece adds a significant wrinkle.

This level of automation implies that the cloud service exposes its capabilities either through a self-service portal or via an application programming interface (API) — and most likely, via both. Some good examples of this are Amazon Web Services (AWS) and Microsoft Windows Azure . With either offering, you can go to their portal, sign up for an account, and begin using their services – all without ever interacting with a human. You could do the same thing from a program via the APIs that they expose. You could also integrate the acquisition, provisioning, scaling, and deprovisioning of cloud services into your trouble ticketing or workflow system (think BMC Remedy and other help desk/change management solutions here). That’s a pretty powerful capability!

Rapid elasticity: having the ability to quickly add and remove capacity can be the difference between having satisfied customers or vacated shopping carts. There are a few really good examples of businesses/entities that have very high fluctuations in demand. For many, the changes are seasonal: the IRS in the first quarter of the year, just about every US-based retailer over the Christmas season, etc. For others, it can be product driven.

A prime example of a company that used the cloud to meet extreme fluctuations in load due to product release is Zynga:

“Then along came FarmVille. After the game’s 2009 release, 10 million users were hitting FarmVille servers within six weeks, and 25 million within five months.

“We couldn’t get power fast enough. We couldn’t get servers fast enough. We just couldn’t scale our infrastructure to match the needs of FarmVille,” said Allan Leinwand, Zynga’s CTO of infrastructure.
** How Amazon saved Zynga’s butt—and why Zynga built a cloud of its own

The first part of second paragraph of that Allan Leinwand quote is critically important: “We couldn’t get power fast enough. We couldn’t get servers fast enough. We just couldn’t scale our infrastructure…“. This was a company that was using a “traditional” data center-based IT infrastructure and they suddenly had a worldwide hit on their hands. The demand grew so quickly that they simply could not provision capacity quickly enough to keep up. It’s also important to note that, eventually, the demand for FarmVille fell off. That meant that Zynga no longer needed all that capacity. Since they were on AWS, they simply spun down the instances they no longer needed and stopped paying for them; try that in your private data center!

I’ll come back to this Zynga example in a subsequent post – I want to talk about why it was the right thing for them to do to go from a private infrastructure to a public cloud and then back to a private (cloud) infrastructure — stay tuned!

While we’re on the topic of rapid elasticity, consider this:

“Each day Amazon Web Services adds enough new capacity to support all of Amazon.com’s global infrastructure through the company’s first 5 years, when it was a $2.76B annual revenue enterprise”
** Expand Your Infrastructure with the Elastic Cloud see slide 4

I’m certain that Google, RackSpace, and a few others can make the same claims … can you?

This ability to scale as needed is especially important for smaller companies (and larger ones who don’t like equipment sitting idle on the data center floor!). Take a quick look over at Amazon’s case study page to see a few examples of companies that launched in the cloud and grew exponentially.

Cloud computing is, more than anything else, a new business model for delivering IT services

Measured service: this is the last of NIST’s essential characteristics. Why am I calling this one out? What makes it so important? Remember, we’re changing the business model for delivering IT. One of the most important shifts is that we’re moving from a capital expenditure (CapEx) model to an operational expenditure (OpEx) model. This simple change allows you to much more accurately track the business value of IT services. Since you’re paying for the capability that you use, there’s a direct correlation between your cloud computing bill and the business impact IT provides.

Why is it important that cloud-based services be “measured”? For two reasons:

1. So that the provider can understand the cost to deliver the service and establish a price for which to sell it, and
2. So the consumer can evaluate the price against the value it will bring to his purpose

I introduced three terms there that I’d like to take a quick detour to discuss:

• The “cost” of something reflects the expenditure (time, labor, power, cooling, etc.) required to provide the service to the consumer.
• The “price” represents the amount of currency that the provider is willing to make the thing available to consumers for.
• A thing’s “value” represents the benefit that is derived through its use.

In very gross terms, the delta between a providers “cost” and the “price” to the consumer represents the provider’s return on investment (ROI). The difference between the “price” and the “value” is the consumer’s ROI.

OK, I lied. There aren’t only two reasons why measured service is important. There’s another, critically important reason why cloud services need to me measured: the measurement of cloud services provides transparency and allows both the provider and the consumer to know whether the service that’s being delivered meets the parameters established in the contract between the provider and consumer.

Oops! There’s another term: contract. Before a consumer can access the services made available by the provider, there has to be a “contract” put in place. The contract defines what it is that the provider is making available to the consumer, establishes some performance characteristics, sets the price, and establishes penalties to be imposed if the provider fails to meet the terms of the contract. The performance characteristics and the penalties combine to form the basis for a “service level agreement” or SLA. The SLA will define the key performance indicators (KPIs) that need to be monitored and the thresholds that are considered “acceptable” performance.

This SLA is one area where most cloud service providers tend to make it difficult for the consumers. In most cases, the SLA template is highly tilted in favor of the provider. If you look at the KPIs, they’re often vaguely defined with thresholds that are easy to meet. Then, when you look at the penalties that are imposed for failing to meet the SLA, you’ll frequently find that it’s something along the lines of “hey, we screwed up, so we’re going to let you use our service for free during the next billing period” – that’s some penalty!

I’m not trying to scare you away from using cloud computing, just want to make you aware of one of the areas that can represent a bump in an otherwise smooth road. The other thing that I want to mention should be fairly obvious: the cloud service provider is on the other side of a network connection. If that connection goes down, you can’t access your cloud-based resources.

OK, that wraps this quick intro to cloud computing. We’ve talked about three of the five “essential characteristics” as enumerated in The NIST Definition of Cloud Computing, the other two are pretty obvious. In summary, cloud computing has the following characteristics:

1. On-demand self-service
2. Broad network access
3. Resource pooling
4. Rapid elasticity
5. Measured service

Cloud computing is all about changing the way in which we consume computing services. It represents a dramatic shift away from the purchase of onsite hardware that you have to maintain and depreciate towards a much more operationally focused model that basically amounts to leasing computing capability on an as-needed basis. It provides you with the ability to dynamically add and remove capacity as needed, and to pay only for what is actually used.

The next post in the series, Cloud 101: The Three Service Models, address the three cloud service models:

1. Infrastructure as a Service (IaaS)
2. Platform as a Service (PaaS)
3. Software as a Service (SaaS)

I will have that post up in the next couple days, so stay tuned!

Thanks,
KLC

<soapbox>
I’m going to let you all in on one of my pet peeves … it seems that too many people who write about technology don’t know the difference between the words “number” and “amount”. A couple of examples:

• What is the amount of NICs in that server?
• The amount of TB of storage is surprising.
• The amount of ways the problem can be solved…
• The number of RAMs in servers today is amazing.

I could go on and on…but you get the idea. Let me make it as simple as I can:

Number

Used for items that are enumerable – i.e. you can count them as 1, 2, 3. In the examples above, you can count NICs, TB, and “ways”, but you can’t count “RAMs”.

Amount

Used for things that do not have a definite quantity. Let’s use RAM as an example. [Q:] How much RAM is in your server? [A:] I have 64GB of RAM in my server.

Notice that you provide a specific number of GB, but “RAM” is not a quantity.

So please, let’s start using the right word in the right place! When you get ready to write a word that indicates a certain quantity of something – consider whether you can COUNT the thing(s) you’re quantifying. And just in case you’re wondering, it doesn’t matter that you can count DIMMs, you can’t count RAM!

</soapbox>

A naming standard is exactly what the title sounds like – a standard for defining the names of things. In my opinion, a naming standard should achieve a couple things:

• Provide a simple, consistent method for assigning names to objects – there is nothing “arbitrary” about a naming standard
• Be flexible enough to accommodate most, if not all, use cases
• Provide an effective means for all parties involved to understand what is being described

While these may seem really obvious and simple to achieve, there can be alligators hiding just beneath the surface!

The first two are, indeed, fairly simple. It’s that third bullet that can cause heartburn. Why? Because there are so many parties involved! First, you have the ESX administrators. They need to be able to accurately connect a virtual machine to the proper port group. Failure to do so could result in a VM that is unable to communicate, or worse, a VM that can communicate on the wrong network! Next, you have the OS administrators who are responsible for administering the guest operating system within the VM. They have to be able to effectively communicate to the ESX admin which network to connect the VM to. This person has absolutely no idea what a “port group” is and they’re not interested in learning…it’s just outside the scope of their responsibility. And if you think the OS admin doesn’t know what a port group is, imagine what the application admin knows!

So, up to this point, we’ve got three different points of view. We’ve got an application administrator who knows that his application needs to be on the SAP network; an OS admin who wants his VM connected to the production network; and an ESX admin who doesn’t care what the functionality is – he just wants to know what port group to connect the vNIC to. Oh yeah, there is one other group who has an interest in this whole thing – the network admins. These folks don’t know about applications, don’t care about operating systems, and stare at you blankly when you mention port groups – all they understand is that a host system needs to be connected to a particular VLAN number!

As you can see, the real challenge of defining a naming standard is developing a common vernacular so that everyone understands what everyone else means when they identify their network. I’ve seen all sorts of standards put into use. Some are better than others, and some are simply miserable!

Virtual switches are actually very simple to name…accept the default value of “vSwitch#” where # is the incremental count of vSwitches that have been created. The first vSwitch to be created will be “vSwitch1”, the second will be “vSwitch2”; I think you get the idea, so I’m not going to spend any more time on vSwitch naming.

Port Groups are another matter all together! By default, when you install ESX, there will be a single vSwitch created (vSwitch1) and it will have two port groups created on it. These port groups will be named “Service Console” and “Virtual Machines” to reflect their intended usage. This is a valid naming convention (i.e. name the port group based on the services that will be connected to it), but it does have some limitations. Think back to our discussion above. The ESX admin will feel right at home, but does “Virtual Machines” mean anything to the application administrator? The OS administrator? Or the network administrator? Probably not.

This is a prime example of a name that doesn’t fulfill our stated objectives. So, what is a good naming standard? Well, let’s consider everyone we have to satisfy:

• Application Admin: We need to be able to let the application administrator communicate the function of the port group
• Server OS Admin: Needs to be able to communicate the environment into which the VM needs to be placed
• ESX Admin: Will be creating the port group and assigning the name. Is also responsible for actually connecting a vNIC to a port group. Needs to be able to understand what his customers are asking him to do
• Network Admin: Needs to be able to communicate and understand where the vNIC needs to reside within the overall network infrastructure

So, a possible option for a naming standard could be something like this:

                SAP Prod VLAN123

This is actually pretty good. We know that the port group is used to support the SAP application in the production environment and that it lives on VLAN 123. There are a couple of issues with this standard, though. The biggest “problem” from my point of view is the use of spaces. Spaces do not cause a problem in a virtual environment; however, they can present an interesting challenge when it comes to automation. Spaces are viewed as delimiters in most scripting languages, so if your script developer (or the script developer of the third-party product or the guy on the Internet who developed a cool script) isn’t careful, you can have some “unexpected behaviors” at some point in the future.

It’s actually a simple matter to protect against this type of scripting error: don’t use spaces in your naming standard! So, you could name your port group something like this:

                SAP_Prod_VLAN123
                SAP_Dev_VLAN224
                Mail_DMZ_VLAN400
                VIAdmin_Admin_VLAN10
                WinAdmin_Admin_VLAN11
                Backup_Backup_VLAN543

Now we have a standard name that is easily understood by all parties involved and protects against poor scripting habits. While this is certainly not the “end-all and be-all” naming standard, it does meet our stated goals. You should look at your environment and develop a standard that meets the requirements identified above plus whatever other requirements you may have. If you can do that – and stick to it – you will have a virtual networking stack that meets your needs and is simple to administer. That’s my definition of goodness.

I’d like to thank you for taking the time to read through this series of articles. It’s been an interesting challenge for me to commit all of this to “paper” and I hope you’ve found it useful. Look forward to more stuff from me in the future!

The HyTrust Appliance Community Edition is a full-featured virtual appliance that allows you to manage up to three ESX hosts. This is a great way for smaller organizations to gain the benefits of centralized authentication, consistent security configuration, and greatly enhanced auditability. It also gives organizations of all sizes the chance to “kick the tires” on the product to see if it fits their needs. All of this in a totally FREE product (well, you do have to register…).

Quoting from the Press Release:

Pricing & Availability

HyTrust Appliance, Community Edition is now available for download now as a pre-built, VMware-compatible virtual appliance to members of HyTrust Community. To join the community free of charge, go to http://www.hytrust.com/community/register. Support for Community Edition is provided by the Community via online forum participation and direct community member interaction.

This is a great opportunity – join the HyTrust Community and download the HyTrust Appliance Community Edition today. It will simplify your life, no matter how small (or large) your environment!

KLC