DoubleCloud » Cloud Computing

Tipping points: the Social Aspect of Cloud Computing

Steve Jin — Wed, 25 Aug 2010 05:01:24 +0000

Many people already know the book “The Tipping Point: How Little Things Can Make a Big Difference.” According to the author Malcolm Gladwell, tipping points are “the levels at which the momentum for change becomes unstoppable.” He defines the term as sociological and uses it to explain sociological epidemics.

Three Rules of Epidemics

In his book, Gladwell laid out the “three rules of epidemics” as follows:

1) The Law of the Few.
“The success of any kind of social epidemic is heavily dependent on the involvement of people with a particular and rare set of social gifts.” The author categorized people into Connectors who link us up with the world; Mavens who are “people we rely upon to connect us with new information;” and Salesmen who are charismatic persuaders.

2) The Stickiness Factor
The specific content of a message that renders its impact memorable.

3) The Power of Context
Human behavior is sensitive to and strongly influenced by its environment.

Although the research comes from sociology, I think it applies to technology as well. After all, technology is social. Just think about social networks like Facebook, and the recent success of Apple’s iPad.

If you want your technology to be a huge success, you cannot ignore its social side story. In the end, it is human beings who make decisions regarding any technology adoption or product purchase.

Two Tipping Points

Cloud computing has become a buzzword. It has also climbed the CIO’s priority list from near the bottom to second place in a recent survey. While we’ve made huge progress in terms of marketing, we haven’t yet seen the tipping point of cloud computing in reality.

Unlike the Hush Puppies shoes discussed in the book, technologies like cloud computing are far more expensive to adopt and and they require much more expertise than buying a pair of shoes.

This uniqueness of cloud computing results in an interesting phenomenon – two tipping points. The first tipping point is with marketing. As an industry, we are pretty good at creating buzz around new technologies. No other industry is as eager as high tech to embrace the “next big thing.”

The second tipping point is with adoption in production. It may or may not come after the first tipping point. After the first tipping point, people may give cloud computing a try with pilot projects. At this tipping point, it becomes absolutely critical that the technology brings real vale to businesses or adoption dies.

There are examples in technology where the second tipping point arrived and then reversed due to the absence of sufficient value to businesses. One of the best examples in my opinion was the EJB (Enterprise Java Bean). It was widely adopted but then faded away. It failed to deliver sufficient value.

Tipping points for Cloud Computing

With so many people talking about cloud computing, we obviously have achieved the first tipping point from marketing perspective. We haven’t yet seen massive adoption through a second tipping point however.

Where will businesses find sufficient value in cloud computing? Cost saving is definitely one, but for sure not the only one. As hardware cost keeps dropping, capital spending on servers may be less a concern for most businesses in the future. They would look for flexibility, control, and growth from cloud computing. These kinds of value will be driven by people if we look at the three rules of social epidemics from a technology perspective. At the second tipping point for cloud computing, breakthrough adoption is now up to the connectors, mavens, and sales people.

With many companies and organizations in the cloud movement, we will for sure have many connectors, mavens, and salespersons who may have different understandings of cloud computing, and different agendas due to company interests. We need to collaborate effectively with each other for the bigger goal: showing real world values to the customers. Only then we will see the second tipping point that we all look forward to.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

InterCloud vs. Internet: What’s Missing in Cloud Computing?

Steve Jin — Wed, 18 Aug 2010 05:01:19 +0000

As more and more clouds go live, it’s time to think about how they will need to interconnect and interact. InterCloud is a new terminology coined for cloud computing after Internet for networking.

Vint Cerf, the “father” of the Internet, said recently that the cloud is much like networking in 1973 when computer networks couldn’t connect or interact. He called for open standards for cloud computing so that InterCloud can become a reality.

It’s hard to design standards when people are still trying to reach a consensus on defining what a cloud is in the first place! The good news is that as an industry we went through a similar process for the Internet. So we can learn from that experience.

The idea is simple: look at basic building blocks we have for the Internet and think about their equivalent for the InterCloud. Believe it or not, InterCloud and Internet share many common characteristics. The following table summarizes some of these.

	Networking	Cloud Computing
Content	Data	Computing workload
Cornerstone	Ethernet	Virtualization
Format	ASN.1	OVF + ?
End point	Host	Hypervisor
Protocols	OSI, TCP/IP, etc.	?
Directory service	DNS	?
ID	IP address/host name	?
Resource locator	URI/URL	?
Interconnectivity	Internet	InterCloud
Killer use cases	Email, Web	System provisioning, Dynamic scaling

Let me emphasize the key difference between the Internet and the Intercloud —the Internet moves data and the InterCloud moves computing workloads. With virtualization and other high level virtual machine technology, computing workload is essentially data. Viewed in this fashion, that would mean the InterCloud can leverage the Internet as a high level application.

As you see from the table above, there remain many question marks where we do not yet have InterCloud equivalents to the Internet. That is something we need to think about and work on moving forward.

Let me know what you think. Do you have suggestions for equivalents?

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

Vertically Complete Systems: Next Big Trend?

Steve Jin — Mon, 09 Aug 2010 05:01:01 +0000

IBM recently announced its re-organization around its software and hardware business units. The previously separate business units were merged together as one – the Systems and Software Group led by the former software chief Steve Mills.

You may recall that IBM did not have a dedicated software group until Lou Gerstner created one 15 years ago to centralize all the software businesses into one business unit. This unit has been IBM’s most profitable business. Before that, IBM offered all the software as add-ons to the systems like 390 and AS/400.

Now can we expect IBM to offer hardware systems as add-ons to their software solutions?

Although companies constantly re-organize to streamline their business execution, this reorganization did indicate a big trend is happening in the IT industry. Computer vendors are striving to own vertically-complete stacks: from hardware all the way up to business applications.

IBM is not alone in this trend. Oracle acquired Sun Microsystems for its SPARC servers, Solaris OS, Java, MySQL database, and even tape storage. Together with its database and business applications acquired from PeopleSoft, Seibel, and many other acquisitions, Oracle is now yet another “IBM” that controls vertically complete stacks. We can expect more IBM-like business model clones emerging in the coming years.

Is this trend good for customers?

Openness vs. User Experience

Openness means choice and flexibility and often lower initial cost. But it can also mean sleepless nights to put different IT components together. When there is an issue with your application/solution, whom do you call? Your hardware vendor, OS vendor, middleware vendors, application vendors, or systems integrator? It’s hard to pinpoint anyone on the list. This is a pain for the customers. Customers like having one throat to choke.

Looking back 30 years ago, we can mostly blame IBM because it sold customers most of their computer and software systems. IBM owned all the responsibility to fix any problem. At least until customers had a different pain: you don’t have choice therefore you have no power in negotiation with Big Blue.

Then customers began to move onto the client-server model of computing and open systems with open software. This strategy started to prosper in the 1990s. Openness has been the winning market strategy ever since.

With the openness problem solved, the solution that gave customers more negotiating leverage also shifted the pain back to them. Today we have so many systems, open or not, that the amount of effort to make them work together is a really big pain. This hurts user experiences.

In the end, users just need the applications to support the business. Again, the application is the end, and everything below is the means. Whatever can do the job better and more economically wins. This is the fundamental truth behind this trend for vertically complete systems.

Software Openness vs. Data Openness

With everyone in the game being vertically complete, how can vendors differentiate again? And for the customers, how should they choose vendors? For customers, the stakes in choosing the right vendor are even higher than before because they are standardizing their system with one vendor at a time. Switching costs are the biggest pain and expense.

Still customers would love to have the flexibility and choice to switch systems. How do they do this?

I think the key is the data. No matter how different systems are, they have to persist data and be able to restart from the point where they shut down. If two systems from two different vendors understand the same set of data, customers still switch easily from one system to the other.

With complicated systems, there may be many data persisted, including the output of data processing, customization settings, user preferences, and more. It takes time and effort to convert them all over from one system to another. Some of the data may never be carried over. For example, if one vendor’s algorithm is not replaced by the other, then the tuning parameters are lost.

Virtualized Vertically Complete Systems

With virtualization, the vertically complete systems can, and should, be re-defined. For one thing, hardware virtualization provides an abstraction for the hardware so that your vertically complete systems can be packed as a bunch of files. These are what I call virtualized vertically complete system.

The benefits are profound: you can move your vertically complete systems to wherever best for whatever reasons such as reliability, performance, saving, and etc. They are extremely important in cloud age where you cannot move around your physical servers but for sure your virtualized servers.

The data openness theme doesn’t change in the cloud environment. The bar may be even higher because you may want to change the system more frequently in the cloud than inside an enterprise.

Conclusion

The industry is experiencing a shift from openness to a vertically complete hardware/software appliance approach. Big vendors are re-aligning their operations for this trend.

For customers, it is mixed news. They may get a better user experience but pay the price in vendor lock-in. To best protect IT investments, customers should demand data openness to protect their ability to switch systems down the road. Data openness is the only solution to this problem.

In this cloud age, the virtualized vertically complete system inherits the benefits of vertically complete systems with additional flexibilities and portability that are crucial for cloud computing. It’s IT’s the next big trend.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

Cloud Architecture Design: Should it be Top-Down or Bottom-Up?

Steve Jin — Mon, 26 Jul 2010 05:01:29 +0000

In my last blog, I discussed how to optimize workloads across the cloud. This is based on the assumption that you already have an existing infrastructure. What if you don’t have an existing cloud infrastructure but would like to design one from scratch? Here is what you should be thinking about to get the most from your new cloud.

But first let’s take a look at other types of infrastructures – say a road. When you design a new road, you have to collect data such as population densities around the area, people’s working schedules, what types of vehicles will run on the road, and so on. With that information, you can decide how many lanes you want, what kind of road surface is required, and so on. You don’t just make up the design specification from scratch, and lay down an eight-lane freeway everywhere.

The same process applies in designing the cloud infrastructure as well. Unfortunately this is not what we see often today.

Top-down approach

In my previous blog , I said infrastructure is a means and application is the end. We need to drive the design cloud architecture from the application perspective. This is what I call the top-down approach.

The benefit of top-down approach is the system efficiency you gain – you create just enough infrastructure for your applications to run without any waste. This gives you the best ROI from a business perspective.

The top-down approach works perfectly for enterprise private cloud. For service providers, however, it may or may not work. If the service provider provides specialized services such as online storage where the application workload pattern is known, then you should definitely follow the top-down approach.

Bottom-up approach

For service providers who provide generic services, it’s hard, if impossible, to know customer workload patterns in advance. In these cases, you are best served by following a bottom-up approach. That means designing the cloud infrastructure based on typical applications.

When new applications come in, just mix them based on their workload patterns described in this blog. In so doing, you may still achieve good workload balancing and the best business ROI.

How to top-down?

When using top-down approach, you want to analyze the workload patterns and quantify them with numbers in CPU, memory, networking, storage and so on. If you cannot easily infer the numbers, just pick a similar system and measure it before adjusting your designed based on the scale ratio.

With the workload numbers, you can translate them into infrastructure level requirements. To play safe, you want to have some allowance for unusual cases. On the networking side, it’s not purely about bandwidth, it’s also about good topology design that can flow network traffic better.

Now, don’t forget another very important dimension of workload pattern – timing. If the same workloads and their peaks are evenly distributed over time, you should be fine. To best design a private cloud, you have to consider the element carefully. In fact, in many enterprises there are some pretty clear patterns with workload over the time. For example, the accounting system will peak at the close of each fiscal quarter.

Summary

Although cloud infrastructure design is mainly about computing infrastructure, we should drive the design from the applications that run on the infrastructure. This is what I call the top-down approach.

When the application workload patterns are unknown, you can go with bottom-up approach. Even so, you still want to balance the workload at runtime by mixing complementary applications together on the same physical resources.

For the private cloud and specialized public cloud, the top-down approach is preferred. For generic service providers, bottom-up is usually best.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

Workload Optimization: Is It a Must-have for Cloud Computing?

Steve Jin — Thu, 22 Jul 2010 04:59:04 +0000

Cloud computing hasn’t changed the nature of computing – it just changed provisioning and management. That’s important to remember because workloads in the cloud are very much similar to what we see in traditional computing infrastructures. To get the most out of your investment in cloud services or in your own physical IT infrastructure, you need to understand how to optimize workloads.

Workload Categorization

Typical computing workloads involve four basic parts: computation, memory, networking, and storage. Almost all applications have these four parts but mostly not balanced.

Now let’s quickly review the essential categories of application workloads:

CPU intensive workloads. These applications include scientific computation with significant data crunching, encryption and decryption, compression and decompression, and so forth;
Memory intensive workload. These applications include in-memory caching servers, in-memory database servers, and so forth;
Networking intensive workload. These applications are typically Web servers, as well as network load balancers, and so forth;
Storage intensive workload. These applications typically involve file serving, data mining applications, and so forth.

What is the problem?

Although cloud computing is supposed to provide unlimited capacity, the real work of specific workloads have to be run on a single server or a cluster of machines which are mostly virtualized.

With the unbalanced nature of individual workloads in mind, the last thing you want to do is to have the same category of workloads running on the same set of physical servers that have limited resources. For example, you don’t want to run all of your file server virtual machines on one physical server competing for storage IO, and leave their CPU cycles largely idle. This creates resource competition on one hand, and resource waste on the other hand.

Another important aspect is timing. If you have the same workload patterns but evenly distributed over time, it’s still balanced.

So, what is the solution?

If you already have an infrastructure in place, you can just mix the different types of workload together. In this way, you can have a balanced utilization of the physical resources on CPU, memory, networking and storage. More importantly, you can overcome the limits by hosting more workloads on the same investment in servers and system software.

This is not a big deal for cloud users because they still use the same resources under typical cloud service level agreements (SLAs). For the service providers, it is a big deal because of the higher ratio of applications to physical investments that impact the margins of the business. This means balanced utilization of workloads can give them a competitive edge over other service providers.

This is much easier said than done. Implementation is everything. You have to collect enough information on the workload patterns of all the applications and then calculate the best distribution of these applications. Based on what you find, you can re-allocate existing applications using live migration technologies such as vMotion, storage vMotion, and so on.

The algorithm described above is a simple one, and does not take into account other elements such as workload distribution over time, isolation of multi-tenants, security and compliance, the criticality of applications, or system backup. To get this workload optimization to work well in real life, you have to think through all of these other factors as well.

With the workload optimization system in place, you can then consult it for every new provision. And, when the workloads are no longer balanced, you can recalculate and re-distribute the workloads for the best utilization. Ta da!

What’s Next?

Now, what if you haven’t set up your infrastructure yet? No problem, in fact you will have more flexibility. I’ll show you how to do this successfully in my next blog.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

When to Use Cloud? Example Use Cases

Steve Jin — Fri, 09 Jul 2010 05:01:51 +0000

In my last post, I discussed when not to use cloud services. Basically you should avoid the cloud for your organization’s core competency IT systems. Remember, cloud computing is not a silver bullet for everything.

Today I want to share the stories from the other side: when you should use cloud services. As a rule of thumb, you use cloud services for your non-core competency IT systems. But, what are the typical non-core competency systems?

There could be many cases in which you can use cloud services. Let me go through some of them by sharing customer experiences:

Outsourcing projects. If something is outsourced, most likely you don’t think it’s a core competency to your business. You can then leverage the full benefit that public cloud services bring to you. You can easily have workspace that is accessible by both your employees and contractors, and it’s more secure than opening up your own infrastructure to your contractors.

Pilot projects. You want to try something new and don’t want to be limited by capital budget not available for infrastructure experiments. From the moment you start a pilot project, you don’t know whether it will work or not. So it’s natural to “rent” the required infrastructures from service providers. This is especially true for pilot projects that require buying lots of machines that you can’t repurpose if the pilot project falls through.

Temporary projects. These are the projects that run for a short period of time, and it doesn’t make sense to buy the infrastructure. It’s like renting furniture instead of buying them for staging your house when you want to sell it. When your house is sold, you can ask the staging company to remove the furniture. You pay based on the furniture and the total time of renting, exactly the same idea as cloud services.

Demo and training scenarios. You may have a pre-sales event in which you want a full demo for a week. Ditto for a training class. These are perfect use cases for leveraging cloud computing.

Extension for dramatic workloads. Notice that I said dramatic, not dynamic workloads. Not every application has a steady workload pattern over time. Some applications could experience 100 times more workloads during peak time than otherwise. For example, a website which may need 1,000 servers for uploading photos during the weekend of the Super Bowls might only require a handful the rest of the time. Would you invest in buying 1,000 servers that are used one weekends in a year? I doubt it. That is a perfect use case for cloud services.

You may have other scenarios that are candidates for best use cloud services. Please feel free to share them in your comments below.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

When NOT to Use Cloud?

Steve Jin — Wed, 07 Jul 2010 07:51:30 +0000

During the July 4^th long weekend, I got the chance to read the book “Delivering Happiness” by Tony Hsieh. It’s a great book with many great ideas and lessons he learned from LinkExchange and Zappos.

So, how does this relate to cloud computing?

Here’s what Tony wrote…

“It was a valuable lesson. We learned that we should never outsource our core competency. As an e-commerce company, we should have considered warehousing to be our core competency from the beginning. Outsourcing that to a third party and trusting that they would care about our customers as much as we would was one of our biggest mistakes. If we hadn’t reacted quickly, it would have eventually destroyed Zappos.”

In this paragraph Tony summarized the lesson from contracting eLogistics for inventory services in Kentucky, which turned out to be a mess and almost killed Zappos when cash flow became a big issue.

From a business perspective, cloud services are not much different from the inventory services. Both are all about outsourcing. The high tech nature of cloud doesn’t change the business nature of cloud services. What happened to Zappos could potentially happen to any cloud customers.

The question your business needs to ask, and answer, becomes “Is IT your core competency?” Or, more specifically, “What part of IT is – and is not – your core competency?”

At face value, they seem like easy questions. When you dig down to the details of your business, however, you may find surprising or even counter-intuitive answers.

Let me give you an example.

Most of us know Paypal, now part of eBay.com, as an online payment service company. You may think the core competency is the web site itself. It’s true. But the most important technical competency is not the web site itself. According to the founder Max Levchin, it’s the ability to judge risk, or protect against fraud. That is why they built a software package called IGOR, which brought down the fraud down to one-tenth of a percent. Without this core competency, they would have been quickly out of business just like their competitors such as MoneyMail that had 25 percent fraud and burned through cash too quickly. (full story at “Founders at work.”)

To decide whether an IT system is your core competency, consider these questions:

Is your system a secret weapon in your market competition with others? By saying a secret weapon, I mean does IT give your business competitive advantages in increasing sales, lowering costs, or creating good-will in the community?
Will you lose big money when the system is offline? You should look both internally for the impacts on daily operations and planning, and externally for impacts on sales and customer satisfaction. There are things that may be impactful in subtle ways.
Are you OK with the system being breached? That includes illegal access, data corruption, and data stolen by malicious hackers. This may involve cash losses and direct legal consequences in the short term, as well as loss of customer trust in the long term.
Will you have enough control of your systems to fulfill different business unit needs? IT systems have to support the growth of the business. Do you need to have control of the systems in terms of software configurations, maintenance, support, SLAs, and so forth? The last thing you want is to have your system become a hurdle of your growth.

Once you decide whether a piece of your IT is a core competency or not, you can plan accordingly. In future blogs, I will talk about when you should consider use cloud services.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

System Provisioning in Cloud Computing: From Theory to Tooling (part 2)

Steve Jin — Thu, 01 Jul 2010 05:01:13 +0000

Application Provisioning

With the right system configuration in place, it’s time to install the applications. So why not use the same tools we used for the OS and middleware? Do we need yet another set of tools?”

It depends. You can use the same set of tools for middleware to install some applications. The middleware appears like an application to the OS as well. The difference is whether your application is stable enough and whether you need to customize per node. The tools like Puppet can be good for stable applications that can be deployed the same way across all nodes. If your application is still a work in progress and you need flexibility to tweak it, you need more specialized application provisioning tools.

The big technical difference between application and middleware provisioning tools is that application tools push the application to the nodes and remotely change anything as needed. The process is procedural.

The middleware provisioning tools normally have agents on the nodes to pull the software based on the prescribed configuration files. The process is declarative.

Beyond the “push” and “pull” difference, the application provisioning tools can also manage the lifecycles of applications (sometimes called services) distributed on different nodes with a single line of command or code. Given the nature of remote command dispatching framework, the application provisioning tool can do almost anything. If there has to be a limitation, it’s your imagination.

So if you develop applications by yourself, you most likely need application provisioning tools.

Let’s see what tools are there.

Capistrano

Capistrano is an open source tool for running scripts on multiple servers; its main use is deploying web applications. It automates the process of making a new version of an application available on one or more web servers, including supporting tasks such as changing databases.

Capistrano is written in the Ruby language and is distributed using the RubyGems distribution channel. It is an outgrowth of the Ruby on Rails web application framework, but has also been used to deploy web applications written using other frameworks, including ones written in PHP.

Capistrano is implemented primarily for use on the bash command line. Users of the Ruby on Rails framework may choose from many Capistrano recipes; e.g. to deploy current changes to the web application or roll back to the previous deployment state.(http://en.wikipedia.org/wiki/Capistrano)

ControlTier

ControlTier is a community driven, cross-platform software system used to coordinate application service management activities across multiple nodes and application tiers…

The Command Dispatcher is a core function of the ControlTier software that provides the mechanism to send commands over the network seamlessly to the correct Nodes. This facility is used whenever you run a command or script, via the command-line (ctl or ctl-exec) or via Jobcenter.

Fabric

Fabric is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.

It provides a basic suite of operations for executing local or remote shell commands (normally or via sudo) and uploading/downloading files, as well as auxiliary functionality such as prompting the running user for input, or aborting execution.

Typical use involves creating a Python module containing one or more functions, then executing them via the fab command-line tool.

Func

Func allows for running commands on remote systems in a secure way, like SSH, but offers several improvements.

Func allows you to manage an arbitrary group of machines all at once.

Func automatically distributes certificates to all “slave” machines. There’s almost nothing to configure.

Func comes with a command line for sending remote commands and gathering data.

There are lots of modules already provided for common tasks.

Anyone can write their own modules using the simple Python module API.

Everything that can be done with the command line can be done with the Python client API. The hack potential is unlimited.

You’ll never have to use “expect” or other ugly hacks to automate your workflow.

It’s really simple under the covers. Func works over XMLRPC and SSL.

Since func uses certmaster, any program can use func certificates, latch on to them, and take advantage of secure master-to-slave communication.

There are no databases or crazy stuff to install and configure. Again, certificate distribution is automatic too.

What’s Different in Cloud Computing?

If you look at the varieties of software at different levels of the stack, you will find the lower the stack the fewer number of choices. When you move up to middleware, you will have more choices. At the application layer, the growth of possibilities gets exponential.

If we draw a diagram here, it’s then like an inverted pyramid shown in following diagram.

Installing an OS or Cloning from template?

With the use of virtualization in cloud computing, the demand for the OS provisioning tools will be much less than before. For one thing, OS plays a less important role for applications. Most of the time it doesn’t matter what OS is there as long as there is one. It therefore makes it possible to consolidate the OSes to several standardized flavors.

On the other side, virtual machines are really just a bunch of files. You can save the standardized OSes as templates or machine images in Amazon terms. When you provision a new machine, you include the OS as well. There is not much need to install it by yourself.

Still, service providers may see many different types of standard OSes even though each user just uses a handful. The service providers therefore still need to use OS provisioning tools to accommodate all the different requirements of their customers.

What about the extra storage space? Good question. Overall the portion of OS images is relatively small and manageable for the service providers who can cross leverage them for different users. Also modern storage de-duplication software has significantly reduced actual storage use, especially when the OSes are mostly the same (for example, Linux OSes of different flavors and different versions).

When it comes to the format of virtual machine template, you want to follow the OVF spec which is a DMTF standard supported by major players.

How About Middleware?

When it comes to middleware, things can get tricky. There are definitely more combinations than with operating systems. It may or may not be a good idea to pre-install the middleware inside a machine template.

The deciding factor is really how much you use the particular middleware. More often than not, you have a pre-defined set of middleware for a particular purpose – for example, building Java-based enterprise Web applications. You can install all the middleware components in a virtual machine image. It’s not only easier to deploy, it can also test as the gold image to standardize within an organization. It also saves time to maintain, patch, and upgrade the related middleware to save costs and improve system security.

There are certain cases in which you have a very specific combination of middleware. Given the rarity of usage, you may either use configuration tools or install it manually. You decide by whichever is more convenient. When you do something just once, you probably won’t bother with learning tools like Puppet. But if you are already familiar with one of the tools, why not use it?

Applications?

Applications have the most varieties in terms of numbers and functionalities. In reality, you may not want to create a virtual machine image for each application most of the time. That’s especially true when you are in the process of developing applications – you don’t have a stable application to build a virtual machine image yet.

Can you wait for the stable release of the application? In theory, it’s possible. But in reality, it’s mostly not an option. You have to deploy it and test it in the staging environment continuously upon daily build or even every check-in.

To facilitate this continuous integration and deployment, you would like to use some automation framework as I mentioned earlier. Besides the application provisioning, you can also automate the testing with the same framework.

Life could really be this easy? Yes. That is the benefit of using a framework. However, no pain no gain. The pain is to set up the framework and write/test the commands. Once you set up the process, you cannot easily change the procedure of installation. This is not an option for most developments especially in initial stages, therefore you have to maintain that as well.

As I mentioned in my previous blog on cloud application architecture, you want to design your applications to be as stateless as possible so that you can standardize the application for massive deployment. If that is the case, you can build a virtual machine with your application installed on the fly. If you choose this approach, you should incorporate the building of a virtual machine as part of your release process, and deploy that virtual machine instead of pushing applications to virtual machines. Many tools like VMware Studio can assist you to do that.

Summary

System provisioning in cloud computing is an important aspect of system architecture, application design and operation. As virtualization gets more and more popular as the enabling technology for cloud computing, we will see more use of virtual machine images/templates for system provisioning, including operating systems and middleware. The standardized templates provide not only operational efficiency but also high quality, pre-qualified software stacks for building cloud applications.

Application provisioning frameworks will still play an important role in system provisioning and other activities such as lifecycle management, automated testing, and more. It’s not only a tool for system operation, but also an essential tool for continuous system integration.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

System Provisioning in Cloud Computing: From Theory to Tooling (part 1)

Steve Jin — Wed, 30 Jun 2010 06:40:58 +0000

Cloud computing is an evolutionary technology because it doesn’t change the computing stack at all. It simply distributes the stacks between the service providers and the users. In some sense, it is not as impactful as virtualization technology which introduced a new hypervisor layer in the computing stack and fundamentally changed people’s perception about computing with virtual machines.

But if you look closely at the latest IaaS clouds, they do leverage virtualization as a way to effectively and efficiently deploy systems. Inside one virtual machine, the computing stacks remain the same as before: from OS to middleware to application.

Keep in mind that the application is the end while the OS and middleware are the means. Customers care about applications more than the underlying infrastructure. As long as the infrastructure can support the applications, whatever the infrastructure might be is fine technically. Then the question would shift to the economic side: whatever is the most cost effective wins in infrastructure. That’s why Linux gains more shares in the cloud than in traditional IT shops.

To get to the end, you have to take a mean. In the IaaS cloud, you have to install the underlying OS and middleware before you can run your application. For the PaaS cloud, you can get away from that by focusing on application provisioning.

OS Provisioning

Remember, the software stack inside a virtual machine doesn’t change. It needs OS, middleware and application installed and configured before the application can work.

Because the software stack has one layer stacked on another, the installation has to come in the order of bottom layer being installed earlier than the layers above. You have to install the OS first, then middleware, and lastly the applications.

Although it happens in a cloud, it’s not a new problem. There are already some tools available for you to solve the problem in traditional computing environments:

Kickstart

This tool allows you to automate most of the Red Hat Linux installation including language selection, network configuration, keyboard selection, boot loader installation, disk partitioning, mouse selection, X Window System configuration, etc. A system administrator needs to create a single file containing the answers to all the questions that would normally be asked during a typical Red Hat installation.

Jumpstart.
It’s used to automate the installation of Solaris OS.
Cobbler.

Cobbler is a Linux installation server that allows for rapid setup of network installation environments. It glues together and automates many associated Linux tasks so you do not have to hop between lots of various commands and applications when rolling out new systems, and, in some cases, changing existing ones.
With a simple series of commands, network installs can be configured for PXE, reinstallations, media-based net-installs, and virtualized installs (supporting Xen, qemu, KVM, and some variants of VMware). Cobbler uses a helper program called ‘koan’ (which interacts with Cobbler) for reinstallation and virtualization support

OpenQRM

openQRM is a very comprehensive and flexible Open Source Infrastracture Management Solution. Its fully pluggable architecture focuses on automatic, rapid- and appliance-based deployment, monitoring, high-availability, cloud computing and especially on supporting and conforming multiple virtualization technologies.
openQRM is a single-management console for the complete IT-Infrastructure and provides a well defined API which can be used to integrate third-party tools as additional plugins. This provides companies with a highly scalable system that supports small companies as well as global businesses who have large server base, multi-os & high-availability requirements.

xCAT

xCAT is DataCenter Control. It allows you to:

Provision Operating Systems on physical or virtual machines: Centos5.X, SLES[10-11], RHEL5.X, Fedora[9-11], AIX, Windows Server 2008, Cloning or scripted installation methods

Remotely Manage Sytems: Integrated Lights-out management, remote console, and distributed shell support

Quickly set up and control Management node services: DNS, HTTP, DHCP, TFTP

xCAT offers complete and ideal management for HPC clusters, RenderFarms, Grids, WebFarms, Online Gaming Infrastructure, Clouds, Datacenters, and whatever tomorrow’s buzzwords may be. It is agile, extendable, and based on years of system administration best practices and experience.

Middleware Provisioning

After getting the OS ready, you can go ahead with middleware installation.

The available tools allow you to describe the target configuration of the software and then they take care of the rest. It’s much like a policy-driven process.

Puppet

Puppet’s declarative language describes your system configuration, allowing you to easily reproduce any configuration on any number of additional systems. Additionally, Puppet can help establish and enforce approved system configurations automatically correcting systems that drift from their baseline. Puppet provides an audit trail of all your systems, which can easily be kept in version control for compliance purposes.

Organizations are increasingly taking advantage of Puppet’s support of a variety of operating systems. Whether you are supporting Linux (Red Hat, CentOS, Fedora, Debian, Ubuntu, SuSE), or Unix OS’es (Solaris, BSD, OS X), Puppet can fulfill your requirements. Although Puppet evolved primarily to support Unix-like OS’es, Windows support is planned in the near future.

Chef

Chef is a systems integration framework, built to bring the benefits of configuration management to your entire infrastructure. With Chef, you can:

Manage your servers by writing code, not by running commands. (via Cookbooks)

Integrate tightly with your applications, databases, LDAP directories, and more. (via Libraries)

Easily configure applications that require knowledge about your entire infrastructure (“What systems are running my application?” “What is the current master database server?”)

SmartFrog

SmartFrog is a powerful and flexible Java-based software framework for configuring, deploying and managing distributed software systems.

SmartFrog helps you to encapsulate and manage systems so they are easy to configure and reconfigure, and so that that they can be automatically installed, started and shut down. It provides orchestration capabilities so that subsystems can be started (and stopped) in the right order. It also helps you to detect and recover from failures.

CFEngine

Cfengine ensures that you have the proper packages installed, that configuration files are correct and consistent, that file protections are correct, and that processes are running (or not) in accordance with policy. Cfengine closes security holes, hardens your systems, and makes sure that critical daemons stay running. It monitors performance and reacts to what it monitors. You tell Cfengine what promises you want it to keep, and the agent does the work.

Cfengine runs natively on all common platforms, including Linux, Unix, Macintosh and Windows. It also has support for virtualization platforms. Cfengine is supported by a community of expert and novice users, and a commercial enterprise of qualified Mission Specialists. Cfengine can play a major role in solving almost any system administration issue, with hands-free automation (see our Solutions guide and standard library resources Policy Starter Kit, and we are constantly working to made automation simpler, without over-simplifying.

BFFG2

Bcfg2 helps system administrators produce a consistent, reproducible, and verifiable description of their environment, and offers visualization and reporting tools to aid in day-to-day administrative tasks. It is the fifth generation of configuration management tools developed in the Mathematics and Computer Science Division of Argonne National Laboratory.

It is based on an operational model in which the specification can be used to validate and optionally change the state of clients, but in a feature unique to bcfg2 the client’s response to the specification can also be used to assess the completeness of the specification. Using this feature, bcfg2 provides an objective measure of how good a job an administrator has done in specifying the configuration of client systems. Bcfg2 is therefore built to help administrators construct an accurate, comprehensive specification.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

What Cloud Standards Are There and Coming?

Steve Jin — Fri, 25 Jun 2010 05:01:04 +0000

Designing standards is like playing stocks. Timing is critical if not all. If too early, it may stifle innovation; if too late, it may never win over de facto standards.

With the popularity of cloud computing, many standard organizations have started to work on open standards from different layers and different aspects. How to find these standards or work in progress?

In his talk at SDForum Cloud SIG on June 22nd, DMTF president Winston Bumpus (@wjbumpus) shared a web site http://cloud-standards.org. It lists the cloud related standard organization and their works.

The organizations include:

Distributed Management Task Force (DMTF)
Cloud Security Alliance
CloudAudit
The European Telecommunications Standards Institute(ETSI)
National Institute of Standards and Technology (NIST)
Open Grid Forum (OGF)
Object Management Group (OMG)
Open Cloud Consortium (OCC)
Organization for the Advancement of Structured Information Standards (OASIS)
Storage Networking Industry Association (SNIA)
The Open Group
Association for Retail Technology Standards (ARTS)

According to Winston, these organizations have regular meetings and maintain their parts of the wiki pages. So you can rely on this page for what’s going on in the cloud standards.

Before you dig into any organization, I would suggest you to read the cloud standards overview. This presentation gives you a fairly good big picture.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.

DoubleCloud » Cloud Computing

Tipping points: the Social Aspect of Cloud Computing

Related Posts

InterCloud vs. Internet: What’s Missing in Cloud Computing?

Related Posts

Vertically Complete Systems: Next Big Trend?

Related Posts

Cloud Architecture Design: Should it be Top-Down or Bottom-Up?

Related Posts

Workload Optimization: Is It a Must-have for Cloud Computing?

Related Posts

When to Use Cloud? Example Use Cases

Related Posts

When NOT to Use Cloud?

Related Posts

System Provisioning in Cloud Computing: From Theory to Tooling (part 2)

Related Posts

System Provisioning in Cloud Computing: From Theory to Tooling (part 1)

Related Posts

What Cloud Standards Are There and Coming?

Related Posts