Virtual Is Now The Reality

A developer friend at Wind River asked me the other day: “Let’s say I have a virtual platform of a small developer board (like the Minnow Board). When should I run the simulation in a VM or a Linux container? And when should I run it as a virtual platform in a cloud based lab?”

After a 3 second reflection, I answered spontaneously “Well, the biggest difference is probably the instant sharing mechanism you have in a cloud based lab with virtual platforms. Think of it like a virtual room where everyone logs into the same lab. They see the same things and instantly share software and running sessions with one another. ”

We had a fruitful discussion, and my friend walked away happy with some new thoughts around cloud based tools. But I haven’t been able to stop thinking about this. Containers and cloud based virtual platforms are so different, yet quite alike. It’s just different virtual concepts.

There must be others thinking along the same lines as my friend, I can certainly see why all the various virtual concepts today can be confusing.  I’m not particularly satisfied with the answer I provided him.  What are the dimensions we can break this down into? We need to understand both the differences between the virtual concepts, what they are, and the reasons for using them.

First, there’s virtualization of hardware, like network function virtualization, software-defined-networks, or software-defined-anything for that matter. This is a sort of an evolution of classic old virtual machine (VM) technologies, where whole machines and operating systems are virtualized. Software containers (used in Linux for example) can be seen as a “lighter” type of VM technology, where all containers share the same operating system kernel, and only parts of the file system are separated into different containers, not the whole operating system image (there are variants here, not all software container formats are alike). See a simple illustration below. (And for a more complete illustration and explanation, read this post from Imesh Gunaratne.)

Modern software systems can become incredibly complex when all these virtual layers are added on top of one another. The original reason for creating a Virtual Machine was to allow multiple users to share the same mainframe. A VM let them run whatever OS they wanted inside the VM, and using VMs to share the big mainframe amongst themselves. These days, the business reason to virtualize your hardware, operating systems, or any other “close-to-the-hardware-software”, is usually because it’s easier to update software than hardware, and you get better utilization of the hardware. Virtualization essentially means that you move functionality from being implemented in hardware to being implemented in software instead. And software enables you to respond to changing demands quicker.

Next we have, cloud based technologies. Simply put, it means you run some piece of software in a large server park somewhere, and you access it remotely via a client that you run on your local machine. You basically “rent” computer time instead of using your own computers. What’s the reason for cloud based technologies? You first have to separate between if you’re thinking of it from the perspective of using a Cloud technology in your company, or if you’re thinking of offering your products as a Cloud based technology.

• If it’s the latter, you probably want to do it because you will offer a service to your customers (instead of selling “a thing”). This can go under the umbrella of selling software-as-a-service (SaaS) models. Your customers buy a service from you, which you offer via the cloud, they don’t license a product. Think of examples like Salesforce.com vs SAP.
• If you are thinking of using a cloud technology, you probably want to do it because it’s an easier and more flexible way of accessing a technology or a tool, which makes it easier to communicate and work together. You don’t want to manage local installations, do all the maintenance and keep track of different versions. Also – you can likely buy the cloud service based on much you use it, which makes it easy to scale up and down the costs depending on how much you use the tool, and you don’t have to invest a lot up front. It becomes a cost structure factor.

Another virtual concept is a virtual lab. It often means you use a local client to access a remote lab. Basically you have your physical lab installed “elsewhere”, and you access it remotely via your local client. This is quite close to cloud based technologies in general. The main distinguishing factor is that while cloud computing tends to use commoditized interchangeable hardware, hardware labs contain specific hardware used for specific products or software stacks. The reason you want a virtual lab is because you want to save money – it’s too costly have a large on-site lab for everyone in your company/team. It’s impractical, takes up too much space, and you’d have to handle the maintenance of it – it’s resource intensive.

Then we have virtual platforms. In this virtual concept you have a software model of a piece of hardware (such as the hardware that would be used in a virtual lab), and you run that model in a simulator on a regular PC or server. If your simulator is a high fidelity simulator (such as Wind River Simics) that can run very large software stacks, you run your entire software application (from OS up to the application) on top of the virtual platform in the simulator. The main values you get from using virtual platforms are developer efficiency and testing at scale.  Developers can work faster and more efficiently by not being limited by hardware and having better tools to collaborate. Testing scales out in a big way because there’s no limit to how many virtual boards you can have. In the end, you reach production quality of your software faster.

Illustration of Virtual Platforms: Note that inside a Virtual Platform the virtual hardware can be entirely different from the underlying host hardware, as can the “inner” OS compared to the external host OS. The Virtual Platform is often a replica of the specific hardware and software stack that will go into production. The applications are often identical in both cases.

Cloud computing and virtual platforms can also be combined, giving you remote access to your virtual platforms, via a local client or a web browser. (This was one of the alternatives my friend talked about – running a virtual version of the Minnow Board in a cloud based lab.) In this case you would get the benefit of several of the above concepts. You can use commodity standard servers to run tests and developer code, you get the benefits of virtual labs in avoiding local hardware, and you get the benefits of virtual platforms. Your lab is not physically limited anymore because you can scale up the hardware on-demand. You get instant access, unlimited number of boards, and running real software stacks. See the illustration below. One example of such a cloud based lab of virtual platforms is Wind River Helix Lab Cloud.

Let’s sum up the dimensions we have discussed above:

• The reason to use virtualization technologies (VMs and containers) is often that you want to optimize hardware resources and be able to respond to market change and demands quicker. Change becomes easier when you move functionality from being implemented in specific hardware, to being implemented in software.
• If you want to move to more continuous revenue streams, and not being dependent upon a few make-it-or-break-it deals, you may consider moving to selling software-as-a-service rather than letting your customers license your technologies. If this is your reason, then moving your product into the cloud may be a good thing.
• If you want to save operation costs in your organization, making staff more efficient, make it easier for them to work together, there are two different types of virtual concepts that help:
• Use cloud based tools. It’s easier to manage, there’s no local install, you keep all users in synch, and you can better align costs with needs because you typically pay for the actual use (not owning the tool).
• Use a virtual lab as a complement to your physical lab. It’s more practical, it doesn’t take up as much space, it doesn’t cost as much, you will have less maintenance costs.
• If you want software development to be faster and you also want your software to reach production quality faster, then virtual platforms is something to consider. In the end, this is about being able to deliver software more frequently (even continuously), meaning that you don’t settle for a release every year, but you want it a more regular cadence. This is a good fit with the business goal of continuous revenue streams mentioned above.

Now that I have given this some thought, here would be my new answer to my friend:  What do you want to accomplish? Are you thinking of it from a business perspective of increasing revenue, time-to-market, etc? Or are you thinking of a new way of working, enabling people to become more efficient and collaborative? Perhaps you’re really trying to sort out how you can combine the two – you want to run something in a Linux container because it’s an elegant solution, and you also want to move your work environment into the cloud?

What becomes clear when looking at all these types of virtual technologies, and the reasons for using them, is that many strive to make software development and delivery faster, not only in a small incremental way, but in a really big way. We know software provides the value and differentiation for many products and what becomes clear now is that how software is being built and delivered is becoming business critical for many companies. That’s where many virtual technologies can help.

If you want to try out Lab Cloud for yourself, you can get a free account at https://lab.cloud.windriver.com/.

Ps. I haven’t got back to my friend yet to continue the discussion, so I don’t know what his objectives were. Maybe I should find out….