Join David Linthicum for an in-depth discussion in this video Map requirements to storage, part of Cloud Architecture: Design Decisions.
- [Instructor] Okay, let's talk about the details now. Let's talk about what it takes to map our requirements down to cloud storage for the purposes of architecture. So what's important here is that it's really a matter of facts and figures, backing the right solution into those requirements. So it comes up to how much storage we need, what kind of performance does that storage need to provide us? How is it gonna be coupled to the workloads of the applications? And we take all this into account when we pick a storage solution.
However, make sure to consider other factors, such as performance and security, because there's always external things that come to play when we look at storage, whether it's leveraged by a database, whether it needs to be secured, whether it needs to deal with encryption, whether it has high performance I/O systems on it, purpose-built for memory-based computing. All these things basically come into play here. So it's not only just numbers and figures. That's the core of it.
It is the external requirements that we see that make all the difference. Keep in mind that multicloud storage deployments work just fine. And so if for some reason we decide that we're going to get some of our storage from Amazon, some of our storage from Microsoft, and some of our storage from Google, that's perfectly fine. We can mix and match the storage. We can make sure that the workgroups are coupled to the correct storage instances. We can pick the best performance, pick the best price.
And so you can do cloud to cloud, workload to storage. You can have one workload talk to many clouds and many different storage systems, really kind of mix and match to meet your requirements. This doesn't mean you're forced to leverage that. This just means that those capabilities are there for you. So consider capacity, storage models, speed, disaster recovery, application interfaces, growth model, management, and security.
And so let's break these down a bit. In capacity we have the gigabytes needed for production. The storage models, we have object, block, and file-based storage that are available to us. Speed, we have response time, I/O. Disaster recovery, we have active/active, the ability to, in essence, set up storage systems that are always functioning and, therefore, always redundant. Active/passive means that we have some that are always functioning and some we're able to start up when we need them.
API and services. Gigabyte growth over time, very important because we have to remember that you're storage is typically gonna grow exponentially over time, and you need to make sure you have the capacity to support the storage needs. Cost of storage, the ability to do updates, the ability to do configuration changes, and then security, such as identity access management and, of course, encryption. So keep in mind that all of these become the requirements. We fill out all those little boxes with what we need, and that backs us into the particular cloud systems or cloud configurations that we're going to pick.
And so, again, this could be all Amazon Web Services. This could be all Microsoft. This could be all Google. Or it could be a mix of all of the above or sometimes additional clouds or special purpose clouds or vertical clouds that we're able to leverage for our storage needs. So the sky's the limit. And the ability to look at your options out there and make sure you leverage the correct storage technology for the business requirements that you're looking for is really kinda how you win the game of storage.
- Advanced architecture concepts
- Building a business case
- Defining storage, processing, and other requirements
- Mapping requirements
- Performance and security