Using a cloud-centric strategy
Of the organizations using cloud services, more than 75% indicate they have a cloud-first strategy (Gartner). A strong cloud strategy influences all aspects of application development. It’s important for enterprises to use a cloud-first approach for app architecture, practices, tools, and the team.
Some best practices for a cloud-centric approach include:
Avoid vendor-specific services for easy lift.
Automate as much as possible—including VPC, infrastructure, build, test, deployment, etc.
Keep up-to-date on cloud platforms (e.g., products, APIs) and update as needed.
Treat infrastructure as code.
Use a CI/CD pipeline to transmit updates to multiple cloud systems at once.
Create abstraction layers to isolate vendor-specific code from core funtions.
Being cloud-first may not be enough. There are significant risks that could cause a cloud project to blow up. What could go wrong?
The cloud supplier shutters. While it is unlikely for the big 3 to abandon operations, when partnering with small or newly established vendors there is a risk for continuity of their service or offering.
The contract with your current cloud provider ends and you decide to switch providers for cost or feature benefit.
The cloud provider doesn’t meet the requirements for a new business initiative or geography.
Having too tight dependencies on vendor-specific services may make migration too painful.
The difference between cloud platforms is vast. To prepare for these situations, go beyond cloud-centric and be cloud-agnostic. There are many reasons you may need to migrate or expand from one cloud provider to another. Being cloud-agnostic is a way to add flexibility, speed, and reduce costs.
Implementing a cloud-agnostic approach
Being strategic and taking an agnostic approach towards the architecture's structure inevitably saves time and money—while offering additional flexibility for managing cloud vendors. Cloud transformation requires an investment from BOTH the organization and the tech company implementing the work. Having the option to migrate from one cloud provider to another allows businesses to address a failure, vendor issue, or even expand to new geography or market swiftly.
The foundation of an agnostic approach includes:
Choosing cloud compatible frameworks and products.
Lifting source code and artifacts.
Adopting tools for automation early in the process.
Stop focusing on how much legacy code to keep. Instead, always focus on the end goal and make decisions based on where you want to end up. There are general rules of engagement for engineering stronger, more flexible architectures.
Establish a cross-functional team: DevOps, developers, and testers should operate as a single unit.
Use a cloud-first, code-first approach: Infrastructure builds and tests code.
Break it to fix it: You may need to invest in some refactoring to become cloud-agnostic.
The result: Healthy, modern development practices that support growing business and evolving technology.
You need to choose the right platform.
Making your initial cloud provider decision should not be done lightly. There are many options to choose from with a variety of considerations that impact whether your cloud becomes a thunderstorm.
There is no clear such thing as the best choice for the cloud. Cloud platforms are not identical when it comes to the services they offer. Requirements change.
Comparing industry favorites
Focus on shared industry standards vs. a specific provider. It’s worth repeating...avoiding vendor lock-in is critical. Favor flexibility without sacrificing the build or abstract proprietary services.
Implementing migration FAST
We were able to implement a migration in just one week using this strategy.
First, choose infrastructure elements that are easily reconfigured. This tactic is best for a quick migration from one cloud platform to another. Then, use a tool to define infrastructure as code (e.g., Terraform). Always treat infrastructure as code. Producing this infrastructure moves fast.
With a flexible architecture, industry-standard tools/practices set, a quick implementation can be executed with the following configuration:
Same source code, artifacts, pipeline
Different deployment
Additional subsets specific to each cloud platform
Once these elements are in place, amending the deployment pipeline takes minutes.
Ensure success with good development behaviors and best practices. Give cross-functional teams sufficient access to all necessary areas of infrastructure. Provide the team with a set of tools for building, storing, deploying artifacts, and managing configuration. Code should be part of every step of build/deploy/configuration. With these guardrails in place:
Migrate the smallest, most isolated components (e.g. Node.js APIs, UI).
Build connections to on-prem, legacy architecture services.
Transform heavier, legacy components gradually.
Connect artifacts.
Transmit changes from one system to another.
Conclusion
Why use a cloud-agnostic approach? Write code once. Reuse and apply to the CI/CD pipeline. Then add in specific requirements. Taking these small steps inevitably saves time and money.
