Moving to the cloud can bring about company-wide transformations, and understanding them is key to success.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
If deploying to your platform, define data flow and how data is stored at rest. In addition, discuss:
In addition to the above, ask SaaS (or MSPs) vendors questions regarding:
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!
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply