DoubleCloud.org

Chasing Moving Targets

Steve Jin — Wed, 08 Feb 2012 05:44:21 +0000

As John F. Kennedy put it, “everything changes but change itself.” This is particularly true in computer industry where things move faster than other industries. It’s further complicated when you also have dependencies that also move fast.

A good example is that your software project depends on another product which is also under development. Sometimes we call it synchronous development. The payoff could be huge if you can ship your product at the same time as the dependent product which presumably has bigger user base. You can then leverage the go-to market opportunity as first player in the bigger community.

The problem is also obvious. If the dependent product gets delayed or cancelled, you are out of luck. All your investment turns up nothing, or you have to invest more. So naturally you have to think about risk management in such cases.

Generally speaking, you don’t want to bet on a moving target unless the vendor has demonstrated a track record to consistently deliver products on time. It doesn’t matter the dependent product is within your organization/company or not. You may think an internal project is more dependable than external ones. But when it comes to software project, it’s not likely true.

To be safe, you want to work on released products. Sometimes it may not be an option. For example, you develop a device driver for next version of Windows. The stake is too high for not to support it on day one with the new Windows.

I have to point out that even a product is there already, there are chances for it to be phased out or replaced by a new generation of products. But then the vendor will provide a migration path to ease the issue. Therefore there should be no immediate impact.

Now, if you have to chase moving targets, what are the effective strategies to mitigate the risks? Here are LID (Limit/Iterate/Diversify) strategies:

Limit. You project is successful only if all your dependent projects are successful. Even all the dependent products are successful, there might still be issues for them to work together. The less moving targets you depend on, the higher chance for your project to succeed. While developing the open source vSphere Java API, I decided that it only depends on dom4j 1.6.1.
Iterate. You don’t want to sync up with the dependent product after it’s released for sure. Instead, you get alpha, beta, RC builds so that you can try out and find potential risks early on. This allows you enough time to adjust your project plan, for example, reduce investment until the dependent products are ready. If it’s an internal project or open source project, you can have even more frequent interations.
Diversify. This is the same wisdom as you spread your investment portfolio into multiple stocks. The techniques are however different in software projects. You want to have an abstraction layer to cover two or more alternatives. Like it or not, the abstraction layer is an overhead and requires more effort to develop. This diversification helps not only manage risk but also expand business opportunites into multiple and sometime competing ecosystems.

I summarize the LID strategies for software project management. The basic principals should be applicable for other non-software projects for risk management as well. Please feel free to give them a try.

Chasing Moving Targets originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

1xN to Nx1: The World Is Flat In Computing

Steve Jin — Mon, 06 Feb 2012 05:01:23 +0000

The first part of the title of this article may seem like mathematics, but it’s really not. This is just about software packaging – a topic not so often discussed. In plain English, it basically says something like: one application with N features vs. N applications, each of which has one feature. More generally speaking, it can describe software entity with sub-elements. I will discuss it in the contexts of mobile/desktop, and virtual/physical.

From Desktop To Mobile

As a software professional, I am really impressed by the rapid growing number of mobile applications today. As estimated, there are more than 500,000 iPhone applications, similar number on Android, and less but good enough on Windows Phone 7.

While we are excited about the big number of choices, normal folks don’t really need that many applications at all. In general, majority of the applications are downloaded just a few times or even no download.

The long tail theory holds true, and it’s good for the store owners like Apple but not necessarily for majority of the app developers. That is a wholly different discussion that we’ll skip here.

Because of the limitation of computing power, small sized screen, lack of mouse and keyboard, it’s natural to have much smaller applications on mobile platforms. So far, it has worked pretty well.

Although rich in features, the traditional applications has majority of the features that normal users never use or think about. It’s fair to say 80% of users use only 20% features of applications like Microsoft Office. When the really simple mobile applications come, you can imagine the excitement.

While we sometimes find it a trouble to find particular menu/keystroke combinations in traditional applications, it’s no longer an issue in mobile applications – it just has one or two features therefore you can’t miss it.

However, the problem of finding right feature to get work done is not gone away. It just morphs to a different problem: finding a right application.

From Physical To Virtual

In theory, the rising of virtualization should not introduce the flatting out packaging. But because of the virtual appliance concept, the packaging in the virtual world is getting flatter than in the physical world.

For example, on a traditional operating system running on a physical machine, it normally has many applications installed. With virtual machines, you could do the same or simply package one application with one OS/virtual machine. It’s not that you cannot package only one application with OS in physical world, but that you can do it so easy and cost effectively in virtual world that it becomes feasible there.

The one to one mapping allows vendor to pre-install and configure an application in a virtual machine, therefore simplify installation and configuration. When a user receives the virtual machine, she can just run it with very few changes like IP address if static IP is needed.
While the installation/configuration issue is dramatically simplified for ONE application, you will have more operating systems to manage. This is the virtual machine sprawl as discussed in my previous article How to Avoid Virtual Machine Sprawl in Cloud Age.

A Rising Problem

While we solving the problem with traditional packaging, the solution brings a new problem, which is to manage more entities, either more applications or more virtual machines. It’s true that the single application or virtual machine is simpler and may easier to use, but the cost of extra applications and virtual machines are rising for sure.

Not only that, the information sharing is easier when an application or operating system is fat than when it’s flat. Multiple applications or virtual appliances takes more efforts and consumes more resources.

It’s hard and too early to say flat application or virtual appliance is a save or not. I don’t think there is a standard answer. Like most things, the result will be case by case.

1xN to Nx1: The World Is Flat In Computing originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Announcing Code Generator For vSphere Java API

Steve Jin — Wed, 01 Feb 2012 08:12:06 +0000

As I tweeted last week, there would be a big announcement when the open source VI Java API gets 20,000 downloads. It hit target yesterday. To celebrate it, I decide to release the code generator for the API, which William (@lamw) rated as “awesome.”

If you have used Onyx for generating PowerCLI code before, you can think it as Java version of Onyx. Even better, it generates complete Java code which is ready to run once you supply the URL, username, and password. It’s so easy that from now on, all the system administrators have no excuse for not trying open source vSphere Java API.

At its heart, the code generator is a reversed proxy which sits between a vSphere Client and vCenter or ESX(i) server, and intercepts the SOAP XML messages. With the XML messages, I designed the algorithm to automatically generate the Java code based on the open source Java API code.

Unlike Onyx, the Java code generator provides richer GUI which allows you to:

Record both the requests and responses.
Sort the recorded messages in any order.
Generate complete code of any selected requests.
Save recorded messages to a local file, and read it back later.
Support raw HTTP data, XML, Java simultaneously in different tabs.

Although the generator supports only Java today, I did designed it to be extensible architecture for other languages like Jython, JRuby, Perl, etc. When I have time, I will continue to work on these in the future.

Too much talk? Let’s take a peek at a few screenshots in this page which includes download link and getting started tutorial. Shorter than my 5 minute VI Java API tutorial, it should be less than one minute this time.

Hope you enjoy the tool and let me how you like it.

Announcing Code Generator For vSphere Java API originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Management Middleware: The Future of Virtualization and Cloud Marketecture

Steve Jin — Sun, 29 Jan 2012 06:08:14 +0000

While installing and configuring vCloud Director recently, I kept thinking how to simplify it by removing un-necessary concepts and steps. To be fair, vCloud Director as of version 1.5 does a decent job to provide a high level abstraction for cloud infrastructure. Still it can be significantly improved just like every other new technology. Note that I pick vCloud Director as an example for the following discussion simply because VMware is the leader in virtualization space and what it does has ripple effects on other vendors.

To make things simpler, we have to answer a fundamental question on the marketecture: how should VMware position vCenter and vCloud Director in its product portfolio? Should their relationship be like application to application? Or should it be middleware to application?

I don’t think anyone has a clear answer, at least not yet reflected in the vCloud product itself. On one hand, it’s like and in fact intended to be middleware to application because vCloud Director depends on vSphere; on the other hand, it’s like application to application because you have to use vCenter to do all the basic configurations before vCloud Director can be installed and configured.

The current situation reminds me of early days of database as middleware: before you run your application, you first need to install your database separately and configure it manually to meet the requirements of the application, which includes manually run SQL scripts to create database tables in the database. You may wonder why not hide the database from the application administrators and users. Well, that is part of the history. Before it’s clear to everyone that database should be middleware, it’s natural to do that way.

I think we are at the similar turning point today in the virtualization management space where we should clearly divide the layers: hypervisors, middleware, and applications. For the hypervisors, there is little doubt. For the upper two layers, there could be confusions about what should go which layer, and more importantly where should be the right boundary of the virtualization management middleware and application.

Luckily we have a good example here. In my opinion, vCenter should be a middleware, and vCloud Director should be an application along with other applications.

The change of mindset is important. With that, we should first hide vCenter and any other related building blocks like vShield, just like in vCenter you don’t feel the existence of a database unless you intentionally dig into it.

Of course, you still need to install and configure vCenter, but do so within vCloud Director installer. Let me borrow an example from database world: your application installs a database and connects to it programmatically for creating new database tables and whatever preloaded datasets.

Following the same idea, vCloud Director should do the same: silently install a vCenter and create whatever provider datacenter programmatically. When that happens, I think the complexity exposed to the cloud administrators can be significantly reduced.
Although I used VMware as an example here, the principles are also applicable for other vendors like Citrix, Microsoft, Red Hat, and Oracle in their virtualization management stacks.

With the right separation of virtualization middleware, there could be a rich portfolio of applications merging in the marketplace, and driving virtualization and enterprise IT management to next level. Companies that do it right can further penetrate the market and win more market shares.

Note: this article talks about virtualization management middleware, not the middleware virtualization which is a different topic.

Management Middleware: The Future of Virtualization and Cloud Marketecture originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Cloud Innovation: Interesting Use Cases

Steve Jin — Sat, 21 Jan 2012 20:19:36 +0000

As I predicted for 2011, the cloud will be the ultimate powerhouse for mobile devices. The reason is simple: although fancy and stylish, the mobile devices typically do not have enough computing power and storage space for certain applications.

While reading BusinessWeek magazine not long ago, I got to know that a company called Elemental Technologies in Portland Oregon is spearheading in that direction. The company develops a box that trans-codes videos to fit receivers’ seen size, resolution, OS, plug-ins, etc, which total up to 250 technological formats. According to the article, the company “plans to introduce a cloud based product so that smaller websites can use its technology without having their own datacenters or owing a video processing box outright.” That makes a lot of senses both technically and business wise.

Video processing is a great example that takes advantages of the computing power of the cloud. There are other domains as well.

I have a friend who ran a company who develops setup boxes (they don’t move as mobile phones but have similar limitations). To save cost, they want to use commodity CPUs in their setup boxes. But they still want their users to play advanced games that require significant amount of computing power. They finally decided to use servers back in their datacenters for computing and render the screen to users’ TVs.

If it sounds a little abstract, think it as another version of remote desktop where setup box is a thin client remotely connected to a desktop running at the back. By doing so, they can achieve significant advantages with lowered setup box prices and flexibility in upgrading their computing power in datacenter alone.

I am sure there are many more interesting examples you may know of. Please feel free to share them in comments.

Cloud Innovation: Interesting Use Cases originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Why vSphere PropertyCollector Is Hard By Design?

Steve Jin — Wed, 18 Jan 2012 05:01:21 +0000

If you’ve had a chance to use vSphere Web Service SDK, you must know the PropertyCollector is very hard to use. It takes a newcomer quite some time to learn how to use it, and even more time to learn to use it effectively. Luckily, you no longer have to if you use the open source vSphere Java API (a.k.a. vijava) because it has encapsulated the PropertyCollector behind these newly added getter methods of the managed object types.

Still, a question has lingered in my mind for a while: “Why was the PropertyCollector designed to be hard?” If you have a similar question, this article is for you. Note that this is just my own thoughts. Hope it offers a good explanation, and more importantly you can learn from it for your future designs.

Although vCenter and ESX/ESXi have implemented the same API interfaces, the vSphere API is mainly for vCenter and heavily influenced by vCenter. Functionality wise, vCenter supports almost all the APIs, while ESX/ESXi does part of them. It’s not strictly superset/subset relationship but pretty close.

As you know, the vCenter is built on top of relational databases, either Oracle or Microsoft SQL Server. With the vFabric Data Director and vPostgress, we can expect Postgress to be used. Why? According to Paul Maritz, you got to eat your own dog food.

So vCenter is a database centric application in server form. What does it really mean? At a high level, the managed object types are mapped to tables in the database; managed object instances to records; properties to fields. The ManagedObjectReference includes both type (table) and value (primary key). Secondly, different threads in vCenter share information via database.

With that in mind, the PropertyCollector is really an interface to the database retrieving different tables (managed object types) and their fields (properties). It’s very natural to design something like PropertyCollector, a single type that is responsible for getting all properties of all managed objects. Also with SOAP Web Services, it does not make much sense (check out the data transfer object design pattern) to provide numerous getters, each of which corresponds to a property.

While the single type making sense, the interface design can be improved however. The most common use case of PropertyCollector is to retrieve a property from a managed object. With the existing interfaces, you got to work with several data objects to specify what you want. It of course works but isn’t easy to use. Ideally it should have included a simple interface as follows:

Object getProperty(ManagedObjectReference obj, String propName)

This simple property retrieval is, however, not the most common usage of PropertyCollector in vSphere Client which has been the first and still the most important application built on top of vSphere API. This is yet another reason why the PropertyCollector is hard to use – its major application vSphere Client has different requirements that have been satisfied, therefore there hasn’t been enough incentives to improve the design.

Now, how to bridge the gap? I think the open source vSphere Java API has demonstrated a good approach. Should you be interested in how, you can check out the code. The architecture is designed so that other distributed system can leverage it as well. So you may still find it useful even if you are not using VMware vSphere.

Why vSphere PropertyCollector Is Hard By Design? originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Physical is New Virtual

Steve Jin — Mon, 16 Jan 2012 01:52:09 +0000

I went to EMC office at Milford, MA last week for a 5 day training class on Vblock Administration. As you may have known, VCE Vblock is the industry’s first and leading converged infrastructure with compute, network, and storage from industry leaders. For the compute, it uses Cisco UCS. If you have followed my blog, you should know that I have blogged about the UCS emulator and XML management APIs.

One key differentiator of UCS is the service profile and related service profile template. The service profile is a server’s identity – it abstracts out the basic characteristics of a blade server, for example, UUID, MAC addresses, boot policy, etc. It can be dynamically applied to a blade server, meaning the physical blade server does not carry these characteristics and can be replaced without any impact. It also means that the same blade server can become a different server with a different service profile. It’s much like the virtual machine hardware.

A service profile can also be moved onto another blade server (to be exact, chassis slot owns a service profile, not blade server) either in the same or other chassis as long as managed by same UCS manager. After the new blade server boots up, it runs exactly the same OS/applications as before although it’s really a different physical server. Does it sound familiar to you? I bet. In some way, it’s like vMotion in virtual world except that it’s not a live but cold migration.

Similar to virtual machine templates, UCS uses service profile templates. A service template aggregates pools (UUID, MAC, WWPN, WWNN), policies (LAN: QoS, Dynamic vNIC connection, flow control, threshold; SAN: threshold; Server: adapter, BIOS, boot, local disk, firmware, vNIC/vHBA placement) and connectivity (vNIC, vHBA) templates, and can be instantiated to new service profiles on the fly. This helps not only speed up the deployment of servers, but also standardize the configurations of blade servers.

With these being said, I hope you would agree with me that UCS has virtualization features built-in. It should not come as a surprise if you know the history of UCS: one of VMware founders Edouard Bugnion had led the design of UCS at Nuova Systems which was acquired by Cisco in May 2008.

You may now wonder, “Do I still need VMware vSphere or other hypervisors if I have UCS already?” Great question. I will talk about it later, and more importantly, explain when you do and when you don’t. Stay tuned.

Physical is New Virtual originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Why So Many Programming Languages?

Steve Jin — Wed, 11 Jan 2012 02:59:08 +0000

While checking out the search engine terms to my blog, I found an interesting one there: “why so many programming languages?” A great question indeed. If you take a look at the Wikipedia page on programming languages, you will be surprised by the number of programming languages today. To give you a hint, the languages are categorized into different sections by their first letters. When I browsed the page, I found most of them were new to me and will definitely remain so in the future.

Now let’s get to the question of why. The simple answer is because there are so many programmers who created them. This is of course not the ideal answer but heading the right direction.

From technical aspect, we need a variety of programming languages for a variety of projects. We cannot expect one programming language killing all. Programming languages like C are very good at lower level programs like device driver, but not much so at high level application development. A generic application programming language may not be the best for Web application development. So there is a real demand for various programming languages.

From historical aspect, a lot of programming languages were created over the last 60 years or so since computer was invented. Some of them are actually no longer active, or limited to very specialized community. Surprisingly, the life time of a programming language can be longer than most of us can imagine. Just think about COBOL – we’ve been thinking it’s dying in the last 20 years but it’s live and was in high demand around year 2000. This accumulated effect has definitely contributed to the sheer number of programming languages.

Although thousands of choices today for programming languages, you don’t need to learn all of them, but one or a few of them. You can definitely make a good living if you can program well in one programming, but most likely one is not enough if you choose to be a programmer. Ideally, you want to learn C, one of Java/C#, and one of Python/Perl/Ruby. From there, it’s very easy to learn other if needed by a project.

Having discussed these, it still does not really explain why so many and new programming languages keep coming. I am also surprised by some magazines’ “language of the month.” I think even once a month is not enough for the new languages, most of which are simply ignored by the programmers at large.

While keeping trying new languages is good, most of them are simply rehashing whatever available in other languages today. Knowing it most like not going anywhere, some programmers keep inventing new languages in a similar way as people who want to be a popular movie star someday.

It reminds me an article I read before (sorry that I cannot find it any more). It basically discussed the programmer visibilities per types of software. I think the programming language is listed the first there, followed by operating systems, and APIs/frameworks, and applications. Now you understand the motivations of creating new programming languages.

Don’t get me wrong here. Nothing is wrong for a programmer to gain visibility. Everyone needs a motivation. Be it visibility or something else is purely personal choice that we should honor. Without the motivations, we wouldn’t have a rich portfolio of programming languages to choose from. For the same token, the richness can cause some confusions as well. That is just two sides of so many programming languages. After all, too many choices is better than no choice. Agree?

Why So Many Programming Languages? originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Random Thoughts on IT Automation

Steve Jin — Fri, 06 Jan 2012 07:00:32 +0000

IT automation is key to IT efficiency, agility and control. Here are some of my recent thoughts on this topic. Please feel free to share yours.

People and Automation

All automations ultimately start from people, not the other way around.
Although automation has a role, it never takes the place of a good system administrator.
Not everything can be automated, and not everything is worth being automated.
Automation is never a self-propelled perpetual motion machine. It needs a driver – the human being.
While system administrators in the driver seats, good feedbacks from the IT system are like dashboard and therefore indispensable.
Good automation should empower system administrators to do works more efficiently and more consistently.
An automated workflow is like a recipe. The goal is to repeat it in a consistent way regardless of cook.

Automation and APIs

Automation is possible if and only if the target is programmable. Therefore APIs are crucial to automation.
Reactive automation is possible only if the target is observable with metrics via APIs.
Unified management APIs are helpful for a unified view of underlying infrastructure therefore simplify the automation development.
API interoperability is a must to avoid automation islands in large scale IT systems.

Policy vs. Script

Policy is easier to understand and author, but less flexible to extend beyond what’s already supported than scripting.
Policy is good for most common use cases that don’t change much over time, while scripting is good for less common use cases that are hard to define their structures.
With many automation scripts in place, the question of how I can get a work done becomes which script I should run.
The “cloudier” an IT system, the more scripting for automation.

Random Thoughts on IT Automation originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

Top 5 Predictions on Cloud Computing for 2012

Steve Jin — Sun, 01 Jan 2012 02:06:49 +0000

After finishing up my reflection of 2011 predictions , it’s time to make my predictions for 2012 as today is the last day of 2011.

1. Virtualization war will be heated between VMware and Microsoft. The trigger will be the Hyper-V 3.0 which is expected to ship in the middle of 2012 with the Windows 8 server. According to many people, the 3.0 release will bring it on par or better than latest VMware hypervisor.

Gartner predicted that by 2012 “Hyper-V will account for 27% of the market, up from 11% two years ago. Within that projected 27%, Gartner says Microsoft will have captured 85% of all businesses with less than 1,000 employees that use virtual servers.” The last 85% is a bit alarming because Microsoft is known for growing market share from small to big, and then to dominance.

The license change in vSphere 5 in 2011 also has a profound and lasting impact on the competition besides the improvements of Hyper-V. While the diversification continuing, VMware continues to lead in terms of technology and market shares. The coming 2012 will be a real test for VMware whether it can effectively defend against competition from Microsoft.

In longer term, I think the competition landscape of VMware and Microsoft in virtualization is probably like that of Oracle and Microsoft in database. Whatever tricks Oracle has used should work for VMware to defend its market share because they are all market leaders and target enterprise customers.

2. More Packaged Applications will be delivered as SaaS. Traditional software vendors simply cannot ignore cloud story even though it may cut into the current revenue of existing license sales. Embracing cloud model may also open doors to new customers and new market opportunities.

Technically, vendors don’t need to redesign software for the cloud but repackage it as a virtual machine or a set of virtual machines. For most ISVs, redesigning software for cloud doesn’t justify the extra cost of not sharing resources like databases, operating systems.

3. PaaS market will be flat. While PaaS made great progresses in 2011 and continues to appeal much to the developers, it won’t have significant growth in 2012.

I think that three factors limit the PaaS as a substantial business opportunity. First, developers like the convenience but still prefer the ultimate freedom to control underlying platforms, which is not only impossible but also somewhat against the PaaS ideology.

Second, most PaaS is not ready for real production systems, where the big money is today. Most production systems are so complicated and demanding that they are not feasible via PaaS model. Also, once a production is set up, it’s not likely needing a PaaS.

Thirdly, most enterprise is not yet ready to run business applications outside their premises due to various concerns like security, compliance, etc.

Generally speaking, the PaaS will largely remain as a testing and development platform in short term until the 3 factors are effectively resolved.

4. IT in a box is the private cloud for enterprises. It’s not about converged hardware infrastructure, but also the packaged software solutions. Integration and automation will be the main themes. With the cloud box, enterprises will enjoy the benefits of cloud computing while avert much of the conventional burdens of assembling hardware infrastructures and installing software stacks.

The enterprise job market will reflect these changes. When the networking, storage, and compute converge, so will the organizations and people’s skill sets.

5. The cross powering of mobile and cloud will continue. As I predicted last year, the cloud will be the ultimate power for mobile computing. The trend will continue in 2012. New mobile devices are widely supported by enterprises. There are more to do on syncing up the contents across them.

Also, mobile devices are not powerful for some sophisticated data processing that demands CPU/GPU powers. The cloud can definitely off help there. The mobile computing makes the cloud more accessible and more appealing to average users.

That is about it. Wish you all a great 2012! Please remember to come back for the review of these predictions by the end of 2012.

Top 5 Predictions on Cloud Computing for 2012 originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.

DoubleCloud.org

Chasing Moving Targets

Related Posts

1xN to Nx1: The World Is Flat In Computing

Related Posts

Announcing Code Generator For vSphere Java API

Related Posts

Management Middleware: The Future of Virtualization and Cloud Marketecture

Related Posts

Cloud Innovation: Interesting Use Cases

Related Posts

Why vSphere PropertyCollector Is Hard By Design?

Related Posts

Physical is New Virtual

Related Posts

Why So Many Programming Languages?

Related Posts

Random Thoughts on IT Automation

Related Posts

Top 5 Predictions on Cloud Computing for 2012

Related Posts