Hello and welcome to Modern Digital Applications. In this episode, we continue our three part series on Service Tiers, and how they can be used to prevent disasters in applications using service based architectures.
We also take another look at Amazon S3, and ask the question, how large is S3? The answer might surprise you.
All of this, in this episode of Modern Digital Applications.
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)
- 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)
Links to stories mentioned in the news section:
* DevOps World (https://www.cloudbees.com/devops-world)
In the last episode, we introduced the concept of service tiers, and we talked specifically about Tier 1 service tier, which is used to label the most critical, highest priority services in your application.
In this episode, we’re going to talk about the definition of the rest of the four service tier levels that are defined.
In review, a Tier 1 service is a service that is mission critical to your application. If a Tier 1 service is down, your application is down. A tier 1 service is a service where if it fails, it has a significant impact on your customer’s and/or your business’s bottom line
After Tier 1, the next level of service is Tier 2. Tier 2 services can have an impact to your business, but are typically less critical than a Tier 1 service. A Tier 2 services is a service where a failure of the service can cause a degraded customer experience in a noticeable and meaningful way but does not completely prevent your customer from interacting with your system.
A great example of a tier 2 service is a search service. This would be a service that handles requests to search by your customers for products, product information or other content from your application. If the search box on your website stopped working, it would have a major impact on customers…especially if a customer is depending on search to find something on your site…but it would not make the application completely unusable to your customers.
Compare this to a tier 1 service, such as the login service. If customer’s can’t login to their application, they can’t do anything.
So a tier 1 service means a failure keeps the customer from doing anything. A tier 2 service failure means they can’t perform some important functionality, but other parts of the application are still available to them.
Tier 2 services can also be services that impact your backend business processes in significant ways, but may not be directly noticeable to your customers. For example, if a service that managed order processing in a fulfillment center fails, this would have a significant impact on your ability to fulfill orders in a timely manner. This would have an impact on your business, and a potential impact on your customers if a package arrived late as a result, but it doesn’t completely bring down your website or application, and customers can still do things, such as create new orders or check on the status of existing orders. A customer may not even notice this failure, yet it could still impact them.
That’s for tier 2 services.
The next level is Tier 3. A Tier 3 service is one that can have minor, unnoticeable or difficult-to-notice customer impact. Or it could have limited effects on your business and systems.
The key words here are: minor, difficult-to-notice, and limited.
The best example of a tier 3 service is a recommendations service. Think back to the last time you were on the website for a retail store. You click on a product to look at it. On the detail page for that product, you often will also see a list of recommended or related products that you might be interested in. You can click on those, and see and potentially purchase these alternate products. These recommendations are created by a recommendations service.
Now what happens if the recommendation service is down or failing? In this case, you can still view products on the website. You can still purchase product, and you can still have that product shipped to you. It’s just that the list of alternate recommended products…the upsell products if you will…won’t be visible on the site.
Most customers would not even notice the missing feature. Or if they did notice, it would be only a limited inconvenience. Yes, it’d be nice if the feature was there, and it probably does have a financial impact to not have those recommendations showing, but it isn’t a significant impact.
That is a tier 3 service.
Another example of a tier 3 service might be a service that pops up a message on your website when a customer first arrives, and offers to help them find something on your site. Those sorts of popups are useful, provide a customer service, and generate more business for you. But if the service that generates that popup is down, the impact to customers would be minor, and perhaps unnoticeable…since it was a nice to have not a required capability for using your site.
The lowest level of service is a Tier 4 service. A Tier 4 service is a service that, when it fails, causes no significant effect on the customer experience and does not significantly affect the customer’s business or finances.
A good example of a Tier 4 service is a the service that generates the weekly sales report for your company. Many managers in your company probably find that report important, but if they don’t get it Monday morning but rather get it Tuesday morning, it won’t have a significant impact on your business…an undoubtedly it will have no impact on your customers.
The same might be true with a service that sends out marketing emails. If you send out a monthly newsletter advertising products to past customers, if that service fails, then you may have to delay sending out the monthly newsletter. Yes, that would have an impact to you, but probably not a significant impact on the business and customer’s probably wouldn’t even notice the delay at all.
Amazon does not disclose much information on the size of any of the AWS services. However, in June of 2012, Amazon disclosed that S3 just reached a huge milestone by storing it’s one trillionth object. That’s one trillion objects. One million million objects.
Let’s try and put that into perspective with some comparisons.
This is equivalent to 142 objects for every man, woman, and child on the entire planet. Put another way, that’s 10 objects for every man, woman, and child who has ***ever*** lived, ever.
Or, a bit over three objects for every star in the Milky Way Galaxy.
That’s a lot of objects.
But how many objects does it store today? Amazon has not released any updated numbers, but given the growth of AWS as a whole since 2012, it’s not unrealistic to think this number may be multiple orders of magnitude higher than that.
AWS advertises a durability for S3 of 99.999999999%. That’s 11-9’s. Assuming that is accurate, that means of the one trillion objects stored in S3 in 2012, AWS would have lost at most ten objects a year.
That’s amazingly resilient.
I think it’s safe to say, without too much concern of exaggeration, that Amazon S3 is perhaps the most provably scalable, reliable, durable service ever built.
Which, of course, is why it continues to grow...and scale...