Up And Away: Clear-Eyed Considerations For Your Cloud-Adoption Journey

It’s no secret the cloud is a driving force powering the digital transformation. However, cloud adoption is rarely a one-size-fits-all operation. Even when done correctly, it can bring about company-wide transformations unique to each organization. At the very core, the move to the cloud is akin to a culture change, and understanding these changes can make the transition successful. The following factors are worth considering:

Business strategy

Your cloud journey should start with company buy in, a budget and a roadmap with clear objectives, outcomes, and performance metrics. The objectives need to be realizable and long-term. Having the right stakeholders involved helps keep initiatives going in the organization and ensures that the effort is not done in a siloed manner. Milestones, playbacks, celebrating successes, and recognizing failures transparently is extremely important. Having the ability to change the organizational design to best leverage a transition is also necessary.

Choosing a platform

Plenty of providers can help you realize what best fits your organization. The key, however, is to know the strengths and weaknesses of each platform. While a relocation from one provider to another is possible, you generally are in partnership with a provider for the long haul. Remember, you are not just provisioning resources — it’s about data, data-lifecycle, applications, leveraging services, cost, building up expertise, and other factors.

Resources for execution

A cloud transformation is not an IT-only project. It’s a partnership between different departments. Having said that, identifying resources in the organization platform fluency is crucial. While not everyone needs to be an expert, you need a group of people who can create a list of pros and cons and put them into practice. Additionally, you should be up-to-date and familiar with the open-source technologies you use. Allowing for free license is a distraction that will increase complexity and affect your security posture.

Security

Your organization should have a well-articulated security posture as you adopt cloud services and infrastructure. Start with understanding your role and responsibilities. Then consider extending your own network into the platform versus using VPN for isolated deployments, roles in the platform, access to the resources in the platform, and divvying up the main account into sub-accounts for better resource management, utilization, complexity, and flexibility. Some other factors worth noting include IP protection, data storage, data life-cycle, resource monitoring, playbooks for security updates and incursions, leveraging platform security features, and more. Above all, be consistent and document and automate everything.

Start small

Create a blueprint for other products, applications, and areas to follow. Start with an area and application that will be the test bed for other policies and procedures. While this is not a license to play it by ear, it will help smooth out the adoption bumps you will undoubtedly come across. More importantly, this allows you to address those bumps in a consistent, wholistic manner.

Automate

Be familiar with open-source frameworks and tools — and use them. Standardize your choice of automation frameworks and enforce them. Don’t be afraid to push for automation. Some basic items such as machine provisioning, data lifecycle, and patch management should be automated, but be mindful of business outcomes as you automate. Don’t over-rotate. Be agile in your tooling and automation, build a backlog of items and work on the most critical automation pieces that will give you consistency first.

Costs

Keep costs in check and justify appropriate utilization to achieve business outcomes. All platforms are transparent about their costs and come with budget monitoring and cost-reduction recommendations. It’s key to understand a platform’s charges. A policy of shutting down a platform when not in use, reserved instances, and spot instances can go a long way to reducing costs.

Architecture

If you are transitioning an existing application, understand its architecture and resource needs. While it’s ideal to demand that applications in the cloud are deployed in an available and scalable manner, that might not be justified. Rewriting a monolith to be micro-service architecture-based is not something to be undertaken lightly. Ask, “How will I know if the application is down? What is the return point objective/return time objective of the application?” For new workloads and applications, it’s fair to require current software best practices.

Culture

Going to the cloud is not the responsibility of a single department. It’s a set of practices shared and enforced everywhere in the company. These practices may include:

• Educate teams on cloud services
• Create chapters/guilds and encourage cross-team collaborations and sharing
• Adopt open-source applications
• Select the right experts and build the right on-ramps
• Encourage adoption by abstracting cloud complexity
• Build a DevOps team
• Build and share the right automation
• Adjust your risk attitude and view of failures

Business critical vendors

If you are deploying or using critical vendor software in the cloud, several factors will come into play. Have a set of questions ready for use-cases — the questions you ask when you use a vendor’s application as SaaS where it’s completely managed by the vendor versus a vendor who will deploy their application to your platform.

Questions for vendors include:

• How experienced is the vendor in either hosting or deploying to cloud?
• Will they fit within the security architecture you have defined?

If deploying to your platform, define data flow and how data is stored at rest. In addition, discuss:

• Encryption keys.
• Data lifecycle handling, data tiering and backups.
• Resiliency posture of the application and its infrastructure, but also how it works with platform capabilities. Also ask about ability to scale on-demand.
• Manual versus automated deployments.
• Upgrade strategy.
• RPO and RTO discussions, including disaster and recovery needs.
• Service level agreement, outage notifications, and penalties and cost structure.
• Monitoring integration and visibility.
• Compliance and governance requirements.

In addition to the above, ask SaaS (or MSPs) vendors questions regarding:

• Multi-tenant versus single-tenant.
• Cloud platform of choice versus you selecting the platform.
• Vendor roles and responsibilities.
• Compliance and standards.
• Encryption key management, especially if multi-tenant.
• Level of automation from initial setup to covering disaster scenarios at the application layer.

We hope that this blog has been educational and raises awareness on key factors and why they are necessary when considering a cloud transition. If you are already utilizing the cloud, we hope you have come away with new insights. If you are just starting your journey, we hope this adds to some of the factors you were already thinking about. Good luck with your journey!