When we first built the Datica Platform in early 2014, we did so from scratch using the resources and tools that were available to us. Since then, cloud technology has skyrocketed. Datica’s core value is not in our choice of developer tooling — it’s in building tools and software for managing security and compliance. Kubernetes has matured to the point that we feel confident offering it as the primary technology that our Platform works with.
Important points about Kubernetes:
- Supported by one of the largest open source communities in the world
- Financially backed by hundreds of technology organizations world-wide
- Mature enough for production
- Has an alignment of values — secure, principled development
- It’s cloud agnostic
When can I migrate to the new Platform?
Once the platform is generally available, you will be able to work with your Datica account manager to plan a migration structured around the specific needs of your business.
How do I architect my application for this new Platform?
Considering that the new Platform’s core experience is Kubernetes, there are no major differences between a stock Kubernetes developer experience and the Datica HIPAA compliant Kubernetes experience. As a result you can begin building your application to work with Kubernetes right away. For those brand new to containerization, we recommend this tutorial. For those more familiar with containerization, we recommend this tutorial. We also have a layout of how to configure your ingress and services in this GitHub repo.
If you need assistance modifying your application to work with Kubernetes, we have a number of different partners we can recommend to help. Please contact us at firstname.lastname@example.org to hear more.
So what are the differences between stock Kubernetes and Datica’s Kubernetes on AWS?
Datica secures and locks down the underlying infrastructure. We do this by provisioning a new VPC and configuring it safely and properly. Once the VPC and infrastructure are stood up and configured, we deploy a Kubernetes cluster into the new VPC. Inside of the new Kubernetes cluster we deploy and configure logging, monitoring, intrusion detection, and antivirus scanning. Additionally, we also configure backups, networking and vulnerability scanning. While these components are core deployments to the Kubernetes Platform and ensure compliance, we may open these up for custom configuration in the future. Once the cluster and all system components are provisioned, configured, and validated, we then give you access to the cluster. By aggregating logging, monitoring, intrusion detection, and vulnerability scanning data, Datica can get the real-time compliance state of your cluster. This state is checked every five minutes by Datica’s ingestion mechanism to ensure that the expected compliance state and your current running state match.
What are my deployment options with the new Platform?
Unique to the new Platform is the option to have Datica deploy and configure the cluster within your own AWS or Azure account. This gives you the option to manage and control the underlying infrastructure. Additionally, you can also have Datica deploy your new cluster within a Datica-controlled cloud account that we create on your behalf.
Am I responsible for more compliance requirements with the new platform than the existing legacy platform?
Datica will still offer its first-in-class BAA with the new Platform. While there are specific compliance requirements that you will be responsible for, it’s very similar to how the current Platform works. Everything from the application layer and above is your responsibility. This means you need to ensure your containers and deployments are compliant. The one exception to this rule is that Datica will ensure the compliance of “Datica-built” deployments. Those include logging, monitoring, intrusion detection, and antivirus.
How long do I have to migrate?
Datica is committed to assisting customers in migrating to the new Platform. Our goal is to have individual conversations with each customer by the end of June. By July we want to have migration plans in place for all Legacy environments. Between July 1 and December 31, customers not already on the new Platform must migrate. Starting in January 2019 we will begin shutting off the Legacy Platform.