Comments (0)

The following tables list all the managed object types in VI 3.5, vSphere 4 and 4.1. A short description is provided for each type explaining its major responsibilities.

Note that the managed object types are added in an incremental way. The types in older versions are still supported in newer versions. The complete types in a verion include ones in the correpsonding table plus all the ones in all older version tables.

Hope this post gives you a high level overview of functionalities of the vSphere APIs. Check out other blogs such as best practices (1-5, 6-10) on how to use them in general. And don’t forget my book which introduces them extensively with many read to use samples.

Table 1 Managed Object Types in VI 3.5 Read more »

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 RSS or Email, and follow on Twitter.

Comments (0)

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. Read more »

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 RSS or Email, and follow on Twitter.

Comments (0)

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. Read more »

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 RSS or Email, and follow on Twitter.

Comments (4)

With the growth of virtualization, a new term “virtual appliance” has been coined for a special type of virtual machines that are used like applications. What does it really mean?

First, a virtual appliance is still a virtual machine. When seen in vSphere Client, the virtual appliance does not look much different from other typical virtual machines. Secondly, the functionality of the virtual machine is limited to that of an application. More often than not, the virtual machine is installed with one application. Because of this, the underlying OS is stripped down only to the minimum required to support that application. This type of OS is also called Just Enough OS (JEOS). All the existence of the JEOS is to support the application in the virtual appliance.

Now, is it a VM or an application? It could be either, depending how you look at it. For ESX/vCenter, a virtual appliance is a virtual machine. You can manage it just like any other virtual machine. For application users, it’s an application, a special one that is different from a normal application. Read more »

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 RSS or Email, and follow on Twitter.

Comments (2)

As I quoted VMware CMO Rick Jackson in my previous blog, cloud computing is a journey. You may wonder, “If so, what are the phases for that journey?”

A great question! Understanding the phases helps us to better plan our journey and have a smooth transition from phase to phase.

In this blog, I will introduce 3 phases one by one: 100% virtualization, private cloud, and federated cloud. I will go over each of them and discuss the challenges in each.

1. 100% Virtualization

The concept of cloud computing is not new. You may still recall on-demand computing, autonomous computing, utility computing model, etc. These terms have come and gone, therefore people naturally have reservation on the future of cloud computing this time.

Unlike its predecessors, cloud computing is now backed by a solid foundation, which is virtualization. Once your computing resources are virtualized, you can do many things that are impossible otherwise.

The milestone for this phase is quite clear: 100%. When talking about 100%, it’s a challenge itself. The percentage is too stringent, isn’t it?! Once you get majority resources virtualized, you are good to move to the next phase.

2. Private Cloud

In this phase, the focus is to drive ROI from previous phase by sharing the resources across an enterprise. A connected and unified virtual infrastructure is the starting point, from where value added services are needed.

These services include but not limited to:

• Administration Automation. Common administrative tasks are fully automated, driven by high level policies.
• Self Service with Workflow Capabilities. Employees can request computing resources via Web based workflow management system.
• Visibility and Reporting. It helps get insights on what’s going on in the cloud, for example how resources are used with concrete data. Also make chargeback available even if there won’t be a real dollar movement from business departments to IT.

While implementing the private cloud, an enterprise can also move up in the stack from IaaS to PaaS, and even SaaS. I have written a short article on “DIY PaaS” at vSphere Java API homepage and reposted at a SpringSource blog. The key benefit of PaaS is to have all the benefits of  “PaaS” but no vendor lock-in.

3. Federated Cloud

To avoid one time capital spending, enterprises would like to “borrow” into public cloud. Initial use cases will be test projects, pilot development/research projects, peak time workload balancing, etc. The common characteristics are non mission critical system with no or limited confidential data.

For big enterprises, it’s all possible to use multiple cloud service providers at the same time. This may be caused by geography, specialty, level of services in the stack, service differentiation, and etc. For example, project A may use SP X’s IaaS service; project B may use SP Y’s PaaS, and so on.

At this phase, the key challenges are:

• Security and Compliance. It’s not a new challenge – you need these even before your cloud journey. But when things are moved to outside, people naturally concern these more than before. With more experiences with the public cloud, they will be more comfortable with the external computing services.
• Federation Framework. The framework facilitates the resource unification and optimization, VM migration. Using the external services should be as easy as internal one, and as secure as internal one.
• Single Glass Pane for Management. With assets in and out the premise, IT needs unified views of every aspect. It may or may not have the resources managed as a single big pool initially, but that is the direction to go.

We’ve discussed the 3 phases in the journey of cloud computing for enterprises. There will be overlaps of different phases in reality, especially in big enterprises where IT infrastructures are distributed across different locations. That is totally OK. The important thing is to understand the progressive nature of cloud computing and plan the adoption accordingly.

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 RSS or Email, and follow on Twitter.