WHITE PAPER Make the move without making mistakes 1
Introduction The cloud is a nebulous concept, literally. Moving to the cloud is not as straightforward as moving a data center from San Francisco to San Jose. In that scenario, you have physical control of both locations and can assume or ensure that they use the same power outlets, Ethernet connections, roadways, loading docks even that the door sizes are standard. Moving to the cloud is dramatically different. The good news is that hundreds of thousands of organizations have made such a move, successfully, and you can learn from their trials and tribulations. Decisions A journey begins with a single step. Throughout your migration to the cloud you will have to make many decisions, but the first and perhaps most important decision is what architecture you will use. Gartner categorizes migration choices as Rehost, Refactor, Revise, Rebuild, or Replace. Each method has its advantages and disadvantages so your business and technical needs will drive the decision-making process. This document discusses the pros and cons of each and includes a flowchart to help make the right decision. Terminology Before we can compare and contrast migration options, there are a few terms that need to be defined. More specifically, these terms are acronyms: IaaS, PaaS, and SaaS, all of which stand for Infrastructure, Platform or Software as a Service respectively. One thing they share in common as that they provide different elements of an enterprise s computing needs via a subscription. The provider manages distinct components of the solution as seen in this table. DATA CENTER IAAS PAAS SAAS Applications Applications Applications Applications Data Data Data Data Runtime Runtime Runtime Runtime MIddleware MIddleware MIddleware MIddleware Operating System Operating System Operating System Operating System Virtualization Virtualization Virtualization Virtualization Servers Servers Servers Servers Storage Storage Storage Storage Networking Networking Networking Networking Table 1: Green items are managed by the customer and blue items are managed by the vendor. 2
As you can see, an IaaS provider proves the infrastructure to host your operating system and everything that sits on top of it. A PaaS provider delivers a prepackaged virtual computer running a preconfigured environment ready to add your application on top of. Finally, a SaaS provider delivers the specific functionality your end users expect to consume, without requiring any management of the underlying technology. Rehost Rehosting is perhaps the most straightforward migration. Rehosting is essentially replicating your internal data center and hosting it in the cloud as a Virtual Machine. No wonder it is often called Lift and Shift! This is usually the quickest way to migrate to the cloud, although you may not immediately realize all of the cost and performance benefits of a true Cloud First architecture. Rehosting works best if the application is essentially independent of the hardware it runs on. For example, Java programs can run unchanged on a SPARCserver running Solaris or an x86 server running Red Hat Linux. Rehosting also allows for potentially greater efficiency in refactoring, revising, and rebuilding (see below) as, once in the cloud, users can take an incremental approach, identify the greatest opportunities, and leverage the most advantageous cloud services to capture the greatest rewards. Rehosting may not be an option if the application simply is not Internet-friendly and is designed to be used via desktop clients expecting to access resources from a local server. In that case, the application will need to be revised, rebuilt or completely replaced. Another obstacle is if third-party software licensing prohibits the use of a Virtual Machine. Fortunately, this obstacle can be overcome, if the cloud provider offers Dedicated Hosts. This allows software licenses to transfer to a specific server instance in the cloud. Such an option adds an extra expense and limits some of the scalability benefits of the cloud. Refactor If your applications are already web-based, you can refactor your web site, enterprise application, database, identity management or authentication mechanism to use comparable servers from your cloud provider. It may be possible to refactor without any coding changes, other than URLs. However, there could be massive changes, particularly if you have been using older versions of software running in the data center, as APIs may have changed. The differences, however, would be comparable to updating your own data center software without moving to the cloud. This method provides greater immediate post-migration benefits than Rehosting, but it will lengthen the migration process. 3
Rebuild Moving to the cloud could be the ideal opportunity to rebuild or rewrite the existing applications to be cloudfriendly. If you don t have access to the source code for original enterprise applications, this may be the only choice. However, rebuilding will be time-consuming and expensive in terms of programmer-hours. The result will be a well-architected Cloud First solution that, post migration, will immediately enable user to reap the cloud benefits of scalability and cost efficiency. The downside is that the realization of these benefits will be significantly delayed by the time consumed in the rebuilding process. Revise If you have legacy applications that are not ready to run in the cloud, they will have to be revised to work in a cloud architecture. Since most modern programming languages are supported by cloud platforms, the code may not need to be rewritten, but custom apps will need to be reconfigured and app data may need to be transformed to work in the cloud. For example, data should be converted to industry standard formats like JSON/XML for client/server accessibility. Likewise, protocols should use encryption as traffic will be flowing over the public Internet and will not have the protection of running behind a firewall on a LAN (Local Area Network.) This is an option that sits between the easier and faster refactoring and the more difficult and time consuming rebuilding. For apps that qualify, it can be the best hybrid solution if the speed of rehosting is not essential. Replace In an ideal world, each function that makes up an organization s application suite would be accomplished by off-the-shelf SaaS (Software as a Service) functionality that can be licensed. As an example of the Replace scenario, an internal messaging tool could be replaced by a tool like Slack. Almost overnight, an organization can turn off their data center applications and replace them with proven, licensed tools that are maintained by service providers. There are other concerns, however, such as who owns the data, how easy (or difficult) it is to switch providers and can you use SSO (single sign on) for authentication. 4
REHOST REFACTOR REVISE REBUILD REPLACE Summary Switch from one platform to another compatible platform Move Web App from one server to a new server Convert old apps to use new platforms Rewrite old app from scratch to use Web technologies Replace custom app with off-the-shelf alternative Example Java on Solaris/ SPARC to Java on Linux/x86 PHP on local server to PHP on cloud server Edit existing app to use SQL, JSON, and Encryption Recreate functionality of a mainframe billing app using Java and SQL Replace internal messaging with Slack Advantages Quick and easy, relatively foolproof Minimal configuration changes required, leverages web Less work than a complete rewrite Opportunity to redesign and leverage modern tools and technologies Low overhead, with no infrastructure to manage Disadvantages Doesn t maximize advantages of new platform Only possible for existing web apps Frameworks used by old app must be available via the web and source code must exist Major undertaking, requires time, personnel and risk. Data ownership concerns, ongoing cost and 100% of old functionality may not be available 5
MIGRATION OPTIONS FLOWCHART Repeat for Each Enterprise Application Do Off-The-Shelf SaaS Alternatives Exist REPLACE REHOST Is Your Existing App Web-based? Is Your App Cross-Platform? REFACTOR Can You Easily Make Your App Web-Enabled? REVISE REBUILD All of the Above The reality is, any migration will probably adopt several of the above scenarios. Each enterprise application has a history and is likely to be in a unique state of its own. An important feature may not exist in a third-party SaaS offering, making replacement unlikely. The source code for a particular application may not be available eliminating revision as a choice. The application may rely upon old versions of programming languages, SDKs (Software Development Kits) or APIs (Application Programming Interface) and be unable to migrate as-is. 6
Where possible, replace proprietary applications with SaaS offerings. Weigh the pros and cons of rebuilding other apps to be Cloud First, if you have the time and resources. Consider creating all new apps using a Cloud First architecture. The overall goal should not necessarily be to move everything to the cloud but rather to migrate the tasks that are best suited to run in the cloud and, over time, revisit which apps can and should make the leap. There is another important lesson: make sure when creating new apps that you build for Cloud First so you don t limit yourself in the future. The End? Once you have migrated to the cloud, your job is not done. Indeed, your job is never done, as optimization of your cloud platform is the way to make sure you achieve the results you were promised. A data center is different from the cloud. In the data center, you never wanted to operate at high capacity because you would have no room for growth. Adding capacity to a data center could require research, proposals and a bidding process. This led to data centers playing it safe and running at 10% of capacity. Conversely, adding capacity in a cloud environment is done with the click of a mouse, so cloud-based enterprises are encouraged to operate at 90% capacity. Similarly, migrating to the cloud means you don t have to worry about the physical security of a data center as that is the responsibility of the cloud provider. However, the cloud uses a Shared Responsibility Model, with the customer in charge of password and encryption policies, File Permissions and Security Groups. Just as a house is only as secure as the homeowner and how they handle their keys, an enterprise must take part in securing their cloud. Conclusion Migrating to the cloud requires a lot of planning and even then, managing the cloud can be daunting. Fortunately, a Cloud Management Platform like CloudCheckr can constantly Right Size and secure your infrastructure to meet your changing needs, making recommendations and even taking actions through automation to keep your cloud optimized and safe, throughout your migration and ongoing operation. About CloudCheckr The CloudCheckr cloud management platform unifies cost, security, and inventory management with visibility and intelligence to mitigate security risks, optimize and allocate costs, and increase operational efficiencies across cloud infrastructure. With continuous monitoring, 450+ best practice checks, and built-in automation, CloudCheckr enables IT, Security, and Finance teams to manage their public cloud environments with confidence. Government organizations and Global 2000 enterprises trust CloudCheckr to unify their native cloud data and deliver the most robust cloud management platform in today s marketplace. VISIT US ONLINE 7