Software Architecture Insights

In this episode, the hardest part of your cloud migration is moving your data to the cloud. Moving your data to the cloud, without suffering planned or unplanned downtime, can be a challenge.

I’m going to give you three strategies that will help you avoid downtime during the migration of your critical application data to the cloud.

And in Tech Tapas, we are going to take a look at what it means to fly two mistakes high, and how that relates to application availability.

Links and More Information

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

• 3 Strategies to Avoid Downtime When Migrating Data to the Cloud (https://blog.newrelic.com/engineering/migrating-data-to-cloud-avoid-downtime-strategies/)
• Modern Digital Applications Website (https://mdacast.com)
• Lee Atchison Articles and Presentations (https://leeatchison.com)
• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

Main Story - 3 Strategies to Avoid Downtime when Migrating Data to the Cloud

Moving your data is one of the trickiest parts of a cloud migration. During the migration, the location of your data can have a significant impact on the performance of your application. During the data transfer, keeping the data intact, in sync, and self-consistent requires either tight correlation or—worse—application downtime.

Moving your data and the applications that utilize the data at the same time is necessary to keep your application performance acceptable. Deciding how and when to migrate your data relative to your services, though, is a complex question. Often companies will rely on the expertise of a migration architect, which is a role that can greatly contribute to the success of any cloud migration.

Whether you have an on-staff cloud architect or not, there are three primary strategies for migrating application data to the cloud:

• Offline copy migration
• Master/read replica switch migration
• Master/master migration

It doesn’t matter if you’re migrating an SQL database, a noSQL database, or simply raw data files—each migration method requires a different amount of effort, has a different impact on your application’s availability, and presents a different risk profile for your business.

Strategy 1: Copy Data While Application is Offline

An offline copy migration is the most straightforward method. Bring down your on-premise application, copy the data from your on-premise database to the new cloud database, then bring your application back online in the cloud.

An offline copy migration is simple, easy, and safe, but you’ll have to take your application offline to execute it. If your dataset is extremely large, your application may be offline for a significant period of time, which will undoubtedly impact your customers and business.

For most applications, the amount of downtime required for an offline copy migration is generally unacceptable. But if your business can tolerate some downtime, and your dataset is small enough, you should consider this method. It’s the easiest, least expensive, and least risky method of migrating your data to the cloud.

Strategy 2: Read Replica Switch

The goal of a read replica switch migration is to reduce application downtime without significantly complicating the data migration itself.

For this type of migration, you start with your master version of your database running in your on-premise data center. You then set up a read replica copy of your database in the cloud with one way synchronization of data from your on-premise master to your read replica. At this point, you still make all data updates and changes to the on-premise master, and the master synchronizes those changes with the cloud-based read replica. The master-replica model is common in most database systems.

You’ll continue to perform data writes to the on-premise master, even after you’ve gotten your application migrated and operational in the cloud. At some predetermined point in time, you’ll “switchover” and swap the master/read replica roles. The cloud database becomes the master and the on-premise database becomes the read replica. You simultaneously move all write access from your on-premise database to your cloud database.

You’ll need a short period of downtime during the switchover, but the downtime is significantly less than what’s required using the offline copy method.

Strategy 3: Master/Master Migration

This is the most complicated of the three data migration strategies and has the greatest potential for risk. However, if you implement it correctly, you can accomplish a data migration without any application downtime whatsoever.

To begin, create a duplicate of your on-premise database master in the cloud and set up bi-directional synchronization between the two masters, synchronizing all data from on-premise to the cloud, and from the cloud to on-prem. Basically, you’re left with a typical multi-master database configuration.

After you set up both databases, you can read and write data from either the on-premise database or the cloud database, and both will remain in sync. This will allow you to move your applications and services independently, on your own schedule, without needing to worry about your data.

At the completion of your migration, simply turn off your on-premise master and use your cloud master as your database.

It’s important to note, however, that this method is not without complexity. Setting up a multi-master database is quite complicated and comes with the risk of skewed data and other untimely results. For example, what happens if you try and update the same data simultaneously in both masters? Or what if you try to read data from one master before an update to the other master has synchronized the data?

As such, this model only works if your application’s data access patterns and data management strategies can support it. You’ll also need application specific synchronization and sync resolution routines to handle sync-related issues as they arise.

If your application, data, and business can handle this migration method, consider yourself fortunate and use it. It’s the cleanest and easiest of the three strategies.

Mitigate migration risks

Any data migration comes with some risk, especially the risk of data corruption. Your data is most at risk while the migration is in progress; swift and determined execution of the migration is critical. Don’t stop a migration until you have completed the process or you have rolled it back completely. And never stop a migration halfway through—half-migrated data isn’t useful to anyone.

Risk of data corruption is especially high when migrating extremely large datasets. Offline data copy and transfer tools such as AWS Snowball can help manage the migration of large quantities of data, but they do nothing to help with your application’s data usage patterns during a migration. Even if you use a transfer device such as Snowball, you’ll still need to use one of the migration strategies described above.

Tech Tapas — Two Mistakes High

I fly model R/C airplanes. There is an expression we use in that hobby while you are learning to fly. It is “keep your plane two mistakes high”.

What does it mean to “keep two mistakes high”?

Well, when you are flying, and you are doing some maneuver, such as a stunt of some sort. If you make a mistake, the result is your plane will typically lose some altitude.

Now, while you are recovering from that mistake — and you are now lower in altitude — what happens if you make another mistake? If your plane isn’t high enough to recover from the second mistake...well...it’s bad news for you and your plane...

You always want to be high enough so you can recover from a mistake, even while you are recovering from a mistake... You always want to stay high enough so you don’t crash, no matter what goes wrong.

This is where the expression “keep two mistakes high” comes from. You always want to perform stunts high enough so that if you make a mistake, you have room to recover even if you make a mistake during the recovery.

This is a good analogy for maintaining availability in our most critical modern web applications. Keeping two mistakes high in our critical modern applications means that even when something is going wrong with our application, you want to be able to keep your application running reliably enough so that you can afford for something else to go wrong while you are still recovering from the main problem.

This applies to many different aspects of modern application availability planning, from dealing with hardware failures, to data redundancy, to capacity planning, to performing retries in your inter-service API calls, to risk management and disaster planning.

Keeping “two mistakes high” is a lesson about redundancy. It’s a lesson about availability, and it’s a lesson about resiliency. It applies to model aviation, and it applies just as effectively to modern application development and operation.

In future episodes of Modern Digital Applications, I will be using this principle in giving you guidance and suggestions to keeping your critical modern applications operating.

Google Cloud Next is coming to the Moscone Center in San Francisco from April 6 until April 8. This is Google’s big cloud event of the year.

Links and More Information

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

• Announcement — Google Cloud Next (https://cloud.google.com/blog/topics/google-cloud-next/join-us-at-google-cloud-next-2020)
• Registration — Google Cloud Next (https://cloud.withgoogle.com/next/sf)
• Use code GRPABLOG2020 for $500 USD off a full price ticket.
• Modern Digital Applications Website (https://mdacast.com)
• Lee Atchison Articles and Presentations (https://leeatchison.com)
• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

Special Report

Hello everyone and welcome to Modern Digital Applications. This is just a very quick news break...

Those of you using Google Cloud will want to hear this. Google Cloud Next is coming to the Moscone Center in San Francisco from April 6 until April 8. This is Google’s big cloud event of the year.

According to the information provided by Google: Google Cloud Next brings together a global cloud community of leaders, developers, and influencers to help you get inspired and solve your most pressing business challenges.

If you would like to attend, check out the show notes for a link to the registration page. Also in the show notes is a code that is good for $500 off a full price ticket.

You can expect that Google will have a host of new product announcements around this time, so even if you don’t attend, listen up in April for more news from Google Cloud.

In this episode, we conclude 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 a look at the very first AWS service. Any guess what that service is?

Finally, what does redundancy look like in outer space? And just how effective was the space shuttle application systems at keeping the shuttle safe?

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)

Main Story

How to Use Service Tiers

So, now that we’ve defined service tiers, how do you use service tiers?

Service tiers have two distinct uses. Helping determine required responsiveness to problems, and requirements for dependencies between individual services.

Responsiveness

Let’s first talk about responsiveness. The service tier level of a service can be used to determine how fast or slow a problem with a service should be addressed. Of course, the higher the significance of a problem, the faster it should be addressed. But, in general, ***the lower the service tier number, the higher importance the problem likely is…and therefore the faster it should be addressed***. A low-to-medium severity problem in a Tier-1 service is likely more important and impactful than a high severity problem with a Tier-4 service.

Given this, you can use the service tier, in conjunction with the severity of the problem, together to determine how fast of a response your team should have to a problem. Should we be alerted immediately, 24 hours a day, 7 days a week and fix the problem no matter what time of the day or night? Or is this a problem that can wait until the next morning to fix? Or is it a problem we can add to a queue and fix it when we get to it in our overall list of priorities? Or should we simply add it to our backlog for future consideration? Service tiers, in conjunction with problem severity, can give you the right procedural guidelines for how to handle a problem. You can use them to set SLAs on service responsiveness. You can even use them to set availability SLAs for your services.

For example, you could create a policy that says that all Tier 1 services need to have an availability of 99.95%. This might dictate that all high severity problems must be resolved within 2 hours of identification, meaning that you must have an on call support team available 24 hours a day, 7 days a week and that support team must have enough knowledge and experience to fix any serious problems that arise. This would likely mean the owning development team would need to comprise the support rotation for this service.

Meanwhile a Tier 3 service might be able to have an availability SLA of only 99.8%. A Tier 4 service might not even have an availability SLA. This would mean that all but the most serious problems could probably wait until the next business day to be fixed, meaning an on call support role may not be needed, or may not need to be as formal or have tight mean time to repair goals.

Service Tiers help set policy on responsiveness requirements for your services, which can then dictate many requirements for your other policies and procedures.

Interservice Dependencies

Now, let’s talk about how service tiers can help with inter service dependencies. Given that services at different service tier levels have different responsiveness requirements. This impacts your dependency map between services and assumptions you can make about your service dependencies.

For example, if a Tier-4 service, a low priority service, makes a call to a Tier-1 service, a high priority)service, then it probably is safe for the Tier-4 service to assume that the Tier-1 service will always respond and will always be available. If for some reason the Tier-1 service does not respond, it would typically be acceptable for the Tier-4 service to simply fail itself. After all, if a Tier-1 service for your application is down, significant efforts will be immediately put into place to try and resolve that service problem. The fact that a Tier-4 service is also down will not be of any significant consequence.

Think of the case where your web application is down because users cannot log in…this would be a Tier 1 service problem. In such a situation, how concerning will it be that the marketing email service is down, delaying the delivery of your day’s marketing emails? The marketing email service is a Tier-4 service problem, so it is dwarfed by the Tier 1 login problem.

But the reverse is not true. If a Tier-1 service depends on a Tier 4 service, , then that Tier-1 service ***must*** ***have*** developed contingency plans and failover recovery plans for when that Tier-4 service might be down. After all, you don’t want a Tier-1 service to fail simply because a much lower priority Tier-4 service is not functioning.

As an example, let’s say you have a Tier-1 web application running. The web application displays the current customer’s avatar in the upper right hand corner whenever they are logged in. It does this by calling the customer avatar service, which is likely a Tier-3 service. After all, if you cannot display the avatar, it really has no significant impact on the customer’s experience.

So, what happens to the Tier-1 web application if it tries to get the customer’s avatar from the Tier-3 avatar service, and the Tier 3 service is down? In this case, it would *not*, under any situation, be acceptable for the Tier-1 application to fail simply because the avatar service was failing. Instead, the Tier-1 service, when it calls the avatar service, should have safe guards in place in order to handle service failures. It should have contingency plans in place for what to do if the tier-3 service call fails. In this case, the web application can simply not show the avatar.

The web application can simply not show the avatar if it is not available. But it would not be acceptable for the entire application to fail simply because it couldn’t display the avatar!

This may sound like an unrealistic example, but I actually saw this happen once, with a company that was not paying attention to service levels. They had a SaaS application that went down and was completely unavailable to their customer’s, simply because they could not load the customer’s avatar due to a problem in the external avatar service. It was an embarrassing problem for them to admit.

Therefore, it is not acceptable for a Tier 1 service to fail simply because a dependent Tier 3 service is unavailable. Instead, the Tier 1 service should be built in such a way that it can work around and deal with failures of the Tier 3 service.

So, we can see that Service Tiers can be used to determine the criticalness of inter service dependencies. If a lower priority service, such as Tier 4 service, depends on a higher priority service, such as a Tier 1 service, then the Tier 4 service can generally ignore failures of the Tier 1 service. But the reverse is not true. If a higher priority service, such as a Tier 1 or 2 service, depends on a lower priority service, such as a Tier 3 or 4 service, then the Tier 1 or 2 service must be written to handle and managed failures of the lower priority dependent service.

This is the power of service tiers.

Tech Tapas - First AWS Service

What was the first cloud service that Amazon put out as part of Amazon Web Services? The first cloud service was the Simple Queue Service. The Simple Queue Service, or SQS, is still available today. It provides a message queuing system for delivery of messages between loosely connected application components. SQS was launched publicly in November of 2004. AWS was relaunched in March of 2006 as a combination of three initial services: SQS, the S3 object storage service, and the EC2 virtual server service. These were all very early implementations. The EC2 instances had no persistent storage attached, so they could not be used to build persistent storage systems, such as relational databases. The services were also all exposed to the public internet, so there was no security available for any of the services. The EC2 instances were openly vulnerable on the public internet.

EC2 didn’t get persistent attached storage until EBS was launched in 2008. It didn’t get private network security until VPC launched in September of 2009. It was after those two capabilities were added that EC2 became a viable option for application computation, and cloud computing took off with a vengeance. 

Tech Tapas - Space Shuttle Redundancy

One requirement of modern digital applications is that they must maintain a high degree of resiliency...resiliency to failure. The ability to stay operational even in adverse conditions, and the ability to successfully recovery easily and quickly when problems do occur in a manner that reduces or eliminates the impact on the end user is critical to modern digital applications.

There is an older, yet great example of building high level of resiliency into a complex software application. That is the United States Space Shuttle program. The United States Space Shuttle is a program that ran from 1981 to 2011.

The space shuttle program had its problems, disastrous problems. But there was one aspect of the program that worked incredibly well...their computers and software systems.

The computer systems aboard the space shuttle were state of the art when they were built. They had to be. A failure of the software on board the space shuttle would be disastrous. It was critical that the software not fail.

To that end, a sophisticated system to maintain availability and reliability was employed. Let’s take the main computer system. There were four identical, redundant copies of the main computer aboard the shuttle. They consisted of identical hardware, identical inputs and outputs, and ran an identical copy of the software. Every computation the computer had to make, was made simultaneously but independently by all four computers. The results of the four computations were then compared, and the results were expected to be the same from all four computers. If they were, all was well.

If, however, the results differed among the computers, then the four computers voted on which result was correct. The winning result was used, and the computers that generated the losing results were disconnected and turned off for the duration of the voyage. The losers were disabled. This is what I call the ultimate in democratic voting!

The space shuttle could operate with as few as two computers operating, but the mission might be changed or shortened. But as long as two of the four computers were operating, the shuttle could be operated safely.

What happened if the computers voted and the result was a tie? Well, then a fifth computer system was consulted. This system was a very different computer...a much simpler one. It had software for only the most critical calculations, and that software was written and the hardware was built by completely independent teams than the ones that built the main computer. That way, a problem that caused the main computers to fail, would not likely impact this fifth computer. If the main computers voted, disagreed, and tied, then the fifth computer would become the tie breaker.

During the 30 year operation of the space shuttle, there was never a case where a serious life threatening problem occurred that was a result of a software problem, even though the software was the most complex software ever built for a space program at the time.

It was a sophisticated system for high availability, especially for the 1970s when this system was first built. But sometimes its useful to look at older techniques, such as this, when deciding how to build and operate modern digital applications.

We will be talking about the space shuttle software system in more detail during a main story in a later episode.

Amazon recently announced a reduction in the cost of their Elastic Kubernetes Service. They lowered the cost of the Amazon EKS service by 50%. The new pricing is greatly appreciated, but is still a barrier to entry in using the EKS service for small clusters.

Links and More Information

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

• AWS EKS Pricing (https://aws.amazon.com/blogs/aws/eks-price-reduction/)
• AWS EKS (https://aws.amazon.com/eks/)
• AWS ECS (https://aws.amazon.com/ecs/)
• Modern Digital Applications Website (https://mdacast.com)
• Lee Atchison Articles and Presentations (https://leeatchison.com)
• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

Special Report

Amazon recently announced a reduction in the cost of their Elastic Kubernetes Service.

As of January 21, 2020, the price of Amazon EKS will be lowered by 50%. The previous price for using the EKS service was 20 cents per hour for each Kubernetes cluster managed. This works out to approximately $144 per month. The new price for running an EKS cluster will now be 10 cents per hour, which works out to approximately $72 per month.

It should be noted that this is the price necessary to operate the cluster, regardless of the number of workers contained in the cluster. You must still pay for the computation costs — either EC2 instance hours or Fargate compute resources — in order for the cluster to be useful. The cost reduction is for the “overhead” cost of maintaining the cluster, which covers the Amazon cost of managing the cluster.

This price has always been an issue with the EKS service. The non-Kubernetes Amazon container management service, ECS, does not have this overhead cost — all you pay for is the cost of running the workers. Only EKS has this overhead. So, the reduction of this overhead cost should be seen as significant reduction in the barrier to entry in using the EKS service.

While I applaud AWS for taking this step, I still believe this overhead cost is too high. It still makes EKS less attractive than ECS for small clusters. The cost is not an issue for large clusters, since you can amortize the cost out over the size of the cluster. But if you run a large number of small clusters, this overhead cost can be significant. For example, if you are running 100 clusters, the overhead cost is around $87,000 per year. Overhead. Now that’s a lot less than the $175,000 it was before the price change, but it’s still quite a bit of overhead.

That said, I applaud AWS for making this price change. It’s a consistent strategy they use — pass on cost savings to their customers as their costs go down due to volume. It’s a strategy very much appreciated by their customers.

A link to the announcement is given in the show notes, along with a link to the EKS and ECS services.

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)

News

Links to stories mentioned in the news section:

* DevOps World (https://www.cloudbees.com/devops-world)

Main Story

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.

Tier 3

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.

Tier 4

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.

Tech Tapas

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...

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.

Modern Digital Applications is a podcast focused on helping corporate decision makers, executives, and architects create or extend their digital business with the help of modern applications, processes, and software strategy.

The podcast is hosted by Lee Atchison, a recognized industry thought leader and pundit in cloud computing. Lee has over 30 years industry experience, and has been working on cloud computing since the early days of the cloud. Lee has committed his career to architecting and building high scale, cloud-based, service oriented, SaaS applications. He has a specific expertise in building highly available systems.

Lee has consulted with leading organizations on how to modernize their application architectures and transform their organizations at scale; including optimize for cloud platforms, utilize service-based architectures, implement DevOps practices, and design for high availability. This experience led him to write his book Architecting for Scale, published by O’Reilly Media. 

Lee is an industry expert and pundit and is widely quoted in publications such as InfoWorld, Diginomica, IT Brief, Programmable Web, and CIO Review. He has been a featured and keynote speaker at events across the globe from London to Sydney, Tokyo to Paris, and all over North America.

In each episode, Lee will give you insights into some aspect of building, modernizing, or scaling your digital applications, and the teams and culture that drive them.

The podcast episodes will contain feature stories, new and noteworthy industry information, and some Tech Tapas, little bits of technology knowledge and data. We’ll also feature interviews with technology experts and other industry pundits. Each episode is designed to be short and concise, easily digestible on a single morning commute trip.

This is ... Modern Digital Applications.

• Lee Atchison Articles and Presentations
• Architecting for Scale — O’Reilly Media
• Modern Digital Applications Podcast