Continuous Deployments and Data Sovereignty: A Case Study

In any production rails application’s simplest form, there is one version of the app deployed to a single host or cloud provider of your choice, but what if there were laws and regulations in place that required your application to be replicated and maintained within the geographical boundaries of other countries. This is a requirement of countries that have data sovereignty laws and a regular hurdle to overcome when dealing with sensitive data such as protected health information. This talk provides a case study of how we devised an automatic deployment strategy to deploy to multiple countries.

Transcript

1. Continuous Deployments and Data Sovereignty: A Case Study Rails Conf 2018 Pittsburgh 4.17.2018
2. Hello!
5. You may know me from… • Life.io • Soon to be Stitch Fix • Talks fast • Previously got to speak about my biggest professional failure • Excited to talk about something other than failure
6. Preamble
7. A Few Words On Data • We generally work in information • “Data” and “Data Science” have been thrust into the spotlight • Consider Regulatory Science
8. Terms
9. Health Insurance Portability and Accountability Act (HIPAA) • Enacted in 1996 • For the United States (foreshadowing) • Health Information and Technology for Economic and Clinical Health expansion (2009, added to HIPAA in 2013) • Cloud service provider coverage added in 2016
10. Data Sovereignty • Sometimes called Data Residency • Sovereignty refers to data being subject to the laws of its location • Residency refers to all data processed and stored within a country’s borders
11. Continuous Deployment • I may have cheated (a little) • For production, this was more “continuous delivery” • For staging, this was “continuous deployment” • Regulatory and client related concerns for release
12. The Problem Let’s be a health care startup! found searching “business people”
13. Let’s Be a SaaS Startup more specifically found searching “hip business people”
14. The Occasional Myth of Convenience • We have some great tools at our disposal in this ecosystem • Rails, PostgreSQL, Heroku, GitHub, CI apps, et al • Encompass the majority of what one reasonably expects to need
15. Back To Our Startup • Decided to be a SaaS company • Let’s collect sensitive user information • Let’s assume all our clients are in the United States • Let’s have our first client not be in the United States • Let’s evaluate our infrastructure found searching “startup people”
17. International Logistics • First time we considered requirements beyond HIPAA • Our potential clients were global entities • Take stock and see what works
18. AWS Data Centers
19. Option #1 • Create a new branch for every region • Advantages: white labeling ease, handle region specific requests easily, low initial time cost • Disadvantages: complete logistical nightmare
20. Option #2 • Regional Deployments • Advantages: One code base, continues the notion of single platform, multi tenancy. • Disadvantages: Some loss of functionality • Consider the case of International Conglomerate Business Co
21. Decided to go with #2
22. Implementation • We knew to continue using GitHub, Semaphore, and Heroku (within the United States) • Needed to introduce AWS • Containerized offering Elastic Beanstalk • Semaphore had AWS support for Elastic Beanstalk
23. An Example
48. Findings • Pros: Effective, scalable • Cons: Steep learning curve, expensive, managing all server configurations could be unwieldy, initial loss of functionality Found searching for “business findings”
49. Next steps • Decomposition of the application • This infrastructure may be best suited for a service based architecture (pending legal considerations). • Consideration of operational costs found searching “business steps”
50. Recommendations • Think hard about your audience before building something • Are you storing sensitive data? • Just because its there, doesn’t mean you need it
51. Thanks! Mike Calhoun / @comike011