Falling from the Cloud: Avoid Common Pitfalls for a Successful Cloud Migration
by Bardia Mehrabian

Falling from the Cloud: Avoid Common Pitfalls for a Successful Cloud Migration

Since 2018, 73% of organizations have some sort of application or more deployed into the cloud and signs point that this trend will continue for some time. Enterprises across the board are clamoring to adopt the #cloud at a quickening pace. While these enterprises understand the importance and advantages the cloud brings to an organization’s IT capabilities, they may not be ready to answer the most important question – HOW?

The “big 3” cloud providers – Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Solutions – provide their own set of Cloud Adoption Frameworks (CAF) that guide enterprise IT department’s or business units to adopt the cloud in a seamless and coherent manner with quick ROI. While each provider may offer a different approach or explanation to adopt the cloud, a few common themes can be identified throughout each of the respective CAFs.

Justify the Cloud

 

 


In its simplest form, all three cloud providers agree that enterprises that are attempting to adopt the cloud need to answer the fundamental question – WHY?

Enterprises need to answer WHY they’re wanting to adopt the cloud and provide good business justification to do so. Answering this question drives, as Microsoft puts it, the business outcomes, justifications, and motivations that are required for stakeholders, financial advisers, and other decision makers to help steer their technological transformation to fit their enterprise’s business needs.

The AWS CAF white paper articulates this well in one simple sentence:

The Business Perspective is focused on ensuring that IT is aligned with business needs and that IT investments can be traced to demonstrable business results.

Once the outcomes and justifications are defined, the different business units that comprise enterprise IT (SysOps, NetOps, DevOps, SecOps, FinOps, Helpdesk, Licensing, etc.) build the strategy, metrics, and milestones to help deliver these specific business outcomes. This includes research into, but not limited to:

  1. Evaluating the Total Cost of Ownership (TCO) and Return on Investment (ROI) for deciding on a business-technological strategic effort.
  2. Development of budgets, cost structures, and financial models to make sound financial decisions for investment into a specific cloud technology or platform.
  3. Strategic business outcomes (e.g. lowering cost, agility in new technology adoption, further reach, better customer engagement, better performance, etc.).

Ultimately, justifying the cloud helps build the roadmap of metrics, milestones, and goals that are required for a successful adoption of the cloud.

Start Small and Mature Over Time

 

Choosing the correct first set of applications to migrate and/or develop in the cloud is probably one of the most important decisions to make when adopting the cloud, and one of the easiest decisions to get wrong. So often enterprises get overly excited and choose overly complex applications and/or workloads to migrate or develop in the cloud when the cloud infrastructure is not fully mature. A classic example is introducing public facing applications or workloads too early into the cloud when proper security and monitoring solutions and mechanisms are not in place.

This is why all three cloud providers insist on taking an incremental or iterative approach when adopting the cloud. Microsoft explains their reasoning in their Azure Cloud Adoption Framework Docs:

This approach helps teams to engage in projects before all requirements are well known. It also creates room for a growth mindset, which frees the team to experiment, learn, and deliver without artificial constraints.

For all these reasons and more, we highly recommend that teams use agile or iterative approaches to cloud adoption planning.

What Microsoft means by this is that due to the amount of time that is required for enterprise IT personnel to:

  • Learn and train (upskill) their cloud knowledge for adoption
  • Conduct thorough discovery of the on-prem estate and discovery/understand all necessary requirements for applications/workloads to move into the cloud (digital rationalization)
  • Establish standardized governance, monitoring, and security in the cloud space that meets the requirements of chosen applications or workloads migrating or being innovated in the cloud

By starting with small and simple applications/workloads and iterating/incrementing them in each sprint, these bullet items can be accomplished without sacrificing early ROI or throwing personnel too deep underwater causing project delivery issues.

Infrastructure as Code

With simple applications and workloads either migrating or being developed in the cloud, it’s easy to leverage the web portals of a given cloud provider and simply “point-click” servers and their dependencies into existence. However, as an enterprise expands into this space and more complex workloads start migrating into the cloud, the manual point-click process of resource creation and change management becomes slow and inefficient at scale.

Google addresses this bottleneck of resource creation and change management at scale by pointing out in their Google CAF White Paper:

[An enterprise’s] ability to scale in the cloud is determined by the extent to which you abstract away your infrastructure with managed and serverless cloud services, as well as the quality of your CI/CD process chain and the programmable infrastructure code that runs through it.

Each point-click action can also be achieved by running code in respective cloud CLIs and APIs. As such, infrastructure deployment and change management can be codified, templatized, and executed at scale. Applications that are developed in a dev/test environments can easily be redeployed into staging and production environments at the running of a script or through CI/CD pipeline (e.g. Azure DevOps, Terraform, etc.) making cloud-based deployments and change management at scale far more efficient.

Leverage Platform-as-a-Service (PaaS)

The previous Google CAF quote identifies Platform-as-a-Service (PaaS) services and solutions as an additional solution to scale deployment and change management. PaaS services and solutions refer to the abstraction of traditional infrastructure resources into managed and/or serverless services and solutions.

Microsoft’s App Service Environment (ASE) and Amazon’s Elastic Beanstalk handle the management of the server, operating system, network connectivity, storage, etc. automatically so that developers and businesses can focus on the development of the app product instead of spending time on infrastructure baselines and prerequisites. Full applications can be housed and isolated entirely by these PaaS solutions as individual units, thereby making connectivity and/or governance change management much simpler and more accurate.

Since PaaS solutions and services are built on a cloud provider’s shared infrastructure and automation, PaaS resources are generally cheaper than their Infrastructure-as-a-Service (IaaS) counterparts. The latter provides dedicated compute reservations regardless of if it’s in use or not. PaaS on the other hand provides more granular computer delivery as required by the application.

Finally, with infrastructure prerequisite planning no longer required for AppDev, increased agility in application development and deployment can be achieved.

Cloud Adoption Support

 

As mentioned in the Starting Small and Mature Over Time section, adequate time is needed for majority of IT personnel to learn all details required for successful cloud adoption. While some enterprises may have some of the brightest IT personnel, adopting the cloud presents a different set of challenges. Falling into common traps and mistakes of cloud adoption can take a long time to overcome and be costly. Therefore, it is imperative to make the right choices early to ensure early ROI and long-term success of cloud adoption.

All three cloud providers recommend the use of third-party partners to help fill in the skill gaps required for cloud adoption. According to Google’s CAF:

Third-party contractors and partners provide subject matter expertise to fill the IT staff’s remaining knowledge gaps or where the topic is so narrow and deep that it would be unreasonable to expect your IT staff to upskill to that level. These external parties serve as a second-tier point of escalation in the event of a technical question or operational incident that cannot be answered or resolved internally within your IT staff. 

Partners are a catalyst to proper and early cloud adoption with quicker ROI. By augmenting staff with SME partners, enterprise IT personnel can learn the fundamental processes that are required for proper cloud adoption and ensure business objectives are met with their newly learned and leveraged frameworks.

Conclusion

Whether partners are leveraged or not, an important first step for businesses attempting to migrate to the cloud should be to first read and have a good comprehension of their respective cloud adoption frameworks. Leveraging the best practice guidelines in these documents will help ensure cloud adoption is a successful project and ROI is achieved early in the process.

How Can We Help?