The restaurant analogy

We've covered how all aspects of data center management have changed. These fundamental changes also change your IT business.

You are now a service provider. While your engineering or technical knowledge is still important, your customer measures you on your business service level. There is a subtle difference between what they care about and what they measure you on.

Sunny Dua and I use the restaurant analogy when explaining the need for a formal Service Level Agreement (SLA). The analogy has resonated well with many customers. Humans can always relate to food!

Essentially, a restaurant has two areas, often with a clear demarcation:

• The dining area
• The kitchen

Think of your IaaS business like a restaurant business. It has a dining area, where your customers live, and a kitchen, where you prepare the food. Guess which one is more important?

You're right. The dining area.

If everything runs smoothly in the dining area, customers are being served on time and with quality food, and they are paying you well, it is a good day for the business. Whether you're running around in the hot kitchen is a separate, internal matter. The customers need not know about it.

We use the analogy to drive the message that you need to focus on the customers first and your IaaS second. While this sounds obvious, we rarely see customers implement it. The vRealize Operations dashboards you will see in Chapter 5, Capacity Monitoring, and Chapter 6, Performance-Monitoring Dashboards, will surprise you, as they are nothing like what you have in your Network Operating Center.

If you take care of your customers well, and they are happy with your service, the problem you have in your IaaS is a secondary and internal matter. Consider this:

• The dining area is the Consumer Layer. Look at the next diagram. It is where your customers' VMs live.
• The kitchen is the Provider Layer. This is your infrastructure layer, where VMware and the hardware reside.
  

  The two layers of IaaS business

There is clearly a line of demarcation between the two layers. Your customers should not care about the details of your SDDC. The VM owner does not care if you are firefighting in the data center. Because they do not care, whether you are using vSphere 5.1 Update 3 or vSphere 6 Update 1 is not something you want them to dictate upon you. The same goes with your choice of hardware brand and specification.

The application team becomes a consumer of a shared service—the virtual platform. Depending on the Service Level Agreement (SLA), the application team can be served as if they have dedicated access to the infrastructure, or they can take a performance hit in exchange for a lower price. For SLAs where performance is guaranteed, the VM running in the cluster should not be impacted by any other VMs. The performance must be as good as if it is the only VM running in the ESXi.

Ponder the previous paragraph and diagram for a moment.

Think of the implication. This is because they do not exist in HDDC. Can you see the impact if you are not 100-percent virtualized?

If you are not 100-percent virtualized yet, you need to have two modes of operation. Yes, it is that big a change.

The consumer layer

The following are the properties of the consumer layer:

• vSphere is well known for its stability. As a result, availability is not something you need to deal with daily. In the event of failure, vSphere HA will bring up the affected VMs within a few minutes, probably before the VM owner notices, if it happens during non-peak hours.
• Performance, on the other hand, is something that needs to be managed daily and monitored in minutes. In fact, this is generally the number one source of disagreement between the application team and Infrastructure team. That's why we put a large "number one" next to performance. As you know well, a VM owner only cares about their VM. Other VMs in the ESXi host or vSphere cluster are irrelevant. When a VM owner complains that her VM performance is slow, can you prove within one minute that your IaaS is serving that VM well? If you cannot, that is a sign you do not have performance SLA.
• When performance is taken care of, you can look at capacity. There is no point in discussing capacity when there is a performance issue. This is why it is given the number-two spot.
• Capacity for a VM is a matter of rightsizing. In general, it's the responsibility of the application team. As an IaaS provider, you can add value by recommending the right size.

The provider layer

The following are the properties of the provider layer:

• The IaaS layer is where you have, or should have, complete control and visibility. If you do not have it, you need to fix it, as your customers assume and expect you to.
• At this layer, you care about everyone, not just a specific VM. You have to care about both the VM and infrastructure, because you want to be assured that the shared infrastructure is not a bottleneck. The big picture is the key here. This is the layer where you answer questions such as "How healthy is my VMware environment?"
• Good performance means everyone is served well. The definition of "well" here is that the level of contention for any given VM is below what you officially promise.
• Good capacity means you are balancing your hardware procurement. Neither high utilization nor low utilization is good for your IaaS business.
• Configuration management becomes critical in your SDDC as it is easy to make changes. However, it is below performance and capacity in terms of business priority as it impacts your customers less directly.
• Availability management is important due to overcommitment. It is less critical relative to performance and capacity because generally, you have redundancy and are protected by vSphere HA. In SDDC, availability management has to cover Infrastructure VM. For example, you need to ensure the uptime of all your NSX Edge VMs and TrendMicro VMs, because they are in the data path.