When you architect IaaS or DaaS, what end goals do you have in mind? I don’t mean the design considerations, such as best practices. I mean the business result that your architecture has to deliver. A sign that your architecture has failed to deliver is you get into this situation:
The goal of IaaS is to ensure the VMs are running well. The goal of DaaS is to ensure End Users are getting good desktop experience. Have you defined well or good?
Let’s discuss IaaS first. Say you’re architecting for 10K VM in 2 datacenters. You envisage 2K VM in the first month, then ramp up to 10K within the first year. Do you know the basic info about each of these 10K VMs, so that you can architect an infra to serve them well?
- How big are they? vCPU, RAM, Disk
- How intense are they? CPU Utilization, RAM utilisation, Disk IOPS, Network throughput?
- Their workload pattern? Daily, weekly, monthly, etc.
You don’t. Even the applications team don’t know. Their vendors don’t know either, as you’re talking about the future.
So why do you promise that your IaaS will serve them well?
That’s a strategic mistake you make as Systems Architect. It’s akin to promising the highway you architect will all the cars, buses and motorcycle well, when you have no idea how many they are and how often they will use it.
Can you do something about it? Yes. You simply provide a good set of choice. The principle you share to your customers are the common sense used in all service industry:
You want it cheap, it won't be fast. You want it fast, it won't be cheap.
You then offer a few class of service. Give 3 good choice, at difference price point. The highest price has the best performance.
- Your price has to be cheaper than VMware on AWS, else what’s the point. VMware on AWS has identical architecture to yours, as it’s using the same software and providing same capabilities. This assures your customers that they are getting good price.
- Your performance is well defined. It is not subject to interpretation. You put a Performance SLA on the table, assuring your customers that you’re confidence of delivering as promised.
You then architect your IaaS to deliver the above classes of service. The class of service is your business offering. It’s the purpose of your architecture. With class of service clearly defined, the question below becomes easy to answer.
When you know exactly the quality of service you need to deliver, the operations team will not suffer. You handover your architecture to them with ease, as it can be operated easily. It has clear definition of performance and capacity.
Keep the summary below when you are architecting IaaS or DaaS.
For more details, review Operationalize Your World.