RTO and RPO
For many years, IT architects have been trying to determine what an application’s availability is (or should be). This factor is a key consideration in the design process. It is referred to as the Recovery Time Objective (RTO), which is the maximum amount of time an application can be unavailable. If the application is unavailable or malfunctions, data may be lost. We also design applications with this in mind. What is the maximum amount of data loss we can allow? This is called the Recovery Point Objective (RPO).
I always try to address these questions, but I’ve noticed that customers often don’t know the answer. The “business” side often determines this based on factors such as the financial loss incurred if the application is unavailable or in the event of data loss. The costs of achieving certain RTO and RPO values must be weighed against this assumed loss. This is something you need to discuss with the “business” side.
In most cases, the requirements for RTO and RPO are not that high. A good backup (and restore) is then sufficient to ensure that the application is back up and running within a few hours. Backup and restore is therefore the simplest of the four disaster recovery methods available. The most complex and expensive DR scenario is the multi-site approach. In this scenario, the application runs at two locations (two data centers, or in combination with a hyperscaler). The advantage of this is that such a setup enables much better RTO and RPO values.
So, what are all the different DR scenarios?
The first—and usually simplest—DR scenario is “Backup & Restore.” In this scenario, the restore takes the longest (several hours), and the RTO and RPO values are the highest (worst).
Second, there is the “Pilot Light.” With this approach, a basic setup (primarily the data) of the application also runs at another site. In the event of a disaster, this site can be brought online and scaled up. This is already faster than restoring from a backup.
Third, there is the DR scenario known as “Warm Standby.” The application “runs” at two locations. Failover can occur quickly, but the downside is that one of the two is always active unnecessarily, resulting in double the costs.
The final DR scenario is “Multi-Site.” In this scenario, the application is actively used on both sites, resulting in the shortest failover time. Both sites are actively used.
For the last three DR scenarios, data replication is required. Data must be available at both locations in the event of a failover.
Cost Reduction
Another topic that always comes up is rising costs—often in connection with the use of a cloud provider or hyperscaler. Costs often rise because so many resources are available, and the engineers and developers building applications aren’t directly confronted with the costs. Tight cost control is quite complicated and requires the cooperation of everyone involved. Agreements on when resources can be removed, for example, are very effective—what you don’t use doesn’t cost anything. As for the resources you do still use, it’s important to make the most of them. Right Sizing is the process of aligning the resources in use with what is actually needed.
Application Modernization
Although right-sizing resources is a smart approach, it says nothing about how the application utilizes those resources. Streamlining the application is necessary to ensure that it uses resources efficiently. This often falls under what is known as “ Application Modernization .” This term, however, encompasses a wider range of activities. Streamlining resource usage is one aspect, but it also includes updating the code or upgrading the runtime software. But if you’re tackling the application for one of these reasons, why not address the others as well?
If one wishes to reduce dependence on American (or commercial) software, it is also important to make different product choices—for example, opting for open-source software and choosing a European cloud provider. This, incidentally, is something that more and more companies are now considering.
Maintenance effort
As I have argued before, maintenance is one of the most important responsibilities of an IT department or IT company. However, the maintenance effort required for an application is not constant throughout the application’s lifecycle. In most cases, the maintenance effort almost always increases. Changes in software versions make upgrading increasingly difficult and, over time, even impossible. That is also why “decommissioning” is so valuable to an organization. Modernizing an application can be used to reduce the maintenance burden. In fact, that is the main reason why you do it.
Digital Sovereignty and Portability
In response to all the geopolitical developments, companies are looking to reduce their dependence on foreign technology. This is quite a hassle for many companies, as they had just finished migrating to a U.S. cloud provider or hyperscaler. If you want to be prepared and ensure that you remain in control of your data (Data Sovereignty) while guaranteeing application availability (Operational Sovereignty—collectively known as Digital Sovereignty), you’ll want to be able to move your application and data to another platform. That’s what we mean by portability. This ties in with the disaster recovery (DR) scenarios we discussed earlier. Increasing an application’s portability also relates to the “ Application Modernization.” My take on this is: design for all objectives from the start.
In addition to general portability, there are sometimes cases of specific data portability and software portability.
How so?
So how do you design for portability? By taking a layered approach to the design challenge, for example. The bottom layer is the data center or hyperscaler. This layer is specific; they can differ from one another. Services differ, networks are different, and so on. On top of this specific layer, you can build a platform, such as a Kubernetes cluster. That cluster is specific to the data center or hyperscaler on which it runs, but it’s generic for the application containers. If they run on one cluster, they can (in principle) also run on another. This third layer (the application) can therefore be generic. That is an important aspect of portability.
If data is also stored in the application, then data replication must also be arranged (I wrote about data replication earlier). Furthermore, these topics can be addressed during a round of “ Application Modernization.” This means these topics are interconnected.
"In short, my view on the matter is that we can achieve multiple objectives with a single design. By designing for portability on, for example, Kubernetes, organizations kill three birds with one stone: lower costs, better disaster recovery, and digital sovereignty." A well-thought-out architecture that serves multiple purposes.
Read more at SUE
Want to know how this works in your environment? On Application Modernization you can read about how SUE modernizes applications, and on Kubernetes, how we build clusters that run on multiple platforms. If you don’t want to manage the cluster yourself, there’s Managed Kubernetes.
You can read more about costs at Cloud Cost Optimization. You can assess your organization’s current status regarding data sovereignty with a Data Sovereignty Assessment. And we previously wrote about data replication in “Data Replication Is the First Step Toward Data Sovereignty.”
