Service Tiers and History of SaaS

Modern Digital Applications with Lee Atchison

Show Notes

Welcome to the inaugural episode of Modern Digital Applications! I’m very glad you are listening, and I hope you’ll find this podcast informative and helpful. My goal is to try and keep the episodes short, so that they can be consumed during a single morning average commute trip to work. Please, let me know how I am doing and what I can to improve.

But, let’s get started.

In this episode, we begin a three part series on Service Tiers, and how they can be used to prevent disasters in applications using service based architectures.

We also take a look at Amazon S3, and the history of SaaS.

Links and More Information

The following are links mentioned in this episode, and links to related information:

• Modern Digital Applications Website (https://mdacast.com)
• Lee Atchison Articles and Presentations (https://leeatchison.com)
• Architecting for Scale — O’Reilly Media (https://architectingforscale.com)
• How Service Tiers Can Help to Avoid Microservices Disasters (https://thenewstack.io/how-service-tiers-can-help-to-avoid-microservices-disasters/)
• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

Main Story

Bringing down an entire application is easy. All it takes is the failure of a single service and the entire set of services that make up the application can come crashing down like a house of cards. Just one minor error from a non-critical service can be disastrous to the entire application.

There are, of course, many ways to prevent dependent services from failing. However, adding extra resiliency in non-critical services also adds complexity and cost, and sometimes that extra cost is not needed.

What if a service, let’s call it Service A, is consuming another service, let’s call it Service B. If the called Service, Service B, is not critical to the operation of the calling Service, Service A, then why should Service A fail if Service B has a problem? Surely, we should be able to build Service A so that it can survive the failure of Service B.

And if Service B is not critical to the functioning of Service A, does Service B need to have the same level of resiliency has Service A? No, of course not.

As we build our dependency map between each of our services and the services they depend on, we will find that some of the dependencies are critical dependencies, and some of them are non-critical dependencies.

How do we determine which dependencies are critical and which are not critical? One important tool for making this determination is to use something called Service Tiers.

What Are Service Tiers?

A service tier is simply a label associated with a service that indicates how critical a service is to the operation of your business.

Service tiers let you distinguish between services that are mission critical, and those that are useful and helpful but not essential.

Service tiers can be used to determine whether the interaction between dependent services is a critical dependency, or a non-critical dependency.

Service Tiers are a great way to help you prioritize where and how you invest in making your services, and their dependencies, more resilient. This allows you to build higher scaled applications that are much more highly available for the same amount of effort.

To see how this works, let’s take a look at the various service tier labels and how you can determine which label to apply to which services.

Assigning Service Tiers

All services in your system, no matter how big or how small, should be assigned a service tier. In the model of service tiers that I use and recommend, there are four distinct tiers, four distinct levels if you will, that allow you to specify the criticalness of a service. Let’s talk about each of these four levels.

Tier 1

The highest level is Tier 1. Tier 1 services are the most critical services in your system. A service is considered Tier 1 if a failure of that service will result in a significant impact to customers or to the company’s bottom line.

Let me repeat that: A service is Tier 1 if a failure of that service will result in a significant impact to customers or to the company’s bottom line.

Significant impact to customer’s. Or significant impact to the company’s bottom line business. If a service can impact either one, then it’s a Tier 1 service.

What are some example Tier 1 services?

• A Login service: This is a service that provides a method for people to login to your application. This is tier 1 because if a customer can’t login to your applications, it creates a significant negative impact to your customers.
• Credit card processing service. This is the service that handles customer payments. If customer’s are unable to have credit card payments processed, then this would have an impact on your company’s bottom line.
• Permission service: This would be a service that tells you what features a given user may have access to. If this service is unavailable, then customer’s won’t be able to get access to the features of your application that they have access to.
• Order-accepting service: This would be a service that lets customers purchase a product on your website. Obviously, if customers can’t purchase product, that impacts your bottom line, as well as the customer experience!

A failure of a Tier-1 service is a serious concern to your company.

In all, there are four service tier levels that we have specified. Tier 1, as we discussed above, is used for the most critical of your services. The remaining three tiers, Tier 2, Tier 3, and Tier 4, are for progressively lower priority services. In our next episode, we will be talking about each of these other service tier levels and what they mean. After we have defined the four tiers, we will discuss how we can utilize service tiers to make our application better, more reliable, more available, and for less money.

If you want to learn more about service tiers, you can read about them in my book, Architecting for Scale, or in my article published in The New Stack titled “How Service Tiers Can Help Avoid Microservice Disasters”. Links to both of these sources is available in the show notes.

Tech Tapas - Amazon S3

Amazon S3. A highly durable, highly available file and object storage mechanism in the cloud. This service is the go to service for most companies that want to store huge quantities of data in the cloud, or for long term persistent object storage.

S3 was designed with the goals of being highly available, highly durable, and highly scalable. The design goal for availability is 99.99%, with a durability of objects of 99.999999999 (that’s 11 9’s).

How available? The 4 9’s availability translates to a total of 52 minutes of downtime per year.

How durable? The 11 9’s durability means that if every man, woman, and child in the world had an object in S3, then Amazon would lose at most one of those objects, approximately once every 15 years.

These are amazing goals, and is one of the reasons S3 has such a great reputation as a high quality object storage system. S3 was one of three initial AWS services and was a big part of AWS’s early success.

Tech Tapas - History of the Term SaaS

When did software as a service start? Well, that depends on what you mean by the term… depending on how you define SaaS, the answer is either the early 1960s, or somewhere around 2005.

Back in the early days of computing, all applications ran on a centralized computer. Users accessed the computers remotely. Initially via punch cards and later via remote terminals. The centralized nature of the application is, by a true definition, Software as a Service.

But the modern definition of SaaS is tied much more closely with cloud computing. SaaS now-a-days refers to software running centrally, typically in a public or private cloud environment, and is shared among multiple users. A thin client of some sort — either a web browser or a thin mobile application — is used to front the centralized application.

From a business model standpoint, users don’t buy SaaS software, instead they rent or lease access to it with monthly or annual fees. Alternatively, the service could be free and supported by advertising or other monetization processes. This is the heart of the business model for social media, for example.

So, SaaS is an old term that has been given new meaning in recent years. But it’s the recent definition that has really changed the way people think and build software today.

This podcast uses the following third-party services for analysis:
Chartable - https://chartable.com/privacy
Podtrac - https://analytics.podtrac.com/privacy-policy-gdrp