Frank Ford – Achieving Workload Portability AND Remaining Compliant Using GitLab and Kubernetes

You'd probably rather be in the public cloud, but sometimes regulatory company compliance and legal restrictions necessitate an on premise solution in achieving workload portability and remaining compliant using GitLab and Kubernetes, Frank Ford of Genworth, will explore ways to remain compliant with an on prem solution. While you work through your organization's public cloud challenges. He'll show you how to do that using GitLab and Kubernetes.

This is GitLab Commit Virtual 2020, and this is achieving workload portability and remaining compliant using GitLab and Kubernetes. I am Frank Ford. T.

architecture design manager for Genworth. Personally, I'm passionate about integration, continuous development, DevSecOps, automation in general, and cloud a little bit about Genworth. Genworth is a financial services company.

Currently, we sell long term care insurance and mortgage insurance, but we also administer life insurance and annuity blocks of business. Our corporate headquarters is in Richmond, Virginia, and my home office is in Lynchburg, Virginia. Just a little bit of a level set to be talking about public cloud and on premises today.

And when I'm referring to public cloud, I'm talking about the big three public cloud providers. So Amazon, Google and Microsoft. And on Prem, I'm referring to on premises.

So these are this is your actual data center, whether it's hardware that you own or something that you've contracted out to another company, it's it's actual on your on premises data center. Now, when we're talking about public cloud, there's a number of advantages that public cloud brings to the table. So in public cloud being on demand, everything being very dynamic and elastic, you provision just what you need and everything is very quick to provision in terms of pricing.

It's the pay as you go pricing model. So you're only paying for the resources that you're actually using, which can present a cost savings to your company. You don't have to worry about maintenance of the hardware because you're running on somebody else's computer.

So the main limitation here is your particular budget, your costs or how much your wallet can actually handle. There are a number of challenges. The contracts present a fair number of challenges.

So you more or less accept the general taxes from the big public cloud providers and then you can add BAA's to those to kind of help structure the contract. So to add a little bit more protection for you, pricing around pay as you go can actually sometimes be a hindrance. If your sourcing department likes to budget lots of dollars and they want to try and allocate those dollars to a particular budget year.

Data security, privacy, you are responsible for securing and making sure that your data remains private inside the public cloud, also adhering to regulations. So things like for for HIPA, GDPR are things like that. You need to make sure that your workloads that you want to run in public cloud, adhere to those particular regulations, access restrictions, making sure that only the right people have access to your public cloud infrastructure and understand that you're also potentially increasing your attack surface, especially if you have your public cloud infrastructure hooked into your corporate network.

So understanding those entry points is is a big thing and also understanding your organization structure and making sure that your organization is actually ready to proceed to public cloud. So you may actually know that your end goal is public cloud, but your organization may be moving through, navigating some of these challenges and or you may just kind of be handcuffed by regulation and some of that needs to be sorted through. So how do you how to maintain some of that momentum or in some cases generate momentum to get yourself started while you wait for some of that stuff to actually be worked through?

Staying on Prem is a good way to either help build or maintain momentum for moving to public cloud. If you if you know your target public cloud, the big three public cloud providers offer on prem solutions to help aid in this effort. So Amazon outpost Google and Microsoft Azure stack.

However, those costs money. You may not necessarily have the budget for one of these, or you may actually need to prove some value in some of these things so Kubernetes can actually help with that. There's a there's a couple and then there's a few more.

But but listed here, RKE allows you to very quickly spin up a Kubernetes cluster in a using just docker containers and Kubeadm allows you to bootstrap your own Kubernetes cluster if you feel like taking on that challenge. This is an example of a of a of an RKE cluster yaml and the process for getting that spun up. Like I said, it runs you can.

M. or bare metal that just has docker containers, that just has Docker installed, it spins up in docker containers, you can very easily spin up a multi node cluster. And like I said, the the configuration is contained in the cluster YAML file over here to the side.

And really all you do is you you write this file, you run RKE, you wait a minute or two and within a little bit of time you have a fully functional single or multi node Kubernetes cluster. So now we get to the fun part of workload portability, so we've talked about, OK, we're we're building some workloads on Prem and we know we're eventually going to need to migrate them to public cloud. As you're starting to spin some of these workloads up, you need to think about workload portability.

So you're going through your you're building new workloads, you're going through your Micro Services transition, or you're migrating existing applications to application containers and you plan to orchestrate them using Kubernetes. Workload portability needs to be at that forefront of what you're thinking about as you're as you're kind of designing and working through these efforts. GitLab can assist with some of this.

GitLab has the ability to target on Prem and resources. And GitLab also has some features such as Crossplane, that can help with your multicloud deployment and also portability issues as well. Just some caveats here.

And I'm going to read this verbatim because it's very important is just because your application is CONTAINERIZE and orchestrated with Kubernetes does not guarantee that the workload is portable. So something that you need to think about are. Please continue to take work with portability into your design as you're designing new workloads, but also think about external external dependencies, does your application need an external good balance or does your application need persistence?

Does your application need connectivity to your corporate network? Also to think about is your application stateless or stable? All of these things kind of help guide you when it comes to being able to build portable workloads.

So now that we've talked about workload portability, we need to talk about compliance, being able to to automate, automate, automate, automate. Automation is the the best and most key aspect to remaining compliant with your your your CI/CD process. So building a CI/CD process preferably in GitLab allows you to make sure that you are following the same procedures at every step along the way.

You have a defined, repeatable process that you know is going to deploy your your application the same way every time adopting infrastructure is code stored and version control provides you with a kind of a golden copy running configuration that can be reviewed and audited at any point in time. And you can also leverage open source tools to apply policy to your your your environment. So taking advantage of open policy agent to apply policy at various levels of your environment.

So Conftest allows the integration of the policies and policies into the CI/CD pipeline. Gate Gatekeeper is a Kubernetes admission controller which can apply policy at the Kubernetes cluster level. And then also open policy agent has plug ins for numerous things, such as being able to apply policy to your infrastructure as code, as well as things like at the network level, monitoring your cluster, so leveraging Prometheus Grafana for visualization of of metrics and things like that.

And also when you do get to public cloud, having a cloud security posture, management solution, there's a number of them out there, kind of helps keep you compliant as you as you migrate to the public cloud. So conclusion's public cloud is great. Sometimes it doesn't necessarily make sense for everybody right off the bat, whether that's due to external regulation, some company policy or you actually need to show and value of some of these things.

To some folks using some open source tools, you can very easily spin up a cluster on Prem and of course, utilize and GitLab and additional open source tooling. You can easily implement secure and compliant CI/CD pipelines on Prem and those can then be migrated to any Kubernetes cluster that you wish to migrate to. So thank you.

And I have my my email and Twitter there, I will warn you that my Twitter is mainly auto racing and Virginia Tech football. So thanks, everybody.