[MUSIC PLAYING]
DUSTIN KIRKLAND: Hello, I'm Dustin Kirkland,
product manager at Google and your host
at KubeCon Copenhagen. I'm joined here by Khash Sajadi.
He's the CEO and founder of Cloud 66,
and he's going to tell us a little bit about his path
to Kubernetes.
KHASH SAJADI: Sure.
Thank you.
So we are a SAS company.
We deliver developmental tools for software companies.
And as a result of being a SAS company,
we were hosting our applications for the past four
and half years on AWS, CC2--
a normal setup of a cloud setup.
And as part of our products, we were
building Kubernetes clusters for our customers
to deploy their applications.
Ultimately, the rigidity of including and introducing
new infrastructure components to our own infrastructure setup
that runs Cloud 66 SAS led us to move over to running
Kubernetes ourselves.
While we consider ourselves experts in Kubernetes,
and we build that for our customers,
we wanted to decouple the risk and not
have too much of an inception, if you will.
So we moved to the best Kubernetes
that we could find outside of Cloud 66,
and that was Google GKE.
So the migration planning for us took about three to four
months, and most of it was spent around risk mitigation and data
transfer planning for our customers to have--
we have customers in about 120 countries.
So there's no night time.
There's no downtime.
We had to do that in a seamless way as much as possible.
And then the migration itself took a day.
DUSTIN KIRKLAND: Wow.
KHASH SAJADI: So we planned the whole thing
and we did the entire thing in a day.
DUSTIN KIRKLAND: So three to four months planning,
a day to do the migration?
KHASH SAJADI: Yes.
So our move to GKE was smooth.
As a result, it cut our infrastructure costs
by about 60%.
But I think the best takeaway that we took away
from moving to Kubernetes, and GKE in this instance,
was it added to the agility of our production and operations
team.
We wanted to be able to introduce
new components and joint infrastructure,
like search components.
And we didn't want to learn maintenance
of yet another product, or having to go and outsource
that from third-party vendors all around,
making us more dependent on a variety
of different components.
DUSTIN KIRKLAND: Now, that 60% cost savings
on the infrastructure, is that primarily savings
on the management layer?
KHASH SAJADI: There is a part that's not very tangible,
and that's how much time we spend less
on managing infrastructure, which is on another P&L.
Which I wouldn't know much about.
I don't have that much visibility over it,
because it's kind of funny money in a way.
But when it comes to spend, we now
tend to spin up bigger boxes, as in VMs,
and pack them much more efficiently.
Before we had one component that would take over
the entire server but would be utilized at 20%.
Now we can move workloads around and make it more flexible.
DUSTIN KIRKLAND: Right.
OK.
So Kubernetes has helped Cloud 66.
Tell me a little bit about Cloud 66's business.
What do you guys do with Kubernetes?
KHASH SAJADI: So our SAS product-- we have two products.
One is scaffolding and building Kubernetes clusters
for our customers, but our focus is not doing that.
As building the container side of the story,
we are mostly focused on workloads
that you don't run inside of the containers, like database
backups, replication, firewall, audit management, access
to service.
That's called Cloud 66 Maestro.
And we actually built a product out of our experience
of moving to Kubernetes and managing our deployments
through Kubernetes, which we call Cloud 66 Skycap
or container delivery pipeline.
We had to make sure two things happen before we
can move to Kubernetes.
One is the technical engineering side of it,
which you have one application.
You usually break it apart into microservices,
and then you wrap them into containers,
and you write a bunch of configuration
files for Kubernetes to run.
That part is the easy part.
As an engineering team, we are fairly capable of doing that.
The part that we had to make sure that happens
is, do we have the toolset to change
the mentality of the team that not the entire application goes
out at the same time?
Somethings are dependent on other ones
when the deployment happens.
How do we know that now that we have
two version controls, essentially, one Git and one
Docker registry, for example, we can trace and track things
down?
We can track and trace things down
in terms of the assets that are now
broken apart into hundreds of containers of micro services.
How can we take care of security secrets
and also make sure that our IP is not linked into one
of the layers of Docker image?
All of that leading in to actually building a product out
of that experience.
We are a product company, and we provide that as a SAS
or offering to our customers.
So we took that opportunity and productized our learnings.
DUSTIN KIRKLAND: Now, application development
on Kubernetes takes a bit of a different approach.
What did you learn on that aspect of your journey,
on your road to Kubernetes?
KHASH SAJADI: That's a very good question.
So in previous life, I've worked as a software architect
for larger enterprises, mostly investment banks,
and what I've experienced was very, very, similar
to the experience that I had with Martin Fowler's way
of doing microservices and service-oriented architecture,
if you will, based on contracts.
It doesn't necessarily have to be broken up
into multiple services.
But we found that applying those principles when
it comes to contract-based development
and having a definitive internal API between services
always helps, regardless of whether that codebase is
one codebase or you break it up out
into physical different codebases.
DUSTIN KIRKLAND: Great.
So I understand that we've got a bit of a demo here?
KHASH SAJADI: Yes
DUSTIN KIRKLAND: All right, let's see it.
KHASH SAJADI: Great.
OK, so we have, as part of Cloud 66 Skycap,
which is container delivery pipeline into Kubernetes,
an application that is just one simple service,
and I wanted to deploy that to GKE.
So here's what we do.
We have a concept of a formation.
And formation for us is a deployment destination.
It's like, environments don't have it anymore,
because you might have five productions and 12 stagings
just because you can do that based on a Kubernetes
namespace.
We do that.
And here, I'm adding different parts of the application
based on templates--
Kubernetes native templates-- that we have in a Git
repository.
The idea for us was to not wrap the Kubernetes API
into yet another API.
To just control the access of our team to Kubernetes,
we wanted developers to have the full access
and experience the full benefits of Kubernetes
when it comes to templates.
But also, for the ops teams and ops people
to have a say over how things are deployed.
So here I'm setting up a namespace from my Kubernetes
information.
And here, I'm doing a deployment of a service.
So this is a normal Kubernetes deployment asset,
as you can see.
And the idea is that my ops team will dictate,
if you want to deploy or add a deployment to Kubernetes,
how should it look like.
For example, if you're running on GKE,
you might want to run on Cloud SQL as well,
and therefore you need cloud proxy
as a side car for production, but this is not
a concern for staging.
Therefore, my ops guys can dictate that,
I'm going to add the port for my service,
enter to the command that starts it in a normal Kubernetes
or Docker-friendly way.
In this instance, I'm running RADIUS directly here
as a container.
And this is all backed by a Git repository,
so you can use normal Git flow as opposed to using the web UI.
And the last step for this is to create a service that
represents that deployment.
Again, this is more ops teams' opinion on how
the service should look like.
And this comes from a Git repository itself,
so you can evolve this.
Here, because I'm deploying to GKE, instead of a node balance
I'm using a load balance there.
So GKE will fire that up for me and save the changes.
And because we were running RADIUS,
we are going to run RADIUS inside of my cluster as well.
I'm going to just fire up RADIUS.
Now, this could be a Helm chart that I can get off
the shelf and just deploy RADIUS,
or it could be my team's opinion on how RADIUS should
be deployed in my organization.
And once I have all those components, what happens
is what we call taking a snapshot of your application,
which will take a snapshot of all
your codebase, all pre-built images
that you have for your application,
and then all of those will result
in a rendered set of Kubernetes native configuration files
that you can then apply to your cluster.
I'm just going to get the command that
will generate that.
We do support multi-accounts, so I'm just
going to switch it to our demo account,
and then paint that onto a Kube control
and apply it to my cluster, which
is the GKE Cluster that I have.
So the namespace-- the secret, which
would be the Docker registry that we provide, all of that
is going to get created.
The namespace is there now.
And let's check the pods.
Great.
So the pods are running.
And I'm going to just quickly check
the service to make sure to look balancer is up.
OK.
So the IP address is now getting started.
I'm going to just put a watch on it.
It's up now.
OK.
So I'm just going to get the IP address that GKE gave me,
and there we are.
So my app is up and running.
But most importantly-- this was a simple app, obviously.
But this is based on the opinion that my operations guys
want me to have.
And I can then switch this formation
into another deployment target that
is running a homemade Kubernetes cluster that
doesn't require certain things.
Or my ops guys can force my developers
to every time they add a new deployment, for example,
they need to have a sidecar for log shipping, for example.
So it gives you the flexibility of a Kubernetes API
without the risks of being able to change things
in the entire cluster that you're not supposed to.
DUSTIN KIRKLAND: Yeah.
That's super interesting.
I can see how this would drastically improve and speed
up some development cycles.
All right, Khash, thank you very much for your time.
Cheers
[MUSIC PLAYING]