Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
At work, but not for production apps
I don’t use WebAssembly but expect to when the technology matures
I have no plans to use WebAssembly
No plans and I get mad whenever I see the buzzword

Why Developers and Ops Engineers Love ‘Continuous Restore’ 

Operators have a disaster recovery solution that provides policy-driven, near-instantaneous recoverability. Developers can spin up test environments with production data in seconds.
Oct 11th, 2022 4:00am by
Featued image for: Why Developers and Ops Engineers Love ‘Continuous Restore’ 
Image via Pixabay.

This is part of a series of contributed articles leading up to KubeCon + CloudNativeCon on Oct. 24-28.

Every organization understands the importance of having a reliable disaster recovery (DR) system to protect its applications and data. That’s because the cost of a business interruption from application failure, power or connectivity outages, or even for criminal acts like ransomware are too great to bear. In fact, the recent rise of ransomware attacks (a 97% increase in 2021 over 2020) has increased the urgency of enterprises to have DR systems and processes in place because they may need to recover their entire organization if they are victimized by an attack.

Unfortunately, most DR approaches commonly used today are expensive or slow, or both.

There Are Two Common DR Paths Most Organizations Walk

Until now, organizations have relied on two common DR approaches. The first, “synchronous replication,” involves backing up applications and data to a “mirror” data center — that is, an exact replica of the original data center: same platform, same storage volumes — in a second location. This approach requires expensive hardware contracts with vendors, dedicated dark fiber between the sites, which limits the distance between sites, and dedicated personnel to maintain. (Read: expensive.)

The second option is asynchronous replication, which can stretch much longer distances than synchronous replication, but results in lags in data. The remote site might be a few minutes to hours behind the production site. Asynchronous replication delivers the better recovery point objective (RPO) — the maximum amount of data as measured by the time that can be lost after a recovery from a disaster — and the best recovery time objective (RTO) — the amount of real-time a business has to restore its processes at an acceptable service level; however, it has the same drawbacks as synchronous replication-based solutions. At best, these solutions can work between two homogenous sites, but extending them to multiple sites — much less multiple heterogeneous sites, which is the real world for most enterprises — is practically impossible.

This problem can be solved with a technology we at Trilio call Continuous Restore, and it’s a technology that both operators and developers will love.

Continuous Restore is a data replication solution that enables users in cloud native environments to continuously stage data at multiple and heterogeneous sites/clouds. This means that applications, regardless of where they reside, will be able to tap into that data and be brought online instantaneously. With Continuous Restore, the backup data is continually updating the restore clusters. If you need to restart an application on a cluster in a new cloud region, the data is already there.

It’s no wonder ops engineers love Continuous Restore.

Continuous Restore completely changes the DR landscape, offering:

  • Near-instantaneous recoverability — Operators are able to achieve availability objectives and recover from outages or failures in a matter of seconds or minutes rather than days or weeks. Using Continuous Restore, recovery time objectives will improve by over 80% versus traditional methods.
  • Policy-driven — The user can set policy on how many copies of backup data need to be staged and where.
  • Easy to implement — Continuous Restore is available in our own TrilioVault for Kubernetes v3.0, and we’re confident others will figure it out soon enough. You can find it with a click on popular cloud marketplaces (Red Hat, AWS).
  • Cost-effective — The user incurs merely the cost of additional generic storage (Amazon EBS) for the backup clusters.
  • Prudent and agile — Organizations can test their DR systems continually instead of once a year to make sure they are ready for a disastrous event.

Developers Love Continuous Restore Too

With Continuous Restore, developers can increase the velocity of CI/CD pipelines by staging data for multiple test/dev environments. These test/dev environments can be spun up in seconds with continuously replicated production data. This removes a huge amount of work from developers’ plates and improves the overall developer experience.

Typically, to execute blue/green testing, developers have to write numerous scripts to create a blue test environment, including making a dummy copy of the production data with which to test the new version of their code. Thus, standing up a blue test environment can be tedious and time-consuming. Continuous Restore changes this.

Continuous Restore eliminates all that manual script-writing work required to create a blue environment, instead offering a simple “click-to-deploy” test environment on a separate cluster that already has access to near real-time copy of the production data (not dummy test data). This means the test itself is likely more predictive of actual future performance, ultimately leading to the release of more stable and reliable code. Furthermore, DevOps teams can use Continuous Restore to test their “restore” protocols to ensure that the restore will work when needed increasing the level of data resiliency.

How Continuous Restore Got Its Name

Operators and developers embrace Continuous Restore because it changes the game for both, bringing powerful capabilities, speed and ease of use to the complete CI/CD pipeline. Operators have an easy-to-implement, cost-effective DR solution that provides policy-driven, near-instantaneous recoverability. Developers can spin up test environments in seconds using production data — no more script-writing, no more dummy data.

In fact, Continuous Restore makes backup, testing and rapid reallocation of cloud native workloads integral to the “continuous” nature of the DevOps workflow. The alternative is something that’s occasional and/or expensive — two things that are becoming increasingly untenable in cost- and performance-intensive IT operations. So it may be time for a new initialism: CI/CD/CR — continuous integration, continuous deployment, Continuous Restore.

To learn more about how Trilio approaches Continuous Restore, visit Trilio at KubeCon NA.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.