Enterprises plan their cloud transformation carefully and thoroughly. And that's exactly what they need to do in order to set their cloud journey up for success.
But the truth is that many organizations don't have a lot of experience when it comes to migrating to the cloud. They are up for a steep learning curve.
That's why we've compiled a list of 6 aspects you need to keep in mind when embarking on your cloud journey:
- Breaking up silo structures
- Assessing the technical expertise of your teams
- Understanding cloud vendor lock-in costs
- Understanding the shared responsibilities in the cloud
- Considering Managed Services
- Develop an agile, cloud native way of working
Let's get to it:
1. Breaking up silo structures
Moving to the cloud requires a change in the organizational structure. Just signing a contract with AWS, GCP or Azure is not enough. Infrastructure silos focusing on databases, networks, and so on are not ideal, to say the least. Everybody working on an application has to communicate with those silos.
Developing and running applications in this scenario puts a lot of overhead responsibilities on the shoulders of DevOps teams. And it grows with each cloud platform they add.
Optimizing in silos can make each silo run their cloud platform perfectly but it won't remove inefficiencies in the overall cloud transformation effort.
A cloud foundation team that sees itself as an enabler for DevOps is the best practice. The cloud foundation can optimize for applications and go-to-market.
2. Assessing the technical expertise of your teams
You have decided on one or more cloud platforms - like AWS, Azure, or GCP - to migrate to and build on. It is now important to focus on assessing the technical expertise in your organization and upskilling your teams to enable them to work with these cloud platforms.
Migrating to the cloud will most likely - and this is often overlooked and not talked about - automate certain positions out of existence. But keeping skilled and qualified IT staff on board should be a priority: Identifying and reskilling people in these positions and offering them new and valuable opportunities within the organization is the way to go.
A cloud foundation team can offer consulting and training to support the ramp up.
3. Understanding cloud vendor lock-in costs
Enterprises must review and fully understand the costs that come with choosing a cloud service provider. The cost reduction promised by the cloud can only be achieved if the cloud transformation is done right and all costs are made explicit.
Going all-in with one cloud vendor leads to a strong dependence on their proprietary technologies. Switching costs are high and may prohibit the move to competing vendors further down the road.
Make sure to have a viable cloud exit strategy in place and go with a cloud governance solution that makes the organizational and technical transition to another vendor economically feasible.
In addition being credibly able to switch providers gives you strong leverage in negotiations.
4. Understanding the shared responsibilities in the cloud
A general rule is that the cloud provider is responsible for the security of the cloud, while you as their customer are responsible for the security in the cloud. However, there are other aspects that affect the shared responsibility model, e.g. the service model you are using (Iaas/PaaS/SaaS).
Here is an example: If you use a SaaS service like Google Docs, you don't have to take care of the VM images or databases this application is running on. If you deploy your own MySQL cluster to AWS EC2 instances, however, you are responsible to encrypt the connection via SSL or TLS.
Another important factor is to assign responsibilities clearly to the cloud foundation team and the DevOps teams. The cloud foundation can offer a security baseline with predefined cloud landing zones and takes care of organizational overhead. The DevOps teams have more freedom when working with the cloud - compared to the data center approach - and with that freedom comes the responsibility to take care of application security. The Cloud Foundation Maturity Model provides more insights on how to structure shared responsibility in a Cloud Foundation context.
5. Considering managed services
Migrating to the cloud is a major task in terms of organization, technology, and operations. Wanting to do everything in-house may be understandable but the already very busy IT teams just might not have the capacity or skill set to take on every project.
Making use of higher-level managed services may be the right choice to keep the cloud migration on track and within budget. You may want to have more than just infrastructure-as-a-service (IaaS) and use more than just one cloud service provider: That's also why an abstraction layer that unifies all clouds brings no value to your cloud transformation.
Even if you start off with a pilot project that your organization can handle capacity- and expertise-wise: The challenges will build up as you move on and broaden the scope of your cloud journey. That is a development we see quite often in the market - companies wasting time and money and then turning to external partners a good way down the road.
The same goes for intra-organizational services: Not every team should have to solve problems that other teams have already successfully overcome. Teams should be enabled to offer their solutions and services to other teams - via a cloud service marketplace - to push innovation and speed up development.
6. Developing an agile, cloud-native way of working
Going with a cloud strategy is only part of making full use of the competitive advantage the cloud can offer. Without an agile and cloud-native way of working the potential will not be fully explored. It is the prerequisite to moving the actual workload to the cloud and taking advantage of the scalability, flexibility, and speed the cloud can provide.
A cloud foundation or a cloud competence center should take care of the organizational overhead and enable developers to fully focus on their products.
A DevOps team lead should be able to provision a cloud account and deploy applications without the interference of some kind of central IT. Offering a self-service cloud account creation requires a high degree of automation. This reduces manual workload and with that reduces the "time-to-cloud" for the developers. Using an existing ITSM tool for cloud resource provisioning seriously limits the usefulness of the cloud.
Moving to the cloud is a deep-rooted transformation in an IT organization and means fundamental changes in how things are done. A cloud foundation team needs to evangelize the use of the cloud and empower the teams on their way. It can not be expected that everybody is on board with the cloud strategy right away. Some applications will have to be refactored - a lot of work - the transformation will only be successful if there are communication efforts to show that it’s worth it.