The limitation with this type of approach is the assumption of a conventional (and, some would say, out of date) architecture, ie. single service on a single VM on a single cloud provider.<p>Topology specification, firewalling, resource constraints (bandwidth, IO speed/resilience... ie. RAID/backup persistence safety), service cohabitation or codependence, performance/capacity testing, cost, cloud provider abstraction, public DNS+SSL+sofware package distribution infrastructure dependencies, legal jurisdiction considerations, speed of instantiation, etc. are all realistic considerations (often requirements) for much modern infrastructure.<p>In short: this only gets you half-way, for relatively simple examples. But if your workload is within that space, by all means go for it.<p>(PS. Before anyone snaps 'you can manage multiple hosts with <tool>', sure. But the architecture of the tools begins to present issues.)