devopsy.kinsta.cloud

Tag: data portability

  • How Dispersed Can We Be?

    How Dispersed Can We Be?

    It is interesting to consider DevOps from the storage perspective. DevOps in general—and specifically newer development and deployment models—tried to pretend that long-term storage was not a necessary component of software delivery. In short, it appears that because there wasn’t a good answer to long-term state in stateless development models, the storage and databases that used state were hand-waved away. Which, of course, failed. Container deployment models did the same thing and failed just as miserably. Oh, containers didn’t fail, but the attempt to ignore persistent storage did; from the very beginning, it was clear that was going to happen. We were doing early container implementations and working through how to ensure that containers ABC had access to the same shared storage. That need never went away and was never going to. Apps can run without persistence, but business doesn’t run without persistent data.

    Checking out the wave of cool new products like, for example, Ionir (disclosure—I know more about them simply because I’m friends with their CMO. Other vendors likely have good solutions, too) makes me realize the answers that we needed were right in front of us. And not just the answer to persistent storage, but to storage portability, which has been a problem from the beginning of the cloud. Data gravity is the idea that data holds apps in place. Tools like Ionir reduce the gravity of data. A lot. They can’t get rid of data gravity, because some platforms charge for data storage, data ingress and egress, etc. but that becomes a TCO operations problem rather than a near-insurmountable tech problem.

    But just as interesting is this: What if the slow but steady increase in core Internet speeds will allow us to access data from anywhere? We could do that now, but performant applications struggle if you force them to leave cloud A and go to your data center or to cloud B to get a dataset. Yet we use APIs that do just that on a regular basis. What are Google Maps and Google Places if not simply big old honking databases? And yet we call out to them from just about every platform.

    So, it’s worth trying out and seeing if the idea of data gravity is maybe an obsolete idea for you. For some applications that really do need super-fast response times, the concept is still relevant. But for many applications? Where your app sits in relation to data may not be as important as you think. Write or grab an API wrapper for a critical dataset and throw a simple test app up on a different platform. See what you get. If it performs well, consider putting apps where it makes sense and using a wrapper API with secrets to grant access to data from any validated app.

    Some of you are doing this already. Not many, but it’s out there. Excellent job; keep rolling!

    Everyone else is kicking rear and taking names, with the world still online every day because of your collective work. So keep rocking it, but consider if you really need the application close to the data these days and, if you do, how data mobility tools might facilitate moving data to the app—something most of us would not have considered for large datasets before the last year or so.

  • The Benefits of an IaC Approach to Storage

    The Benefits of an IaC Approach to Storage

    Adopting an IaC approach to storage offers freedom from storage infrastructure considerations

    Today’s multicloud world allows you to move applications and/or functions between clouds depending on your needs, but it also puts you in the position of having to understand the different storage requirements of each cloud provider. These providers have their own unique storage offerings and parameters, which differ not only from each other but also from storage being used in private cloud deployments.

    Infrastructure as code (IaC) can be invaluable in navigating this multicloud environment. Over the past couple of years, IaC has become well-known in application development as a type of IT infrastructure that can be managed and provisioned automatically using a common template.

    The same basic principle can be applied to the way you approach storage across clouds. With IaC, your applications can consume storage in a consistent manner across all environments and providers so you don’t have to worry about the specific infrastructure aspects of each cloud platform. It offers an abstraction layer that essentially eliminates inconsistencies in the ways various providers handle storage while gaining a consistent set of interfaces that help you manage applications across clouds.

    IaC and Storage

    Here are three ways IaC can help you leverage different clouds to your advantage, regardless of their storage requirements.

    Freedom to Move

    One of the things that make multicloud environments so great is being able to take advantage of the unique benefits of different clouds, particularly as your needs and business requirements change. For example, it may be more cost-effective to host certain functionality in one cloud over another during peak hours, and then move that functionality back to a different cloud in off-peak times.

    With an IaC approach, you can have greater application portability so you can move applications across clouds or regions. You won’t be encumbered by specific infrastructure components or physical locations. You can transfer workloads as necessary. The abstraction layer can enable you to manage those workloads in the same way across all clouds.

    You can also protect your data by automatically replicating copies of object data across multiple clouds. If one copy is compromised, the data will continue to be available in other locations. You’ll have the resiliency to keep your applications running without interruption.

    Freedom to Keep Your Data Close

    Data gravity can improve performance by decreasing latency. This is especially important for applications that need fast access to data or depend on large data sets. The closer the data is to the application, the better that application can perform.

    To maintain performance, you must be able to move your data along with your applications. The abstraction layer enables you to do this because it removes the barriers and various data parameters that exist between different cloud providers. You can migrate your application’s data along with the application itself.

    Freedom to Scale

    You may be employing a number of different size workloads and storage types for various applications–traditional file storage for smaller workloads or object or block storage for larger and growing datasets, for example. Regardless of what you have today, you’ll want the freedom to scale out your storage as business needs change. The abstraction layer enables you to embrace a diversity of workloads without worrying about whether they’ll be supported in a particular cloud environment. You can also repatriate your applications back on-premises if the costs of using a public cloud become too exorbitant or if your security or performance needs change.

    Yet you can’t put a price on flexibility, which is instrumental to modern agile software development. You need the flexibility to move between clouds with ease. Adopting an IaC approach will give you the freedom to let go of storage infrastructure considerations and focus your energy on developing the best applications possible.