Most organizations today are looking for ways they can cut costs but still remain competitive and drive differentiation via greater agility. The public cloud is increasingly being seen as a way to accomplish these goals faster.
Organizations are also now looking to have a global footprint serving customers all over the world. In order to deliver a resilient application that consistently delivers great performance across the entire globe, an organization will need to operate or run multiple sites from where to serve the application. The organization will also need the ability to be elastic in the face of changing demand. Scaling up application infrastructure when necessary and removing capacity when it’s idle and not needed.
Public cloud service providers offer all these capabilities. It allows their customers to be highly agile and respond to changes in demand very quickly. The public cloud also has multiple interfaces with a very high level of self-service where customers can interact and launch needed resources. Most public cloud service providers also provide programmatic access via API endpoints that customers can use to integrate custom scripts to automate the deployment of resources needed. This kind of automation and self-service greatly reduces not only the time needed to deploy needed resources but also makes it reliable and repeatable.
Moving to the cloud allows organizations to reduce expenditure on infrastructure, have a quicker time to market because of the automation benefits and be elastic when serving demand.
What to Migrate?
At Opcito, we have helped customers migrate applications to the cloud. And as a consequence, we have spent a lot of time thinking about migrating workloads to the cloud. The goal of any migration evaluation is to identify which applications are prime candidates for the move to the cloud and which are more suited to stay onsite. There are multiple ways of classifying a broad set of workloads, one easy way is to classify applications into standalone or customized applications.
Standalone applications are usually commercial off the shelf applications. These applications will usually have pre-build images available for most if not all public cloud providers making the largest job during the migration of these applications the moving of customer data to the new install on the cloud.
Customized applications need more nuance. These are usually applications built in-house or custom just for the organization based on unique requirements. When evaluating these applications for cloud migration readiness these are the factors to be considered:
- Application design complexity
Some traditional applications are so complicated and tightly coupled that customers might not be willing to rework it.
- Integration complexity
Every application has its integration points, like payment gateways, SMTP servers, web services, external storage, and third-party vendors. It’s very important to analyze the impact a cloud migration will have on those dependencies. A cloud migration will experience unexpected connectivity or authentication challenges if integration points are missed during the migration.
The most critical (and tedious) task is to identify all those integration points. Since older applications might be poorly documented and the developers familiar with the end-to-end functional and non-functional details may no longer be available, a module-wise manual code dive through may be the only way to identify the integration points for the application.
Many of these issues can be addressed through a combination of the familiarity internal IT teams have with the apps and an asset discovery tool (either open source or commercial). An asset discovery tool can help you to identify entire server configurations within a network, along with connectivity details.
- Dynamic Characteristics of the application
In addition to the static characteristics such as OS version, CPU, memory etc, it is also useful to understand the dynamic characteristics of the application being migrated. Discovery tools can collect sample data on resource utilization and network traffic for applications. For example, time series data on CPU utilization for a server/VM can show what average and peak utilization trends are. This information can be used by migration solutions to right size the cloud compute requirements and match the workload to the right compute instance on the cloud. Similarly, an understanding of network traffic size and trends can also appropriately size bandwidth requirements in the cloud. Gaining an understanding of these dynamic characteristics can allow for better trade-offs between performance, availability, and cost.
Where to migrate?
Selecting the right kind of cloud is also important. There are 3 basic cloud models:
- IaaS – Infrastructure as a Service (examples: AWS, Azure, Google Compute Engine)
- PaaS – Platform as a Service (examples: AWS Elastic Beanstalk, Heroku, Google App Engine)
- SaaS – Software as a Service (examples: Google Apps, Salesforce)
Choosing the right model is an important step in the migration process. Customers who would otherwise be fine hosting their applications in third-party data centers, but would prefer to outsource the care of their physical infrastructure so they can concentrate more on developing, deployment, and monitoring, should select an IaaS host.
If the customer prefers that his applications are portable they should drop them within a robust PaaS that provides a full (and invisible) infrastructure environment.
SaaS is a delivery model through which centrally hosted productivity software is licensed on a subscription basis.
Once a cloud model has been chosen the next important question to be answered is what type of cloud the migration is going to target. As with cloud models, there are 3 types:
- Public – where the resources are entirely hosted by a cloud provider like Amazon’s AWS
- Private – where platforms like VMware’s vCloud or OpenStack are used to create a private cloud for the customer
- Hybrid – where resources are spread over both private and public platforms
What are the stages in a typical cloud migration?
There are many factors that impact the success of a migration project some of them include the availability of skilled IT staff, a thorough understanding of the applications being moved, selecting the right cloud model, type, provider and realistic project planning.
A Typical migration will involve the following stages a design and build phase, pilot testing, and only then, full-scale commissioning. Let’s take a look at what’s involved in each of these phases:
Assess and Plan
The successful migration of services to the cloud requires an assessment phase. We’ve already looked at how to gather information about your deployed applications and select the right applications to be moved to the cloud in the previous section. Identifying the workloads for migration will determine the cloud model most appropriate for your organization, be it private, public or hybrid.
Design and Build
Once you have assessed your workloads and done your due diligence to determine the most appropriate cloud model for your organization, you must develop the strategy. The design phase involves an assessment of an organization’s existing network, data center, application environment and produces a series of detailed design documents that articulate network, application migration, and implementation processes.
A migration plan is then created based on the destination workload profiles. The plan combines a specific sequence of actions and the human and financial resources required. It evaluates migration options for each specific workload and the location of the workload placement, including:
- Rightsizing the workloads
- Network design
- Application profiling
- Dependency mapping
- Data protection
Organizations must also decide whether they will embark on a phased or ‘big bang’ approach to cloud implementation. Most organizations favour an incremental approach as it allows them to ‘cloud-enable’ their IT assets without interrupting day-to-day business operations. It is in this phase that you will also determine the approach to cloud migration. The ‘lift and shift’ method is a common option, where in-house applications can be replicated in the cloud without re-design. If your organization is ‘bleeding costs’ from maintaining its own infrastructure, or you are migrating applications for disaster recovery purposes, then this is the way to go, as re-architecting applications can be costly and time-consuming. Generally though, re-design is recommended for resource-intensive applications, such as those used for big data analysis and image rendering. Otherwise, they can suffer from performance and latency issues.
The design and build phase should document the complete migration strategy for workloads moving to the cloud. It is important to have clear communication of the planned cloud migration approach with all stakeholders.
Pilot testing is a recommended approach to mitigate any potential migration risk. It verifies that the services migrated or provisioned meet the business requirements and expectations, and ensures that critical business applications perform as expected in a cloud environment before migrating the production instances. Pilot testing also verifies the migration process, allowing for better planning of the commissioning phase.
Undertaken, including the implementation of any tools required for migration, workload configurations, and network configuration. Testing applications and databases following the implementation is also recommended and is usually the largest contributor to the migration effort. This involves tasks such as data verification, testing of database stored procedures and functions, and testing of application interaction with new database platforms. Cloud migration is a reasonably straightforward process as long as you have a carefully planned approach. By assessing the current portfolio of applications, an organization is able to understand the challenges, complexity, and level of effort required to have its workloads migrated.
Who to ask for help?
The information provided in this whitepaper may make it seem like cloud migrations are hard and fraught with business risks but the good news is organizations don’t have to do this on their own. There are service providers, technologies, and resources available to help organizations migrate to a cloud environment.
Several third-parties can migrate server workloads between different virtual, physical, and cloud-based environments. Two examples Racemi and Oracle’s GoldenGate. If you want a product to help migrate servers across different types of technologies, these vendors may be a good place to start.
If you are seeking an organization that will walk you through the entire migration lifecycle and does much of the heavy lifting for you, you may want to consider bringing in a third party consulting partner. Often, they can scope out an engagement that will take you from A to Z, or anywhere in between. One consulting organization you may want to consider for this is Opcito.
If you aren’t interested in using a third-party consulting partner to help you in this process, you’ll likely still want more detail on best practices for migration. To that end, we’ve provided a few documents that will be useful to read. They discuss this process from AWS’s perspectives and provide extra context for your decisions. You can find the AWS resource here.
Organizations have long realized the benefits of migrating to cloud, which is evident from the rate at which organizations are migrating their applications as well as data to the cloud. As per Gartner’s predictions, by 2019 more than 30 percent of the 100 largest vendors’ new software investment will have shifted from cloud-first to cloud-only. Migrating to the cloud is not an easy task, but with the right tools, resources, planning, and personnel, it can be done. Regardless of where you lie within the cloud migration cycle, Opcito can help you at every stage. Schedule a call today and see how Opcito can help you ensure your cloud migration is a success!