As the year of efficiency continues at Readiness one topic that the development team has been working on for almost two years has taken an unexpected turn.

As we have built out our systems (first servers, then desktop) on Microsoft Azure we were in a very fortunate position be supported (and funded) by Microsoft. “Spinning up” servers and desktops to create test profiles and multiple packaging scenarios was actually pretty expensive a few years ago. Especially, if you had to pay for it.

So, looking at the costs of running these large (and sometimes very complex) network and resources we embarked on an internal effort to find a way to massively scale-out with a corresponding (and massive) cloud computing bill (Thank you Microsoft). After some deliberation (and shouting) we agreed to pursue three options:

1. Microservices
2. Containers
3. Super cheap machines sourced from around the world (this is/was the fantasy bit)

Given that we had decided on our API architecture was going to be based on REST API’s, micro-services, which are defined as;

“a micro-service architecture is a variant of the service-oriented architecture structural style. It is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols.”

This seemed like a good idea at the time. Small atomic units (application specific functions) that coexisted and communicated across disparate systems sounded good to us. Maybe we could even use Linux. Wow! This avenue of research quickly collapsed as we worked through our desktop system requirements. The way applications work and how they install/update/uninstall required significant desktop resources. The final nail in the coffin for micro-services was Microsoft’s AppService functionality. Almost all of the “generic” services that we were going to develop to help/host our automation platform were suddenly mostly free (for production use, Microsoft will charge – albeit a small amount). The “technical tide” had risen to float our boat sufficiently that we could focus on our core business offering – automating the packaging process. This was a big moment for us.

Now what? So, we decided to have a go at using Microsoft containers.

The whole idea behind containers is completely sound. All of the necessary components, pre-requisites are available and there is (now) a decent security model incorporated in the Azure platform. All we had to do was a little tuning…. and… and… then we realized that with our pace of development and new features which were added almost in real-time didn’t suit the UI and service restrictions inherent in the container model. Containers would be great for a set library services or very stable components – but just not the raging coal-fire of a development team hell-bent delivering customer requests.

So, the container “modernization” effort was put on pause. Sigh.

So, the pursuit of super cheap VM’s, securely available anywhere in the world had begun. And, to our surprise Microsoft Azure delivered: with Spot VM pricing. Spot VM pricing allows for super cheap (95% price reductions) for VM’s that do not need to be persistent.

The Readiness packaging model is based on the idea that we can rapidly create a virtual machine (VM) for:

• Application Discovery
• Testing
• Packaging or Conversion
• Automated QA
• Publishing to SCCM/Intune

These machines are used for a specific task and then deleted/removed. Which suits the Azure SPOT pricing model perfectly.

In summary the SPOT VM pricing model wins as it offers:

• low/no code modification
• world-wide/global access (there doesn’t seem to much a price difference across regions)
• easily accessible cost model, with no long-term contract/obligations.

Our customers have benefited tremendously – we can now offer faster, higher spec systems and still offer a great deal on Assurance. Our customers can now:

• Repackage and convert massive applications (e.g., AutoCAD)
• Test over 1000 applications per day
• Assess, repackage/convert, test, document, QA and publish packages in less than one hour (we think that this is amazing).

To find out more, visit the application readiness downloads section.