CLOUD TRANSFORMATION FAILURES AND HOW TO AVOID THEM
Having no "why?"
Whenever a client wants to do a cloud transformation, my first question is “‘why“? It might sound strange at first sight because, as engineers, we find it cool to use new technologies. But this should not be the driver. There must be a business reason for cloud migration.
Possible reasoning for cloud transformation may include:
Processes matter
Suppose you’ve decided that your business needs cloud technologies. You need to realize that to achieve your cloud transformation goals, company processes have to be adapted to the cloud too.
If an organization wants to have their processes 1:1 in the cloud, this is not a transformation, in best case this would be an optimization, if ever. There are often certain silos in big enterprises, such as network, computing, security, developers, operation, and so on. This model needs to be changed, as it does not support the end-to-end ownership that the business demands. Mixed skill-set teams with a DevOps mindset are the key to successful transformation.
Why is this all so hard?
The shift to DevOps and cloud requires a change in tooling and methods. For example, let’s consider necessary changes in the following aspects:
Security: From physical with high trust and strong perimeters to virtual, end-to-end with zero trust.
Change process: From change request tickets to self-service.
Change cycle: From weeks or even months to daily and continuous deployments.
Testing: From manual to automated.
Infrastructure provisioning: From manual to Infrastructure as Code.
Recommended by LinkedIn
Servers: From dedicated physical servers to virtual servers in the cloud.
Network: From static IPs to dynamic IPs and service discovery.
Going to the cloud without acknowledging these changes leads to problems.
Let me give you 3 examples to illustrate the consequences when companies decide to switch to the cloud, but their processes are not adapted to the cloud:
1. Infrastructure provisioning
Infrastructure as Code is required. When omitting this, you establish a manual practice, aka "ClickOps" on the GUI of the cloud provider console. This will enforce issues with maintenance and governance/drift detection. Furthermore, as cloud infrastructure is pay-as-you-go, you lose the ability to stop/destroy and rebuild your infrastructure as required in a defined way, and most likely it will generate additional costs.
2. Change process
In an on-prem world, change request tickets, change advisory boards, and preplanning over a cycle of weeks are common practices. Cloud developers and product teams should have a self-service to continuously deploy and improve applications and infrastructure with approved architecture blueprints and standardized templates ensuring governance requirements. Avoiding this step leads to losing one major advantage of the cloud: establishing a faster go-to-market when creating new products or services.
3. Security
End-to-end security with zero trust is the key to a secure cloud environment. Encryption in transit and encryption at rest are mandatory. A good security architecture makes use of Infrastructure as Code with architecture blueprints and approved templates and has an established configuration drift detection. A good strategy covers these aspects alongside the requirements for authorization, authentication, monitoring, and logging in a proper setup of the landing zone before the first workload is migrated to the cloud. Neglecting this step leads to an environment with a non-predictable state of reliability in regards to security.
So, if you are not sure how to plan your cloud transformation, working with a trusted partner will help you get the right strategy and desired business outcomes. We, at СoE Critical Services, SoftServe, have solid cloud expertise and can recommend the best way to adapt your existing processes to your particular cloud path.
By Martin Graeber, Enterprise Solutions Principal
Center of Excellence Critical Services, SoftServe
