WEBVTT
00:00:00.000 --> 00:00:02.419
For the last decade, the default infrastructure
00:00:02.419 --> 00:00:05.820
answer has basically been cloud first, Kubernetes
00:00:05.820 --> 00:00:09.039
probably, and then good luck to whoever has to
00:00:09.039 --> 00:00:11.679
operate the thing after the architecture diagram
00:00:11.679 --> 00:00:15.240
gets turned into real life. And to be fair, the
00:00:15.240 --> 00:00:18.219
cloud solved a lot of real problems. Nobody wants
00:00:18.219 --> 00:00:20.980
to go back to waiting on hardware, filing tickets
00:00:20.980 --> 00:00:24.000
for VLANs, or discovering that the one person
00:00:24.000 --> 00:00:27.800
who understood the SAN is on vacation. But there
00:00:27.800 --> 00:00:30.489
is another side of this now. Cloud bills are
00:00:30.489 --> 00:00:32.990
getting harder to explain. Kubernetes platforms
00:00:32.990 --> 00:00:36.229
are getting harder to maintain. Data sovereignty
00:00:36.229 --> 00:00:39.530
is becoming a real business requirement. And
00:00:39.530 --> 00:00:41.950
a lot of teams are quietly looking at all of
00:00:41.950 --> 00:00:44.289
the layers that they have built and asking a
00:00:44.289 --> 00:00:47.049
pretty reasonable question. Is this actually
00:00:47.049 --> 00:00:49.899
simpler? because sometimes the thing that was
00:00:49.899 --> 00:00:52.899
supposed to reduce operational burden just moves
00:00:52.899 --> 00:00:55.500
the complexity somewhere else into Terraform
00:00:55.500 --> 00:00:59.100
into Helm charts into networking into managed
00:00:59.100 --> 00:01:02.579
service glue into a platform team that is now
00:01:02.579 --> 00:01:05.879
responsible for making 15 different abstractions
00:01:05.879 --> 00:01:09.200
feel like one coherent system and that is really
00:01:09.200 --> 00:01:11.799
what this conversation is about not cloud is
00:01:11.799 --> 00:01:15.099
bad not bare metal is back everybody grab a screwdriver
00:01:15.099 --> 00:01:18.659
more like What happens when teams want more control,
00:01:18.879 --> 00:01:22.159
more predictable cost, better performance, and
00:01:22.159 --> 00:01:25.140
less platform sprawl without going back to the
00:01:25.140 --> 00:01:27.900
old-school pain of managing infrastructure by
00:01:27.900 --> 00:01:30.659
hand? I'm Brian Teller from Teller's Tech, and
00:01:30.659 --> 00:01:49.989
this is Ship It Weekly. Welcome back to Ship
00:01:49.989 --> 00:01:52.430
It Weekly, where I filter the noise and focus
00:01:52.430 --> 00:01:54.909
on what actually matters when you are the one
00:01:54.909 --> 00:01:56.790
running infrastructure and owning reliability.
00:01:57.310 --> 00:02:00.349
Most weeks, it's a quick news recap. In between
00:02:00.349 --> 00:02:03.390
those, I do conversation episodes with people
00:02:03.390 --> 00:02:05.930
who are building platforms, running infrastructure,
00:02:06.269 --> 00:02:09.090
organizing events, and thinking through where
00:02:09.090 --> 00:02:12.129
this industry is actually headed. Today is one
00:02:12.129 --> 00:02:14.870
of those conversations. I'm joined by Jake Warner,
00:02:15.090 --> 00:02:19.419
founder and CEO of Cycle.io. Cycle is an infrastructure
00:02:19.419 --> 00:02:22.639
platform that lets teams run containers and virtual
00:02:22.639 --> 00:02:25.900
machines across bare metal, cloud, private cloud,
00:02:26.099 --> 00:02:29.000
and hybrid environments without trying to turn
00:02:29.000 --> 00:02:32.139
every company into a full-time platform engineering
00:02:32.139 --> 00:02:35.240
shop. And I like this conversation because it
00:02:35.240 --> 00:02:37.960
gets into a topic that a lot of people are thinking
00:02:37.960 --> 00:02:40.379
about right now, even if they are not always
00:02:40.379 --> 00:02:43.020
saying it out loud. A lot of teams are tired,
00:02:43.180 --> 00:02:46.800
not lazy, not anti-cloud, not anti-Kubernetes,
00:02:47.400 --> 00:02:50.060
just tired of the amount of complexity that has
00:02:50.060 --> 00:02:52.860
piled up around modern infrastructure. You start
00:02:52.860 --> 00:02:55.860
with a simple goal. Run the application. Scale
00:02:55.860 --> 00:02:59.520
it. Deploy safely. Keep it reliable. Don't spend
00:02:59.520 --> 00:03:02.400
a fortune. Then suddenly, you have Kubernetes
00:03:02.400 --> 00:03:06.500
clusters, node groups, disruption budgets, autoscalers,
00:03:06.659 --> 00:03:10.319
Terraform modules, managed services, IAM policies,
00:03:10.900 --> 00:03:14.580
GitOps controllers, observability agents, service
00:03:14.580 --> 00:03:18.199
meshes, secrets systems, and a Slack channel where
00:03:18.199 --> 00:03:21.039
somebody asks why the platform is blocking delivery.
00:03:21.379 --> 00:03:23.719
And somewhere in the middle of that, people start
00:03:23.719 --> 00:03:26.460
wondering whether there is another way to think
00:03:26.460 --> 00:03:29.620
about infrastructure. In this conversation, Jake
00:03:29.620 --> 00:03:32.400
and I talk about why some teams are moving back
00:03:32.400 --> 00:03:35.539
toward private cloud and bare metal, but not
00:03:35.539 --> 00:03:38.039
in the nostalgic racking and stacking servers
00:03:38.039 --> 00:03:41.039
was awesome kind of way. More because of cost,
00:03:41.300 --> 00:03:45.439
performance, data sovereignty. and wanting more
00:03:45.439 --> 00:03:48.280
ownership over the stack. We also get into what
00:03:48.280 --> 00:03:50.500
people still misunderstand about bare metal,
00:03:50.620 --> 00:03:53.360
why some teams want VMs and containers living
00:03:53.360 --> 00:03:55.879
together, where Kubernetes is still the right
00:03:55.879 --> 00:03:59.120
answer, and where an opinionated platform might
00:03:59.120 --> 00:04:01.780
be a better fit than giving every team every
00:04:01.780 --> 00:04:05.009
possible knob to turn. There's also a good thread
00:04:05.009 --> 00:04:07.729
in here around failover versus active-active
00:04:07.729 --> 00:04:11.050
systems, stateful workloads, why application
00:04:11.050 --> 00:04:13.969
-level replication often beats platform-level
00:04:13.969 --> 00:04:17.189
magic, and what it really means to make raw infrastructure
00:04:17.189 --> 00:04:20.069
feel like a cloud-like resource. And towards
00:04:20.069 --> 00:04:23.870
the end, we talk a bit about AI workloads, GPUs,
00:04:23.949 --> 00:04:26.750
hype cycles, and why the most bleeding-edge
00:04:26.750 --> 00:04:29.889
teams are not always the same teams that want
00:04:29.889 --> 00:04:32.600
an opinionated platform. So if you work around
00:04:32.600 --> 00:04:36.600
DevOps, SRE, platform engineering, cloud infrastructure,
00:04:37.060 --> 00:04:40.199
Kubernetes, private cloud, or you are just starting
00:04:40.199 --> 00:04:42.720
to wonder whether your modern platform has become
00:04:42.720 --> 00:04:45.540
a very expensive junk drawer, this one should
00:04:45.540 --> 00:04:47.939
be worth your time. All right, let's jump in.
00:04:53.000 --> 00:04:56.439
Today, I'm joined by Jake Warner. He's CEO and
00:04:56.439 --> 00:04:59.180
founder of Cycle.io. We're going to be talking
00:04:59.180 --> 00:05:02.449
about private cloud, bare metal, and why a lot
00:05:02.449 --> 00:05:05.709
of teams are quietly exhausted by platform complexity.
00:05:06.250 --> 00:05:08.750
Jake, thanks for joining me. Thanks for having
00:05:08.750 --> 00:05:10.910
me. Give me your thesis. Why are teams pulling
00:05:10.910 --> 00:05:13.310
back toward private cloud and bare metal again?
00:05:13.529 --> 00:05:16.029
So, you know, for most of the people watching
00:05:16.029 --> 00:05:17.769
this podcast, we all knew that bare metal was
00:05:17.769 --> 00:05:21.430
really sexy a decade ago, right? 15 years ago.
00:05:21.529 --> 00:05:24.449
The cloud made it super easy to move away from
00:05:24.449 --> 00:05:27.509
bare metal. It solved the big complexity that
00:05:27.509 --> 00:05:31.319
came into, you know, I mean. We all know how
00:05:31.319 --> 00:05:32.980
hard it was to get a bare metal server online,
00:05:33.139 --> 00:05:35.079
get it configured, do it at scale. In the early
00:05:35.079 --> 00:05:36.899
days of Cycle, I'd always say, you know,
00:05:36.899 --> 00:05:39.819
anyone can deploy one or two servers. But when
00:05:39.819 --> 00:05:41.720
you need to start automating 100 servers, that's
00:05:41.720 --> 00:05:43.439
when the problems get really complex, right?
00:05:43.740 --> 00:05:46.519
I'm guessing most people listening to this podcast
00:05:46.519 --> 00:05:49.829
are completely aware of that. With what we built
00:05:49.829 --> 00:05:53.149
with Cycle, our goal was to simplify that process
00:05:53.149 --> 00:05:55.769
so that way you could have companies that were
00:05:55.769 --> 00:05:58.509
able to own their bare metal, et cetera, and
00:05:58.509 --> 00:06:00.290
still provision it like a cloud-like resource.
00:06:00.569 --> 00:06:03.269
And the reason why we kind of did that and why
00:06:03.269 --> 00:06:05.269
we see companies coming back to bare metal is,
00:06:05.329 --> 00:06:08.389
number one, cost. Hyperscalers ended up, you
00:06:08.389 --> 00:06:10.660
know, they made it really easy. But we've all
00:06:10.660 --> 00:06:12.579
seen hyperscalers just continue to increase costs.
00:06:12.720 --> 00:06:14.220
And once you get locked into that ecosystem,
00:06:14.519 --> 00:06:16.439
your costs kind of only go up. So that's number
00:06:16.439 --> 00:06:19.339
one. Number two is about data sovereignty concerns.
00:06:19.480 --> 00:06:21.639
I think especially with a lot of the geopolitical
00:06:21.639 --> 00:06:23.019
issues that we're seeing in the world right now,
00:06:23.079 --> 00:06:24.759
most of the companies that we've been working
00:06:24.759 --> 00:06:26.560
with are companies that are saying whether it's
00:06:26.560 --> 00:06:29.500
compliance reasons or they have customer demands,
00:06:29.779 --> 00:06:32.199
maybe is the right term for it. We have companies
00:06:32.199 --> 00:06:34.689
that are coming to us and saying. we cannot be
00:06:34.689 --> 00:06:38.149
on a US-owned hyperscaler. Even if geographically
00:06:38.149 --> 00:06:40.050
that infrastructure is sitting over in Europe,
00:06:40.209 --> 00:06:43.509
we need to, because of the US Cloud Act, we have
00:06:43.509 --> 00:06:45.790
companies that are saying we cannot be on US
00:06:45.790 --> 00:06:48.209
-owned infrastructure. So I think that in terms
00:06:48.209 --> 00:06:49.689
of private cloud, in terms of bare metal, it
00:06:49.689 --> 00:06:51.769
all kind of comes back to number one, cost, number
00:06:51.769 --> 00:06:54.410
two, data sovereignty and compliance. And then
00:06:54.410 --> 00:06:56.850
the third item there would be performance. And
00:06:56.850 --> 00:06:59.250
for a long time, I think people kind of... gave
00:06:59.250 --> 00:07:01.949
up the performance that bare metal would give
00:07:01.949 --> 00:07:04.730
because of the ease of the cloud outweighed the
00:07:04.730 --> 00:07:06.769
performance you got from bare metal. But fast
00:07:06.769 --> 00:07:08.689
forward to today where you have platforms like
00:07:08.689 --> 00:07:12.709
what we've built that can make bare metal a cloud
00:07:12.709 --> 00:07:14.790
-like experience on top of bare metal. It allows
00:07:14.790 --> 00:07:17.490
those organizations to go back toward performance,
00:07:17.790 --> 00:07:20.850
lower their costs and own more of their stack
00:07:20.850 --> 00:07:23.730
in the process. So along those same lines, is
00:07:23.730 --> 00:07:26.670
there like a common misconception you see that
00:07:26.670 --> 00:07:30.660
people have regarding? bare metal or on-prem
00:07:30.660 --> 00:07:34.540
in general? Oh, absolutely. So, you know, as
00:07:34.540 --> 00:07:37.300
recently as, I mean, it happens all the time,
00:07:37.319 --> 00:07:40.240
but we were doing a demo back in November. And
00:07:40.240 --> 00:07:42.899
this was with a large company over in Denmark.
00:07:43.060 --> 00:07:45.819
And they were one of the early companies to adopt
00:07:45.819 --> 00:07:49.060
AWS. And this company, they were looking at getting
00:07:49.060 --> 00:07:52.500
away from Kubernetes. They were using EKS. And
00:07:52.500 --> 00:07:55.839
the main reason they were coming to us was data
00:07:55.839 --> 00:07:57.560
sovereignty issues. They had customers that were
00:07:57.560 --> 00:08:00.120
saying that they needed to not be on AWS to be
00:08:00.120 --> 00:08:02.019
able to continue to be customers of that company.
00:08:02.199 --> 00:08:04.220
And during that demo, one of the requirements,
00:08:04.540 --> 00:08:06.100
because I kind of posed the question, like, are
00:08:06.100 --> 00:08:07.959
you interested in just getting off AWS? Are you
00:08:07.959 --> 00:08:10.139
also interested in adopting bare metal as part
00:08:10.139 --> 00:08:11.959
of this. And the company was like, no, no, no,
00:08:11.980 --> 00:08:13.519
we don't want to talk bare metal. Like we don't,
00:08:13.519 --> 00:08:14.800
we don't want to be responsible for maintaining
00:08:14.800 --> 00:08:16.939
hardware. We don't want to be responsible for
00:08:16.939 --> 00:08:18.839
setting up all the networks and all of those
00:08:18.839 --> 00:08:20.759
things. And you could tell, again, very technical
00:08:20.759 --> 00:08:23.439
team, but they had spent so much of the last
00:08:23.439 --> 00:08:26.060
decade plus in the cloud that they were just
00:08:26.060 --> 00:08:28.920
kind of used to that. And we did the demo and
00:08:28.920 --> 00:08:30.600
three quarters of the way through, I was like,
00:08:30.639 --> 00:08:32.100
you know, hey, we're talking about all these
00:08:32.100 --> 00:08:33.500
DevOps terms. We're talking about containers,
00:08:33.659 --> 00:08:35.759
infrastructure, et cetera. What if I do the rest
00:08:35.759 --> 00:08:38.509
of this demo and do it on bare metal? but not
00:08:38.509 --> 00:08:40.570
tell them until afterwards. And it was kind of
00:08:40.570 --> 00:08:42.149
like a game to me. Like I had someone kind of
00:08:42.149 --> 00:08:44.330
challenge my thoughts on, you know, the ease
00:08:44.330 --> 00:08:46.789
of bare metal. And so we got to the end of the
00:08:46.789 --> 00:08:48.750
demo and I showed my cards and I was like, oh,
00:08:48.789 --> 00:08:50.570
by the way, like the infrastructure we just deployed
00:08:50.570 --> 00:08:52.090
and the containers we just deployed, that was
00:08:52.090 --> 00:08:54.830
all bare metal. And the company immediately did
00:08:54.830 --> 00:08:57.649
a 180. And they're like, okay. You've sold us.
00:08:57.750 --> 00:08:59.690
Let's talk about bare metal now. Because they
00:08:59.690 --> 00:09:01.409
realized it was one of those things where, you
00:09:01.409 --> 00:09:03.129
know, kind of to the three points that I just
00:09:03.129 --> 00:09:05.190
made about cost, data sovereignty and performance.
00:09:05.389 --> 00:09:07.250
The main item for them was data sovereignty.
00:09:07.610 --> 00:09:10.070
But when they realized that now they could have
00:09:10.070 --> 00:09:12.529
that cost and performance conversation at the
00:09:12.529 --> 00:09:14.429
same time, and it wasn't necessarily exclusive,
00:09:14.809 --> 00:09:18.570
it was kind of eye opening. So yes, back to the
00:09:18.570 --> 00:09:19.889
question that you asked, which is what is the
00:09:19.889 --> 00:09:22.629
big misconception? There's a lot of people that
00:09:22.629 --> 00:09:25.629
have spent much of their careers in the cloud.
00:09:26.110 --> 00:09:27.809
I mean, again, it's been the main way we've been
00:09:27.809 --> 00:09:31.549
deploying for a decade now. That because of that,
00:09:31.710 --> 00:09:33.929
they've kind of, what's the whole cliche? Going
00:09:33.929 --> 00:09:35.870
through the forest or the mountains or you're
00:09:35.870 --> 00:09:37.690
missing, I don't remember the cliche, but the
00:09:37.690 --> 00:09:39.570
point is that when you're so focused on something,
00:09:39.690 --> 00:09:42.470
you kind of miss some of the advancements that
00:09:42.470 --> 00:09:44.070
are happening in the process. Yeah, for sure.
00:09:44.149 --> 00:09:47.250
I mean, so I am one of those people where I was
00:09:47.250 --> 00:09:51.149
early days, I worked at a colo facility, racking
00:09:51.149 --> 00:09:54.240
and stacking, you know, servers. very, very different
00:09:54.240 --> 00:09:57.399
world now than it was back in the late 90s, early
00:09:57.399 --> 00:10:00.000
2000s. Yeah, very different as far as management
00:10:00.000 --> 00:10:02.639
of those colo facilities. Completely different
00:10:02.639 --> 00:10:05.360
now. With those colo facilities, it's really
00:10:05.360 --> 00:10:07.759
interesting because so many of the people that
00:10:07.759 --> 00:10:09.779
I encounter that are bare metal friendly and
00:10:09.779 --> 00:10:11.960
like ready to return to it are the people that
00:10:11.960 --> 00:10:13.779
were racking and stacking back at that time.
00:10:13.799 --> 00:10:16.120
And, you know, the early cPanel days and they're
00:10:16.120 --> 00:10:17.500
like, I want to get back to that because they
00:10:17.500 --> 00:10:19.480
kind of missed that. Like it means something
00:10:19.480 --> 00:10:21.360
to them. But then you have this whole generation
00:10:21.360 --> 00:10:23.679
kind of in the middle where cloud was the beginning
00:10:23.679 --> 00:10:26.379
of their career. So as you talk about racking
00:10:26.379 --> 00:10:28.500
and stacking, like that is dear to me as well.
00:10:29.019 --> 00:10:32.720
Yeah. So when you say turn any infra into a private
00:10:32.720 --> 00:10:35.620
cloud, what does that mean for a DevOps team
00:10:35.620 --> 00:10:39.620
day two? So with Cycle, the way we kind of approach
00:10:39.620 --> 00:10:42.019
things, from a philosophical standpoint, I'm
00:10:42.019 --> 00:10:45.080
kind of anti-infrastructure as code. Like in
00:10:45.080 --> 00:10:47.080
Cycle, we call it environments as code. The idea
00:10:47.080 --> 00:10:49.879
is that you have a thin but defined line between
00:10:49.879 --> 00:10:51.700
infrastructure and everything that's going to
00:10:51.700 --> 00:10:53.700
run on top of that. And so in Cycle, we have
00:10:53.700 --> 00:10:55.340
what we call environments as code, which is...
00:10:55.559 --> 00:10:57.379
called stacks. And that's where you define your
00:10:57.379 --> 00:10:59.639
load balancers, containers, everything that you
00:10:59.639 --> 00:11:01.460
are going to be deploying over and over and over.
00:11:01.539 --> 00:11:03.919
But then infrastructure, we treat as just a pool
00:11:03.919 --> 00:11:05.799
of resources. So I guess maybe that's kind of
00:11:05.799 --> 00:11:08.440
a throwback to the racking and stacking days that we're
00:11:08.440 --> 00:11:09.820
just talking about where you're taking cPanel
00:11:09.820 --> 00:11:12.379
and trying to pack these hosts with as many
00:11:12.379 --> 00:11:15.519
things as you can and so with Cycle the idea
00:11:15.519 --> 00:11:17.519
is that you know you bring bare metal you bring
00:11:17.519 --> 00:11:20.059
vms whether it's in the cloud or we have we have
00:11:20.059 --> 00:11:21.559
some companies that are running Cycle on top
00:11:21.559 --> 00:11:24.440
of vmware the idea is you bring raw compute a
00:11:24.440 --> 00:11:25.980
cycle will automatically join it into a mesh
00:11:25.980 --> 00:11:28.379
and then that becomes kind of your private cloud
00:11:28.379 --> 00:11:30.919
so it can be hybrid infrastructure multi-cloud
00:11:30.919 --> 00:11:33.600
fully on-prem or a mixture of all of the above
00:11:34.000 --> 00:11:35.399
And then applications that you're building, your
00:11:35.399 --> 00:11:37.860
networks, et cetera, just overlay on top of that.
00:11:38.019 --> 00:11:40.000
So again, you have this thin but very defined
00:11:40.000 --> 00:11:43.120
line between infrastructure on one side and your
00:11:43.120 --> 00:11:45.639
applications on the other. So one of the things
00:11:45.639 --> 00:11:47.720
that I believe I read on, I believe it was on
00:11:47.720 --> 00:11:50.419
your website, you say no DevOps army required.
00:11:50.740 --> 00:11:53.100
What does that mean in practice? So I've been
00:11:53.100 --> 00:11:56.559
writing code for, I don't know, probably 22 years
00:11:56.559 --> 00:11:59.120
now. I guess there's the common saying that the
00:11:59.120 --> 00:12:00.600
best DevOps engineer will automate themselves
00:12:00.600 --> 00:12:02.860
out of a job, whether that's true or not. up
00:12:02.860 --> 00:12:05.200
for continuous debate, but I've been writing
00:12:05.200 --> 00:12:08.100
code for a long time and it seemed like any time
00:12:08.100 --> 00:12:09.720
it came to actually deploying that, whether it
00:12:09.720 --> 00:12:12.100
was back in the cPanel days or with Docker or
00:12:12.100 --> 00:12:13.860
Kubernetes, et cetera, that was always the thing
00:12:13.860 --> 00:12:16.120
that slowed me down the most. And while I always
00:12:16.120 --> 00:12:18.320
loved working with infrastructure, I didn't really
00:12:18.320 --> 00:12:20.919
like maintaining it. That was always a thing
00:12:20.919 --> 00:12:22.700
like, I mean, sure, getting it up and running
00:12:22.700 --> 00:12:24.200
is fun, right? I mean, it's why I think most
00:12:24.200 --> 00:12:26.059
of us get into it. The first days of setting
00:12:26.059 --> 00:12:27.820
up infrastructure and, you know, placing an order
00:12:27.820 --> 00:12:29.980
to buy a new bare metal machine. That's exciting,
00:12:30.120 --> 00:12:32.059
right? But, you know, three months later, no
00:12:32.059 --> 00:12:34.379
one wants to maintain it anymore. And so the
00:12:34.379 --> 00:12:37.360
goal cycle was how can we how can we build how
00:12:37.360 --> 00:12:38.940
can we build a platform that allows developers
00:12:38.940 --> 00:12:40.659
to do the things that typically you would need
00:12:40.659 --> 00:12:43.220
a DevOps engineer to do? And I'm not saying that,
00:12:43.279 --> 00:12:45.100
you know, to fully replace DevOps engineers,
00:12:45.179 --> 00:12:48.259
but in many cases, companies that are coming
00:12:48.259 --> 00:12:51.299
to us are companies where it's very engineering
00:12:51.299 --> 00:12:53.620
heavy. So, you know, like 10 developers to every
00:12:53.620 --> 00:12:56.200
DevOps engineer or a greater ratio. We have some
00:12:56.200 --> 00:12:58.879
companies that are 25 to one, et cetera. And
00:12:58.879 --> 00:13:00.940
those seem to be the places where we do best.
00:13:01.159 --> 00:13:04.000
And one of my favorite components of that is
00:13:04.000 --> 00:13:06.340
when we have developers that are deploying things
00:13:06.340 --> 00:13:08.519
on top of the platform that aren't really DevOps
00:13:08.519 --> 00:13:11.139
engineers at all. And they can't tell you how
00:13:11.139 --> 00:13:14.700
they did something, but it works. And, you know,
00:13:14.700 --> 00:13:17.200
that's one of the things that is nice about that.
00:13:17.850 --> 00:13:20.990
So no DevOps army is required is just that
00:13:20.990 --> 00:13:22.970
philosophy. Like, how do we empower developers
00:13:22.970 --> 00:13:25.269
to do what they need to do without having to
00:13:25.269 --> 00:13:28.230
become DevOps experts as part of that? So talking
00:13:28.230 --> 00:13:30.610
about mixed workloads, can you give me like a
00:13:30.610 --> 00:13:34.210
real world workload mix? Like, why do teams want
00:13:34.210 --> 00:13:36.870
VMs and containers living together? Why would
00:13:36.870 --> 00:13:39.049
they want that? There's probably... Hundreds
00:13:39.049 --> 00:13:40.889
of different potential reasons. One company that
00:13:40.889 --> 00:13:42.929
I was helping earlier this morning are running
00:13:42.929 --> 00:13:45.210
all of their different microservices in containers.
00:13:45.370 --> 00:13:49.049
That's just how they built their platform. But
00:13:49.049 --> 00:13:51.529
then due to a whole bunch of legacy, their company
00:13:51.529 --> 00:13:53.690
that's been around for. I think, 18 years. They
00:13:53.690 --> 00:13:55.309
have a number of applications that are built
00:13:55.309 --> 00:13:58.669
on top of .NET and require Microsoft SQL and
00:13:58.669 --> 00:14:00.470
things like that. For them, all of their newer
00:14:00.470 --> 00:14:02.690
microservices are running inside of containers.
00:14:02.789 --> 00:14:06.629
But for them being able to have those legacy
00:14:06.629 --> 00:14:09.850
applications running inside of Windows VMs sitting
00:14:10.320 --> 00:14:12.500
on the same infrastructure, on the same network
00:14:12.500 --> 00:14:14.620
where to the containers, they don't know they're
00:14:14.620 --> 00:14:16.820
talking to a VM and vice versa. It's just fully
00:14:16.820 --> 00:14:19.620
abstracted. So everything just sees network endpoints,
00:14:19.679 --> 00:14:22.580
but it allows companies not have to change
00:14:22.580 --> 00:14:25.379
everything for adoption. So that's one. And I
00:14:25.379 --> 00:14:27.659
guess another use case is we have some companies
00:14:27.659 --> 00:14:30.139
that are in regulated industries and things like
00:14:30.139 --> 00:14:33.690
that where. For certain applications, they need,
00:14:34.009 --> 00:14:37.090
you know, true virtualization for isolation as
00:14:37.090 --> 00:14:39.730
opposed to, you know, just cgroups and, you
00:14:39.730 --> 00:14:42.210
know, the isolation that comes with containers.
00:14:42.909 --> 00:14:46.190
Yeah. I feel like as an industry now too, everybody
00:14:46.190 --> 00:14:49.370
wants to containerize every service and makes
00:14:49.370 --> 00:14:51.710
sense in a lot of cases. But I've also found
00:14:51.710 --> 00:14:53.950
that there are cases where putting it inside
00:14:53.950 --> 00:14:56.690
of Kubernetes or some sort of container orchestration
00:14:56.690 --> 00:14:59.700
layer doesn't always make sense. We're just doing
00:14:59.700 --> 00:15:02.179
it because that's the phase right now. It just
00:15:02.179 --> 00:15:04.440
seems like every trade show I go to, too, it's
00:15:04.440 --> 00:15:06.620
pushing this idea of containerization, which,
00:15:06.679 --> 00:15:09.460
again, microservice layers make sense. There's
00:15:09.460 --> 00:15:11.919
certain applications, though, where I don't think
00:15:11.919 --> 00:15:14.500
putting bridges and stuff inside of a container
00:15:14.500 --> 00:15:16.200
makes sense, especially when you're dealing with
00:15:16.200 --> 00:15:18.940
services that can't be disrupted. It's an issue
00:15:18.940 --> 00:15:21.340
that I've come across a lot in the last year
00:15:21.340 --> 00:15:23.980
or two. Yeah, I mean, I would say that I'm probably
00:15:23.980 --> 00:15:26.610
on the opposite side of that. I containerize
00:15:26.610 --> 00:15:30.210
everything that I possibly can. But I mean, I
00:15:30.210 --> 00:15:31.950
also put the platform for it. So, you know, kind
00:15:31.950 --> 00:15:34.970
of aligns with my belief there. But yeah, I containerize
00:15:34.970 --> 00:15:38.070
everything to the point that on Cycle, every
00:15:38.070 --> 00:15:41.190
virtual machine is also actually a container.
00:15:41.370 --> 00:15:44.769
And so that way we have container layer, we have
00:15:44.769 --> 00:15:49.289
a containerized hypervisor, and then you
00:15:49.289 --> 00:15:50.830
have your VM sitting inside of that. And so the
00:15:50.830 --> 00:15:52.990
nice thing about that is that as we roll out
00:15:52.990 --> 00:15:55.370
new versions of the hypervisor, you know, given
00:15:55.370 --> 00:15:57.269
that it's containerized from that perspective,
00:15:57.490 --> 00:15:59.470
we're able to kind of roll out different versions
00:15:59.470 --> 00:16:02.370
of the hypervisor as users opt into it. So, you
00:16:02.370 --> 00:16:06.429
know, kind of little benefits from that. So that's
00:16:06.429 --> 00:16:07.950
interesting. So let's talk, I guess, a little
00:16:07.950 --> 00:16:10.610
bit more about the containerization aspect. In
00:16:10.610 --> 00:16:13.090
Kubernetes, I'm dealing with PDBs, pod disruption
00:16:13.090 --> 00:16:15.389
budgets. I'm dealing with maybe Karpenter if
00:16:15.389 --> 00:16:18.970
I'm on AWS. So I'm having this scale up and down
00:16:18.970 --> 00:16:21.269
nodes as needed. And then if I'm dealing with
00:16:21.269 --> 00:16:23.970
spot instances, I could have disruptions to...
00:16:24.159 --> 00:16:27.080
workloads how does cycle handle that orchestration
00:16:27.080 --> 00:16:31.259
of services so there's two ways that cycle approaches
00:16:31.259 --> 00:16:34.220
that number one is that in general i believe
00:16:34.220 --> 00:16:36.440
that the idea of failover is a terrible idea
00:16:36.440 --> 00:16:39.080
and i've seen so many times in my career where
00:16:39.080 --> 00:16:40.899
you know you set up all these processes for failover
00:16:40.899 --> 00:16:43.019
and then things fail to fail over when things
00:16:43.019 --> 00:16:47.100
go wrong right and so um with that you know the
00:16:47.100 --> 00:16:49.789
idea that failover is you know kind of high risk.
00:16:50.509 --> 00:16:55.049
It's also along the same kind of philosophy that,
00:16:55.210 --> 00:16:58.750
you know, less moving parts is better. So inside
00:16:58.750 --> 00:17:01.149
of cycle, when we talk about like stateful workloads
00:17:01.149 --> 00:17:04.670
and things like that, in general, the approach
00:17:04.670 --> 00:17:06.730
that we have is to run everything in active active
00:17:06.730 --> 00:17:09.289
100 % of the time. So that way, if one side goes
00:17:09.289 --> 00:17:11.549
down, you're perfectly fine. Like, you know,
00:17:11.549 --> 00:17:13.410
when that side comes back up, you know, you'll
00:17:13.410 --> 00:17:15.690
recover. Now, if you need to evacuate, you know,
00:17:15.690 --> 00:17:17.589
to another host, you can do that too. But there's
00:17:17.589 --> 00:17:20.630
a reason why, Mongo and so many of these modern
00:17:20.630 --> 00:17:22.670
database technologies have their own replication
00:17:22.670 --> 00:17:24.950
built into it. And I guess maybe that's a little
00:17:24.950 --> 00:17:27.529
bit of a tangent is it bothers me so much when
00:17:27.529 --> 00:17:29.710
platforms try to automate storage replication,
00:17:30.089 --> 00:17:32.150
as opposed to letting the application that knows
00:17:32.150 --> 00:17:35.589
how to replicate it properly, replicate it. And
00:17:35.589 --> 00:17:38.769
so in Cycle's world, we try to, everything is
00:17:38.769 --> 00:17:41.029
active, active. We try to move things as little
00:17:41.029 --> 00:17:43.470
as possible. And then if you are deploying a
00:17:43.470 --> 00:17:45.589
container and you mark it as stateful, the platform
00:17:45.589 --> 00:17:47.589
will treat that container separately, almost
00:17:47.589 --> 00:17:49.640
like a VM. It'll almost treat it like a VM.
00:17:49.759 --> 00:17:51.319
So that way its data will always move with it.
00:17:51.380 --> 00:17:53.299
Like we will like, instead of like creating like
00:17:53.299 --> 00:17:55.460
a volume claim in Kubernetes, we will create
00:17:55.460 --> 00:17:59.299
an attached LVM, like a raw LVM, and then migrate
00:17:59.299 --> 00:18:01.839
that as needed. And if you need to scale up,
00:18:01.839 --> 00:18:04.160
we'll scale up, but we're going to rely on the
00:18:04.160 --> 00:18:05.980
underlying application to know how to replicate
00:18:05.980 --> 00:18:07.839
that data. Because again, if we're talking about
00:18:07.839 --> 00:18:09.839
like Mongo as an example, being able to have
00:18:09.839 --> 00:18:12.880
collection-level locking as you do migrations
00:18:12.880 --> 00:18:15.660
and things like that, as you have elections happening.
00:18:16.349 --> 00:18:18.970
great why should a platform try to do that in
00:18:18.970 --> 00:18:20.990
general what would be like a best bare metal
00:18:20.990 --> 00:18:24.210
use case right now given the trajectory of the
00:18:24.210 --> 00:18:28.230
industry i mean i think that For companies that
00:18:28.230 --> 00:18:32.190
are trying to reclaim ownership of their stack,
00:18:32.490 --> 00:18:35.190
bare metal is a great way of doing that. At that
00:18:35.190 --> 00:18:38.130
point, you're just consuming raw compute. The
00:18:38.130 --> 00:18:42.549
different services that you're kind of locked
00:18:42.549 --> 00:18:45.029
into are significantly less. I mean, I guess
00:18:45.029 --> 00:18:46.670
it depends on what provider you're going with
00:18:46.670 --> 00:18:48.329
and things like that. But for the most part,
00:18:48.470 --> 00:18:49.970
your pricing is going to be significantly more
00:18:49.970 --> 00:18:52.349
stable. For example, we just signed a partnership
00:18:52.349 --> 00:18:55.069
today to be announced soon that includes 100
00:18:55.069 --> 00:18:57.000
terabytes of bandwidth per service. server on
00:18:57.000 --> 00:18:59.359
a 10 gig link. And, you know, I mean, you know,
00:18:59.420 --> 00:19:01.160
when you start talking about 100 terabytes
00:19:01.160 --> 00:19:03.539
of bandwidth of bandwidth,
00:19:03.779 --> 00:19:07.440
per, you know, VM or, or whatever
00:19:07.440 --> 00:19:10.000
AWS, you're talking about a huge bandwidth bill.
00:19:10.400 --> 00:19:13.640
Uh, so, uh, the fact that some of these, these
00:19:13.640 --> 00:19:15.180
bare metal providers are including a 100
00:19:15.180 --> 00:19:18.619
terabytes, um, per server
00:19:18.619 --> 00:19:21.819
just out of the box with normal pricing is wild
00:19:21.819 --> 00:19:25.299
um and maybe i should take my earlier response
00:19:25.299 --> 00:19:28.799
back and instead talk about performance um and
00:19:28.799 --> 00:19:32.099
performance density right because like we as
00:19:32.099 --> 00:19:33.799
a company we've been buying some more bare metal
00:19:33.799 --> 00:19:35.980
um recently for we're getting ready to launch
00:19:35.980 --> 00:19:37.940
a european control plane so we're buying more
00:19:37.940 --> 00:19:40.619
infrastructure for that control plane and the
00:19:40.619 --> 00:19:43.519
fact that we were able to buy physical machines
00:19:43.519 --> 00:19:50.680
with 24 physical cores for $280 a month with
00:19:50.680 --> 00:19:53.839
dual 10-gig links and 100 terabytes of bandwidth
00:19:53.839 --> 00:19:58.059
included and 192 gigabytes of memory each and
00:19:58.059 --> 00:20:04.700
RAID 1 with terabyte NVMe drives. Like, I mean, those
00:20:04.700 --> 00:20:08.680
same specs would be, I mean, I don't know the
00:20:08.680 --> 00:20:10.440
exact number, but I'm guessing probably three
00:20:10.440 --> 00:20:12.920
to four times over at AWS. And then you'd still
00:20:12.920 --> 00:20:14.880
have the virtualization overhead on top of that.
00:20:15.440 --> 00:20:18.559
What do you think is the reason for that? Do
00:20:18.559 --> 00:20:22.700
you think that these colo or server providers
00:20:22.700 --> 00:20:26.299
are trying to compete with that market? Or what's
00:20:26.299 --> 00:20:28.680
the reason for the discrepancy in pricing, you
00:20:28.680 --> 00:20:31.119
think? Is it just because we're paying so much
00:20:31.119 --> 00:20:33.640
for the control plane at AWS? That's my theory.
00:20:33.759 --> 00:20:37.460
I don't actually know. It's wild that you can
00:20:37.460 --> 00:20:40.759
buy that level of performance for that price.
00:20:41.039 --> 00:20:43.809
And yeah, like, yes, there's... One of the cons
00:20:43.809 --> 00:20:46.349
that you typically get from most of these, these
00:20:46.349 --> 00:20:48.230
kind of bare metal providers today, one of the
00:20:48.230 --> 00:20:50.190
cons is that from a network perspective, you
00:20:50.190 --> 00:20:53.509
have way fewer PoPs, right? So your latency from
00:20:53.509 --> 00:20:56.630
a network standpoint can be meaningfully higher
00:20:56.630 --> 00:20:59.109
where if you're using AWS and GCP, I mean, you'll
00:20:59.109 --> 00:21:00.829
have great latency to almost anywhere in the
00:21:00.829 --> 00:21:02.630
world where some of these bare metal providers,
00:21:02.789 --> 00:21:04.569
you might get one or two pops. Now, granted,
00:21:04.569 --> 00:21:06.970
there are some like Equinix and Megaport that
00:21:06.970 --> 00:21:09.029
that's what they do and they can still give you,
00:21:09.049 --> 00:21:11.670
you know, a really solid network. So there's...
00:21:11.869 --> 00:21:14.369
you know, uh, pros and cons, but I don't know
00:21:14.369 --> 00:21:18.990
if having 10-plus PoPs, you know, at GCP is also
00:21:18.990 --> 00:21:21.890
worth a three X price increase on compute. I
00:21:21.890 --> 00:21:24.450
don't know if that's the reason why, but I think
00:21:24.450 --> 00:21:28.069
the network is like the network resiliency is
00:21:28.069 --> 00:21:31.609
probably the one con to bare metal today. Yeah.
00:21:31.730 --> 00:21:33.849
I guess it matters what your workloads are if
00:21:33.849 --> 00:21:36.369
you, if you're latency sensitive, but yeah. Like
00:21:36.369 --> 00:21:38.809
if you're doing high traffic bidding applications
00:21:38.809 --> 00:21:41.740
where you need to bid for, for. creative or something
00:21:41.740 --> 00:21:44.319
i could see you needing to have that low latency
00:21:44.319 --> 00:21:47.839
for that but i don't think that most people if
00:21:47.839 --> 00:21:49.519
especially if you're serving websites or serving
00:21:49.519 --> 00:21:51.480
a web app i don't think for the most part it
00:21:51.480 --> 00:21:54.660
would matter but also i mean Level 3 is in
00:21:54.660 --> 00:21:57.099
northern virginia in the same area as you know
00:21:57.099 --> 00:22:00.900
you could probably buy colo space again i'm sure
00:22:00.900 --> 00:22:03.720
northern virginia area is is expensive just because
00:22:03.720 --> 00:22:07.170
dc metro area but You could probably buy Colo
00:22:07.170 --> 00:22:10.589
servers in that area competitively against AWS's
00:22:10.589 --> 00:22:12.349
rates as well. Well, it's kind of funny that
00:22:12.349 --> 00:22:16.170
you mentioned that. Because of AWS's presence
00:22:16.170 --> 00:22:19.190
there, we have so many companies that when they're
00:22:19.190 --> 00:22:21.450
switching to bare metal and using Cycle as part
00:22:21.450 --> 00:22:23.829
of that process, we have companies that specifically
00:22:23.829 --> 00:22:26.829
need bare metal in that region. And it's like,
00:22:26.890 --> 00:22:28.289
hey, you can deploy bare metal anywhere in the
00:22:28.289 --> 00:22:30.309
world. And they're saying, no, no, no, no. I
00:22:30.309 --> 00:22:32.809
need to connect to Supabase or... some other
00:22:32.809 --> 00:22:35.029
service running on top of AWS. So even though
00:22:35.029 --> 00:22:37.569
they're trying to get off of AWS as a cloud provider,
00:22:37.789 --> 00:22:40.250
they still need to be in proximity to it because
00:22:40.250 --> 00:22:42.029
so many of the services they're communicating
00:22:42.029 --> 00:22:45.170
with are still sitting right
00:22:45.170 --> 00:22:47.250
on top of that infrastructure. So we have companies
00:22:47.250 --> 00:22:49.490
that did initial test deployments and they were
00:22:49.490 --> 00:22:51.789
deployed to somewhere around New York City or
00:22:51.789 --> 00:22:55.289
somewhere to Atlanta and they would find out
00:22:55.289 --> 00:22:59.269
that extra. 12, 15 millisecond latency was too
00:22:59.269 --> 00:23:01.690
much for them. And so they had, so like, it's
00:23:01.690 --> 00:23:06.329
weird how there seems to be such a, and it's
00:23:06.329 --> 00:23:09.569
only on US East 1. We don't have any other companies
00:23:09.569 --> 00:23:12.450
that are like, oh, US East 2 or US West 1 is
00:23:12.450 --> 00:23:14.109
where I need to be. But for whatever reason,
00:23:14.150 --> 00:23:17.829
US East 1, we just have an extreme number of
00:23:17.829 --> 00:23:19.609
companies that are like, I need to be close to
00:23:19.609 --> 00:23:21.529
that. And it's kind of coincidental because that's
00:23:21.529 --> 00:23:23.130
the one that always has an outage or at least
00:23:23.130 --> 00:23:25.549
it seems. And it's the control plane for the
00:23:25.549 --> 00:23:28.349
rest of the services. So what I have found is
00:23:28.349 --> 00:23:30.970
when US East 1 goes down, if you have services
00:23:30.970 --> 00:23:34.069
that are in US West 2, maybe like an auto-scaling
00:23:34.069 --> 00:23:36.890
group that needs to scale up, you know, new instances,
00:23:37.109 --> 00:23:39.130
it's not able to because it's not able to reach
00:23:39.130 --> 00:23:40.849
out to the control plane, which lives in US East
00:23:40.849 --> 00:23:44.390
1. Yeah. There's still marriage there as much
00:23:44.390 --> 00:23:46.869
as they maybe try to say that they're isolated.
00:23:47.029 --> 00:23:49.670
They're not. Yeah, that is something I've absolutely
00:23:49.670 --> 00:23:52.269
noticed as well. When US East 1 goes down, you
00:23:52.269 --> 00:23:54.750
just have to assume that everything else is also
00:23:54.750 --> 00:23:58.490
impacted. Okay, so speaking about Cycle versus
00:23:58.490 --> 00:24:00.430
Kubernetes, what do you think that Kubernetes
00:24:00.430 --> 00:24:04.049
gets right? And where does it become self-inflicted
00:24:04.049 --> 00:24:10.160
pain? So with Kubernetes versus Cycle and when
00:24:10.160 --> 00:24:13.079
is kind of a better fit for one versus the other,
00:24:13.200 --> 00:24:15.839
it really kind of comes down to the needs of
00:24:15.839 --> 00:24:18.160
individual companies from a customization perspective.
00:24:18.339 --> 00:24:21.619
For companies that are really, as I mentioned
00:24:21.619 --> 00:24:23.680
earlier, kind of engineering heavy, that are
00:24:23.680 --> 00:24:27.259
like, hey, we're mainly developers. We're very
00:24:27.259 --> 00:24:32.279
microservice heavy. We might need object storage
00:24:32.279 --> 00:24:34.440
or like the requirements that they have are pretty,
00:24:34.539 --> 00:24:37.480
let's say, you know, commoditized, right? They
00:24:37.480 --> 00:24:39.599
need some disk. They need some, you know, object
00:24:39.599 --> 00:24:42.680
storage. They need kind of the primitives. That's
00:24:42.680 --> 00:24:44.740
where Cycle really shines. But at the same time,
00:24:44.779 --> 00:24:46.880
if you have companies that are like, hey, we
00:24:46.880 --> 00:24:50.519
need people to run on. very specific hardware
00:24:50.519 --> 00:24:53.359
with very specific kernel drivers and, you know,
00:24:53.380 --> 00:24:55.500
things like that. That's where Kubernetes is,
00:24:55.500 --> 00:24:57.460
you know, a better fit from that perspective
00:24:57.460 --> 00:24:59.920
because with Cycle, we ship a standardized OS
00:24:59.920 --> 00:25:03.440
to everyone. We don't provide SSH access. That
00:25:03.440 --> 00:25:06.000
OS is made to be as dumb and as tiny as possible.
00:25:06.579 --> 00:25:08.559
You know, it's 40 megabytes in size. So that
00:25:08.559 --> 00:25:10.119
means that naturally it's going to be kind of
00:25:10.119 --> 00:25:11.900
limited in terms of what it can do. Like our
00:25:11.900 --> 00:25:15.380
goal is to target 80%, right? But if you have
00:25:15.380 --> 00:25:16.960
like really specific infrastructure you need
00:25:16.960 --> 00:25:18.769
to run or, you know, Supercomputing applications
00:25:18.769 --> 00:25:22.430
or some of these big AI models that people are
00:25:22.430 --> 00:25:24.549
buying a whole bunch of really sophisticated infrastructure
00:25:24.549 --> 00:25:28.670
for these days. Cycle today is not built for
00:25:28.670 --> 00:25:31.799
bring anything. We are built for more of bring
00:25:31.799 --> 00:25:34.980
your typical x86 server you know with a few drives
00:25:34.980 --> 00:25:36.740
in it we'll get it up and running we'll get you
00:25:36.740 --> 00:25:38.920
what you need so it all comes back to whether
00:25:38.920 --> 00:25:41.759
do companies need just basic primitives and they
00:25:41.759 --> 00:25:44.359
don't want to be devops or do they have a very
00:25:44.359 --> 00:25:47.960
specific list of requirements um that you know
00:25:47.960 --> 00:25:52.180
extend from network to hardware to um maybe the
00:25:52.180 --> 00:25:55.279
oa the host os that those nodes need to run people
00:25:55.279 --> 00:25:57.279
who are coming to cycle are looking for an opinionated
00:25:57.279 --> 00:25:59.279
answer it's why most of the companies that are
00:25:59.279 --> 00:26:01.400
on Cycle today are companies that left Kubernetes for Cycle
00:26:01.400 --> 00:26:03.960
like you know they went that route they tested
00:26:03.960 --> 00:26:06.619
it um many of them were on Kubernetes for years
00:26:06.619 --> 00:26:09.859
before they decided like i think that it's natural
00:26:09.859 --> 00:26:12.099
for for all of us techies to want to play with
00:26:12.099 --> 00:26:14.059
new technologies but at some point people are
00:26:14.059 --> 00:26:15.859
like you know what i don't i don't want to play
00:26:15.859 --> 00:26:17.819
with all the bells and whistles anymore i just
00:26:17.819 --> 00:26:20.819
wanted to work yeah and it's something that you
00:26:20.819 --> 00:26:23.220
know i kind of talked about often is you know
00:26:23.220 --> 00:26:25.539
most people when they get their first smartphone
00:26:25.539 --> 00:26:28.779
or at least you know for me and most of my friends
00:26:28.779 --> 00:26:30.440
as we were growing up your first smartphone is
00:26:30.440 --> 00:26:32.960
an android right um and i know i'm probably about
00:26:32.960 --> 00:26:34.539
to piss off a whole bunch of people but you're
00:26:34.539 --> 00:26:36.359
for you know typically your first phone is an
00:26:36.359 --> 00:26:37.779
android phone because you want to you want to
00:26:37.779 --> 00:26:39.940
customize it you want to you know play with it
00:26:39.940 --> 00:26:42.759
you want to make it yours yeah yeah exactly um
00:26:42.759 --> 00:26:44.839
but eventually people are like i don't really
00:26:44.839 --> 00:26:46.519
care about that anymore i just want a phone that
00:26:46.519 --> 00:26:49.099
works i don't want to you know like let me change
00:26:49.099 --> 00:26:50.980
my background and i don't care and then they
00:26:50.980 --> 00:26:53.799
switch to an iphone um and so that's kind of
00:26:53.799 --> 00:26:55.839
what i've kind of always said about cycle like
00:26:56.190 --> 00:26:57.789
Companies, you know, they're going to go play
00:26:57.789 --> 00:26:58.990
with Kubernetes. They're going to go play with
00:26:58.990 --> 00:27:00.509
Rancher. They're going to go kind of test out,
00:27:00.589 --> 00:27:03.109
you know, the latest and greatest. They want
00:27:03.109 --> 00:27:05.210
something where they can change every variable.
00:27:05.509 --> 00:27:07.829
But at some point, it no longer becomes about
00:27:07.829 --> 00:27:10.150
changing variables and playing with the latest
00:27:10.150 --> 00:27:11.769
and greatest of everything. They just want to
00:27:11.769 --> 00:27:14.190
get back to what they want to build. And so that's
00:27:14.190 --> 00:27:15.609
where we built Cycle for companies that
00:27:15.609 --> 00:27:19.089
are like, yeah, just give me a standard opinionated
00:27:19.089 --> 00:27:22.710
platform and I'll just work with that. And so,
00:27:22.789 --> 00:27:26.509
yeah. Yeah, it makes sense. So, okay, wrapping
00:27:26.509 --> 00:27:29.130
up, what's one thing you'd do first if you had
00:27:29.130 --> 00:27:32.410
to modernize on-prem or hybrid without blowing
00:27:32.410 --> 00:27:35.390
up the team? This is going to go back to a conversation
00:27:35.390 --> 00:27:38.670
we had, you know, 10 minutes ago, but containerize,
00:27:38.750 --> 00:27:42.109
right? Like, you know, I'm a big fan of containerizing
00:27:42.109 --> 00:27:44.990
everything. It makes applications typically way
00:27:44.990 --> 00:27:48.549
more portable. And if your goal is to chase portability,
00:27:48.670 --> 00:27:51.829
so that way you can kind of move to whether it's,
00:27:51.829 --> 00:27:55.700
you know, VMs or bare metal or on-prem, I mean,
00:27:55.720 --> 00:27:57.619
I guess that's bare metal too. Or mixture. Being
00:27:57.619 --> 00:27:59.500
able to standardize containers is, you know,
00:27:59.519 --> 00:28:01.900
I think why I'm in such favor of them. Yeah,
00:28:02.000 --> 00:28:05.119
I think that would be my first step. I think
00:28:05.119 --> 00:28:07.579
that would absolutely be my first step from that
00:28:07.579 --> 00:28:09.680
standpoint. Now, if the question is, what if
00:28:09.680 --> 00:28:11.579
I'm already containerized and now I'm trying
00:28:11.579 --> 00:28:14.559
to like go towards, you know, bare metal? I think
00:28:14.559 --> 00:28:17.140
the next step there is, you know, look at your
00:28:17.140 --> 00:28:20.470
dependencies. If you're in a hyperscaler. And
00:28:20.470 --> 00:28:23.349
you're using things like Lambda and S3 and things
00:28:23.349 --> 00:28:25.210
like that. Your next step is kind of to decide
00:28:25.210 --> 00:28:27.490
what services I'm going to try to replicate on
00:28:27.490 --> 00:28:29.430
top of bare metal. What am I going to be okay
00:28:29.430 --> 00:28:33.230
having still in the cloud? And do the primitives
00:28:33.230 --> 00:28:35.509
that I need allow me to be on bare metal? Because
00:28:35.509 --> 00:28:37.390
again, if you are tightly integrated into Lambda
00:28:37.390 --> 00:28:39.430
and some of these other things, bare metal might
00:28:39.430 --> 00:28:41.750
not be the best fit for you. But if you're just
00:28:41.750 --> 00:28:43.470
running a whole bunch of containers, then you're
00:28:43.470 --> 00:28:45.990
kind of in a good spot. So assuming you're containerized,
00:28:46.089 --> 00:28:48.490
I think then the next part of that is just...
00:28:48.569 --> 00:28:50.589
evaluating what third-party services you need
00:28:50.589 --> 00:28:52.690
and whether you can bring those in-house or
00:28:52.690 --> 00:28:53.990
whether you're okay with those staying in the
00:28:53.990 --> 00:28:59.269
cloud. Have you noticed an increase in AI workloads
00:28:59.269 --> 00:29:02.529
and people building containers around AI-specific
00:29:02.529 --> 00:29:06.109
workloads using Cycle? So it's kind of interesting
00:29:06.109 --> 00:29:09.230
for how much, you know, you log into LinkedIn
00:29:09.230 --> 00:29:11.849
and Reddit and things and everything's about
00:29:11.849 --> 00:29:13.930
AI. So many of the companies that are on Cycle
00:29:13.930 --> 00:29:16.269
today, like, yes, you know, a number of them
00:29:16.269 --> 00:29:19.200
do have some AI component. in what they're doing.
00:29:19.279 --> 00:29:21.819
But I think we only have one or two clients that
00:29:21.819 --> 00:29:24.700
are running like true models with GPUs. Yeah.
00:29:25.079 --> 00:29:27.700
I didn't mean like API calls to OpenAI, but
00:29:27.700 --> 00:29:30.799
yeah, like actual modeling locally. Yeah. Yeah,
00:29:30.839 --> 00:29:35.000
so Cycle out of the box supports all NVIDIA data
00:29:35.000 --> 00:29:37.319
center class GPUs. And so that's one of the drivers
00:29:37.319 --> 00:29:39.420
that we keep up to date. So we support that.
00:29:39.579 --> 00:29:43.279
But we were hoping that we'd have more AI, you
00:29:43.279 --> 00:29:45.039
know, focused applications on top of the platform
00:29:45.039 --> 00:29:47.119
today. But I think that it's one of these kind
00:29:47.119 --> 00:29:48.900
of interesting things where it's kind of like
00:29:48.900 --> 00:29:53.180
with IoT and then crypto and now AI. Like, yes,
00:29:53.299 --> 00:29:55.200
you know, there are hype waves. And I'm not saying
00:29:55.200 --> 00:29:59.009
that AI is, you know, you know. equivalent to
00:29:59.009 --> 00:30:02.970
IoT or crypto or things like that but as we see
00:30:02.970 --> 00:30:06.549
these hype waves happen we always see people
00:30:06.549 --> 00:30:10.690
who kind of love bleeding edge technology chase
00:30:10.690 --> 00:30:12.589
them right like so many of my friends that were
00:30:12.589 --> 00:30:15.789
like really gung-ho on on crypto are now the
00:30:15.789 --> 00:30:18.170
same people that are really deep into you know
00:30:18.170 --> 00:30:20.769
ai and then the next thing that comes out they're
00:30:20.769 --> 00:30:22.410
going to chase that as well like it's what they
00:30:22.410 --> 00:30:25.630
do and those people typically are the same people
00:30:25.630 --> 00:30:30.200
that like changing all the, you know, the dials
00:30:30.200 --> 00:30:32.599
and they like playing and tweaking. And so that's
00:30:32.599 --> 00:30:34.059
where they kind of, I think those people, they
00:30:34.059 --> 00:30:35.839
don't want an opinionated platform like Cycle.
00:30:35.920 --> 00:30:37.559
They want something where they can customize
00:30:37.559 --> 00:30:40.319
everything. It's kind of like the book of, you
00:30:40.319 --> 00:30:43.180
know, Crossing the Chasm, right? Cycle is there
00:30:43.180 --> 00:30:45.099
for the majority in the middle. They're like,
00:30:45.200 --> 00:30:46.740
hey, no, I just want to run stuff. I want to
00:30:46.740 --> 00:30:49.180
build stuff. But then, you know, those super
00:30:49.180 --> 00:30:50.900
early adopters that are always chasing new technology,
00:30:51.160 --> 00:30:54.619
they want to be, they want more customization
00:30:54.619 --> 00:30:57.609
than Cycle will give them. And I guess to an
00:30:57.609 --> 00:30:58.950
earlier point, that's where Kubernetes probably
00:30:58.950 --> 00:31:00.710
makes more sense for them. But when applications
00:31:00.710 --> 00:31:02.690
kind of become more standardized and they just
00:31:02.690 --> 00:31:04.650
want to run them, then that's where Cycle starts
00:31:04.650 --> 00:31:07.910
to win. Makes sense. What is Cycle? Why would
00:31:07.910 --> 00:31:10.910
someone choose Cycle? What would be a reason
00:31:10.910 --> 00:31:13.829
for choosing Cycle? Yeah, so for an organization
00:31:13.829 --> 00:31:17.009
that is really engineering heavy, a company that
00:31:17.009 --> 00:31:19.750
wants to spend more time focused on building
00:31:19.750 --> 00:31:22.369
versus maintaining. And when I say building versus
00:31:22.369 --> 00:31:24.089
maintaining, I'm talking about building the actual
00:31:24.089 --> 00:31:26.170
applications, the platforms, the services, etc.
00:31:26.349 --> 00:31:29.789
Less on maintaining the host OS, the host kernel,
00:31:29.970 --> 00:31:32.750
the underlying infrastructure. That's where Cycle
00:31:32.750 --> 00:31:34.390
really shines for these organizations, especially
00:31:34.390 --> 00:31:38.150
teams that where they have. really talented developers,
00:31:38.289 --> 00:31:40.210
but these developers really don't have interest
00:31:40.210 --> 00:31:42.509
in becoming DevOps engineers as part of that
00:31:42.509 --> 00:31:45.029
process is kind of where Cycle shines. Makes
00:31:45.029 --> 00:31:48.069
sense. Okay, so wrapping up, where can people
00:31:48.069 --> 00:31:50.430
read more about you, find out about you, read
00:31:50.430 --> 00:31:52.109
more about Cycle? Where should they go? Yeah,
00:31:52.170 --> 00:31:54.710
so to learn more about Cycle, you can visit our
00:31:54.710 --> 00:31:57.400
website, which is Cycle.io. We also have a Slack
00:31:57.400 --> 00:31:59.839
community that we have a lot of developers and
00:31:59.839 --> 00:32:02.220
DevOps engineers that hang out in. That's
00:32:02.220 --> 00:32:05.599
slack.cycle.io. And then for people who want to maybe
00:32:05.599 --> 00:32:09.380
learn more about me, I guess linkedin.com/in/jakewarner. Like it's kind of weird
00:32:11.539 --> 00:32:14.960
to hand out my or to use my LinkedIn as that
00:32:14.960 --> 00:32:17.299
as the primary source. But I think I keep it
00:32:17.299 --> 00:32:18.960
more up to date than anything else I do these
00:32:18.960 --> 00:32:21.619
days. That makes sense. I'll also put links for
00:32:21.619 --> 00:32:23.759
all of that in the show notes as well. So make
00:32:23.759 --> 00:32:27.029
it easier. Sounds good. Awesome. Well, thank
00:32:27.029 --> 00:32:29.190
you, Jake, so much for coming on and telling
00:32:29.190 --> 00:32:31.930
me more about Cycle and containerization. Really
00:32:31.930 --> 00:32:34.009
appreciate it. Yeah, really, really appreciate
00:32:34.009 --> 00:32:36.750
you having me on, Brian. Really enjoyed the conversation.
00:32:37.289 --> 00:32:40.349
Always fun to be able to, you know, as you mentioned
00:32:40.349 --> 00:32:42.430
earlier about racking and stacking, meet people
00:32:42.430 --> 00:32:44.509
of like mind in terms of how we got to where
00:32:44.509 --> 00:32:48.089
we are today. Awesome. Thanks. All right. That
00:32:48.089 --> 00:32:50.730
was my conversation with Jake Warner from Cycle
00:32:50.730 --> 00:32:53.930
.io. My biggest takeaway from this one. is that
00:32:53.930 --> 00:32:56.750
the cloud versus bare metal debate is kind of
00:32:56.750 --> 00:32:58.829
the least interesting version of the conversation.
00:32:59.150 --> 00:33:01.490
The better question is, what are you actually
00:33:01.490 --> 00:33:04.390
trying to optimize for? Because sometimes the
00:33:04.390 --> 00:33:06.690
answer is cloud. Sometimes it is Kubernetes.
00:33:07.009 --> 00:33:09.829
Sometimes it is managed services all the way
00:33:09.829 --> 00:33:12.410
down because your team does not have the time,
00:33:12.529 --> 00:33:15.730
people, or business reason to own more of the
00:33:15.730 --> 00:33:17.970
stack. But sometimes the answer is different.
00:33:18.150 --> 00:33:21.089
Sometimes the problem is cost. Sometimes it is
00:33:21.089 --> 00:33:23.920
performance density. Sometimes it is data sovereignty.
00:33:24.240 --> 00:33:27.400
Sometimes it is compliance. Sometimes it is latency.
00:33:27.660 --> 00:33:29.819
Sometimes it is the fact that your developers
00:33:29.819 --> 00:33:32.460
just want to ship software and your platform
00:33:32.460 --> 00:33:35.859
team is slowly drowning in a pile of abstractions
00:33:35.859 --> 00:33:38.180
that were supposed to make everything easier.
00:33:38.359 --> 00:33:40.640
That is the part I think is worth paying attention
00:33:40.640 --> 00:33:43.630
to. A lot of teams do not necessarily want to
00:33:43.630 --> 00:33:46.329
go backwards. They want to go back to owning
00:33:46.329 --> 00:33:49.230
the parts that matter without reintroducing all
00:33:49.230 --> 00:33:51.890
of the old pain. And that is a much more useful
00:33:51.890 --> 00:33:54.670
framing than pretending there is one correct
00:33:54.670 --> 00:33:57.609
infrastructure model for everybody. I also like
00:33:57.609 --> 00:34:00.509
Jake's point about opinionated platforms. Because
00:34:00.509 --> 00:34:03.990
as engineers, we love flexibility. We love knobs.
00:34:04.230 --> 00:34:06.869
We love knowing that technically, if we really
00:34:06.869 --> 00:34:09.809
wanted to, we could customize every piece of
00:34:09.809 --> 00:34:12.250
the stack. But there is a cost to that. Every
00:34:12.250 --> 00:34:14.969
knob becomes a decision. Every decision becomes
00:34:14.969 --> 00:34:18.070
something to document. Every exception becomes
00:34:18.070 --> 00:34:21.230
something to support. And eventually, the platform
00:34:21.230 --> 00:34:24.090
that was supposed to help teams move faster becomes
00:34:24.090 --> 00:34:27.090
another system that needs its own platform team
00:34:27.090 --> 00:34:29.949
just to keep it sane. That does not always mean
00:34:29.949 --> 00:34:32.869
opinionated platforms are always better. If you
00:34:32.869 --> 00:34:35.449
need very specific kernel drivers, specialized
00:34:35.449 --> 00:34:39.079
hardware, deep customization, or you are doing
00:34:39.079 --> 00:34:42.159
weird edge case infrastructure work, then Kubernetes
00:34:42.159 --> 00:34:45.559
or a more flexible platform may absolutely be
00:34:45.559 --> 00:34:48.179
the better fit. But for a lot of teams, especially
00:34:48.179 --> 00:34:51.739
teams that mostly need containers, VMs, networking,
00:34:52.099 --> 00:34:55.780
storage, load balancers, and a sane way to deploy
00:34:55.780 --> 00:34:59.119
applications, there is a real argument for fewer
00:34:59.119 --> 00:35:02.159
choices and better defaults. And honestly, that
00:35:02.159 --> 00:35:04.440
is probably where a lot of infrastructure conversations
00:35:04.440 --> 00:35:07.039
are heading. Not everything should be cloud.
00:35:07.199 --> 00:35:09.900
Not everything should be Kubernetes. Not everyone
00:35:09.900 --> 00:35:12.800
should move back to bare metal. More like what
00:35:12.800 --> 00:35:16.099
complexity is actually helping us? And what complexity
00:35:16.099 --> 00:35:19.159
are we just carrying? Because the industry told
00:35:19.159 --> 00:35:22.219
us this is what modern infrastructure is supposed
00:35:22.219 --> 00:35:25.340
to look like. I'll have links to Jake,
00:35:25.340 --> 00:35:28.420
Cycle.io, and their Slack community in the show notes.
00:35:28.619 --> 00:35:31.599
If you enjoyed this conversation, follow or subscribe to
00:35:31.599 --> 00:35:34.179
Ship It Weekly wherever you listen to podcasts.
00:35:34.599 --> 00:35:36.900
It helps the show, and it makes sure you get
00:35:36.900 --> 00:35:39.420
both these conversation episodes and the weekly
00:35:39.420 --> 00:35:42.420
DevOps, SRE, platform, cloud, and security news
00:35:42.420 --> 00:35:45.079
recaps. You can also find the show notes and
00:35:45.079 --> 00:35:48.440
links over on shipitweekly.fm. Thanks for listening,
00:35:48.500 --> 00:35:50.099
and I'll see you later this week.
00:00:00.000 --> 00:00:02.419
For the last decade, the default infrastructure
00:00:02.419 --> 00:00:05.820
answer has basically been cloud first, Kubernetes
00:00:05.820 --> 00:00:09.039
probably, and then good luck to whoever has to
00:00:09.039 --> 00:00:11.679
operate the thing after the architecture diagram
00:00:11.679 --> 00:00:15.240
gets turned into real life. And to be fair, the
00:00:15.240 --> 00:00:18.219
cloud solved a lot of real problems. Nobody wants
00:00:18.219 --> 00:00:20.980
to go back to waiting on hardware, filing tickets
00:00:20.980 --> 00:00:24.000
for VLANs, or discovering that the one person
00:00:24.000 --> 00:00:27.800
who understood the SAN is on vacation. But there
00:00:27.800 --> 00:00:30.489
is another side of this now. Cloud bills are
00:00:30.489 --> 00:00:32.990
getting harder to explain. Kubernetes platforms
00:00:32.990 --> 00:00:36.229
are getting harder to maintain. Data sovereignty
00:00:36.229 --> 00:00:39.530
is becoming a real business requirement. And
00:00:39.530 --> 00:00:41.950
a lot of teams are quietly looking at all of
00:00:41.950 --> 00:00:44.289
the layers that they have built and asking a
00:00:44.289 --> 00:00:47.049
pretty reasonable question. Is this actually
00:00:47.049 --> 00:00:49.899
simpler? because sometimes the thing that was
00:00:49.899 --> 00:00:52.899
supposed to reduce operational burden just moves
00:00:52.899 --> 00:00:55.500
the complexity somewhere else into Terraform
00:00:55.500 --> 00:00:59.100
into Helm charts into networking into managed
00:00:59.100 --> 00:01:02.579
service glue into a platform team that is now
00:01:02.579 --> 00:01:05.879
responsible for making 15 different abstractions
00:01:05.879 --> 00:01:09.200
feel like one coherent system and that is really
00:01:09.200 --> 00:01:11.799
what this conversation is about not cloud is
00:01:11.799 --> 00:01:15.099
bad not bare metal is back everybody grab a screwdriver
00:01:15.099 --> 00:01:18.659
more like What happens when teams want more control,
00:01:18.879 --> 00:01:22.159
more predictable cost, better performance, and
00:01:22.159 --> 00:01:25.140
less platform sprawl without going back to the
00:01:25.140 --> 00:01:27.900
old-school pain of managing infrastructure by
00:01:27.900 --> 00:01:30.659
hand? I'm Brian Teller from Teller's Tech, and
00:01:30.659 --> 00:01:49.989
this is Ship It Weekly. Welcome back to Ship
00:01:49.989 --> 00:01:52.430
It Weekly, where I filter the noise and focus
00:01:52.430 --> 00:01:54.909
on what actually matters when you are the one
00:01:54.909 --> 00:01:56.790
running infrastructure and owning reliability.
00:01:57.310 --> 00:02:00.349
Most weeks, it's a quick news recap. In between
00:02:00.349 --> 00:02:03.390
those, I do conversation episodes with people
00:02:03.390 --> 00:02:05.930
who are building platforms, running infrastructure,
00:02:06.269 --> 00:02:09.090
organizing events, and thinking through where
00:02:09.090 --> 00:02:12.129
this industry is actually headed. Today is one
00:02:12.129 --> 00:02:14.870
of those conversations. I'm joined by Jake Warner,
00:02:15.090 --> 00:02:19.419
founder and CEO of Cycle.io. Cycle is an infrastructure
00:02:19.419 --> 00:02:22.639
platform that lets teams run containers and virtual
00:02:22.639 --> 00:02:25.900
machines across bare metal, cloud, private cloud,
00:02:26.099 --> 00:02:29.000
and hybrid environments without trying to turn
00:02:29.000 --> 00:02:32.139
every company into a full-time platform engineering
00:02:32.139 --> 00:02:35.240
shop. And I like this conversation because it
00:02:35.240 --> 00:02:37.960
gets into a topic that a lot of people are thinking
00:02:37.960 --> 00:02:40.379
about right now, even if they are not always
00:02:40.379 --> 00:02:43.020
saying it out loud. A lot of teams are tired,
00:02:43.180 --> 00:02:46.800
not lazy, not anti-cloud, not anti-Kubernetes,
00:02:47.400 --> 00:02:50.060
just tired of the amount of complexity that has
00:02:50.060 --> 00:02:52.860
piled up around modern infrastructure. You start
00:02:52.860 --> 00:02:55.860
with a simple goal. Run the application. Scale
00:02:55.860 --> 00:02:59.520
it. Deploy safely. Keep it reliable. Don't spend
00:02:59.520 --> 00:03:02.400
a fortune. Then suddenly, you have Kubernetes
00:03:02.400 --> 00:03:06.500
clusters, node groups, disruption budgets, autoscalers,
00:03:06.659 --> 00:03:10.319
Terraform modules, managed services, IAM policies,
00:03:10.900 --> 00:03:14.580
GitOps controllers, observability agents, service
00:03:14.580 --> 00:03:18.199
meshes, secrets systems, and a Slack channel where
00:03:18.199 --> 00:03:21.039
somebody asks why the platform is blocking delivery.
00:03:21.379 --> 00:03:23.719
And somewhere in the middle of that, people start
00:03:23.719 --> 00:03:26.460
wondering whether there is another way to think
00:03:26.460 --> 00:03:29.620
about infrastructure. In this conversation, Jake
00:03:29.620 --> 00:03:32.400
and I talk about why some teams are moving back
00:03:32.400 --> 00:03:35.539
toward private cloud and bare metal, but not
00:03:35.539 --> 00:03:38.039
in the nostalgic racking and stacking servers
00:03:38.039 --> 00:03:41.039
was awesome kind of way. More because of cost,
00:03:41.300 --> 00:03:45.439
performance, data sovereignty. and wanting more
00:03:45.439 --> 00:03:48.280
ownership over the stack. We also get into what
00:03:48.280 --> 00:03:50.500
people still misunderstand about bare metal,
00:03:50.620 --> 00:03:53.360
why some teams want VMs and containers living
00:03:53.360 --> 00:03:55.879
together, where Kubernetes is still the right
00:03:55.879 --> 00:03:59.120
answer, and where an opinionated platform might
00:03:59.120 --> 00:04:01.780
be a better fit than giving every team every
00:04:01.780 --> 00:04:05.009
possible knob to turn. There's also a good thread
00:04:05.009 --> 00:04:07.729
in here around failover versus active-active
00:04:07.729 --> 00:04:11.050
systems, stateful workloads, why application
00:04:11.050 --> 00:04:13.969
-level replication often beats platform-level
00:04:13.969 --> 00:04:17.189
magic, and what it really means to make raw infrastructure
00:04:17.189 --> 00:04:20.069
feel like a cloud-like resource. And towards
00:04:20.069 --> 00:04:23.870
the end, we talk a bit about AI workloads, GPUs,
00:04:23.949 --> 00:04:26.750
hype cycles, and why the most bleeding-edge
00:04:26.750 --> 00:04:29.889
teams are not always the same teams that want
00:04:29.889 --> 00:04:32.600
an opinionated platform. So if you work around
00:04:32.600 --> 00:04:36.600
DevOps, SRE, platform engineering, cloud infrastructure,
00:04:37.060 --> 00:04:40.199
Kubernetes, private cloud, or you are just starting
00:04:40.199 --> 00:04:42.720
to wonder whether your modern platform has become
00:04:42.720 --> 00:04:45.540
a very expensive junk drawer, this one should
00:04:45.540 --> 00:04:47.939
be worth your time. All right, let's jump in.
00:04:53.000 --> 00:04:56.439
Today, I'm joined by Jake Warner. He's CEO and
00:04:56.439 --> 00:04:59.180
founder of Cycle.io. We're going to be talking
00:04:59.180 --> 00:05:02.449
about private cloud, bare metal, and why a lot
00:05:02.449 --> 00:05:05.709
of teams are quietly exhausted by platform complexity.
00:05:06.250 --> 00:05:08.750
Jake, thanks for joining me. Thanks for having
00:05:08.750 --> 00:05:10.910
me. Give me your thesis. Why are teams pulling
00:05:10.910 --> 00:05:13.310
back toward private cloud and bare metal again?
00:05:13.529 --> 00:05:16.029
So, you know, for most of the people watching
00:05:16.029 --> 00:05:17.769
this podcast, we all knew that bare metal was
00:05:17.769 --> 00:05:21.430
really sexy a decade ago, right? 15 years ago.
00:05:21.529 --> 00:05:24.449
The cloud made it super easy to move away from
00:05:24.449 --> 00:05:27.509
bare metal. It solved the big complexity that
00:05:27.509 --> 00:05:31.319
came into, you know, I mean. We all know how
00:05:31.319 --> 00:05:32.980
hard it was to get a bare metal server online,
00:05:33.139 --> 00:05:35.079
get it configured, do it at scale. In the early
00:05:35.079 --> 00:05:36.899
days of Cycle, I'd always say, you know,
00:05:36.899 --> 00:05:39.819
anyone can deploy one or two servers. But when
00:05:39.819 --> 00:05:41.720
you need to start automating 100 servers, that's
00:05:41.720 --> 00:05:43.439
when the problems get really complex, right?
00:05:43.740 --> 00:05:46.519
I'm guessing most people listening to this podcast
00:05:46.519 --> 00:05:49.829
are completely aware of that. With what we built
00:05:49.829 --> 00:05:53.149
with Cycle, our goal was to simplify that process
00:05:53.149 --> 00:05:55.769
so that way you could have companies that were
00:05:55.769 --> 00:05:58.509
able to own their bare metal, et cetera, and
00:05:58.509 --> 00:06:00.290
still provision it like a cloud-like resource.
00:06:00.569 --> 00:06:03.269
And the reason why we kind of did that and why
00:06:03.269 --> 00:06:05.269
we see companies coming back to bare metal is,
00:06:05.329 --> 00:06:08.389
number one, cost. Hyperscalers ended up, you
00:06:08.389 --> 00:06:10.660
know, they made it really easy. But we've all
00:06:10.660 --> 00:06:12.579
seen hyperscalers just continue to increase costs.
00:06:12.720 --> 00:06:14.220
And once you get locked into that ecosystem,
00:06:14.519 --> 00:06:16.439
your costs kind of only go up. So that's number
00:06:16.439 --> 00:06:19.339
one. Number two is about data sovereignty concerns.
00:06:19.480 --> 00:06:21.639
I think especially with a lot of the geopolitical
00:06:21.639 --> 00:06:23.019
issues that we're seeing in the world right now,
00:06:23.079 --> 00:06:24.759
most of the companies that we've been working
00:06:24.759 --> 00:06:26.560
with are companies that are saying whether it's
00:06:26.560 --> 00:06:29.500
compliance reasons or they have customer demands,
00:06:29.779 --> 00:06:32.199
maybe is the right term for it. We have companies
00:06:32.199 --> 00:06:34.689
that are coming to us and saying. we cannot be
00:06:34.689 --> 00:06:38.149
on a US-owned hyperscaler. Even if geographically
00:06:38.149 --> 00:06:40.050
that infrastructure is sitting over in Europe,
00:06:40.209 --> 00:06:43.509
we need to, because of the US Cloud Act, we have
00:06:43.509 --> 00:06:45.790
companies that are saying we cannot be on US
00:06:45.790 --> 00:06:48.209
-owned infrastructure. So I think that in terms
00:06:48.209 --> 00:06:49.689
of private cloud, in terms of bare metal, it
00:06:49.689 --> 00:06:51.769
all kind of comes back to number one, cost, number
00:06:51.769 --> 00:06:54.410
two, data sovereignty and compliance. And then
00:06:54.410 --> 00:06:56.850
the third item there would be performance. And
00:06:56.850 --> 00:06:59.250
for a long time, I think people kind of... gave
00:06:59.250 --> 00:07:01.949
up the performance that bare metal would give
00:07:01.949 --> 00:07:04.730
because of the ease of the cloud outweighed the
00:07:04.730 --> 00:07:06.769
performance you got from bare metal. But fast
00:07:06.769 --> 00:07:08.689
forward to today where you have platforms like
00:07:08.689 --> 00:07:12.709
what we've built that can make bare metal a cloud
00:07:12.709 --> 00:07:14.790
-like experience on top of bare metal. It allows
00:07:14.790 --> 00:07:17.490
those organizations to go back toward performance,
00:07:17.790 --> 00:07:20.850
lower their costs and own more of their stack
00:07:20.850 --> 00:07:23.730
in the process. So along those same lines, is
00:07:23.730 --> 00:07:26.670
there like a common misconception you see that
00:07:26.670 --> 00:07:30.660
people have regarding? bare metal or on-prem
00:07:30.660 --> 00:07:34.540
in general? Oh, absolutely. So, you know, as
00:07:34.540 --> 00:07:37.300
recently as, I mean, it happens all the time,
00:07:37.319 --> 00:07:40.240
but we were doing a demo back in November. And
00:07:40.240 --> 00:07:42.899
this was with a large company over in Denmark.
00:07:43.060 --> 00:07:45.819
And they were one of the early companies to adopt
00:07:45.819 --> 00:07:49.060
AWS. And this company, they were looking at getting
00:07:49.060 --> 00:07:52.500
away from Kubernetes. They were using EKS. And
00:07:52.500 --> 00:07:55.839
the main reason they were coming to us was data
00:07:55.839 --> 00:07:57.560
sovereignty issues. They had customers that were
00:07:57.560 --> 00:08:00.120
saying that they needed to not be on AWS to be
00:08:00.120 --> 00:08:02.019
able to continue to be customers of that company.
00:08:02.199 --> 00:08:04.220
And during that demo, one of the requirements,
00:08:04.540 --> 00:08:06.100
because I kind of posed the question, like, are
00:08:06.100 --> 00:08:07.959
you interested in just getting off AWS? Are you
00:08:07.959 --> 00:08:10.139
also interested in adopting bare metal as part
00:08:10.139 --> 00:08:11.959
of this. And the company was like, no, no, no,
00:08:11.980 --> 00:08:13.519
we don't want to talk bare metal. Like we don't,
00:08:13.519 --> 00:08:14.800
we don't want to be responsible for maintaining
00:08:14.800 --> 00:08:16.939
hardware. We don't want to be responsible for
00:08:16.939 --> 00:08:18.839
setting up all the networks and all of those
00:08:18.839 --> 00:08:20.759
things. And you could tell, again, very technical
00:08:20.759 --> 00:08:23.439
team, but they had spent so much of the last
00:08:23.439 --> 00:08:26.060
decade plus in the cloud that they were just
00:08:26.060 --> 00:08:28.920
kind of used to that. And we did the demo and
00:08:28.920 --> 00:08:30.600
three quarters of the way through, I was like,
00:08:30.639 --> 00:08:32.100
you know, hey, we're talking about all these
00:08:32.100 --> 00:08:33.500
DevOps terms. We're talking about containers,
00:08:33.659 --> 00:08:35.759
infrastructure, et cetera. What if I do the rest
00:08:35.759 --> 00:08:38.509
of this demo and do it on bare metal? but not
00:08:38.509 --> 00:08:40.570
tell them until afterwards. And it was kind of
00:08:40.570 --> 00:08:42.149
like a game to me. Like I had someone kind of
00:08:42.149 --> 00:08:44.330
challenge my thoughts on, you know, the ease
00:08:44.330 --> 00:08:46.789
of bare metal. And so we got to the end of the
00:08:46.789 --> 00:08:48.750
demo and I showed my cards and I was like, oh,
00:08:48.789 --> 00:08:50.570
by the way, like the infrastructure we just deployed
00:08:50.570 --> 00:08:52.090
and the containers we just deployed, that was
00:08:52.090 --> 00:08:54.830
all bare metal. And the company immediately did
00:08:54.830 --> 00:08:57.649
a 180. And they're like, okay. You've sold us.
00:08:57.750 --> 00:08:59.690
Let's talk about bare metal now. Because they
00:08:59.690 --> 00:09:01.409
realized it was one of those things where, you
00:09:01.409 --> 00:09:03.129
know, kind of to the three points that I just
00:09:03.129 --> 00:09:05.190
made about cost, data sovereignty and performance.
00:09:05.389 --> 00:09:07.250
The main item for them was data sovereignty.
00:09:07.610 --> 00:09:10.070
But when they realized that now they could have
00:09:10.070 --> 00:09:12.529
that cost and performance conversation at the
00:09:12.529 --> 00:09:14.429
same time, and it wasn't necessarily exclusive,
00:09:14.809 --> 00:09:18.570
it was kind of eye opening. So yes, back to the
00:09:18.570 --> 00:09:19.889
question that you asked, which is what is the
00:09:19.889 --> 00:09:22.629
big misconception? There's a lot of people that
00:09:22.629 --> 00:09:25.629
have spent much of their careers in the cloud.
00:09:26.110 --> 00:09:27.809
I mean, again, it's been the main way we've been
00:09:27.809 --> 00:09:31.549
deploying for a decade now. That because of that,
00:09:31.710 --> 00:09:33.929
they've kind of, what's the whole cliche? Going
00:09:33.929 --> 00:09:35.870
through the forest or the mountains or you're
00:09:35.870 --> 00:09:37.690
missing, I don't remember the cliche, but the
00:09:37.690 --> 00:09:39.570
point is that when you're so focused on something,
00:09:39.690 --> 00:09:42.470
you kind of miss some of the advancements that
00:09:42.470 --> 00:09:44.070
are happening in the process. Yeah, for sure.
00:09:44.149 --> 00:09:47.250
I mean, so I am one of those people where I was
00:09:47.250 --> 00:09:51.149
early days, I worked at a colo facility, racking
00:09:51.149 --> 00:09:54.240
and stacking, you know, servers. very, very different
00:09:54.240 --> 00:09:57.399
world now than it was back in the late 90s, early
00:09:57.399 --> 00:10:00.000
2000s. Yeah, very different as far as management
00:10:00.000 --> 00:10:02.639
of those colo facilities. Completely different
00:10:02.639 --> 00:10:05.360
now. With those colo facilities, it's really
00:10:05.360 --> 00:10:07.759
interesting because so many of the people that
00:10:07.759 --> 00:10:09.779
I encounter that are bare metal friendly and
00:10:09.779 --> 00:10:11.960
like ready to return to it are the people that
00:10:11.960 --> 00:10:13.779
were racking and stacking back at that time.
00:10:13.799 --> 00:10:16.120
And, you know, the early cPanel days and they're
00:10:16.120 --> 00:10:17.500
like, I want to get back to that because they
00:10:17.500 --> 00:10:19.480
kind of missed that. Like it means something
00:10:19.480 --> 00:10:21.360
to them. But then you have this whole generation
00:10:21.360 --> 00:10:23.679
kind of in the middle where cloud was the beginning
00:10:23.679 --> 00:10:26.379
of their career. So as you talk about racking
00:10:26.379 --> 00:10:28.500
and stacking, like that is dear to me as well.
00:10:29.019 --> 00:10:32.720
Yeah. So when you say turn any infra into a private
00:10:32.720 --> 00:10:35.620
cloud, what does that mean for a DevOps team
00:10:35.620 --> 00:10:39.620
day two? So with Cycle, the way we kind of approach
00:10:39.620 --> 00:10:42.019
things, from a philosophical standpoint, I'm
00:10:42.019 --> 00:10:45.080
kind of anti-infrastructure as code. Like in
00:10:45.080 --> 00:10:47.080
Cycle, we call it environments as code. The idea
00:10:47.080 --> 00:10:49.879
is that you have a thin but defined line between
00:10:49.879 --> 00:10:51.700
infrastructure and everything that's going to
00:10:51.700 --> 00:10:53.700
run on top of that. And so in Cycle, we have
00:10:53.700 --> 00:10:55.340
what we call environments as code, which is...
00:10:55.559 --> 00:10:57.379
called stacks. And that's where you define your
00:10:57.379 --> 00:10:59.639
load balancers, containers, everything that you
00:10:59.639 --> 00:11:01.460
are going to be deploying over and over and over.
00:11:01.539 --> 00:11:03.919
But then infrastructure, we treat as just a pool
00:11:03.919 --> 00:11:05.799
of resources. So I guess maybe that's kind of
00:11:05.799 --> 00:11:08.440
a throwback to the racking and stacking days that we're
00:11:08.440 --> 00:11:09.820
just talking about where you're taking cPanel
00:11:09.820 --> 00:11:12.379
and trying to pack these hosts with as many
00:11:12.379 --> 00:11:15.519
things as you can and so with Cycle the idea
00:11:15.519 --> 00:11:17.519
is that you know you bring bare metal you bring
00:11:17.519 --> 00:11:20.059
vms whether it's in the cloud or we have we have
00:11:20.059 --> 00:11:21.559
some companies that are running Cycle on top
00:11:21.559 --> 00:11:24.440
of vmware the idea is you bring raw compute a
00:11:24.440 --> 00:11:25.980
cycle will automatically join it into a mesh
00:11:25.980 --> 00:11:28.379
and then that becomes kind of your private cloud
00:11:28.379 --> 00:11:30.919
so it can be hybrid infrastructure multi-cloud
00:11:30.919 --> 00:11:33.600
fully on-prem or a mixture of all of the above
00:11:34.000 --> 00:11:35.399
And then applications that you're building, your
00:11:35.399 --> 00:11:37.860
networks, et cetera, just overlay on top of that.
00:11:38.019 --> 00:11:40.000
So again, you have this thin but very defined
00:11:40.000 --> 00:11:43.120
line between infrastructure on one side and your
00:11:43.120 --> 00:11:45.639
applications on the other. So one of the things
00:11:45.639 --> 00:11:47.720
that I believe I read on, I believe it was on
00:11:47.720 --> 00:11:50.419
your website, you say no DevOps army required.
00:11:50.740 --> 00:11:53.100
What does that mean in practice? So I've been
00:11:53.100 --> 00:11:56.559
writing code for, I don't know, probably 22 years
00:11:56.559 --> 00:11:59.120
now. I guess there's the common saying that the
00:11:59.120 --> 00:12:00.600
best DevOps engineer will automate themselves
00:12:00.600 --> 00:12:02.860
out of a job, whether that's true or not. up
00:12:02.860 --> 00:12:05.200
for continuous debate, but I've been writing
00:12:05.200 --> 00:12:08.100
code for a long time and it seemed like any time
00:12:08.100 --> 00:12:09.720
it came to actually deploying that, whether it
00:12:09.720 --> 00:12:12.100
was back in the cPanel days or with Docker or
00:12:12.100 --> 00:12:13.860
Kubernetes, et cetera, that was always the thing
00:12:13.860 --> 00:12:16.120
that slowed me down the most. And while I always
00:12:16.120 --> 00:12:18.320
loved working with infrastructure, I didn't really
00:12:18.320 --> 00:12:20.919
like maintaining it. That was always a thing
00:12:20.919 --> 00:12:22.700
like, I mean, sure, getting it up and running
00:12:22.700 --> 00:12:24.200
is fun, right? I mean, it's why I think most
00:12:24.200 --> 00:12:26.059
of us get into it. The first days of setting
00:12:26.059 --> 00:12:27.820
up infrastructure and, you know, placing an order
00:12:27.820 --> 00:12:29.980
to buy a new bare metal machine. That's exciting,
00:12:30.120 --> 00:12:32.059
right? But, you know, three months later, no
00:12:32.059 --> 00:12:34.379
one wants to maintain it anymore. And so the
00:12:34.379 --> 00:12:37.360
goal cycle was how can we how can we build how
00:12:37.360 --> 00:12:38.940
can we build a platform that allows developers
00:12:38.940 --> 00:12:40.659
to do the things that typically you would need
00:12:40.659 --> 00:12:43.220
a DevOps engineer to do? And I'm not saying that,
00:12:43.279 --> 00:12:45.100
you know, to fully replace DevOps engineers,
00:12:45.179 --> 00:12:48.259
but in many cases, companies that are coming
00:12:48.259 --> 00:12:51.299
to us are companies where it's very engineering
00:12:51.299 --> 00:12:53.620
heavy. So, you know, like 10 developers to every
00:12:53.620 --> 00:12:56.200
DevOps engineer or a greater ratio. We have some
00:12:56.200 --> 00:12:58.879
companies that are 25 to one, et cetera. And
00:12:58.879 --> 00:13:00.940
those seem to be the places where we do best.
00:13:01.159 --> 00:13:04.000
And one of my favorite components of that is
00:13:04.000 --> 00:13:06.340
when we have developers that are deploying things
00:13:06.340 --> 00:13:08.519
on top of the platform that aren't really DevOps
00:13:08.519 --> 00:13:11.139
engineers at all. And they can't tell you how
00:13:11.139 --> 00:13:14.700
they did something, but it works. And, you know,
00:13:14.700 --> 00:13:17.200
that's one of the things that is nice about that.
00:13:17.850 --> 00:13:20.990
So no DevOps army is required is just that
00:13:20.990 --> 00:13:22.970
philosophy. Like, how do we empower developers
00:13:22.970 --> 00:13:25.269
to do what they need to do without having to
00:13:25.269 --> 00:13:28.230
become DevOps experts as part of that? So talking
00:13:28.230 --> 00:13:30.610
about mixed workloads, can you give me like a
00:13:30.610 --> 00:13:34.210
real world workload mix? Like, why do teams want
00:13:34.210 --> 00:13:36.870
VMs and containers living together? Why would
00:13:36.870 --> 00:13:39.049
they want that? There's probably... Hundreds
00:13:39.049 --> 00:13:40.889
of different potential reasons. One company that
00:13:40.889 --> 00:13:42.929
I was helping earlier this morning are running
00:13:42.929 --> 00:13:45.210
all of their different microservices in containers.
00:13:45.370 --> 00:13:49.049
That's just how they built their platform. But
00:13:49.049 --> 00:13:51.529
then due to a whole bunch of legacy, their company
00:13:51.529 --> 00:13:53.690
that's been around for. I think, 18 years. They
00:13:53.690 --> 00:13:55.309
have a number of applications that are built
00:13:55.309 --> 00:13:58.669
on top of .NET and require Microsoft SQL and
00:13:58.669 --> 00:14:00.470
things like that. For them, all of their newer
00:14:00.470 --> 00:14:02.690
microservices are running inside of containers.
00:14:02.789 --> 00:14:06.629
But for them being able to have those legacy
00:14:06.629 --> 00:14:09.850
applications running inside of Windows VMs sitting
00:14:10.320 --> 00:14:12.500
on the same infrastructure, on the same network
00:14:12.500 --> 00:14:14.620
where to the containers, they don't know they're
00:14:14.620 --> 00:14:16.820
talking to a VM and vice versa. It's just fully
00:14:16.820 --> 00:14:19.620
abstracted. So everything just sees network endpoints,
00:14:19.679 --> 00:14:22.580
but it allows companies not have to change
00:14:22.580 --> 00:14:25.379
everything for adoption. So that's one. And I
00:14:25.379 --> 00:14:27.659
guess another use case is we have some companies
00:14:27.659 --> 00:14:30.139
that are in regulated industries and things like
00:14:30.139 --> 00:14:33.690
that where. For certain applications, they need,
00:14:34.009 --> 00:14:37.090
you know, true virtualization for isolation as
00:14:37.090 --> 00:14:39.730
opposed to, you know, just cgroups and, you
00:14:39.730 --> 00:14:42.210
know, the isolation that comes with containers.
00:14:42.909 --> 00:14:46.190
Yeah. I feel like as an industry now too, everybody
00:14:46.190 --> 00:14:49.370
wants to containerize every service and makes
00:14:49.370 --> 00:14:51.710
sense in a lot of cases. But I've also found
00:14:51.710 --> 00:14:53.950
that there are cases where putting it inside
00:14:53.950 --> 00:14:56.690
of Kubernetes or some sort of container orchestration
00:14:56.690 --> 00:14:59.700
layer doesn't always make sense. We're just doing
00:14:59.700 --> 00:15:02.179
it because that's the phase right now. It just
00:15:02.179 --> 00:15:04.440
seems like every trade show I go to, too, it's
00:15:04.440 --> 00:15:06.620
pushing this idea of containerization, which,
00:15:06.679 --> 00:15:09.460
again, microservice layers make sense. There's
00:15:09.460 --> 00:15:11.919
certain applications, though, where I don't think
00:15:11.919 --> 00:15:14.500
putting bridges and stuff inside of a container
00:15:14.500 --> 00:15:16.200
makes sense, especially when you're dealing with
00:15:16.200 --> 00:15:18.940
services that can't be disrupted. It's an issue
00:15:18.940 --> 00:15:21.340
that I've come across a lot in the last year
00:15:21.340 --> 00:15:23.980
or two. Yeah, I mean, I would say that I'm probably
00:15:23.980 --> 00:15:26.610
on the opposite side of that. I containerize
00:15:26.610 --> 00:15:30.210
everything that I possibly can. But I mean, I
00:15:30.210 --> 00:15:31.950
also put the platform for it. So, you know, kind
00:15:31.950 --> 00:15:34.970
of aligns with my belief there. But yeah, I containerize
00:15:34.970 --> 00:15:38.070
everything to the point that on Cycle, every
00:15:38.070 --> 00:15:41.190
virtual machine is also actually a container.
00:15:41.370 --> 00:15:44.769
And so that way we have container layer, we have
00:15:44.769 --> 00:15:49.289
a containerized hypervisor, and then you
00:15:49.289 --> 00:15:50.830
have your VM sitting inside of that. And so the
00:15:50.830 --> 00:15:52.990
nice thing about that is that as we roll out
00:15:52.990 --> 00:15:55.370
new versions of the hypervisor, you know, given
00:15:55.370 --> 00:15:57.269
that it's containerized from that perspective,
00:15:57.490 --> 00:15:59.470
we're able to kind of roll out different versions
00:15:59.470 --> 00:16:02.370
of the hypervisor as users opt into it. So, you
00:16:02.370 --> 00:16:06.429
know, kind of little benefits from that. So that's
00:16:06.429 --> 00:16:07.950
interesting. So let's talk, I guess, a little
00:16:07.950 --> 00:16:10.610
bit more about the containerization aspect. In
00:16:10.610 --> 00:16:13.090
Kubernetes, I'm dealing with PDBs, pod disruption
00:16:13.090 --> 00:16:15.389
budgets. I'm dealing with maybe Karpenter if
00:16:15.389 --> 00:16:18.970
I'm on AWS. So I'm having this scale up and down
00:16:18.970 --> 00:16:21.269
nodes as needed. And then if I'm dealing with
00:16:21.269 --> 00:16:23.970
spot instances, I could have disruptions to...
00:16:24.159 --> 00:16:27.080
workloads how does cycle handle that orchestration
00:16:27.080 --> 00:16:31.259
of services so there's two ways that cycle approaches
00:16:31.259 --> 00:16:34.220
that number one is that in general i believe
00:16:34.220 --> 00:16:36.440
that the idea of failover is a terrible idea
00:16:36.440 --> 00:16:39.080
and i've seen so many times in my career where
00:16:39.080 --> 00:16:40.899
you know you set up all these processes for failover
00:16:40.899 --> 00:16:43.019
and then things fail to fail over when things
00:16:43.019 --> 00:16:47.100
go wrong right and so um with that you know the
00:16:47.100 --> 00:16:49.789
idea that failover is you know kind of high risk.
00:16:50.509 --> 00:16:55.049
It's also along the same kind of philosophy that,
00:16:55.210 --> 00:16:58.750
you know, less moving parts is better. So inside
00:16:58.750 --> 00:17:01.149
of cycle, when we talk about like stateful workloads
00:17:01.149 --> 00:17:04.670
and things like that, in general, the approach
00:17:04.670 --> 00:17:06.730
that we have is to run everything in active active
00:17:06.730 --> 00:17:09.289
100 % of the time. So that way, if one side goes
00:17:09.289 --> 00:17:11.549
down, you're perfectly fine. Like, you know,
00:17:11.549 --> 00:17:13.410
when that side comes back up, you know, you'll
00:17:13.410 --> 00:17:15.690
recover. Now, if you need to evacuate, you know,
00:17:15.690 --> 00:17:17.589
to another host, you can do that too. But there's
00:17:17.589 --> 00:17:20.630
a reason why, Mongo and so many of these modern
00:17:20.630 --> 00:17:22.670
database technologies have their own replication
00:17:22.670 --> 00:17:24.950
built into it. And I guess maybe that's a little
00:17:24.950 --> 00:17:27.529
bit of a tangent is it bothers me so much when
00:17:27.529 --> 00:17:29.710
platforms try to automate storage replication,
00:17:30.089 --> 00:17:32.150
as opposed to letting the application that knows
00:17:32.150 --> 00:17:35.589
how to replicate it properly, replicate it. And
00:17:35.589 --> 00:17:38.769
so in Cycle's world, we try to, everything is
00:17:38.769 --> 00:17:41.029
active, active. We try to move things as little
00:17:41.029 --> 00:17:43.470
as possible. And then if you are deploying a
00:17:43.470 --> 00:17:45.589
container and you mark it as stateful, the platform
00:17:45.589 --> 00:17:47.589
will treat that container separately, almost
00:17:47.589 --> 00:17:49.640
like a VM. It'll almost treat it like a VM.
00:17:49.759 --> 00:17:51.319
So that way its data will always move with it.
00:17:51.380 --> 00:17:53.299
Like we will like, instead of like creating like
00:17:53.299 --> 00:17:55.460
a volume claim in Kubernetes, we will create
00:17:55.460 --> 00:17:59.299
an attached LVM, like a raw LVM, and then migrate
00:17:59.299 --> 00:18:01.839
that as needed. And if you need to scale up,
00:18:01.839 --> 00:18:04.160
we'll scale up, but we're going to rely on the
00:18:04.160 --> 00:18:05.980
underlying application to know how to replicate
00:18:05.980 --> 00:18:07.839
that data. Because again, if we're talking about
00:18:07.839 --> 00:18:09.839
like Mongo as an example, being able to have
00:18:09.839 --> 00:18:12.880
collection-level locking as you do migrations
00:18:12.880 --> 00:18:15.660
and things like that, as you have elections happening.
00:18:16.349 --> 00:18:18.970
great why should a platform try to do that in
00:18:18.970 --> 00:18:20.990
general what would be like a best bare metal
00:18:20.990 --> 00:18:24.210
use case right now given the trajectory of the
00:18:24.210 --> 00:18:28.230
industry i mean i think that For companies that
00:18:28.230 --> 00:18:32.190
are trying to reclaim ownership of their stack,
00:18:32.490 --> 00:18:35.190
bare metal is a great way of doing that. At that
00:18:35.190 --> 00:18:38.130
point, you're just consuming raw compute. The
00:18:38.130 --> 00:18:42.549
different services that you're kind of locked
00:18:42.549 --> 00:18:45.029
into are significantly less. I mean, I guess
00:18:45.029 --> 00:18:46.670
it depends on what provider you're going with
00:18:46.670 --> 00:18:48.329
and things like that. But for the most part,
00:18:48.470 --> 00:18:49.970
your pricing is going to be significantly more
00:18:49.970 --> 00:18:52.349
stable. For example, we just signed a partnership
00:18:52.349 --> 00:18:55.069
today to be announced soon that includes 100
00:18:55.069 --> 00:18:57.000
terabytes of bandwidth per service. server on
00:18:57.000 --> 00:18:59.359
a 10 gig link. And, you know, I mean, you know,
00:18:59.420 --> 00:19:01.160
when you start talking about 100 terabytes
00:19:01.160 --> 00:19:03.539
of bandwidth of bandwidth,
00:19:03.779 --> 00:19:07.440
per, you know, VM or, or whatever
00:19:07.440 --> 00:19:10.000
AWS, you're talking about a huge bandwidth bill.
00:19:10.400 --> 00:19:13.640
Uh, so, uh, the fact that some of these, these
00:19:13.640 --> 00:19:15.180
bare metal providers are including a 100
00:19:15.180 --> 00:19:18.619
terabytes, um, per server
00:19:18.619 --> 00:19:21.819
just out of the box with normal pricing is wild
00:19:21.819 --> 00:19:25.299
um and maybe i should take my earlier response
00:19:25.299 --> 00:19:28.799
back and instead talk about performance um and
00:19:28.799 --> 00:19:32.099
performance density right because like we as
00:19:32.099 --> 00:19:33.799
a company we've been buying some more bare metal
00:19:33.799 --> 00:19:35.980
um recently for we're getting ready to launch
00:19:35.980 --> 00:19:37.940
a european control plane so we're buying more
00:19:37.940 --> 00:19:40.619
infrastructure for that control plane and the
00:19:40.619 --> 00:19:43.519
fact that we were able to buy physical machines
00:19:43.519 --> 00:19:50.680
with 24 physical cores for $280 a month with
00:19:50.680 --> 00:19:53.839
dual 10-gig links and 100 terabytes of bandwidth
00:19:53.839 --> 00:19:58.059
included and 192 gigabytes of memory each and
00:19:58.059 --> 00:20:04.700
RAID 1 with terabyte NVMe drives. Like, I mean, those
00:20:04.700 --> 00:20:08.680
same specs would be, I mean, I don't know the
00:20:08.680 --> 00:20:10.440
exact number, but I'm guessing probably three
00:20:10.440 --> 00:20:12.920
to four times over at AWS. And then you'd still
00:20:12.920 --> 00:20:14.880
have the virtualization overhead on top of that.
00:20:15.440 --> 00:20:18.559
What do you think is the reason for that? Do
00:20:18.559 --> 00:20:22.700
you think that these colo or server providers
00:20:22.700 --> 00:20:26.299
are trying to compete with that market? Or what's
00:20:26.299 --> 00:20:28.680
the reason for the discrepancy in pricing, you
00:20:28.680 --> 00:20:31.119
think? Is it just because we're paying so much
00:20:31.119 --> 00:20:33.640
for the control plane at AWS? That's my theory.
00:20:33.759 --> 00:20:37.460
I don't actually know. It's wild that you can
00:20:37.460 --> 00:20:40.759
buy that level of performance for that price.
00:20:41.039 --> 00:20:43.809
And yeah, like, yes, there's... One of the cons
00:20:43.809 --> 00:20:46.349
that you typically get from most of these, these
00:20:46.349 --> 00:20:48.230
kind of bare metal providers today, one of the
00:20:48.230 --> 00:20:50.190
cons is that from a network perspective, you
00:20:50.190 --> 00:20:53.509
have way fewer PoPs, right? So your latency from
00:20:53.509 --> 00:20:56.630
a network standpoint can be meaningfully higher
00:20:56.630 --> 00:20:59.109
where if you're using AWS and GCP, I mean, you'll
00:20:59.109 --> 00:21:00.829
have great latency to almost anywhere in the
00:21:00.829 --> 00:21:02.630
world where some of these bare metal providers,
00:21:02.789 --> 00:21:04.569
you might get one or two pops. Now, granted,
00:21:04.569 --> 00:21:06.970
there are some like Equinix and Megaport that
00:21:06.970 --> 00:21:09.029
that's what they do and they can still give you,
00:21:09.049 --> 00:21:11.670
you know, a really solid network. So there's...
00:21:11.869 --> 00:21:14.369
you know, uh, pros and cons, but I don't know
00:21:14.369 --> 00:21:18.990
if having 10-plus PoPs, you know, at GCP is also
00:21:18.990 --> 00:21:21.890
worth a three X price increase on compute. I
00:21:21.890 --> 00:21:24.450
don't know if that's the reason why, but I think
00:21:24.450 --> 00:21:28.069
the network is like the network resiliency is
00:21:28.069 --> 00:21:31.609
probably the one con to bare metal today. Yeah.
00:21:31.730 --> 00:21:33.849
I guess it matters what your workloads are if
00:21:33.849 --> 00:21:36.369
you, if you're latency sensitive, but yeah. Like
00:21:36.369 --> 00:21:38.809
if you're doing high traffic bidding applications
00:21:38.809 --> 00:21:41.740
where you need to bid for, for. creative or something
00:21:41.740 --> 00:21:44.319
i could see you needing to have that low latency
00:21:44.319 --> 00:21:47.839
for that but i don't think that most people if
00:21:47.839 --> 00:21:49.519
especially if you're serving websites or serving
00:21:49.519 --> 00:21:51.480
a web app i don't think for the most part it
00:21:51.480 --> 00:21:54.660
would matter but also i mean Level 3 is in
00:21:54.660 --> 00:21:57.099
northern virginia in the same area as you know
00:21:57.099 --> 00:22:00.900
you could probably buy colo space again i'm sure
00:22:00.900 --> 00:22:03.720
northern virginia area is is expensive just because
00:22:03.720 --> 00:22:07.170
dc metro area but You could probably buy Colo
00:22:07.170 --> 00:22:10.589
servers in that area competitively against AWS's
00:22:10.589 --> 00:22:12.349
rates as well. Well, it's kind of funny that
00:22:12.349 --> 00:22:16.170
you mentioned that. Because of AWS's presence
00:22:16.170 --> 00:22:19.190
there, we have so many companies that when they're
00:22:19.190 --> 00:22:21.450
switching to bare metal and using Cycle as part
00:22:21.450 --> 00:22:23.829
of that process, we have companies that specifically
00:22:23.829 --> 00:22:26.829
need bare metal in that region. And it's like,
00:22:26.890 --> 00:22:28.289
hey, you can deploy bare metal anywhere in the
00:22:28.289 --> 00:22:30.309
world. And they're saying, no, no, no, no. I
00:22:30.309 --> 00:22:32.809
need to connect to Supabase or... some other
00:22:32.809 --> 00:22:35.029
service running on top of AWS. So even though
00:22:35.029 --> 00:22:37.569
they're trying to get off of AWS as a cloud provider,
00:22:37.789 --> 00:22:40.250
they still need to be in proximity to it because
00:22:40.250 --> 00:22:42.029
so many of the services they're communicating
00:22:42.029 --> 00:22:45.170
with are still sitting right
00:22:45.170 --> 00:22:47.250
on top of that infrastructure. So we have companies
00:22:47.250 --> 00:22:49.490
that did initial test deployments and they were
00:22:49.490 --> 00:22:51.789
deployed to somewhere around New York City or
00:22:51.789 --> 00:22:55.289
somewhere to Atlanta and they would find out
00:22:55.289 --> 00:22:59.269
that extra. 12, 15 millisecond latency was too
00:22:59.269 --> 00:23:01.690
much for them. And so they had, so like, it's
00:23:01.690 --> 00:23:06.329
weird how there seems to be such a, and it's
00:23:06.329 --> 00:23:09.569
only on US East 1. We don't have any other companies
00:23:09.569 --> 00:23:12.450
that are like, oh, US East 2 or US West 1 is
00:23:12.450 --> 00:23:14.109
where I need to be. But for whatever reason,
00:23:14.150 --> 00:23:17.829
US East 1, we just have an extreme number of
00:23:17.829 --> 00:23:19.609
companies that are like, I need to be close to
00:23:19.609 --> 00:23:21.529
that. And it's kind of coincidental because that's
00:23:21.529 --> 00:23:23.130
the one that always has an outage or at least
00:23:23.130 --> 00:23:25.549
it seems. And it's the control plane for the
00:23:25.549 --> 00:23:28.349
rest of the services. So what I have found is
00:23:28.349 --> 00:23:30.970
when US East 1 goes down, if you have services
00:23:30.970 --> 00:23:34.069
that are in US West 2, maybe like an auto-scaling
00:23:34.069 --> 00:23:36.890
group that needs to scale up, you know, new instances,
00:23:37.109 --> 00:23:39.130
it's not able to because it's not able to reach
00:23:39.130 --> 00:23:40.849
out to the control plane, which lives in US East
00:23:40.849 --> 00:23:44.390
1. Yeah. There's still marriage there as much
00:23:44.390 --> 00:23:46.869
as they maybe try to say that they're isolated.
00:23:47.029 --> 00:23:49.670
They're not. Yeah, that is something I've absolutely
00:23:49.670 --> 00:23:52.269
noticed as well. When US East 1 goes down, you
00:23:52.269 --> 00:23:54.750
just have to assume that everything else is also
00:23:54.750 --> 00:23:58.490
impacted. Okay, so speaking about Cycle versus
00:23:58.490 --> 00:24:00.430
Kubernetes, what do you think that Kubernetes
00:24:00.430 --> 00:24:04.049
gets right? And where does it become self-inflicted
00:24:04.049 --> 00:24:10.160
pain? So with Kubernetes versus Cycle and when
00:24:10.160 --> 00:24:13.079
is kind of a better fit for one versus the other,
00:24:13.200 --> 00:24:15.839
it really kind of comes down to the needs of
00:24:15.839 --> 00:24:18.160
individual companies from a customization perspective.
00:24:18.339 --> 00:24:21.619
For companies that are really, as I mentioned
00:24:21.619 --> 00:24:23.680
earlier, kind of engineering heavy, that are
00:24:23.680 --> 00:24:27.259
like, hey, we're mainly developers. We're very
00:24:27.259 --> 00:24:32.279
microservice heavy. We might need object storage
00:24:32.279 --> 00:24:34.440
or like the requirements that they have are pretty,
00:24:34.539 --> 00:24:37.480
let's say, you know, commoditized, right? They
00:24:37.480 --> 00:24:39.599
need some disk. They need some, you know, object
00:24:39.599 --> 00:24:42.680
storage. They need kind of the primitives. That's
00:24:42.680 --> 00:24:44.740
where Cycle really shines. But at the same time,
00:24:44.779 --> 00:24:46.880
if you have companies that are like, hey, we
00:24:46.880 --> 00:24:50.519
need people to run on. very specific hardware
00:24:50.519 --> 00:24:53.359
with very specific kernel drivers and, you know,
00:24:53.380 --> 00:24:55.500
things like that. That's where Kubernetes is,
00:24:55.500 --> 00:24:57.460
you know, a better fit from that perspective
00:24:57.460 --> 00:24:59.920
because with Cycle, we ship a standardized OS
00:24:59.920 --> 00:25:03.440
to everyone. We don't provide SSH access. That
00:25:03.440 --> 00:25:06.000
OS is made to be as dumb and as tiny as possible.
00:25:06.579 --> 00:25:08.559
You know, it's 40 megabytes in size. So that
00:25:08.559 --> 00:25:10.119
means that naturally it's going to be kind of
00:25:10.119 --> 00:25:11.900
limited in terms of what it can do. Like our
00:25:11.900 --> 00:25:15.380
goal is to target 80%, right? But if you have
00:25:15.380 --> 00:25:16.960
like really specific infrastructure you need
00:25:16.960 --> 00:25:18.769
to run or, you know, Supercomputing applications
00:25:18.769 --> 00:25:22.430
or some of these big AI models that people are
00:25:22.430 --> 00:25:24.549
buying a whole bunch of really sophisticated infrastructure
00:25:24.549 --> 00:25:28.670
for these days. Cycle today is not built for
00:25:28.670 --> 00:25:31.799
bring anything. We are built for more of bring
00:25:31.799 --> 00:25:34.980
your typical x86 server you know with a few drives
00:25:34.980 --> 00:25:36.740
in it we'll get it up and running we'll get you
00:25:36.740 --> 00:25:38.920
what you need so it all comes back to whether
00:25:38.920 --> 00:25:41.759
do companies need just basic primitives and they
00:25:41.759 --> 00:25:44.359
don't want to be devops or do they have a very
00:25:44.359 --> 00:25:47.960
specific list of requirements um that you know
00:25:47.960 --> 00:25:52.180
extend from network to hardware to um maybe the
00:25:52.180 --> 00:25:55.279
oa the host os that those nodes need to run people
00:25:55.279 --> 00:25:57.279
who are coming to cycle are looking for an opinionated
00:25:57.279 --> 00:25:59.279
answer it's why most of the companies that are
00:25:59.279 --> 00:26:01.400
on Cycle today are companies that left Kubernetes for Cycle
00:26:01.400 --> 00:26:03.960
like you know they went that route they tested
00:26:03.960 --> 00:26:06.619
it um many of them were on Kubernetes for years
00:26:06.619 --> 00:26:09.859
before they decided like i think that it's natural
00:26:09.859 --> 00:26:12.099
for for all of us techies to want to play with
00:26:12.099 --> 00:26:14.059
new technologies but at some point people are
00:26:14.059 --> 00:26:15.859
like you know what i don't i don't want to play
00:26:15.859 --> 00:26:17.819
with all the bells and whistles anymore i just
00:26:17.819 --> 00:26:20.819
wanted to work yeah and it's something that you
00:26:20.819 --> 00:26:23.220
know i kind of talked about often is you know
00:26:23.220 --> 00:26:25.539
most people when they get their first smartphone
00:26:25.539 --> 00:26:28.779
or at least you know for me and most of my friends
00:26:28.779 --> 00:26:30.440
as we were growing up your first smartphone is
00:26:30.440 --> 00:26:32.960
an android right um and i know i'm probably about
00:26:32.960 --> 00:26:34.539
to piss off a whole bunch of people but you're
00:26:34.539 --> 00:26:36.359
for you know typically your first phone is an
00:26:36.359 --> 00:26:37.779
android phone because you want to you want to
00:26:37.779 --> 00:26:39.940
customize it you want to you know play with it
00:26:39.940 --> 00:26:42.759
you want to make it yours yeah yeah exactly um
00:26:42.759 --> 00:26:44.839
but eventually people are like i don't really
00:26:44.839 --> 00:26:46.519
care about that anymore i just want a phone that
00:26:46.519 --> 00:26:49.099
works i don't want to you know like let me change
00:26:49.099 --> 00:26:50.980
my background and i don't care and then they
00:26:50.980 --> 00:26:53.799
switch to an iphone um and so that's kind of
00:26:53.799 --> 00:26:55.839
what i've kind of always said about cycle like
00:26:56.190 --> 00:26:57.789
Companies, you know, they're going to go play
00:26:57.789 --> 00:26:58.990
with Kubernetes. They're going to go play with
00:26:58.990 --> 00:27:00.509
Rancher. They're going to go kind of test out,
00:27:00.589 --> 00:27:03.109
you know, the latest and greatest. They want
00:27:03.109 --> 00:27:05.210
something where they can change every variable.
00:27:05.509 --> 00:27:07.829
But at some point, it no longer becomes about
00:27:07.829 --> 00:27:10.150
changing variables and playing with the latest
00:27:10.150 --> 00:27:11.769
and greatest of everything. They just want to
00:27:11.769 --> 00:27:14.190
get back to what they want to build. And so that's
00:27:14.190 --> 00:27:15.609
where we built Cycle for companies that
00:27:15.609 --> 00:27:19.089
are like, yeah, just give me a standard opinionated
00:27:19.089 --> 00:27:22.710
platform and I'll just work with that. And so,
00:27:22.789 --> 00:27:26.509
yeah. Yeah, it makes sense. So, okay, wrapping
00:27:26.509 --> 00:27:29.130
up, what's one thing you'd do first if you had
00:27:29.130 --> 00:27:32.410
to modernize on-prem or hybrid without blowing
00:27:32.410 --> 00:27:35.390
up the team? This is going to go back to a conversation
00:27:35.390 --> 00:27:38.670
we had, you know, 10 minutes ago, but containerize,
00:27:38.750 --> 00:27:42.109
right? Like, you know, I'm a big fan of containerizing
00:27:42.109 --> 00:27:44.990
everything. It makes applications typically way
00:27:44.990 --> 00:27:48.549
more portable. And if your goal is to chase portability,
00:27:48.670 --> 00:27:51.829
so that way you can kind of move to whether it's,
00:27:51.829 --> 00:27:55.700
you know, VMs or bare metal or on-prem, I mean,
00:27:55.720 --> 00:27:57.619
I guess that's bare metal too. Or mixture. Being
00:27:57.619 --> 00:27:59.500
able to standardize containers is, you know,
00:27:59.519 --> 00:28:01.900
I think why I'm in such favor of them. Yeah,
00:28:02.000 --> 00:28:05.119
I think that would be my first step. I think
00:28:05.119 --> 00:28:07.579
that would absolutely be my first step from that
00:28:07.579 --> 00:28:09.680
standpoint. Now, if the question is, what if
00:28:09.680 --> 00:28:11.579
I'm already containerized and now I'm trying
00:28:11.579 --> 00:28:14.559
to like go towards, you know, bare metal? I think
00:28:14.559 --> 00:28:17.140
the next step there is, you know, look at your
00:28:17.140 --> 00:28:20.470
dependencies. If you're in a hyperscaler. And
00:28:20.470 --> 00:28:23.349
you're using things like Lambda and S3 and things
00:28:23.349 --> 00:28:25.210
like that. Your next step is kind of to decide
00:28:25.210 --> 00:28:27.490
what services I'm going to try to replicate on
00:28:27.490 --> 00:28:29.430
top of bare metal. What am I going to be okay
00:28:29.430 --> 00:28:33.230
having still in the cloud? And do the primitives
00:28:33.230 --> 00:28:35.509
that I need allow me to be on bare metal? Because
00:28:35.509 --> 00:28:37.390
again, if you are tightly integrated into Lambda
00:28:37.390 --> 00:28:39.430
and some of these other things, bare metal might
00:28:39.430 --> 00:28:41.750
not be the best fit for you. But if you're just
00:28:41.750 --> 00:28:43.470
running a whole bunch of containers, then you're
00:28:43.470 --> 00:28:45.990
kind of in a good spot. So assuming you're containerized,
00:28:46.089 --> 00:28:48.490
I think then the next part of that is just...
00:28:48.569 --> 00:28:50.589
evaluating what third-party services you need
00:28:50.589 --> 00:28:52.690
and whether you can bring those in-house or
00:28:52.690 --> 00:28:53.990
whether you're okay with those staying in the
00:28:53.990 --> 00:28:59.269
cloud. Have you noticed an increase in AI workloads
00:28:59.269 --> 00:29:02.529
and people building containers around AI-specific
00:29:02.529 --> 00:29:06.109
workloads using Cycle? So it's kind of interesting
00:29:06.109 --> 00:29:09.230
for how much, you know, you log into LinkedIn
00:29:09.230 --> 00:29:11.849
and Reddit and things and everything's about
00:29:11.849 --> 00:29:13.930
AI. So many of the companies that are on Cycle
00:29:13.930 --> 00:29:16.269
today, like, yes, you know, a number of them
00:29:16.269 --> 00:29:19.200
do have some AI component. in what they're doing.
00:29:19.279 --> 00:29:21.819
But I think we only have one or two clients that
00:29:21.819 --> 00:29:24.700
are running like true models with GPUs. Yeah.
00:29:25.079 --> 00:29:27.700
I didn't mean like API calls to OpenAI, but
00:29:27.700 --> 00:29:30.799
yeah, like actual modeling locally. Yeah. Yeah,
00:29:30.839 --> 00:29:35.000
so Cycle out of the box supports all NVIDIA data
00:29:35.000 --> 00:29:37.319
center class GPUs. And so that's one of the drivers
00:29:37.319 --> 00:29:39.420
that we keep up to date. So we support that.
00:29:39.579 --> 00:29:43.279
But we were hoping that we'd have more AI, you
00:29:43.279 --> 00:29:45.039
know, focused applications on top of the platform
00:29:45.039 --> 00:29:47.119
today. But I think that it's one of these kind
00:29:47.119 --> 00:29:48.900
of interesting things where it's kind of like
00:29:48.900 --> 00:29:53.180
with IoT and then crypto and now AI. Like, yes,
00:29:53.299 --> 00:29:55.200
you know, there are hype waves. And I'm not saying
00:29:55.200 --> 00:29:59.009
that AI is, you know, you know. equivalent to
00:29:59.009 --> 00:30:02.970
IoT or crypto or things like that but as we see
00:30:02.970 --> 00:30:06.549
these hype waves happen we always see people
00:30:06.549 --> 00:30:10.690
who kind of love bleeding edge technology chase
00:30:10.690 --> 00:30:12.589
them right like so many of my friends that were
00:30:12.589 --> 00:30:15.789
like really gung-ho on on crypto are now the
00:30:15.789 --> 00:30:18.170
same people that are really deep into you know
00:30:18.170 --> 00:30:20.769
ai and then the next thing that comes out they're
00:30:20.769 --> 00:30:22.410
going to chase that as well like it's what they
00:30:22.410 --> 00:30:25.630
do and those people typically are the same people
00:30:25.630 --> 00:30:30.200
that like changing all the, you know, the dials
00:30:30.200 --> 00:30:32.599
and they like playing and tweaking. And so that's
00:30:32.599 --> 00:30:34.059
where they kind of, I think those people, they
00:30:34.059 --> 00:30:35.839
don't want an opinionated platform like Cycle.
00:30:35.920 --> 00:30:37.559
They want something where they can customize
00:30:37.559 --> 00:30:40.319
everything. It's kind of like the book of, you
00:30:40.319 --> 00:30:43.180
know, Crossing the Chasm, right? Cycle is there
00:30:43.180 --> 00:30:45.099
for the majority in the middle. They're like,
00:30:45.200 --> 00:30:46.740
hey, no, I just want to run stuff. I want to
00:30:46.740 --> 00:30:49.180
build stuff. But then, you know, those super
00:30:49.180 --> 00:30:50.900
early adopters that are always chasing new technology,
00:30:51.160 --> 00:30:54.619
they want to be, they want more customization
00:30:54.619 --> 00:30:57.609
than Cycle will give them. And I guess to an
00:30:57.609 --> 00:30:58.950
earlier point, that's where Kubernetes probably
00:30:58.950 --> 00:31:00.710
makes more sense for them. But when applications
00:31:00.710 --> 00:31:02.690
kind of become more standardized and they just
00:31:02.690 --> 00:31:04.650
want to run them, then that's where Cycle starts
00:31:04.650 --> 00:31:07.910
to win. Makes sense. What is Cycle? Why would
00:31:07.910 --> 00:31:10.910
someone choose Cycle? What would be a reason
00:31:10.910 --> 00:31:13.829
for choosing Cycle? Yeah, so for an organization
00:31:13.829 --> 00:31:17.009
that is really engineering heavy, a company that
00:31:17.009 --> 00:31:19.750
wants to spend more time focused on building
00:31:19.750 --> 00:31:22.369
versus maintaining. And when I say building versus
00:31:22.369 --> 00:31:24.089
maintaining, I'm talking about building the actual
00:31:24.089 --> 00:31:26.170
applications, the platforms, the services, etc.
00:31:26.349 --> 00:31:29.789
Less on maintaining the host OS, the host kernel,
00:31:29.970 --> 00:31:32.750
the underlying infrastructure. That's where Cycle
00:31:32.750 --> 00:31:34.390
really shines for these organizations, especially
00:31:34.390 --> 00:31:38.150
teams that where they have. really talented developers,
00:31:38.289 --> 00:31:40.210
but these developers really don't have interest
00:31:40.210 --> 00:31:42.509
in becoming DevOps engineers as part of that
00:31:42.509 --> 00:31:45.029
process is kind of where Cycle shines. Makes
00:31:45.029 --> 00:31:48.069
sense. Okay, so wrapping up, where can people
00:31:48.069 --> 00:31:50.430
read more about you, find out about you, read
00:31:50.430 --> 00:31:52.109
more about Cycle? Where should they go? Yeah,
00:31:52.170 --> 00:31:54.710
so to learn more about Cycle, you can visit our
00:31:54.710 --> 00:31:57.400
website, which is Cycle.io. We also have a Slack
00:31:57.400 --> 00:31:59.839
community that we have a lot of developers and
00:31:59.839 --> 00:32:02.220
DevOps engineers that hang out in. That's
00:32:02.220 --> 00:32:05.599
slack.cycle.io. And then for people who want to maybe
00:32:05.599 --> 00:32:09.380
learn more about me, I guess linkedin.com/in/jakewarner. Like it's kind of weird
00:32:11.539 --> 00:32:14.960
to hand out my or to use my LinkedIn as that
00:32:14.960 --> 00:32:17.299
as the primary source. But I think I keep it
00:32:17.299 --> 00:32:18.960
more up to date than anything else I do these
00:32:18.960 --> 00:32:21.619
days. That makes sense. I'll also put links for
00:32:21.619 --> 00:32:23.759
all of that in the show notes as well. So make
00:32:23.759 --> 00:32:27.029
it easier. Sounds good. Awesome. Well, thank
00:32:27.029 --> 00:32:29.190
you, Jake, so much for coming on and telling
00:32:29.190 --> 00:32:31.930
me more about Cycle and containerization. Really
00:32:31.930 --> 00:32:34.009
appreciate it. Yeah, really, really appreciate
00:32:34.009 --> 00:32:36.750
you having me on, Brian. Really enjoyed the conversation.
00:32:37.289 --> 00:32:40.349
Always fun to be able to, you know, as you mentioned
00:32:40.349 --> 00:32:42.430
earlier about racking and stacking, meet people
00:32:42.430 --> 00:32:44.509
of like mind in terms of how we got to where
00:32:44.509 --> 00:32:48.089
we are today. Awesome. Thanks. All right. That
00:32:48.089 --> 00:32:50.730
was my conversation with Jake Warner from Cycle
00:32:50.730 --> 00:32:53.930
.io. My biggest takeaway from this one. is that
00:32:53.930 --> 00:32:56.750
the cloud versus bare metal debate is kind of
00:32:56.750 --> 00:32:58.829
the least interesting version of the conversation.
00:32:59.150 --> 00:33:01.490
The better question is, what are you actually
00:33:01.490 --> 00:33:04.390
trying to optimize for? Because sometimes the
00:33:04.390 --> 00:33:06.690
answer is cloud. Sometimes it is Kubernetes.
00:33:07.009 --> 00:33:09.829
Sometimes it is managed services all the way
00:33:09.829 --> 00:33:12.410
down because your team does not have the time,
00:33:12.529 --> 00:33:15.730
people, or business reason to own more of the
00:33:15.730 --> 00:33:17.970
stack. But sometimes the answer is different.
00:33:18.150 --> 00:33:21.089
Sometimes the problem is cost. Sometimes it is
00:33:21.089 --> 00:33:23.920
performance density. Sometimes it is data sovereignty.
00:33:24.240 --> 00:33:27.400
Sometimes it is compliance. Sometimes it is latency.
00:33:27.660 --> 00:33:29.819
Sometimes it is the fact that your developers
00:33:29.819 --> 00:33:32.460
just want to ship software and your platform
00:33:32.460 --> 00:33:35.859
team is slowly drowning in a pile of abstractions
00:33:35.859 --> 00:33:38.180
that were supposed to make everything easier.
00:33:38.359 --> 00:33:40.640
That is the part I think is worth paying attention
00:33:40.640 --> 00:33:43.630
to. A lot of teams do not necessarily want to
00:33:43.630 --> 00:33:46.329
go backwards. They want to go back to owning
00:33:46.329 --> 00:33:49.230
the parts that matter without reintroducing all
00:33:49.230 --> 00:33:51.890
of the old pain. And that is a much more useful
00:33:51.890 --> 00:33:54.670
framing than pretending there is one correct
00:33:54.670 --> 00:33:57.609
infrastructure model for everybody. I also like
00:33:57.609 --> 00:34:00.509
Jake's point about opinionated platforms. Because
00:34:00.509 --> 00:34:03.990
as engineers, we love flexibility. We love knobs.
00:34:04.230 --> 00:34:06.869
We love knowing that technically, if we really
00:34:06.869 --> 00:34:09.809
wanted to, we could customize every piece of
00:34:09.809 --> 00:34:12.250
the stack. But there is a cost to that. Every
00:34:12.250 --> 00:34:14.969
knob becomes a decision. Every decision becomes
00:34:14.969 --> 00:34:18.070
something to document. Every exception becomes
00:34:18.070 --> 00:34:21.230
something to support. And eventually, the platform
00:34:21.230 --> 00:34:24.090
that was supposed to help teams move faster becomes
00:34:24.090 --> 00:34:27.090
another system that needs its own platform team
00:34:27.090 --> 00:34:29.949
just to keep it sane. That does not always mean
00:34:29.949 --> 00:34:32.869
opinionated platforms are always better. If you
00:34:32.869 --> 00:34:35.449
need very specific kernel drivers, specialized
00:34:35.449 --> 00:34:39.079
hardware, deep customization, or you are doing
00:34:39.079 --> 00:34:42.159
weird edge case infrastructure work, then Kubernetes
00:34:42.159 --> 00:34:45.559
or a more flexible platform may absolutely be
00:34:45.559 --> 00:34:48.179
the better fit. But for a lot of teams, especially
00:34:48.179 --> 00:34:51.739
teams that mostly need containers, VMs, networking,
00:34:52.099 --> 00:34:55.780
storage, load balancers, and a sane way to deploy
00:34:55.780 --> 00:34:59.119
applications, there is a real argument for fewer
00:34:59.119 --> 00:35:02.159
choices and better defaults. And honestly, that
00:35:02.159 --> 00:35:04.440
is probably where a lot of infrastructure conversations
00:35:04.440 --> 00:35:07.039
are heading. Not everything should be cloud.
00:35:07.199 --> 00:35:09.900
Not everything should be Kubernetes. Not everyone
00:35:09.900 --> 00:35:12.800
should move back to bare metal. More like what
00:35:12.800 --> 00:35:16.099
complexity is actually helping us? And what complexity
00:35:16.099 --> 00:35:19.159
are we just carrying? Because the industry told
00:35:19.159 --> 00:35:22.219
us this is what modern infrastructure is supposed
00:35:22.219 --> 00:35:25.340
to look like. I'll have links to Jake,
00:35:25.340 --> 00:35:28.420
Cycle.io, and their Slack community in the show notes.
00:35:28.619 --> 00:35:31.599
If you enjoyed this conversation, follow or subscribe to
00:35:31.599 --> 00:35:34.179
Ship It Weekly wherever you listen to podcasts.
00:35:34.599 --> 00:35:36.900
It helps the show, and it makes sure you get
00:35:36.900 --> 00:35:39.420
both these conversation episodes and the weekly
00:35:39.420 --> 00:35:42.420
DevOps, SRE, platform, cloud, and security news
00:35:42.420 --> 00:35:45.079
recaps. You can also find the show notes and
00:35:45.079 --> 00:35:48.440
links over on shipitweekly.fm. Thanks for listening,
00:35:48.500 --> 00:35:50.099
and I'll see you later this week.
