Analysis Services in the Cloud: IaaS vs PaaS
When deciding to deploy an Analysis Services solution to the cloud, one of the very first decisions to make is whether to go with an Infrastructure-as-a-Service or Platform-as-a-Service architecture.
The diagram below does a good job in explaining the differences between the two.
Note: from an Analysis Services cloud architecture perspective, the “Software-as-a-Service” is simply not an option offered by Microsoft. However, depending on your business model and product line, you might build & offer a Software-as-a-Service solution to your end customers based on Analysis Services IaaS or PaaS (and a good bit of other technology and custom code). In other words, Microsoft doesn’t offer it, but you could build it! If you’re interested, please reach out… I would love to work on a project like that.
The rest of this post provides a breakdown of the 2 options (IaaS vs PaaS) to help you make that decision.
Infrastructure as a Service (IaaS)
This option is basically the same as an on-premise virtualized environment (e.g. VMware, HyperV) only instead of owning the host servers, networking, storage solution, & virtualization layer… you lease all that stuff from Microsoft.
- super easy migration path (i.e. “lift and shift”) for existing on-premise solutions
- scaling up/down is easier than on-premise solutions (but not as easy or fast as PaaS)
- not limited to Azure… can deploy to AWS and other cloud providers
- can run Tabular and/or Multidimensional solutions
- option to bring your own SQL Server license
- lots of hardware (CPU/Memory/Disk) options to choose from (almost too many!)
- ability to run SQL DB and SSAS side-by-side
- difficult to scale-out for high-concurrency scenarios (same approach as on-premise)
- difficult to grant access to public/external users (same as on-premise)
- must design and implement HA/DR yourself
- must apply software and security updates yourself
Platform as a Service (PaaS)
This is the SSAS-equivalent of Azure SQL DB… Azure AS. The main difference, is that Azure SQL DB is can be thought of as a “Database-as-a-Service” whereas Azure AS is more along the lines of an “Instance-as-a-Service”.
- automagic software and security updates
- automagic HA/DR
- dynamic scale up/down
- dynamic scale in/out
- management API
- easy to grant access to public/external users
- migration path is a bit more involved than the IaaS (but not exactly difficult)
- stuck w/ Azure (though that’s not really a bad thing these days)
- no multidimensional option (yet?)
- fewer options in terms of HW (CPU/Memory)
Cost is an important factor (perhaps the most important) but also one that’s very hard to calculate due to the wide variability in solution requirements and pricing breaks. The longer I spend in this industry, the more I realize that list-price is just a starting point for negotiations and only “direction-ally” useful.
However, if you’re interested, I’ve scraped the hourly pricing from the MSFT sites for Azure VMs and Azure AS instances and lined them up to help compare at the various break-points (download excel file).
Couple of points to keep in mind…
- these are list prices… please don’t pay this amount before negotiating w/ your MSFT rep
- Hardware performance is not necessarily apples-to-apples… clock-speed/cache of the CPUs behind Azure AS are still not publicly disclosed (as far as I’m aware)… same w/ memory frequency (much more is known and/or discoverable w/ Azure VMs).
- prices are about the same at each level assuming you lease the Azure VMs w/ SQL license… if you already have your own SQL license, then you can just lease the Azure VM w/ windows (or linux) and pay quite a bit less.