Hello, and welcome back. My name is Tyler McMinn with Aruba, and this is our Cloud Basics video course. We're looking at the last video in Part 1, which is going to be moving applications to the Cloud. Without further ado, let's jump on it. In this section, we're taking a look at moving applications to the Cloud, and applications in a Hybrid or a Multi-Cloud environment are being considered. Before migrating legacy applications to Hybrid Cloud, we want to understand the difference between traditional legacy application architectures and Hybrid Cloud platforms. Hybrid Clouds have at least a private and a public Cloud side to the architecture. With Multi-Cloud architectures include more than just one private and public Cloud, you could have multiple providers for redundancy as well as multiple sites between them. Hybrid Clouds are often desirable because they can deliver the best of both the private and public Cloud infrastructures by lending the organization move workloads back and forth between the two platforms. Applications can be partitioned to reside in both public and private Cloud if they're written for that. Traditional client, server, or three-tier web applications, are generally going to be set up as stateful applications. Stateful applications keep information about the interaction between the client and the application in a session, and the session information is local to each server. This concept is known as the shopping cart problem. That's why typical load balancers will use session persistence. Session persistence is where users are going to be given a particular server and redirected to that server, because the application staple nature each new connection the user makes must return to server 1, where their shopping cart exist. Regardless of the load balancing algorithm, this is where the user ends up. This is necessary to maintain their existing shopping cart status. If the server goes down, the user from that server will not be directed to other servers, but they'll lose out on their shopping cart. Of course, not all applications will use shopping cards, but the concepts are basically the same when it comes to staple applications. For instance, a user must log in again when they are moved to another server. Now, let's look at Cloud Native applications. Cloud Native applications are written in a fundamentally different way. They are designed as stateless. They might use the load balancer but the servers are not sticky. In a Cloud data situation load balancer can send a request to any of the servers. If the user puts an item and a shopping cart, that information will be back-ended and shared across it state distributed and cash across the other servers. In general, Cloud Native applications, managed state external to the application, typically, through durable stores in order to pull this off. You can send a request to any of them and they'll handle it. Migrating applications. If you want to take a legacy stateful application, you've got this hurdle to get over which is that it may have been written specifically for a particular virtual machine and you would then have to migrate the VM and application as a full entity which could be hosted on a Cloud-based solution but it would rely on the hypervisor features like vMotion or live migration. Cloud Native applications and VMs are typically not tightly integrated. If one host fails, load balancers use surviving servers. There's no user impact. This allows for last. This is like Hadoop is a good example of that. Traditional apps and sticky servers. Elasticity, well, in a traditional application environment , servers are sticky. The load balancers use a session persistence. If the application experiences a surge in demand, you may want to spin up additional servers. The problem with session persistence is that only new users will be sent to the new servers, because the existing users must remain on their original overburdened servers. Thus, the user on the original servers will solve a bad user experience. Server overload spent on more servers, but servers are not used due to that sticky nature that statefulness. Cloud Native apps because of elasticity, servers get overwhelmed, you spend on more servers, and everything balances out on the backend. Overall, a good user experience for everybody. Services and microservices. SOA, or service oriented architecture, which is where a lot of modern applications are now moving to. Over time, these services become more and more granular and many Cloud Native applications are now being built as microservices through things like containers. Containers are just the bare minimum of what you need to script or run in order for that functionality to take place. A database service, a shopping cart service, a security service. Then access to and from these are available through Cloud provider tie-ins. Provider-specific APIs are very convenient and more difficult to move to a new provider using a Multi-Cloud, but they spin up. They're very efficient and very lightweight. So are much more economical and user-friendly. In a Hybrid or Multi-Cloud environment, we need to decide where to place which part of a workload. These decisions are very dependent on the situation. But a Cloud architect should be aware that there's a choice and that choice will influence the user experience. Based on the user experience, do you want to do a big data solution where you store data here to lower the cost or the UI here to reduce latency at Corp DC on-premise, or do you move like the mobile Cloud or a Salesforce? You want to put the front end in the UI in the provider Cloud and keep the database on-premise for security or for compliance reasons. We saw a slide like this in an earlier video. Then ultimately, some of the key tenants of moving applications to the Cloud, this concept of a rehost. Six main strategies on the list here for moving. Rehost is generally referred to as a lift and shift involving moving the workload from the current environment and deploying it onto the destination Cloud as a machine-to-machine move. It's very simple. It's very straightforward, but you might end up having to host a lot more resources than you necessarily need. If you just need to run Excel, it doesn't make sense that you have to install a complete baseline server and an operating system and then Office, and then you run your Excel application. If you can just run the Excel script or the Excel application on a container, or even an application as a service, software as a service, you could end up using a lot less resources. Replatform so a minor configuration change and a simple remediation. This is the application requiring minor config in order to migrate to up level OS or different but compatible platform. One sub strategy of this is referred to as partitioning, which leverages a Hybrid Cloud architecture parts of the application run on the premise. Other parts run on a Cloud as like a sales support system. The transactional part might be put into the public Cloud for economic reasons while the database and the user interface might be hosted in private Cloud for security reasons. The advantage of partitioning could be cost savings or enhance user experience. Part of the application you would run where it makes the most sense. The disadvantage compared to a lift and shift is that it takes a lot of extra work to partition what part of the app runs where while keeping the functionality intact. Refactoring, making minor application improvements, or major significant targeted changes to meet the Cloud requirement there. At replace, legacy apps are refactored. They're just not an opt-in, there's old. A full replace applies to technology that can't be remediated or refactored. Application may be replaced with software as a service or new applications. Instead of old host-based outlook e-mail, you might go with a corporate Gmail solution as an example. Retain, not suitable to migrate from current environment, and a fine-tune infrastructure required for the app to stay. These applications are not able to be migrated. There may be worked to fine tune or optimized, but ultimately, you're going to keep them On-premise. Then lastly, you might retire the application, which is a little like saying like, "Well, the way we get it to work is we fire it." They're no longer viable to use, and so you archive the app data and decommission. That is it. A summary of the factors that influence a migration workload to a Cloud environment. Infrastructure factors, overlay, and delay networks. The network latency, the peering, oversubscription issues, and differences between a traditional application. We talked about Cloud Native applications. Then strategies to move workloads to the Cloud environment were touched on here. Basically, we looked at the beginning of Part 1 here at Cloud products and technology. We looked at Network Management System and Orchestration. We looked at security and moving applications to the Cloud. What comes next is we are going to take a look at Aruba central monitoring, troubleshooting, working with Cloud applications and a quick dive into some other aspects of what ArubaCloud really means from a more nuts and bolts basis in Part 2 of our series of videos. Again, my name is Ben Tyler. I will see you guys in the second set of videos finishing off the next half of the last half. Thank you very much.
