You’ve heard the joke, I’m sure - there is no cloud, just someone else’s computer. The joke gets even better when we talk about going cloud first by storing your data, source code, intellectual property on someone else’s “cloud,” which is just someone else’s insecure computer

So when your team consider going cloud first, how do you make sure the joke isn’t on you? That’s the million dollar question, and given the frequency of data breaches, you are smart to ask it. There are a lot of layers to that onion, so in answering that question, we will talk about why you would go cloud first, what may be preventing you from starting that journey, who and what you need on said journey, and what sort of compliance you will need to consider for cloud first longevity.

Benefits that outweigh risk

Before we get to that, most people would probably agree that the concept of storing sensitive and valuable data on someone else’s computer sounds objectively awful -- who in their right mind would want to go cloud first? As data and security professionals, we are also well aware of the headaches and heartaches preventing universal cloud first adoption: primarily, concerns over security, spend, resources, and performance. But clearly the benefits can be worth the risk. At this point in history, you have heard about the allure of going cloud first -- among other benefits, it is tempting to rapidly deliver features and quickly squash bugs.

First, any team’s kingpin is the lead/principal architect/engineer; after all, there is no cloud first architecture without the architect. This person may be you or a member of your founding team. This lead has intimate knowledge of the product, knows precisely where all the bodies are buried, and is your best resource for gauging implications of going cloud first. They will likely work very closely with the next hire you will need to make, if you don’t already have it - an individual contributor to develop and harden the cloud components. Titles here can vary from cloud security to dev ops to site reliability to cloud support, but the role remains the same - this person is your hands-on lead for maintaining your cloud-first product.

Finally, you will need to find an excellent lead for quality assurance and testing; your product can only be as robust as the tests run against it. This lead will manage continuous development/continuous integration, deploy any nightly builds, and handle feedback on broken unit tests. And if you’re very lucky, these three leads will work together harmoniously, even in the face of a production outage.

Technical debt vs flexibility

After getting the right people in place, the next step is technology. To start, your product needs a cloud platform on which to run. There are a few choices to consider - you’ve likely heard of the top contenders: Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure. While there’s no one-size-fits-all solution for platform selection, there are different credit programs on each that may interest you. It shouldn’t be the only factor in your cloud-first decision, try to take advantage for your platform of choice. But before going with your platform of choice, seriously consider looping in your stakeholders -- you may find strong opinions on cloud and trust.

If you’re migrating from on-prem to cloud, your core product/application is the master link in the chain your team will develop. As you add links to your chain, one of the first decisions you’ll make is whether to use a hosted solution or roll your own. The key tradeoff you are considering is alleviating technical debt vs flexibility. To make a concrete example -- many web applications require a database as a moving part; is it better to consider a hosted database solution (AWS RDS, GCP Cloud SQL, or Azure SQL Database), or develop infrastructure as code leveraging one of the many projects from the Cloud Native Computing Foundation (CNCF)? Best answers here will vary with individual teams and products. If you have the runway, consider maximizing your flexibility with technology from the CNCF. Project maturity and number of graduated projects continues to grow; the graduation criteria is well-defined.

Finally, after having the right people build the best technology stack for your product, if you are working with and storing personal data (remember that objectively awful idea from before?), you will need to contend with data governance. Compliance in this area has become more robustly defined in recent years with the General Data Protection Regulation (GDPR), and the California Consumer Privacy Act. The reason why this matters even to small businesses is that data breaches are not an “if” by “when” scenario -- and when said breach happens, if the breach doesn’t sink your business, the fine almost certainly will.

There is no easy way around improving a product without using data, but the best way to combat a future breach is to evaluate what data you collect and weigh its worth against the risk of a potential breach and subsequent fine. After some consideration, you may find a great deal of value in minimizing risk through mindfully collecting less data.