#Mirroring

Migrating InterSystems IRIS and InterSystems IRIS for Health from on-premises to the cloud offers many advantages for Application Providers and Solution Providers. These advantages include simplified operations, access to flexible resources, and enhanced resilience. Companies no longer need to worry about the physical constraints and expenses associated with maintaining on-prem infrastructure, such as power and space requirements and expensive computer hardware.

One of the most compelling benefits is the ability to accelerate speed to market. By removing the burden of infrastructure maintenance, cloud environments enable faster development and deployment cycles, allowing businesses to respond quickly to market demands and opportunities. Operational costs are also lowered, because companies can scale resources up or down based on actual needs, leading to more efficient use of capital. Moreover, migrating to the cloud can contribute to a reduced carbon footprint by optimizing energy usage through shared cloud infrastructure.

Transitioning to the cloud may involve significant changes. Companies may benefit from a more operational focus, managing and optimizing cloud resources continuously. This shift may require changes to business models, reconsideration of margins, and strategies for scaling operations up or out. While requiring more investment, embracing these changes can lead to improved agility and competitive advantage in the marketplace.

Background

For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.

Unfortunately the built-in storage classes in most Kubernetes implementations (whether cloud or on-prem) do not provide this capability:

A step by step implementation path to a cross regional stretched IrisCluster with Mirroring using the Intersystems Kubernetes Operator (IKO), Google Cloud Platform, and Tailscale.

I am giving this distraction the code name "Compliment Sandwich" for a reason yet to be realized, but I'd rather the community go right for the jugular shooting holes in a solution that implements wireguard based connectivity for our workloads in general, as I would like to refine it as a fall project leading up to KubeCon in Atlanta and if I miss the mark, Ill get it done before Amsterdam.

Mirror Your Database Across the Galaxy with Seeding

Hello cpf fans! This distraction I used the "seed" capability in IRIS to provision an entire IrisCluster mirror, 4 maps wide with compute starting from an IRIS.DAT in a galaxy far far away. This is pretty powerful if you have had a great deal of success with a solution running on a monolithic implementation and want it to scale to the outer rim with Kubernetes and the InterSystems Kubernetes Operator. Even though my midichlorian count is admittely low, I have seen some hardcore CACHE hackers shovel around DATS, compact and shrink and update their ZROUTINES, so this same approach could also be helpful shrinking and securing your containerized workload too. If you squint and feel all living things around you, you can see a glimpse of in place (logical) mirroring in the future as a function of the operator and a migration path to a fully operational mirrored Death Star as the workload matures.