Join David Linthicum for an in-depth discussion in this video Map requirements to storage, part of Cloud Architecture: Design Decisions.
- So now let's get into the meat and potatoes of this, and so we'll talk first about mapping requirements to storage. In other words, how to deal with your own requirements and how they map into actual storage solutions, what process do you go to make that happen? We'll dig into the details, so follow along. So in capacity, you need to figure out gigabytes needed for production. In other words, that's it, so what is the gigabytes that we have as the as-is state, and also think about to-be state, that we need to leverage as we deploy our storage systems.
Next you need to think about the storage models, are we going to leverage object, block, file? Speed, any response time, I/O. In other words, what kind of performance do we need for our storage systems? Are we going to communicate via the application in the storage system intracloud? In other words, we're going to go within the cloud network. Or this is going to be intercloud, meaning we communicate with another cloud brand, such as Microsoft communicating with AWS. Also disaster recovery, are we going to support active/active, the ability to have two systems up and running all the time, able to take over for each other? Or active/passive, where we're able to fire up another system and get it up and running if our existing primary system goes down? And then application interfaces.
APIs and services, how are those going to be leveraged? Growth model, growth of GB over time, cost of storage, so again, what's the to-be state? How big is this going to be in the next one year, two year, five years? And are we able to keep up with the capacity demand within the cloud-based storage platforms we picked? Management, including updates, configuration changes, and then finally security, identity access management, encryption, all those things need to be considered.
So, the idea is to take all these requirements as we defined them, and then map them into a physical brand of cloud, and the choices typically are going to be AWS, Google, Microsoft, there could be others, could be IBM, could be a private cloud, could be a managed service provider, or other ideas that you have as outsourcing these various systems. Or in some cases, it may be you mapping this to a hybrid cloud or a pragmatic hybrid cloud, where we're dealing with legacy systems that are paired with public clouds, or private clouds that are paired with public clouds.
So, lots of things to consider when considering storage but if you go by what's on the left hand side of this chart, and able to answer each one of those boxes and pick each one of the options that are there, you really can't go wrong.
This course is targeted at IT professionals who have a basic understanding of the cloud and are ready to move on to creating a cloud architecture. David Linthicum begins with the business case and requirement patterns, and then moves onto mapping requirements to individual architecture concepts. There are multiple aspects to consider: storage, processing, governance, management and monitoring, security, performance, and more. David also includes discussion of advanced topics such as serverless architectures and containers. Watch and learn how to make sense of today's requirements, and plan your cloud-based architecture to scale with what your company needs to succeed tomorrow.
- Advanced architecture
- Building a business case
- Defining storage, processing, database, and other requirements
- Mapping requirements
- Performance and security