A move to the public cloud presents a unique set of challenges and possibilities that have been explored ad nauseam. Rather than regurgitating the choices and potential pitfalls you have in front of you, I thought it would be helpful to talk about Smartsheet’s journey to the public cloud after more than ten years of pre-public cloud experience, and what we’re learning along the way.
Staff to Support Multiple Clouds
The public cloud offers an unprecedented opportunity to change the way IT has previously managed capital expenditure. That said, we knew that once our data was in one cloud, moving would be hard. And the larger our dataset the worse off we would be. So in planning our move to the public cloud, I have started budgeting for people on staff that know how to support more than one cloud.
This is not simply for the economic advantage of running our business in the public cloud rather than in-house. Having people on board who can run and manage our existing infrastructure, as well as an infrastructure in the public cloud, helps with business continuity and provides consistent support for tools through versions.
I realize not everyone can afford to staff this way. If you’re not able to build out a team who can run and manage infrastructure in the cloud, focus on minimizing the number of cloud-specific tools you are using, so that changing platforms will not cost you an inordinate amount of development effort.
Structure Ops to Build Expertise
Over the past 6 years, Smartsheet tech operations has automated the provisioning and management of our virtual machines on bare metal hardware. We have built monitoring, alerting, and deployment code for our app to allow us to maintain, grow, and improve our infrastructure at no small investment. We knew it would be a multiyear journey to the cloud for us, so we set a course that would allow us to yield the benefit of the public cloud while our organization built up its expertise.
Our path here was to remain on common software and work on the operations of that common software in a different setting. This was much like choosing Linux and using different hardware vendors was in the past. Now there are more pieces and parts but the concept still holds.
Over the last two years, we have begun deploying parts of our app in the public cloud, but have continued to use the same tools (Puppet, Grafana, Docker, etc.) in this new public cloud context. This change did require the addition of several people to understand how to deploy into that cloud. However, the next cloud deployment will have a smaller incremental cost, as we are now supporting our own infrastructure and public cloud at the same time.
Go Slow to Make Adjustments and Mitigate Risk
Slowing down and testing whenever possible has made it easier for us to course correct without causing major issues for our organization. Before we began our move to the public cloud, we set expectations with the business that the transition would take a while. We made it clear that our existing infrastructure wouldn’t turn off the next day, nor would we want it to.
One approach we took to get started was to deconstruct our app so that we could test elements in the cloud without affecting the whole. For instance, Smartsheet offers a data connection platform into Salesforce. This enables our customers to manage processes while seamlessly integrating into their sales, finance, and support organizations.
The service that we developed for this used our own API infrastructure tied to Salesforce. What soon followed was an understanding of how to enable our developers to create multiple add-on apps for the cloud. Had we made the wrong choice here or if it was too complicated, we weren’t betting the future of our whole infrastructure.
This measured approach has also allowed us to critically evaluate vendors and figure out which ones make the most sense from an operational point of view. We make sure we can pilot systems before we engage the generous professional services that cloud providers offer, as they are driven to get us to shift to the cloud, not necessarily to help us make the best long-term decisions.
For instance, we’ve taken the time to think through what it would mean to deploy to more than one public cloud by evaluating three of the players in the space. For the candidate system, we chose our cloud development environment. If it takes a long time or if we learn something about Azure vs. GCP vs. AWS during this process, our current development systems will continue to run without a hiccup.
There will always be new learnings, as the architecture of each of these systems is dramatically different. Giving ourselves permission to change our minds has allowed us to think about strategic opportunities with cloud vendors and take advantage of the systems that give our end users the best product.
Your Journey to the Cloud
Moving to the cloud will look different for everyone. But no matter what shape your transition may take, you can’t start soon enough. The more time you have to make your move the less risk you have to absorb. Find a candidate system to move and start working on it tomorrow. Let the business know that it will take a while. But don’t wait to get going. A journey of a thousand miles and all that. Take the first step today, and good luck on your journey to the cloud.