Some weeks ago, I discussed the dangers of using Amazon Machine Images (AMIs) from third-party providers and suggested that a web-service combining profound security scanning with community feedback could be a solution to reach a good level of transparency and trust. But are AMIs really the right abstraction for a software marketplace? Can they replace installers? Is searching for an AMI that fits the need of a customer and then launching it, the way that people want to install software? Are AMIs the determining abstraction of cloud IT?
I see two important limitations to the role of the AMI:
- The first is the problem of sharing resources on application level: starting an AMI for every application is costly, the customer needs to pay for every running instance that is in most cases overprovisioned. At the other hand, you loose all advantages of simplicity when you deploy, maintain, and upgrade several applications on the same instance. There’s probably no AMI that deploys your preferred CRM plus your preferred bug-tracking tool plus WordPress – you need to create it yourself (and run into new questions, e.g. how to maintain and upgrade your setup).
- The second is that launching is just not enough: instances must also be configured, e.g. with IP addresses, application specific parameters, or to achieve persistency. An AMI is not just a simpler software installer or even a DVD-like digital asset that can be played with one click, it is only one brick of a service or an application among others and it rarely works out-of-the-box.
If AMIs are not the right entity for a cloud infrastructure marketplace, which could be the right one then? One possibility could be a marketplace for “cloud deployment services” where a deployment service is basically a programming routine that takes input from the user and performs the complete setup, i.e. starting AMIs, attaching persistent storages, configuring static IP addresses, applying account information, connecting application-servers to database, encrypting storage, etc.
Such deployment services would clearly solve problem number two (configuration), but could also be enabled to reuse existing resources and thus solve the problem number one (resource sharing). At the other hand, they may become so specific that they are often needed only once. Any thoughts?