Bret (2): were you sorta seeing where
this all could take us in terms of
agents helping us in infrastructure
Doron: we wanted to reduce the
cognitive load on engineers not
having to stitch together Kubernetes,
Istio, Grafana, Prometheus, Vault,
and all the CNCF, solutions out there.
And we created an API that gives you
unified access to any cloud, any service,
and we find that AI, if you just tell it,
"Create me the infrastructure," it's gonna
duplicate a lot of resources: and it's
gonna be expensive, non-deterministic, and
it's gonna be non-secure, non-compliant.
And where is the logging, the metrics,
the tracing, the secrets management,
the service discovery, the TLS, the DNS?
And the list goes on and on.
So what AI needs, just like an engineer
needs, is a reduced cognitive load.
Give it a deterministic API
that says, "Hey, take my
desired state and make it so.
And by the way, make it so on any
cloud." It makes AI a lot more effective.
we find AI in a perfect, intersection
because we can now make it do
tricks that is otherwise very, very
expensive or even u- unattainable
Bret (2): Welcome to another
episode of DevOps & Docker Talk.
I'm your host, Bret, and in this one,
we go deep into the universal control
plane for the cloud and the search for
the singular management system, which
we have been doing my entire 30-year
career, been trying to find that perfect
sweet spot of a tool that can manage
all of my infrastructure from one API.
And what better person to have on
to talk about this than the CEO and
co-founder of Control Plane, the company
building this unified API layer for
controlling all your infrastructure.
I'm having Doron Grinstein on the show,
and we go deep into what they're building,
And he has a very similar story to me,
just trying to use the infrastructure
that we had at the time and the tooling
we had at the time, and I have managed
infrastructure for so long that I have
forgotten about all the tools that we've
tried to use over the years to unify
everything, and we never quite get there.
We get 60%, maybe if you're really
lucky, 80%, but then there's always
that other thing that doesn't quite fit.
And it's exciting to see a company
that's brave enough to take this
on, because it's no small task.
It's no small achievement to be able
to say you have a universal API control
plane that you can access from the
browser or from Terraform or from Pulumi
or from your agent harness, and it feels
like that's what they're achieving.
And we walked through a bunch of demos.
In fact, if you're interested in the
demos, go check out the link in the
show notes to go to the live stream,
'cause we demoed for about an hour
after the conversation, and, we
didn't put those into this podcast.
So if you wanna check out all
those demos, go check the link.
But we talk about everything from
how they onboard customers, what are
their customers looking like in terms
of their infrastructure, and how are
they managing it once they get there.
Surprise, not a lot's changed.
They still use Terraform or OpenTofu.
All the things that they were using
before are compatible with their APIs.
But they also have MCP and CLI tools
to manage this, and once you get into
their interface, you realize that part
of what they can do, because they're
agnostic and they want to operationalize
all of this across multi clouds, is
they're setting up the Kubernetes
distributions across the clouds for you.
They're making the decisions around how
the encrypted tunnels are gonna happen
between the different providers, it
feels kind of like what Docker felt at
first, where they had this old saying
at Docker of, "Batteries included, but
swappable" and that is something that
I feel like I could call control plane.
It feels like it's very easy out
of the box, but they hide a little
bit of that complexity with their
opinionated defaults, which I like
opinionated defaults, especially
when I agree with those opinions.
And we dive into some of their extra
features that they're building on top
of this universal control plane, like
a, a sandboxing approach that is so
popular right now that we have agent
harnesses needing sandboxes, and we're
now talking about the corporate vibe
coders, which I call app creators, the
people that are outside of IT that maybe
need a safe space to experiment with
ideas that they can then hand over to
either robots or humans to maybe develop
further and get onto their production.
Those people are coming, and us platform
engineers and DevOps engineers, we're
having to deal with that problem, and it
feels like we need some solutions that
help automate that middle layer out of the
way with a higher level of abstraction,
and it looks like that's what they built.
So let's get into my conversation
with Doron about Control Plane.
welcome to the show.
I'm glad to have you here.
Doron: g-great to be here.
looking forward to it
Bret (2): Give us a little bit of your
background, Tell me the origin story,
Doron: I ran a company, sold a
company, was chief architect at
Dell, chief architect at, SAP, and
then ended up as, chief architect,
for VMware for cloud services.
And, at VMware, I missed my
interactions back at SAP with a guy
named Dan Wilson, who was the best
DevOps/platform engineer I ever met.
And what I wanted at VMware
was, Dan Wilson as a service.
And, I really saw hundreds of,
outside customers and internal teams
struggle with Kubernetes, Istio,
Grafana, Prometheus, and having to
reinvent the wheel again and again.
And so had the idea for Control
Plane, left VMware, started
this company, called Dan Wilson.
He was back at SAP and I said, "I want you
to join me as my CTO and really deliver to
the world, what you do as a service." And
I thought it's gonna be a hard battle, but
he jumped ship and he said, "Yeah, I'll
join you." And, that was the origin story.
And then we brought on a few other
brilliant, engineers that have decades
of, practice on, on, cloud native
architectures, and, we built this company
Bret (2): this is pre-AI, right?
So, th- we're gonna get into a
whole bunch of details later on,
agent-driven infrastructure, like
MCP and CLI tooling, agent h- harness
first, whatever we wanna call this
thing, th- this new future we're in.
but what did, what was it like
to to be an infrastructure
company and to see AI coming?
Were, were you sorta like seeing
where this all could take us in
terms of agents helping us in
infrastructure and stuff like that?
Doron: 100%.
we, I think, got more lucky.
We have more luck than brain, because
it found us at a very interesting time.
We, we wanted to reduce the cognitive
load on engineers not having to stitch
together Kubernetes, Istio, Grafana,
Prometheus, Vault, and the things…
all the CNCF, solutions out there.
And we created an API that gives you
unified access to any cloud, any service,
and we find that AI, if you just tell
it, "Create me the infrastructure," it's
gonna duplicate a lot of resources: a
NAT gateway, a load balancer, brain, a
Kubernetes set of nodes, and it's gonna
be expensive, non-deterministic, and
it's gonna be non-secure, non-compliant.
And where is the logging, the metrics,
the tracing, the secrets management,
the service discovery, the TLS, the DNS?
And the list goes on and on.
So what AI needs, just like an engineer
needs, is a reduced cognitive load.
In the era of AI is less
tokens, less context window.
Give it a deterministic API
that says, "Hey, take my
desired state and make it so.
And by the way, make it so on
any cloud." It is a boon for AI.
It makes AI a lot more effective.
we find AI in a perfect, intersection
because we can now make it do
tricks that is otherwise very, very
expensive or even u- unattainable
Bret (2): Yeah, I always struggled
with, automation, pre-AI, in terms
of, there's a point at which you're
trying to automate things and
automate triggers and intelligence
with a deterministic language.
And I always would get to a point where
I want this to be more automated, but
the level of effort to automate that
small thing was way more than it was
worth in terms of the automation.
And, and in DevOps forever, we've been
talking about the toil, and I think
that, I think the first time I heard
that was from Google's SRE paper, was
talking about, the toil of ops, and
I always felt like there was a better
way, a more complete way to automate
things, but every time I would try to
take it to the next level, it, it was
like the management had no tolerance
for me spending all of my time trying
to automate these little things.
I'm like, "Yeah, but they're tiny
paper cuts and they add up over time,"
and I was trying to, defend the,
the case for more automation, but
we would just never quite get there.
And now I feel like the
world is our oyster.
I feel like we're, we're at a place where
you're only limited by your imagination
and your ability to, manage the harness
and manage that agent inside it.
Doron: we, we called it
the cloud is your oyster.
We truly allow you to have a singular
API and leverage BigQuery on Google
and Cosmos DB on Azure and S3 on Amazon
and-- or any one of the services.
You can now write code and run it on your
Raspberry Pi or Dell machine or your EC2
instances or EKS, AKS, GKE, whatever.
And you can, not be
confined by any factor.
So think of all the clouds as They have
merged, and now you can run the compute in
a basement or on a cloud or on a secondary
or neo cloud, but leverage any service of
any cloud, and, and let AI do the work.
Like, I need a Postgres, I
need a Redis, I need a Kafka.
You can conversationally get those
things up and running deterministically
Bret (2): All right, so if we back up a
second, If someone hasn't heard of Control
Plane, how is this different than a cloud
or different than a cloud management
tool that we might all be using, like
Terraform or, any of the dozen, different
opportunities I have to manage my cloud
with a CLI or some sort of service?
Doron: Sure.
So Terraform allows you
to create resources.
We provide the Terraform
provider for control plane.
We provide Pulumi, we provide other
interfaces Control Plane is a virtual
cloud, allowing you to not have a
cloud and be cloudless and still
run on Amazon, Google, Azure, Oracle
without a cloud account and pay by
the millicore and megabyte of compute.
So if you deploy the Bret app,
you can run essentially serverless
on any cloud or multiple clouds
without having a cloud account.
You can bring your own cloud account.
If you're a SaaS and your customers
tell you, "Hey, you must run on Azure,"
or, "You must run on Oracle," or,
"Must run on Hetzner," you now can.
Your code, without any change,
can run anywhere, even on-prem.
We let you have observability
built in We let you, as I
mentioned, run by the millicore.
We let you, communicate across clouds.
If you have data in a VPC, let's say
RDS, Relational Database Service, and
you want to run the workload on-prem,
yet communicate with RDS without
poking holes in the firewall, you can.
You can, run above the cloud.
So today, when you run RDS as
an example, you're paying a
high premium to run a database.
You're not paying for the compute.
Control Plane lets you run any
open source project very easily.
We've certified, lots
and lots of, templates.
You can run Kafka, Postgres, MySQL,
Cassandra, Mongo above the cloud.
So if you wanted to move your
persistent store to Linode or Hetzner
or Oracle or on-prem, you can.
If you need multi-master replication,
we support that for many database types.
we provide, sandboxes, so you
can deploy workloads or, or write
code in a isolated environment.
The difference about our, sandboxes
is that they allow you to communicate
to your databases and other resources
in private data centers or VPCs.
And you can traverse the network
boundary, easily connecting Amazon
US East and Azure US West and Oracle
in, the Middle East, et cetera.
So you can think of all the clouds
have, having merged and, with a hundred
x simplification on how to consume
them, but without any limitation.
So if you need to use the
native SDK for SQS, SNS,
Dynamo, or any other native service,
you can we, we-- think of us as
a virtual cloud, just like what
virtualization did to servers.
You didn't care if it's
Dell or HP, we do to cloud.
We make it so you don't care and the
agent doesn't care if you're running
on Azure or any other, cloud provider.
In fact, you can deliver traffic close
to where the customer is, and if there
is a failure, let's say Amazon US East is
down, you automatically get routed to GCP
or to Amazon US West or somewhere else.
So you deliver low latency
and extreme high availability.
We provide a five-nine guarantee,
translating to five minutes, fifteen
seconds per year of cumulative downtime.
So the reason customers come to us is
for unbreakable compute, for, extreme
ease of use, for, cost optimization.
Many of our customers save about fifty
percent compared to running natively
on Amazon or Google because They can
pay for what they use and not pay for
a cow when you need a glass of milk.
'Cause when you buy a Kubernetes
cluster, you pay for the brain nodes,
the worker nodes, you pay a hundred
percent of their utilization, even
though they may consume twenty percent.
And on control plane, you
pay twenty percent if you're
consuming twenty percent.
Bret (2): so you built this sort of
unified API layer over multiple clouds
and, It sounds like you're adding almost
like your own custom services on top
of that like you mentioned the, the
sandboxing, and obviously someone can,
design their own little, EC2 instance
or whatever, or they can, they can try
to design their own sandboxing solution.
But it sounds like you're, you're
adding these as, specific services
on top of that unified API, This
is actually a long question.
I'm spitballing here.
But, you could implement something
in one of those sandboxes or one of
your other, ideas on top of any of the
clouds, whether or not that cloud has a
particular offering labeled that, right?
'Cause when I think of unified
cloud, I think of, reducing it down
to its core elements and then, only
getting to use those core elements.
But it sounds like you're
enriching on top of that API to
give us higher level services.
Doron: yes, people assume because
we unify the cloud, we give
you, lowest common denominator.
But in fact, we're the opposite.
We give you the union of all clouds,
because now You can write the code
with a native SDK for Google, for
Cloud Spanner, for Amazon, for, SQS,
for, Azure, for cloud, for, let's
say, Entra ID or Cosmos DB or whatever
machine learning service that is on
Azure, and we allow you to consume
those services without credentials.
Why is it important in the era of AI?
You do not want to leak to
the LLM, the credentials.
So neither in design time, meaning coding,
nor at runtime are keys exposed, and
in fact, you don't even have to rotate
the keys because you get ephemeral,
zero trust, least privileged tokens.
and we patented the technology
called Universal Cloud Identity that
basically gives you the identity, the
IAM of all the clouds in a much more,
streamlined manner, and the code is
devoid of credentials completely.
Yet the code can only do the
exact, operations on the exact
resources you granted it access to.
Bret (2): what are you
seeing with adoption?
as a, as someone who's… I've managed
infrastructure for over 30 years
at this point, and, w- we've been
chasing this dream in ops land of,
the unified control plane, right?
we've had for decades now, ever since
really the cloud or before, we've
had all these attempts at unifying.
You know, VMware wanted to do it.
Microsoft tried to do it.
we had just all these different pieces,
and the best we could do was, like, stick
to one OS and then use their, I think
they, system management tools or whatever.
And then I feel like ever since then
I've been chasing this dream, whether
it was Terraform or Chef and Puppet
before that, and then we got Pulumi, and
we've had all these different attempts
at, one control plane essentially that
controls not necessarily my workloads,
but just the infrastructure behind it,
and it's always felt like a compromise.
It always felt like if I'm gonna do
Terraform, that's great, but it's gonna
get much harder as I go multi-cloud, and
I'm gonna be spending my days in TOML
hell just trying to make sure I don't
break things with a, with an update.
So I'm curious of, like, some
customer stories around, onboarding.
How do people get to control
plane from where they are,
and what does that look like?
Doron: Yeah.
So we have, over, eighteen hundred,
now over two thousand customers.
Some of them are very large,
some of them are tiny, doing
vibe, coding type projects.
And most of the larger customers,
the-- none of them are greenfield.
They're all coming from Amazon,
from Google, from Heroku, from, uh,
Azure, and they all have a sprawling,
degree of Helm charts and, Terraform
or Pulumi or Crossplane, artifacts.
And we have, mechanical translation in
the CLI allowing you to take a Kubernetes
YAML and enrich it to the Control
Plane YAML because Kubernetes doesn't
have the concept of the global virtual
cloud, a cloud made up of N clusters.
So in Control Plane, I can take three
clusters or three hundred and turn
them into one global virtual cloud
or actually subdivide them into many
global virtual clouds and deploy an
application to the GVC, which is like
a VPC, but spread across two regions or
a hundred in one cloud or many So our
customers typically have a couple days
up to a couple weeks, depending on how
large the customer is, of migration,
which is, again, that mechanical
translation of their YAML or Helm chart
or other artifacts to Control Plane.
But we integrate very nicely
into their CI/CD pipelines.
We integrate with Flux or Argo CD.
so it's very natural.
The learning curve is very shallow.
Once you learn Control Plane, you
feel, and what I hear from customers,
we run circles around our peers.
And one customer, I think the best
compliment I ever got was after
using Control Plane, moving back
to not using Control Plane is like
going from iPhone seventeen to
Nokia from nineteen ninety-seven.
That's-- And, and now, that was
very rewarding for me to hear, and
I would-- I'm eager to demonstrate.
and my objective is after this,
call, y- are you gonna go back to
the old ways or are you gonna adopt
Control Plane to deploy your code?
I think it's the latter, because,
it's-- we, we truly give you,
Dan Wilson as a service, the one
I, I mentioned, I started with.
He's our CTO, and he really, rather than
you having to spend or the AI having
to spend millions of tokens reinventing
the wheel, focus on what matters, which
is your rocket shipping system or your,
whatever the thing that you're doing
and not be, knee-deep in the toil.
and there is a lot of toil.
It's one thing to have toil,
but why should every company
reinvent the same wheel?
Logging, metrics, tracing, secrets,
m- mutual TLS between services because
you want a service mesh, audit trail,
scaling, scaling strategies, failover
Should every company reinvent that wheel?
Does that make sense?
Should every company have an Exchange
server engineer babysitting email?
That was the case.
It isn't anymore because it
doesn't make sense when you can,
shift left or whatever, delegate
that, mundane responsibility to
somebody who is excelling at it.
And think about it.
If every company reinvents the same
items I just mentioned, it represents
technical debt because now you need to
maintain, fix the CVEs, upgrade Kubernetes
every three months, upgrade Istio,
upgrade Prometheus, upgrade Grafana.
When do you have time to do the
actual work when you're babysitting
an infrastructure that your
peers are doing the same thing?
We say stop with the babysitting
of infrastructure, start
delivering value to customers,
Bret (2): We talked about this
last time when we, we had a
r- a call a couple weeks ago.
The, the assumption that I have about
services like this, like if I'm looking
at your homepage and I've not talked
to you and I don't know anything about
the company, is that, to me, there's
always a compromise, I feel like.
And so when I think about the complexity
of the cloud APIs, just for AWS, the,
"This Week in AWS" podcast with Corey
Quinn, I've been, I've been on his
show, he's been on mine, but I, I always
find his articles about, yet another
AWS service that we don't understand
what it is, and it's redundant.
And, and so he talks about the hundreds
and hundreds of services they have, and
it's, th- there's always a customer for
the things, but it may not be you or me.
And I always find it hilariously
complex that I am so behind on how
many of those products I don't know
about and I've never used, and it just,
Am I even an engineer if I
don't understand half the
things that AWS deploys, right?
Sometimes I question it.
But, I'm curious about, how your API
relates to their product APIs, and how
you guys have been able to innovate
around covering all the bases to make
sure that we're not left with, this
reduced abstraction that's only the
same core fundamentals across every
cloud, but you're allowed to, you're
able to e- enrich it a little bit.
Tell me a little bit about that.
How's that work?
Doron: Yeah, that's a great question.
So I mentioned we're not the
lowest common denominator, but the
union, and what does that mean?
It means if Amazon came up with a
Bret service a microsecond from now,
we would support it because we're
not trying to, abstract the API,
the native API to the Bret service.
We integrate at the identity
and access management layer.
And so we would mechanically be able
to pull permissions from their IAM IAM
system relating to the new Bret service.
The coder, AI or human, would use
the native SDK if there is one to the
Bret service or the C-- or the API.
We just inject the token necessary
for the Bret service to do its work,
and we're able to do it whether you--
the workload is running on-prem,
on Hetzner, on DigitalOcean, , on
Google, on Amazon, on Azure.
So because we integrate at the IAM, the
identity and access management layer
Bret (2): Yeah
Doron: We are supportive of any
new service that Google, Amazon or
anybody else provides instantly.
There is no work that we need to do.
And the likelihood of Amazon or anybody
else changing their identity and access
management APIs that we exploit are
zero, because if they change their APIs,
the cl-- the world would break, right?
Because everybody, millions of
people have, utilized their services.
So if they were to change, they
would give you multi-year head start.
but, because again, we integrate at the
IAM level, when you consume, let's say,
RDS, but you're on, Azure, the, the, the
workload is running on Azure or on-prem,
we obtain the correct token from their
STS, their security token service, and
know how to inject it at runtime from
the SDK to RDS, in our case, And, so in
effect, the workload is liberated and
no longer captive to the subject cloud.
You can now move amongst the clouds.
People spent millions of dollars
moving from Amazon to Google or
Google to Oracle, but on Control
Plane, the cloud is your oyster.
You can move from Amazon to Google,
from Google to on-prem, from on-prem
to whatever with a click of a button,
and you can leverage all of them.
So we flip the script where
the clouds want to-- their
objective is to lock you in.
We flip it on its head and, turn them
in-into just commoditized utilities.
So when you consume electricity,
your TV doesn't care if it's
Edison or somebody else.
It cares about the interface.
With Control Plane, you now have a virtual
cloud operating system that utilizes
the power, the whole power of Amazon,
the whole power of Google, et cet- et
cetera, but without locking you in.
Bret (2): Yeah.
I wanna change the conversation
a little bit to be more specific
on some of the AI, uh, stuff that
we're all managing right now.
So, this whole year for me has been really
focused in understanding other DevOps
teams and, platform engineering teams,
like understanding the way that they're
using agent harnesses to do their job.
I think, if we f- if we rewound a year
ago, maybe even three or four years
ago when Google Copilot was kinda like
the first IDE to throw AI completion
in, and even in those early days,
I think I demoed it when it was in
beta when we were on this channel.
I remember one summer we were, I
think it was 2022 or something.
It was before ChatGPT came out, and we
were, like, looking at the, the early
GPT model that was embedded in, in
GitHub Copilot, and the, VS Code UI.
And we were, we were trying to
see how far we could get with YAML
and TOML by tab completing, right?
Like, we were trying to figure out
how much time can it save me as an,
as a ops engineer, but we were really
just talking about file completion,
completion in a YAML statement.
So, it was saving me keystrokes, and
it maybe, was saving me potentially
some human error that would
hopefully be caught by a linter,
but it wasn't a huge gain, right?
And so you fast-forward a
little bit, and then we're all,
we're doing that with ChatGPT.
People are copying and pasting.
And then last year when we got Claude
Code for the first time and we under- we
started to understand what an agent loop
is, it, it started to shift and I started
to notice that my, my production friends
were all dabbling with letting their, the
first thing they would do is let their
agent have, a read access token to some
part of their infrastructure so that it
could maybe run the kubectl commands for
them or run the AWS CLI commands for them.
And I was doing that same thing
for, like, GitHub CLIs for, for CI.
CI.
Like, I cared about GitHub Actions
and, my build status and stuff
like that, so I was, I was managing
that middle portion, and I was
using agents to, keep track of it.
And now it's like these are all inherent
features that are really built in.
They, they've got the background
workers, the sub-agents, and things
that are making this really possible.
But I'm curious what you're
seeing with your customers.
how, how are they driving
their infrastructure with AI?
Like, I guess maybe if we can get
to some, into some nitty-gritty
details around, are they focused
on only using their agent harness?
Are they using, MCP to, to Control Plane?
Are they using, Control Plane CLIs?
Like, how are they actually doing
this work, and what are some
of the stories you're hearing?
Doron: Yeah, our customers, pretty
much all use our MCP server,
and we always pride ourselves in
providing all the accessibility.
Of course, at the lower end is, is the
API, but everything you can do in the
API, you can do in the CLI, Terraform,
Pulumi, Crossplane, UI, and MCP.
To us, these are symmetric interfaces.
Of course, with MCP, you can now bring
the intelligence to let it discover
what can be done, and now you can
have conversational infrastructure.
You now have the equivalent of
a enterprise architect/platform
engineer/DevOps/SRE bundled into one
that you can have a conversation with.
you can tell me the app you want
to build and the dependencies that
you want to have, and the MCP will
go and negotiate and build those
things that we want to build for us.
And then if we need to troubleshoot
or need to look at observability, the
MCP is able to look at the traces,
the logs, the metrics, a- and add the
intelligence to give you actionable items.
So you feel like you have the best SREs
and platform engineers at Google with you
twenty-four seven, and you don't pay them.
So you can vibe code a very complex
system made up of 20 microservices all
intertwined with databases and queues
and, and caches and say, "Okay, give
it to me codified." And our codified
version is always backwards compatible.
So I'm sure Kubernetes deprecate
stuff every three months.
You have some deprecations and new APIs.
It's a fairly unstable substrate.
So if you wanted to take YAML
from 10 years ago and just run
it, you'll run into issues.
So we made an early choice.
Bret (2): At a minimum
warnings, possibly errors, yeah
Doron: Right.
And we made a decision.
We, we noticed that six years ago and
made the very, I think, good decision of
always having backwards compatibility.
So if you take YAML from six years ago and
apply it today, you'll get the exact same
artifacts on top of any compute substrate,
whether it's on-prem, Azure, etcetera.
Bret (2): we-- Are-- When you s-
when you say that, are we talking
about your customers can continue
to use Terraform or Pulumi?
I'm assuming that that's how they're,
they're interacting with you, right?
Like, they're, they're talking
to your API from these particular
management tools, right?
I'm ass- I'm assuming, um,
OpenTofu is s- is supported.
What else, what are the other ways?
'Cause, o- one of the things I've
started to see with agents is if,
if you're a singular cloud, it might
just be better if your, if your
agent is the complete interface to h-
whatever the description language is.
I've seen some examples of people actually
switching away from Terraform back to
the native, cloud formation or whatever
of their cloud, because they look at
it as there's this agent abstraction
between me and the YAML or the JSON.
I don't have to be the expert in every
single line of that anymore, so I
actually care more about, some of the
inherent functionality of a different,
of, of the language tooling itself rather
than, we always looked at Terraform
as maybe a little bit more to, easier
to understand than cloud formation.
A little bit, a little less comprehensive,
a little, little less verbose.
But if you've got an agent in
the way, that matters less.
Are you seeing anything like that?
Are, are you seeing people,
switch, products now that they're
using agents, as their interface?
Doron: Somewhat, yes.
I've seen people that, that used
certain… I don't want to name names
'cause I don't want to dish on any one
platform, but there are many equivalents.
Like when-- whether you use
Crossplane, Pulumi, CloudFormation,
Terraform, and a few others,
they're functionally equivalent.
They're like French, English, Spanish.
You can express the same
ideas in these languages.
They do things in slightly different
manners, like Pulumi is more,
programmatic than, than, declarative,
and Terraform is more declarative.
But at the end of the day, they
express a desired state, and there is a
translation layer that takes the desired
state, like with DAG on, on the case
of, Terraform, and applies in the right
order, calls the APIs that are affecting
the, the actual resources in the cloud.
It's just a translation, right?
So like you said, if I don't
have to write to that language,
why can't I talk in English and
let it make the calls directly?
But here is the thing.
Terraform, as an example, or OpenTofu,
invested heavily in doing the DAG and
doing the validation and doing stuff that
the agent itself will have to reinvent
what they had done to apply things in the
right order and give you the rigor that
they have already baked into the platform.
It is better, like in the Excel example
I've ga-- I've given, to let the
agent leverage a tool like Terraform
than to learn, the underlying, API.
It's, it's possible.
here it's, it's, it's
not an exact science.
Here is subject to, to, judgment.
It can call the, the direct, it
can call the API, it can call
the CLI of the AWS, let's say.
It can call, a CDK, There are
many, again, equivalent, logically
equivalent, options here.
So
Bret (2): So
Doron: our
Bret (2): you, I
Doron: w- w- we, we just give you the,
the one API, and it's your choice.
You tell the AI, " Use the API, use
Terraform, use YAML, use JSON, JSON,
use, CRD." We give the choice to the
customer or the AI, and the AI would
choose the, the least token-consuming
manner that it can operate in
Bret (2): So when someone's migrating
to your platform, if they're using
CloudFormation, d- I'm assuming you
don't support CloudFormation because
you're sitting in front of the AWS.
Like, you're, you're
Doron: Correct.
Bret (2): different
Doron: we, we don't support cloud
formation for control plane.
We have customers that use cloud
formation to create their S3 buckets
and their RDS and their Dynamo,
then, then they tell control plane,
run a workload that connects to
the S3 bucket to RDS to Dynamo.
They're not, in conflict with each other.
They're just not overlapping.
There is no reason for us to introduce
a cloud formation concept 'cause
it's a proprietary, lingo of AWS.
So we are operating at
the cloud agnostic, layer.
We fly above the cloud.
We don't wanna fly in, in that cloud.
We fly above it
Bret (2): Do you see, do you
think that Terraform is still the
primary way your customers are
managing their infrastructure?
Do you see that as, the majority?
Doron: I would call it 60%.
Bret (2): Okay
Doron: Just because of inertia,
Not because it has a, a, a
specific advantage, like I said.
Whether it's Terraform, Pulumi, or
Crossplane, or something else, All they
are, are syntactic sugar on top of the
API with some DAG, that, that decides
what to create first and what to destroy
first, and maybe save the state and so on.
So to me, those are fairly
commoditized, languages.
So for, for the audience to
understand, we don't compete with
Terraform, not even a little bit.
It's like a car doesn't
compete with, a sandwich.
It's two different animals completely.
Bret (2): yeah.
so we talked about customer
base, and, like, the different
size of customers, right?
And it's hard for, any one cloud to
always, a-adopt all customers, right?
We, we all think of, the digital oceans
and, the Vercels of the world, that
they're all like a very niche cloud,
that they've got a very specific purpose,
and then you have the three hyperscalers
that are just everything for everyone,
but it's also impossible for anyone
to get on board really easily, right?
Do you, do you see, are small teams
of, with n-no developers or very few
operators or anything like that, do
they-- Is Control Plane being used by
those kinds of small little companies?
'Cause I, I have a scenario where
I'm thinking, I have, companies
that are, they, th-they might have
one or two IT staff, but, they
don't have internal developers.
So usually when it, it's hard to figure
out, as a consultant, your heart, it's
hard to figure out, what do I do for them?
Because I either have to put them
on a hyperscaler, and then now they
can't do anything without me, right?
I become a bottleneck, which I, I, me as
a consultant, I don't ever wanna do that.
I wanna be instantly
replaceable re-usually.
Or I have to put them on some sort of
niche cloud that, if it's too niche, it
may not be here in five years, or it might
be somehow limited i-in, in what it can
do, and then I'm li- like a Lovable for
AI or whatever, like these, these little
fly-by-night dashboard companies, right?
Do you… W-what's it look like for the
really small teams on, on Control Plane?
Doron: The good news, you will always
have a substrate to run upon 'cause it can
be, like I said, your on-prem, it can be
Azure, Google, Amazon, Oracle, et cetera.
And we have customers that have, non,
traditional developers, certainly no
dev… We have DevOps engineers that
use Control Plane, platform engineers,
but we have people that are just vibe
coding and not know anything about…
They don't know the if
statement, and they still deploy
successfully on Control Plane.
case in point, my younger
son, wanted to build an app.
He never wrote a code, any
piece of code in his life.
He was able to write a full game,
which was pretty impressive, and
run it on Control Plane, and he
didn't even ask me how to do it.
So he deployed the whole game with
a back end, and, I was shocked.
You know, I, I helped develop the
product, and I was shocked at,
at, at what he was able to do, and
he's never written a line of code
despite me wanting him to, to learn.
But he was able to do it.
So we have many people with
no coding experience that are
able to be very successful.
Bret (2): Yeah.
Do you think that's a-- With AI, I mean,
I, I know my answer to this question,
but, it's like a leading question.
Do you think that with these agents
getting better and better and th-
there's the… Now we got Cowork and,
and Claude Code built into people's
Claude and ChatGPT subscriptions for
people that aren't technical, right?
You don't have to use the TUI anymore.
And so I feel like we're, we're heading to
a, pretty quickly to a place where non-IT
staff are getting more and more power
to be able to potentially do things like
vibe code their own app and deploy it on
the internet, and If they don't have the
IT staff to help them manage it,
they can, they can at least get
by with some, some simpler stuff.
do you see that happening
on Control Plane too?
It sounds like it is, since your, since
Doron: 100%.
We are, we are releasing a,
more consumer-oriented…
I'll come out and say it.
We are, the, shipping very soon.
We're in the tail end of,
Vers- not Vercel, but, Lovable
and Replit, Base44 killer.
And why we're able to do what they
do, but they're not able to do
what we do, is the coding agents.
when you look at Replit, most of the
effort has been put into, Guardrails
and skills that are just, wrappers,
assisting agents for, for the LLM.
and, and those are now in the LLM
itself most of the, of the time.
The heavy lifting is allowing you to
run on any cloud, letting you scale
using a hundred different scaling
strategies, letting you fail over
automatically, leveraging hundreds
of diff- the operational stuff.
So we've been hard at work building
this operating system for six and a
half years, and it's not something
you can vibe code, absolutely not.
And so we built this operating system,
and for us to layer the, consumer-facing
app builder is a lot easier than
for an, an app builder to create an
operating system for running, anywhere.
Replit is I, I played
with it a little bit.
It's a, it's a good tool.
I don't know that it will let
you scale to Netflix grade.
I, I think what happens is, and I wrote
an article that I'm publishing, but many
people, when they start scaling or need
security or need compliance, they get
off of that vibe coding platform, where
Control Plane takes you all the way to
Netflix grade cloud native maturity.
You get the compliance, the security, the
scalability, the, unbreakable compute.
Bret (2): I would just assume that
a lot of those platforms are not
like, SOC 2, PCI, you know, HIPAA,
Doron: HIPAA, right
Bret (2): all the things that like a dec-
any decent sized company is gonna care
about, and there's probably someone in
marketing vibe coding something on Lovable
that's completely not up to standards.
For me, my experience so far has been one
of the biggest challenges in like the vibe
codings products out there, is they don't
really answer the data problem, right?
Like, 'cause usually m- everyone that
I've talked to so far, like creating
a dashboard is cute, and these are,
these are important things for teams.
but th- th- there needs to
be data on that dashboard.
There needs to be data in that app, and
it's usually existing cust- company data
locked up somewhere, usually not behind
like a perfectly designed open portal
with a proper API across every surface
with, with automatic, token delivery
for people that request it to ins- Like,
there's just this whole infrastructure
of cloud native that a lot of companies
they haven't matured to yet.
And that's to me, like building these vibe
coding platforms for companies, which I
think, yeah, again, like we could probably
do a whole separate podcast on, but
like that world is inherently necessary
that you have a very modern mature
infrastructure before you can do that.
' Cause a lot of it is about, automation
and security and encryption and, l-
like you said, auditing and compliance.
That's, that's where I live, and that's
where the vibe coded app, while it may
not be stable or highly redundant, it has
to… It, it… Those things are almost
like optional, maybe someday things.
But what's not usually optional
is for this thing to be useful, I
need to access that SQL database,
and how do I get that, right?
How do I ensure that
that data doesn't leak?
How do I make sure that
this is behind the firewall?
Like, there's all those levels
of complexity that I don't see
the Replitz and the Lovables of
the world ever truly tackling.
So I think you're right that this is
probably… These, these solutions
are probably gonna come more from
infrastructure companies like yourself
rather than a, a startup that's focusing
on AI as a, as a sort of, magic button.
So, I'm, I'm interested to get into that.
So I know you brought some demos,
and we could talk about this product
forever, but I, I feel like we've,
we've covered some of the questions
that I wanted to, to know about.
l- l- what are we gonna, what
are we gonna look at today?
Doron: So I want to show you, I, I want
to do a tour around the platform, and
I'll give a sneak peek at some of the
power you get right out of the box, and
traverse the network boundaries, allow
you to run an app anywhere, even on-prem,
that consumes any service of any cloud,
show you the observability, show you
the audit trail, show you the Terraform,
capabilities and, and stuff like that.
So just give you a general tour
so people know what exists.
And, most people don't know that they
have at their fingertips so much power,
and they keep struggling with Amazon.
And, w-where you can get a hundred
x the productivity by leveraging,
a, a platform like Control Plane.
and not only that, save a bundle
because you're not running full EC2
instances, you're running the millicores.
So you can literally run your Bret
app for six-- five and a half cents a
day, a day meaning twenty-four hours,
literally less than six cents a day.
and yet people are spending money
on NAT gateways, load balancers and,
Kubernetes nodes and pay hundreds
of dollars per month when they can
be paying, cents on the dollar.
And that's what I want to show.
Boom questions?
Bret (2): no, this is, this is a lot.
That's, I'm trying to think of my
workflows and, like, how my workflows
for creating infrastructure and managing
infrastructure need to adapt to this
model, 'cause it's, it's flexible enough.
you have click ops, right?
but it seems so easy to hop back and forth
between the click ops, 'cause it feels
like the click ops is backed because you
have that versioning and the audit trail.
you don't, it doesn't, it looks like
you've removed the risk of the, sort of
the rogue click that now is no longer
compatible or, or can- isn't tracked in
a way that you can update your Terraform.
this is the classic problem of, we're
git- we're trying to do GitOps, and
we're putting all of our infrastructure
in, in Git, and we're storing changes
there, and we've maybe got some
automation for Terraform plans and
applies, or we've got, we've got some
stuff going on there, and that's the
only way we're supposed to do it.
And then we get some person that shows
up and in an emergency or because they
didn't know or whatever, they go into
the AWS console and make a change,
and now I'm bifurcated, and I have
no path to success because AWS isn't
gonna really easily export, it's not
gonna to export Terraform for me.
And so I have to figure out what they
changed before, I risk blowing their
stuff away with my future Terraform apply.
And so we, we've always had this
challenge in infrastructure of,
sometimes we do need the click ops.
Sometimes we ne- do need to be able to go
into a GUI really quick, troub- especially
when you're, like, troubleshooting or
just trying to recover from outage.
You don't wanna stare at a bunch
of l- code in TOML forever.
So you're, you're usually in the, in
the dis- in this GUI app trying to
figure things out, but you also know
that y- it's, you can't touch it.
It has to be read-only because you
need to make your changes somewhere
else, and you're so nervous.
So it feels like you've kinda
thought about that a little bit.
Doron: Yeah, and everything,
like I said, everything you
can get as, YAML or, or JSON.
But here is our app running, and
so we give you a more consumer-y
interface to this thing.
but the bottom line, it's really backed
by the control plane API, and the control
plane API lets you run anywhere, and with,
with determinism, and, and it's the same.
You c-- Again, you can run it on
your Raspberry Pi or Dell machine.
And the cloud wormhole, which I
haven't demonstrated, allows you to
very, very easily connect to an RDS
instance in a VPC or connect from
a, the seven different locations
here to my own Redis on my machine.
And we have a service catalog
where you can run above the cloud.
If you want to run CockroachDB or
Cassandra or really any open source
project, we certify these s-services.
Like let's say I want to run Hermes
Agent or Langfuse or Keycloak or, you
name it, Postgres, Mongo You can run
them at the cost of the infrastructure
instead of paying a premium to RDS.
You pay double what the compute
is, but Control Plane lets you
do backups, lets you do leaders
election, lets you do multi-master
replication with different add-ons.
You can run Ollama, you can
run whatever you want to run.
and you can conversationally say, "Hey,
get me an N8n, run me a Hermes agent,
run me, know, OpenBaO or run me whatever,
Postgres very, very easily." you,
you can do all of, all of that stuff.
And again, you can run anywhere.
Bret (2): Yeah
Doron: w-we're not going to do
an exhaustive demonstration.
one of the things that, that people
care about is security, and you
can set very granular policies of
who is allowed to do exactly what.
You can say, this agent is allowed only
to push image but not delete an image.
This Lisa can only, read a
certain value but not write.
Secrets are only available to X and Y.
So everything is very, very granular.
and th-there is a lot, a lot more.
You can set custom domains.
we have customers with twenty
thousand different domains, and
they run perfectly on Control Plane.
It gives you the confidence to operate
above the clouds without being bogged down
by the complexity of any particular cloud.
And the thing I wanted to show,
because we have this thing called
Capacity AI That is by default on.
If you look at the spend, you're spending
twenty-five millicores 'cause the system
learned over time that Bret video game
only needs twenty-five one-thousandth
of a CPU and thirty-two megs of RAM.
If you go to the control plane pricing
and plug in-- And you can bring your
own compute, or you can use control
plane compute, or you can do both.
So twenty-five millicores and
thirty-two megs of RAM cost you a
dollar seventy-eight per month, period.
You don't pay for load balancers,
you don't pay for nodes,
you don't pay for anything.
That's all you pay.
We charge you by the second.
let's say a full hour would cost
you, No, sorry, a full day would
cost you less than six cents.
So if you ran the Bret app for a
full twenty-four hours in a location,
it would cost you six cents.
That's why I'm saying sometimes running
it in more locations is even cheaper
than running it in a single location,
'cause if you were to stand up a EKS
cluster, you would pay hundreds of
dollars in a month to heat up the planet
Earth or to make Jeff Bezos richer.
We let you pay for what you eat,
not for heating up the planet Earth.
So extremely cost-effective
Bret (2): In that, in the,
the workflows you were showing
as you would, as you were doing this
stuff, I w- guess one of my questions is
Deployment configurations and design can
often be, hard for teams, especially when
they start to adopt Kubernetes, right?
Because then they have to pick Flux
or Argo, and they have to decide on a
particular way to deploy that, and then
they have to configure it all correctly,
and then when they have b- a bunch of
different apps, yeah, so my premise was,
like one of the, one of the challenges
that I, I train people on and is a lar-
a d- decent amount of my consulting
over the last six years has been once
teams adopt Kubernetes, there becomes
this deployment complexity because it's
not enough to just have Kubernetes.
Then, then you need, your code's stored
in a place, GitHub, GitLab, whatever, and
then you gotta connect all that together.
And, in the old days before containers,
a- and even when we first, first
started using containers, it was very
much "I'm gonna write a CI job that
runs kubectl apply," or, "I'm gonna
run a Docker run, and, and it's gonna
connect to the server from my CI."
And then we grew up, and we
realized we maybe need a more
deterministic methodology, and then
we started adopting Argo and Flux.
And, and so for the longest time,
I've been f- I've been advocating
and teaching those technologies.
We call it GitOps, but it doesn't
necessarily have to be labeled that.
and I'm curious how you, how
your platform works with that.
Does that m- It, it… You've got a
lot of, glue there that feels like
it makes a lot of these rough edges
streamlined and it's almost like you're
applying opinionated defaults, which I
love because I'm a, I'm a very much a,
an opinionated defaults kind of guy.
when it comes to like the code in
the repos, and is it as easy as
someone on your platform pointing
to repos, and then it figures out
how to get it into Kubernetes?
do they need to even worry
about Argo at this point?
'Cause you've been saying things like
deploy this app, and it's doing it.
I don't know how it's doing it.
I know it's, I know it's
running on Kubernetes.
But what's that, that deployment
look like for Control Plane?
Is it automating it?
Is it, is it doing Argo for you?
Doron: So it c-- you can use Argo.
So we have, a CRD, a control plane
CRD, so you can have a cluster and,
use Argo or Flux very naturally.
the way it works, so you said, "I'm not
sure how it works," so let me explain.
you get the YAML.
Let me share real quick.
and again, YAML is just one of many.
So if… let's take this
guy for-- as an example.
I can export, this YAML.
So you can see the kind is workload.
It's a new kind that doesn't exist on
Kubernetes, and it has the different,
like what's the memory, what's the
scaling strategy, what GVC does it go on?
And you j-just say CPLN apply
and give it, minus F and give
it the YAML, and it deploys it.
Like I said, we have other ways
to deploy, but at the end of
the day, we have a data service.
We have an-- we have the control
plane API, and you make a call to
the plane itself is, is running
on Amazon, Google, and Azure, and
the-- our data is distributed.
It calls a component we call the which
is a control plane, Go-based application.
It runs on the edge, we
call them edge clusters.
So you can have one cluster, or in
our case, we have one, two, three,
four, five, six, seven clusters.
These are different clusters.
They can have hundreds of nodes.
we provide clusters that are, cloudless,
meaning we provide clusters, or you can
bring your own, you can bring your own
cluster like I did in the Ron office.
I created the Kubernetes brain in the
cloud, but I could have run OpenShift or
EKS or whatever, in the local environment
The-- what you need is a Kubernetes
cluster with the actuator and a few other
components like the, the log, collector,
the metrics collector, and so on.
But we control planify a cluster,
and then it becomes part of
that global virtual cloud.
We use NATs under the covers to have
our, control plane, if you will,
communicate the desired state to all the
clusters, and they all take the desired
state and actuate it in the cluster.
So under the cover, you have, stateful
sets or, deployments or, pods and
all the Kubernetes goodness that is
happening, but it has been abstracted.
And if you want to see the Kubernetes
resources and, and it's a bring your
own Kubernetes like I have here, you
can get the kubeconfig and go edit
or use the dashboard and go edit.
But we… You noticed we didn't
have to issue kubectl apply commands
and all that because there is an
actuator component in this cluster
that went and did the actuation
of the desired state Makes sense.
And also, if we are down, the, the cluster
operates autonomously and serves traffic.
Maybe you can't upgrade the version
of the workload, but A, we're very
highly, redundant and highly available.
so we're very, very unlikely to go down.
But if we were to go down, we are the
control plane, not the data plane.
The data plane is where the data,
flows, and you mentioned that earlier.
so hopefully that gives you kind
Bret (2): the goal, right?
Is like the control plane never,
never takes down the data plane
when it's, when it's unavailable.
Yeah.
Doron: Exactly.
A, we're extremely… Yeah,
and we test everything, like,
like I can't even tell you.
From day one, we created what we call
the Observer Project, and it does
twenty-four seven millions of tests
simulating node failure, multi-node
failure, cluster failure, AZ failure,
region failure, whole cloud failure.
And we do, fuzzing.
We do random failure, introduction of
failure modes with a core objective
of making sure you never go down.
So one of the things you get with
Control Plane is mainframe-grade
availability over commodity infrastructure
Bret (2): All right Yeah, the
fractional CPU, stuff is, is
pretty flexible and pretty awesome.
When you're running small stuff and
you're a small company and every single
workload you add has, this minimum
cost to it, and Even when you try to
run, small instances in an EC2 cluster,
you're limited on how small you can go,
and then you're inherently bottlenecked
there if you ever get any decent traffic
because it, it doesn't know how to…
You, you have to build a lot of
intelligence in in order for it to
auto-scale up and correctly change
the node size, if you need more memory
because, a classic example is, a legacy
app with a PDF export and someone
decides to PDF export a report that isn't
batched properly, so then it consumes
all the memory on the server for one
report, and then the, and then your tiny
little app crashes the whole thing all
because you wanted to print a report.
So there's always, there's always, sizing
challenges because you just want things,
especially when, when it's, a small
business kind of situation where, they,
you tell them, $500 a month for something
that they consider not worth all that is a
hard sell when you're like, "Well, that's
what it takes to be minimum redundant
across regions in this particular cloud."
And the idea that I can say, "Well,
you're, you're only using this
app internally, so we don't even
need a single CPU. We need a half
of one. We need a third of one,"
Doron: Yeah, we need a fif-fiftieth
of one or, one, one-twentieth of one.
Yeah, and that's… And you can now
give people redundant availability for
three dollars, five dollars a month.
you can run an app for five
dollars a month that is-- has the
availability of a real enterprise.
Bret (2): how do people get started?
They go to Control Plane.com
and sign up for an account?
Doron: Yeah.
Yeah, it's very easy.
so they go to Control Plane, they
click sign up, they follow the prompts.
we ask for a credit card, and I
find some people get intimidated.
we're happy to give you,
especially to your listeners,
shoot me an email directly, Doron,
D-O-R-O-N, @ Control Plane.com.
I'll give you, basically a, a
free month to experiment with.
Of course, don't do crypto mining and
don't do crazy stuff, but happy to
let you experiment on the platform.
Even if we were to charge you, you can
run so cost effectively that unless you
reach five dollars in spend, which is a
lot on Control Plane, we don't charge you.
So if you're under five dollars a
month, we don't even charge you 'cause
it's not worth it to send to Stripe.
So many people can run real projects on
Control Plane for less than five bucks.
There is no platform fee, there's no
per seat fee, there's just usage fee,
and it's very, very cost effective.
Bret (2): That's what I used
to use Heroku for, so now m-
now maybe you're my new Heroku
Doron: Think of us as a non-toy Heroku.
Bret (2): Yeah
Doron: the non-toy, replace your, Heroku
with, the, the, the cloud du jour.
But, we give you all the power
of all the clouds, but, with the
ease of use of Heroku or better,
Bret (2): thank you so
much for being here, Doron.
Doron: thank you.
Really enjoyed, the conversation.
You asked great questions.
super happy we connected
Bret (2): And we'll
see you guys next time.
Ciao.
