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 (https://mdacast.com)) Lee Atchison Articles and Presentations (https://leeatchison.com (https://leeatchison.com)) Architecting for Scale — O’Reilly Media (https://architectingforscale.com (https://architectingforscale.com)) How Service Tiers Can Help to Avoid Microservices Disasters (https://thenewstack.io/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 (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...