Cloud Adoption Pitfalls to Avoid Part 2: Designing Around First Workload and Click To Provision

Adrian Romo

Cloud Adoption Pitfalls to Avoid Part 2: Designing Around First Workload and Click To Provision

Cloud adoption can often start by accident. Developers use the cloud as a sandbox to try something new, it becomes useful to the business, and the wider organization begins to rely on it. But none of the usual planning, architectural design, or governance were incorporated, which can be painful to rectify down the road.

This is the second blog post in a five-part series focused on cloud adoption and the common pitfalls organizations experience on this journey. In part one, we discussed an as-is lift-and-shift to the cloud and how it can bloat cost. This blog post will explore how designing cloud implementations around the first workload and using click-to-provision without a comprehensive plan for policies and controls can lead to governance headaches and rework.

Beginning Stages of Cloud Adoption

Every organization’s cloud adoption story is different. However, we have seen some common themes over the years. In many cases cloud adoption doesn’t begin intentionally. Developers frequently try out cloud services like Azure, AWS, or Google Cloud Platform by using it as a sandbox for development. They are attractive because developers can quickly stand up an environment by enabling container services, platform as a service (PaaS) features, and serverless functions. The resulting infrastructure reflects the quick and easy click-to-provision of services centered around this initial workload. Security and role-based access controls are typically not present because developers have privileged access to everything. Monitoring, logging, analytics, high availability, and disaster recovery are often limited or absent from the architecture because they weren’t required to deliver the desired features and functionality.

Pitfalls of Quick Cloud Adoption

Over time the sandbox cloud application matures, demonstrates business value, and becomes mission critical without ever having been properly planned, architected, or governed. At this point business leadership wants to guarantee uptime, ensure performance, and protect the data so they bring it to infrastructure and operations to manage.

However, there are challenges associated with inheriting an application or workload that grew organically. Network architecture and integration with other networks must be engineered around whatever default click-to-provision configuration is in place. Wrapping core and edge networking services around existing infrastructure and establishing reliable on-premises connectivity is often cumbersome and painful. This is frequently exacerbated by infrastructure teams being new to the cloud and treating it like another data center by leveraging familiar but costly infrastructure as a service (IaaS) versions of the load balancers, firewalls and servers they use on-premises instead of less expensive cloud native tools and PaaS offerings. Implementing role-based access controls (RBAC), least privilege, and segregation of duties after the fact can also be very challenging. Does this story sound familiar?

How to Avoid Cloud Adoption Pitfalls

The key to avoiding this pitfall is to begin with the end in mind and bring all the stakeholders to the table to collaborate on cloud adoption strategy and governance. IT leadership, application developers, infrastructure engineering, security teams, and business stakeholders all have different perspectives and priorities.

Prioritization & Alignment

If this prioritization and alignment is not clearly articulated to technical and business stake holders at the start of a cloud adoption process, organizations often end up with misaligned expectations. They may also end up with environments that are hard to manage and fail to deliver on the stated goals. When Credera leads cloud architecture planning and governance workshops, we partner with all these stakeholders to ensure goals are aligned and security/compliance, reliability, performance, cost optimization, and operational excellence considerations are factored into the design.

Identity & Access Management

Our typical approach starts with identity and access management, mapping out personas and responsibilities to ensure team members are given the right permissions at the right time to do their job. We also address the different kinds of compute that will be used to support workloads—virtual machines, containers, high performance computing (HPC), and PaaS, and how they should be segmented to facilitate isolation of core infrastructure and RBAC. Considering network architecture and future connectivity requirements up front can help prevent security breaches and complex redeployments later. Each cloud platform also has features and tooling to automate policy enforcement and ensure compliance.

Governance-Centric Architecture

Establishing a governance-centric architecture as the foundation of any cloud adoption is the best way to future-proof its design. It’s also important to explore cloud monitoring, alerting, and integration with any existing security information and event management (SIEM) platforms (topics we will explore in-depth in the fifth blog post in this series). Lastly, we usually bookend cloud governance workshops by examining the cloud provider’s cost reporting and management capabilities and how these might impact an organization’s requirements. The goal is not to address every issue and question up front but begin the conversations to get directional alignment and buy-in from all stakeholders.

Learn More

This is the second blog post in a multi-part series focusing on cloud migration and adoption. In the next post we will talk about cloud adoption challenges related to migration complexity, dependency pitfalls, and competing priorities.

If you are interested in learning more about cloud adoption or are looking for a partner to join you in your journey, we have a team of highly experienced individuals who can help. Please feel free to reach out to us at findoutmore@credera.com.