Redefining Software in Cloud Age

As software professionals, we may still use the same programming languages and tools as 10 years ago. But there has been a fundamental shift in how we think of software, and make and consume software.

Static blueprints

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

Traditionally software really means blueprints, which are used to construct running software instances. The blueprints include binary code, installer, and related documentations guiding the installation and configuration of the software. Software vendors make the software packages and sell them to customers who then deploy and run them.

These blueprints are static once they are released, and do not specify exactly the operational aspects of the running software instances. These are left to the customers.

Running instances/services

When clouds come in, more customers consume software online without worrying about the operational aspect of the software. To these customers, the software really means services: either application as a service, platform as a service, or infrastructure as a service.
As Salesforce CEO Marc Benioff commented,

“If you’re talking about more hardware or if you’re talking about more software, it’s not about the cloud. And the cloud is really this next generation of computing and that’s new software and that’s new services.” (BTW, Marc also commented the approaches of VMware and on cloud computing. Feel free to check out the article.)

As a key benefit, customers don’t need to buy IT infrastructure up front, but to subscribe to the needed services online. That means zero capital investment, and zero time and effort in building infrastructure. It appeals well to the startup companies which have limited funding and want to focus on their own products/services.

Deployment aspects

Although more software is offered as services today, the fundamentals of software development lifecycle haven’t changed much. Even at, I believe there are more engineers developing/testing the software than running it as services.

What has changed is who deploy and operate the software. The cloud model has shifted deployment and operation from customers to either vendors or service providers. By centralizing them, an economy of scale may be achieved, and leads to reduced operation costs.
Technically, the software upgrade cycle can be much shorter than software product because the vendors and service providers have better control over the running environment.

In the product cases, I rarely find any customers who want more than one upgrade a year due to hassle of upgrading/migrating/ testing/training. That is why product companies normally have one major release per year.

For customers, there is no capital cost to build infrastructure and buy software license. At the same time, the flexibilities and controls may be reduced. These are two sides of the cloud story.

Two Stacks

In the cloud model, the traditional software stack remains the same. But a new stack has emerged to manage the running infrastructure and applications in the cloud, depending on what level of cloud services (IaaS, PaaS) you are using. Examples could be Amazon EC2 Web Services (IaaS), VMware CloudFoundry (PaaS). If you take VMware vSphere as platform for private cloud, then vSphere APIs fits into this stack as well.

The management stack is independent of the software stack. Built on top of the management stacks are Web based management tools, various plug-ins to IDE or test/build tools to make the user and developer experience more friendly.


With the rising of cloud computing, the traditional software has extended beyond packaged products to running instances for various services. Both delivery models have pros and cons in different contexts. For majority of the software, they will coexist for long period of time if not forever.

This entry was posted in Cloud Computing, Software Development and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Peter
    Posted May 30, 2012 at 8:42 am | Permalink

    I completely agree with the viewpoint that both traditional software running on local IT systems and cloud services will stay for a while side by side. In my view the usefulness of cloud services has to be seen in the context of the enterprises business. The Cloud service vendors often seen IT automation/consolidation as a drive for migrations to the cloud. In my opinion you have to look to the complete picture and certainly also to the opt-out options. In any case where you host your service the activities (deployment/development/etc) needed to resolve a business challenge stays the same. Wherever this is done by the cloud service provider or internally the enterprise, the complete solution end2end needs to be covered by the business owner.

  2. Posted May 30, 2012 at 10:43 am | Permalink

    Hi Peter,
    Thanks for sharing your thoughts on this, especially the end2end business perspective.

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.