The web is filled with articles on cloudification. Most focus on the benefits that an organisation’s stakeholders enjoy once they move into the Cloud. Our previous article painted a more realistic picture of a cloud migration project by highlighting the challenges most implementation teams face. We also emphasised how architecture is key to a project’s success.
If you’ve made it this far into our series on SAS Cloud Migration, we imagine that you’re decided on moving your data analytics platform. In this fourth and last instalment of this series, we share different strategies of cloudification and how certain ones are more appropriate depending on your organisation’s data analytics journey.
By the end of this article, you should have a better understanding of your next steps to begin your cloudification journey confidently.
One of the first steps to migrating your SAS workload into the Cloud is understanding your company’s current needs and future aspirations. Organisations are at different stages of growth, and their current maturity level will have a profound impact on how you go about your cloud migration.
The industry abounds in cloud readiness assessment and frameworks, but most are IT-centric or for generic application migrations. Below, we’ve shared a quick Cloud Readiness Assessment that details some important factors that highly impact your strategy for your data analytics migration.
Figure 1. Simple Cloud Readiness Assessment Framework
Some questions to ask yourself include:
Figure 1 contains a high-level assessment. More thorough, detailed discussions are necessary to obtain a realistic assessment of your organisation’s readiness to migrate to the Cloud. Many cloud service providers have proven frameworks that can help your organisation decide on the best approach to migrate your workload.
It is important to note that companies rarely migrate their applications in one go. More often, the enormous migration task is broken down into several more manageable phases.
This is done for many reasons, including:
For this reason, it’s good to have an overarching strategy but implemented in smaller stages. Thus, the assessment should be performed organisation-wide and also per application.
A sensible way to go about the task is to migrate per analytics workload.
These analytics use cases may share data, but one process can be prioritised over the other.
For less mature workloads, your organisation can take steps to prime them into maturity.
For example, if it is highly critical, redundancies can be created. When batch performance is critical, experiments can be done to determine the most optimal VM configurations. These small steps can be done in advance. When your organisation is ready to migrate a specific workload, some pre-work has already been accomplished.
Shadow runs and parallel executions are also great options for highly critical workloads. Environments for these should be prepared in advance.
For off-premise applications that are more mature, these can be timed with inflexion points of your off-premise systems. A good example is hardware that is ready to be decommissioned. The best time for a migration is when the infrastructure has been fully depreciated (in accounting books, typically 3-5 years) and has no significant performance issues that necessitate additional support from a third party. This sweet spot can be considered an optimal time to move your workload into the Cloud. Other inflexion points include software renewals or upgrades, changes in regulations, etc.
It is important to note that, regardless of the readiness of your workload for migration, it is always a good idea to automate as much testing as possible. The test scenarios should be done in advance as well.
As early as 2018, Forbes predicted that 83% of enterprise workloads would be in the Cloud by 2020. However, despite increased spending for cloud migration initiatives, their research revealed most respondents did not see a full migration to the Cloud in the foreseeable future. CIOs and CEOs from the manufacturing and financial services industries are more inclined to a hybrid solution with selected applications moving to the Cloud and the rest remaining as on-premise applications.
The cloud readiness assessment described in the previous section helps identify which applications or workloads are more appropriate for the Cloud. It also shows how that workload can be migrated to the Cloud.
The image below illustrates five use cases or methods that can be employed to migrate your workload to the Cloud.
Figure 2. Data Analytics Migration Strategies
This strategy involves creating a server instance in the cloud through an infrastructure-as-a-service model and installing an instance of SAS on the virtual machine. During the migration, the environments are not accessible. Because of the necessary downtime, this migration strategy is recommended for non-critical workloads.
SAS workloads already deployed on virtual machines on-premise can be replicated on a cloud-based VM. Since the on-premise VM image is simply copied to the cloud as-is, there is no downtime. A virtual machine deployed on an on-premise device would not have been designed for elastic resource allocation, thus resource optimisation cannot be performed with this strategy.
Containers help make applications lighter and enable more straightforward, safer deployments in multiple environments. Many on-premise applications have not been designed to maximise Docker containers and may require revisions in the code. Once an application is containerised, future updates can be easier to manage. This is ideal for SAS Viya 4 which has been redesigned to maximise the use of Docker containers. Sustained downtime may be necessary to make the existing code and other assets compatible with Docker containers and container deployment.
This strategy is best for critical workloads in a production environment that needs to be continually accessed. The environment can be cloned incrementally, particularly during off peak hours. The clone is then deployed into the Cloud. The differences between the two parallel environments are identified through a comparison of metadata. Only the data with changes are ported over from the on-premise system to the cloud clone. When the two environments are equivalent, the on-premise system is then decommissioned. With the incremental migration, downtime and data loss is minimised if not eliminated. It is important to note that this strategy can only be used migrating to and from the same version of SAS.
Figure 3. Illustration of Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
Some use cases don’t require computation and data store to be on the same machine. This strategy involves migrating the data warehouse to the cloud and leaving SAS compute on-premise. Some code re-factoring may be necessary to minimise data egress charges. As such, downtime is to be expected to make the necessary optimisations.
Cloud Service Providers will have their own methodologies that can be adapted to different migration strategies and workloads. However, the following steps are listed as they cover most of the steps involved in a SAS cloudification project.
Some of these steps can be performed in parallel with each other. When presented visually, it could resemble the chart presented in Figure 4 below that represents a Cloud Strategy Roadmap.
Figure 4. Sample Cloud Strategy Roadmap
The roadmap described above should give you a better idea of how your cloud migration might be implemented. The different names that should be identified under the “Responsible Party” column represent the skillsets that should be present in your organisation. It is perfectly possible to implement a cloud migration in-house, but in our years of practice, we’ve found that it’s best to learn from others. This dramatically speeds up the process. In this section, we discuss ways to leverage others’ experiences for your organisation’s benefit.
A simple internet search will reveal a wealth of tools and frameworks that can help you with each step in your cloud strategy roadmap. Many people have taken the time and effort to create templates that will help you design and document your migration. Do note that no two cloud migration projects are the same. As such, take what you can from the available references and adapt as you see fit.
SMB peer groups are particularly beneficial. While your competitors may not share all the details involved in migrating their workload to the Cloud, many organisations are willing to share information such as best practices, learning points, and preferred vendors. This information can also be gleaned in industry meetings or a mentor/mentee relationship.
Many Cloud Service Providers publish case studies to showcase their experience and expertise in migrating their clients to the Cloud. These case studies often describe nuanced scenarios that can only be encountered by going through the whole project. Take advantage of learning from other’s hands-on experiences rather than making costly mistakes on your own. Even if the industry or use case is far removed from your application, certain similarities can be observed. The lessons from which can be applied to your use case, even if it is only to a limited extent. Further, companies that allow their stories to be published are often generous with information. Digging a little further, you may be able to connect with the individuals behind a migration project through official channels and possibly through LinkedIn and other social media platforms.
A cloud migration’s success is limited by the experience of your delivery team. Suppose you see a SAS migration on the horizon. In that case, it may be a good time to invest in your workforce with training or hiring more seasoned developers, analysts, architects, and project managers.
The most efficient way to leverage experience from others is to seek the assistance of a Cloud Service Provider. Their years of cloud migration experience, with different workloads, requirements, and constraints, allow these Partners to help you navigate a cloud migration with ease. Most partners will have distilled their experience into templates, proprietary software, and processes. They also have trained teams who are experts at what they do. By putting an expert behind your migration initiative, the projects typically have shorter timelines and help you avoid costly technical and strategic mistakes. An expert can help you take shorter routes without cutting proverbial corners.
Seasoned consultants can identify which analyses are critical and which can be removed, thereby avoiding analysis paralysis that can overwhelm an inexperienced project team.
When exploring a new city, you could do it on your own. You also have the option to take a hop-on-hop-off tour or take a planned tour, where you don’t need to think about anything at all. You can think of a Cloud Service Provider as a like-a-local tour guide. Often, when a local takes you around for a customised city tour, your experience is made richer and more meaningful. You get the best of a place, suited to your preferences, in the least amount of time.
As we end this series on cloudification, imagine what your company would look like after migrating your SAS workload to the Cloud? Are your costs lower? Is your team able to collaborate better? Have you removed bottlenecks for data access? Is your data more secure? Do you experience better performance? Is it easier to manage technical issues like upgrades? Such is the promise of the Cloud when done correctly.
It may be an arduous journey ahead but well worth it. The faster you can get there, the better. MySASTeam is a SAS Partner and certified Azure Cloud Service Provider. We’re here to help you fast track your cloud migration no matter what stage you are at.
If you’d like to discuss how you can begin your organisation’s cloudification journey today, we would love to help. Leave your details, and we’ll get back to you.
Leave your details below so we can help find the best solution for your organisation.
At MySASteam, we believe that every SMB deserves the Power to Know. Please leave your details below so we can find the best solution for your organisation. We’ll call you.