Companies that leverage cloud will collect hundreds of cloud services, and these services will become parts of mission-critical applications. As we discussed last week, this situation creates the need to identify these services and build a catalog that can properly discover, track, leverage, manage, and secure the services.
We’ve always had the notion of tiers when it came to understanding the importance of applications, network services, data, etc., and a services catalog can play an important role in tier management. The idea is to provide more detailed support to applications at the higher tiers, which are applications with higher importance to the organization. These applications need infrastructure services and platforms that provide better up time and performance, even if they cost more.
- The ability to leverage the most expensive resources for the applications that are most important for the business. In the days of traditional hardware and software, this meant purchasing dual redundant systems, and higher performing hardware. The price for that stuff was huge, and thus had to be fully justified.
- The ability to prioritize maintenance. Systems that support the most important applications get the most attention from those who manage the systems.
- The ability to categorize security services. This means that the most sophisticated, effective, but most expensive security services are directed at the business-critical systems. Those applications that are less critical typically have very few security services, or, in some cases, none at all.
As enterprises move to public cloud-based resources, the use of application and data categories will play more important roles, for the same reasons listed above. For instance, there are public cloud storage services that are guaranteed to support SLAs (service level agreements) that approach 100 percent up time, but the costs are much higher per gigabyte of storage. Of course, there are public cloud services that don’t offer the same amount of up time, but charge way less.
You need to match the right storage or compute services to the right use of those services by application tier, based upon cost-to-value. Again, we’ve been doing this for years with hardware and software, now we’re just extending this to the use of cloud-based services. The concepts should not be new, for most enterprises.
While the way that application tiers, and the level of cloud services that support them, will vary greatly from enterprise-to-enterprise, I’ll suggest a basic model. See Figure 1.
Figure 1: Using tiers to categorize cloud services insures that costs are directed properly, and the most important applications get the most effective cloud services.
Tier 1 is the easiest to define. It’s all of the applications that run the business, and the data bound to those applications. The applications may include inventory control applications, sales management systems, shipping and logistics systems, etc.. They are any business system that can stop the business in its tracks if they stop working. In many cases, they may cost millions a day in lost revenue for larger enterprises.
Thus, the types of cloud services we leverage when we build, deploy, and manage these systems are also top tier services. Very specific SLAs define very high availability, including cloud services that support high fault tolerance and provide scalable performance on-demand.
Most public cloud providers, including AWS, Microsoft, and Google, have approaches to fault tolerance and scalable performance. AWS, for example, provides a reference architecture and guidance around provisioning and deploying such cloud services.
“Most of the higher-level services, such as Amazon Simple Storage Service (S3), Amazon SimpleDB, Amazon Simple Queue Service (SQS), and Amazon Elastic Load Balancing (ELB), have been built with fault tolerance and high availability in mind. Services that provide basic infrastructure, such as Amazon Elastic Compute Cloud (EC2) and Amazon Elastic Block Store (EBS), provide specific features, such as availability zones, elastic IP addresses, and snapshots, that a fault-tolerant and highly available system must take advantage of and use correctly.”
AWS dominates these types of (tier 1) public cloud services right now, and most enterprises find AWS easiest to use and deploy. However, IaaS providers such as Verizon and IBM are focusing on their area of the cloud market. Verizon and IBM have been the solution of choice for larger enterprises that have pre-existing relationships with the companies, and these enterprises may demand more direct control of their cloud services.
The cost of such services is typically higher than more lower-level cloud services where the availability and performance is not guaranteed. However, the prices have been dropping over the last few years. In some cases, there is very little difference, in terms of price, between highly available and high performing services, and commodity types of cloud services. So, make sure you run the numbers to take advantage of the value that’s available.
Tier 2 cloud services are for applications that are not business critical, or won’t stop the business from functioning if they go down. These applications should leverage cloud services that provide good value in terms of cost, reliability, and performance, but enterprises should be more focused on cost than in Tier 1.
Of course, the SLAs are reflective of Tier 2 applications, and don’t provide the same degree of availability promises. The cost should be less for these cloud services, but you should not be surprised if you experience occasional outages, perhaps 1 or 2 a month. Despite what the SLA reflects, in my experience, most public cloud services rarely go down no matter what you pay for them. Thus, what you actually pay for are the promises and legal protections more so than the services.
Tier 3 applications are only used occasionally, such as applications for end-of-quarter processing, or those that may be used to take occasional inventory. If cloud services are indeed needed for these applications, the focus is solely on cost efficiencies. In many instances, there are no SLAs involved. Examples would include the use of Dropbox or Box.net for storage services, or Google Applications. They are either free, or offered at a very low cost.
The use of tiers to define the types of cloud services that exist within the right catalog of applications means that we pay close attention to the core application requirements, and applying the right level of cloud services. The core reason for leveraging public cloud-based resources is the ability to save money and provide better business agility. If you apply higher-end and more costly cloud services to applications that don’t require them, you will not meet that objective. However, if you use lower level services that could put the application at risk, you put the business at risk as well.
Consider application tiers in the context of building the cloud services catalog, and perhaps force the categorization of the cloud services (Tier 1, 2, and 3) as the services are on-boarded, along with the categorization of the applications. This will allow enterprises to set policies to support internal SLAs, and maximize the value enterprises get from the cloud.