Hi everyone. My name is Patrick Acu and this
episode is all about Kubernetes, internal developer platforms and
platform engineering. Joining me today is Mushtaba
Imani, Cloud Kubernetes and Platform Architect, as well as
the founder of Cube Rise, an open source and free internal
developer platform to streamline Kubernetes deployments.
We talk about Kubernetes versus serverless, when to actually
move to Kubernetes, when it makes sense, what internal
developer platforms are in the 1st place, and effective
platform engineering. So enjoy.
One of the biggest advantages of using Kubernetes is the avoiding
vendor lucky because you know there is two ways of creating
internal developer platform. One way is using the cloud
specific services and tools and one way is create your internal
developer platform inside the Kubernetes.
And the benefit of the second one is that then it doesn't
matter much that who provides that Kubernetes to you.
Your architecture and your platform would be almost the
same. Because it's in Kubernetes.
Because it is in the Kubernetes. Kubernetes is unified between
the different cloud providers and your on premise Kubernetes.
And it's almost because there are also some integration points
between the Kubernetes and the cloud as well.
For example, the the entry point of your Kubernetes.
It depends on the mechanism of the load balancer that the cloud
provider provide for you. Yeah, makes sense.
Or some people prefer to have their database managed by the
cloud, not themselves deploy the database inside the Kubernetes
themselves. Yeah.
Those are the integration point that depends on the cloud that
you are using. But other than that, there are
many other things that you just deploy and manage yourself in
your Kubernetes cluster which is independent from the cloud and
provider. Yeah, makes sense.
I mean, almost all experience that I've had building a product
from scratch from zero to one has been using serverless
technologies and leveraging whatever cloud functionality is
there, right? Not necessarily thinking about
vendor locking, but really going as fast as possible using as
much out-of-the-box as possible, a real low cost of ownership
from a team perspective and then going live with that product
specifically. So I'm always wondering when it
looks when I look at serverless and like cloud technology.
Specifically, when would I use Kubernetes and manage that
myself versus using whatever the cloud offers?
It's good way to start quickly, but there are also some cost to
that easy way of doing stuff. Yeah.
So it made everything easy for you, but it has cost.
So it means that for example, for one of the clients who are
deploying services in Fargate in AWS, which is like serverless
deployment of the container in, in AWS very easy.
You just need to take care of your container.
Then you give the address of the container to the cloud formation
and you deploy for you. It will scale it for you.
Everything is taken care of, but the cost is that it's expensive.
And they say that if you want to deploy a service that is up and
is working for like periodically, periodically and
then like a period of time or is temporarily for the like peak
time is good. But if you have a service that
is going to be up 24/7 all the time, it's too expensive.
It's better to use the other models that have like a virtual
machine and deployed to the machine instead of fully
serverless. Interesting.
Yeah. And if you are a big company
that have a lot of micro services, use fully serverless
for everything. Is it too much?
Is it too expensive? Too expensive?
If you are want if you want to optimize the the cost and also
scalability is better to go to Kubernetes.
Interesting. Yeah, but like cost isn't
serverless. Usually the kind of main benefit
is also paper use, right? It scales back to 0 if you don't
use it. Indeed, it's not there
specifically. So I get that if you have a
longer running application that needs to be up 24/7, then it
doesn't make sense, right, Because it will scale down to 0
if there's no traffic or you need to finale your way into
keeping kind of the up time. But still, it might just be
killed off specifically because that's not why you would use
serverless. But then for everything related
to web traffic and like peak traffic when it comes to
seasonality, which is at Christmas for example and the
festivities usually that's a big purchasing time for anything web
traffic related or ecom, then I would say serverless is is
better even at scale, isn't it? Yeah, yeah.
In Kubernetes also if you configure it properly for
scalability is, is very good, even sometimes better and faster
base come in compared to the the cloud serverless services.
But for the cost, definitely. And because for if a small
company few micro services, Kubernetes isn't that easy.
It's complex, it's expensive, it needs skills, it needs, it needs
tools. So some companies try to make it
easier for the for for adoption, of course, like cube rice that
they owe. So it makes sense to go to
Kubernetes if you're like have some good amount of micro
services or if you are very small startup just starting to
deploy few services to see what happens.
Is not advice to go to Kubernetes at the beginning?
Yeah, makes sense. Like I've, I've used Kubernetes
when it was already set up, let's say, and I came in, I need
to develop something or work within an existing team that was
already running on Kubernetes infrastructure.
And then I've, I've dabbled a little bit with it, but I've
never set it up from scratch specifically.
I everything that I know kind of knowledge wise from setting it
up. Maybe I should try it once, But
I hear that you need a lot of knowledge to get in, get started
basically. And especially in a small team
when you don't have the capacity for that cost of ownership, then
I agree with you might not be the best choice.
But when you reach a point of scale where you're looking at
the cost and you make this kind of cost benefit analysis and you
want to move, let's say you have that serverless set up from the
start, you're now moving to either manage Kubernetes or
you're going to do it yourself in the first place.
How would you transition and what kind of knowledge do you
need to get started in the first place?
So imagine that inside the Kubernetes is full feature of
the cloud that you need to learn for networking, for security,
for load balancing, for monitoring, for logs, for
alerting, for everything. So before Kubernetes, the cloud
provider was providing everything for you, all of these
services and you just, you were just using it.
But when you in terms of the Kubernetes, it gives you an
empty space that you have to think about all of those tools
and features yourself. That's why it is complex.
You need to know networking security.
You need to know about the how to make sure that the the load
is balanced and scaled properly. If a company can use cloud
because not all companies are are are possible to to go to the
cloud. One of my client was financial
and they were not allowed to go to the cloud so they had to
manage their Kubernetes cluster on premises.
Yeah, if it is possible to use the the cloud providers,
definitely it's better to use managed Kubernetes.
Because a lot of things are already handled by them.
Yeah, especially the Kubernetes itself.
There are some. So to use Kubernetes, there are
different distributions. OK.
One of them the the basic one is called vanilla Kubernetes, which
is the main open source Kubernetes project.
And there are different distributions that some
companies or people just modified a little bit that
project for different purposes. For example, some distributions
are just for creating a small light Kubernetes cluster in
local computer, in laptop, for for learning, for experimenting,
for development. And some, there are some other
distributions that are good for a production Kubernetes
environment on premises in your data centre.
Yeah. So I would say the first step is
to 1st decide to use manage Kubernetes from cloud providers
or on premises Kubernetes and then decide about the
distribution that you want to use.
OK. Then the most important thing is
making everything automatic and as code.
So infrastructure as code and Githubs.
These are two main principles. Because we see a lot of
companies at the beginning they say, OK, thinking about
automation, we don't know how to do it, it's too soon, we put it
later, but and then make a big technical debt for the future.
They start using dashboards, they do kilicops, they run
commands manually and then later nobody knows what happened and
how to manage and how, what was the configuration and who did
the configuration. Yeah.
One of the clients that they they told us that there were a
developer before that installed the Kubernetes.
In dashboard manually and he's not in the company anymore and
we don't know how to manage this or how to upgrade it.
So it's very important to start with automation and start with
everything as code principle. And then it is 2 part
installation of the Kubernetes itself, which usually we do it
by infrastructure as code languages like Terraform.
And then after you install the Kubernetes itself, now you need
to deploy platform tools and your applications and micro
services. And for this part we use Git OPS
principle. Git OPS means it's different
with GitHub. Git OPS means that you need to
have a git repository which is single source of truth and
whatever is happening inside your Kubernetes cluster is
written in code in this repository.
Gotcha. And there are some tools that
make sure that they are synced together.
And whatever you want to do for the for your Kubernetes cluster,
you deploy anything, you change the configuration, you just need
to change the code, create a pull request, then your team
will review it and you will merge with the main branch.
And then these git OPS tools like Argos, CD or Flux will sync
the code with the Kubernetes cluster.
I can imagine that. I mean, since it's very
configuration heavy indeed, that code is going to help, right?
Yeah, First of all, with kind of an audit trail of what happened
in the 1st place and who did what.
But also eventually when you have something up and running to
review and be like, OK, is this still the right way or what do
we need to tweak or what is the truth in the first place?
Actually, it is so important that nobody has in real
scenarios. I saw several companies that
even nobody or almost nobody has access to the cloud.
So you cannot go to to log into your cloud account or use QCTL
in your Kubernetes cluster to do anything manually, OK?
The only way that you can change anything is to change the code,
OK? And it's very important because
if you do it in a proper way, in a Github's way, then you have
the history of changes of your cloud.
It is clear who did the change and why he did the change and
who approved that. And because all the previous
versions of the code is there in the repository.
Whenever anything happens in a disaster time, you can always
revert back to a previous version that was working fine.
Yeah, so these are the benefits of the Githubs.
Makes sense. Is that best practice than that
people? Indeed, when you go to a cloud
environment, you can't actually click anything together or make
those configuration changes without actually.
Yes, code deployment, yeah, especially, especially for
production environments. Maybe in development environment
they will keep it is also so you know, there are usually
different environments that replicates each other.
Dev test acceptance, production, yeah, some companies they say
OK, dev is like for experimenting, for learning
anything open. But the rest of the three should
be exactly the same. So because if there is a small,
even small change in each of these environments, then when
your application is running in one of them, you don't know if
it would run in the other environment as well.
Yeah, it's not replicable. So the best practice in that in
test acceptance and production, nobody has access, nobody can
log in and change anything manually, everything should be
in the court. Interesting.
When it, when I look at then let's say this knowledge curve,
because we said, OK, Kubernetes, I mean it has from what I've
heard a lot of configuration you can do a lot with regards to
kind of the ownership that you have.
You mentioned networking security.
Those are not to be taken lightly, especially nowadays.
And if those are, then let's say your responsibility or the team
responsibility. Plus you want to do everything,
infrastructure as code. It's like a big hump to get
something up and running minimally and then also
distribute it over, let's say, your environments.
I think that might be what's holding people back kind of this
dragon of starting, because once everything is started and it's
already smooth operation, then probably building on top of
things. You don't have to change many
things, right? Maybe you tweak things based on
efficiencies or based on kind of your observables that you've
seen. But once everything is there,
it's smooth riding and you can focus on product development.
For me, it's kind of this path to get there that's most
challenging at this. From a actually the the old good
days developers just they need to SSH to a remote server and
run their application and it was fine.
That's it. And then it became so complex,
so many different club powers with different way of working on
APIs than the Kubernetes environments.
That's not possible for developers to up to date and
learn everything. Yeah.
And even the the development, the programming languages, the
technologies that they use also growing a lot.
And if they can up to date in those areas themselves, they
actually doing a great job. So that's why the the platform
engineering concept arrived and a report that was released by
Gartner in 2023 was introducing top 10 strategic technologies of
2024 and technology #4 was platform engineering.
And actually platform engineering is the way that you
make those complexities hidden to developers to make an
abstraction. We call it Intel Internal
Developer Platform. You provide a self-service set
of tools. And templates and defaults and
standards and unified way of working to developers and then
developer can focus on the development it increase their
productivity. And by using those self-service
tools, they will deploy their services to the cloud or
Kubernetes. They will use all those services
that you already embedded in your platform.
We don't need the deep knowledge and how to configure it.
So there are many benefits of that way of working.
For example, one of the challenge that we see in the
companies, there are several different development teams.
Each of them they use different way of working, different tools,
different technologies. From a technology.
Perspective, yeah. And then first it is not
possible that those teams help each other and also it is not
possible for the central IT or platform team to support them.
But by creating the platform you define a unified way of working
and take a set of technologies. And also one of the things that
developer waste their time is by installation of those platform
tools like database or authentication, authorization or
lock mechanism. But these are inside the
included in the internal developer platform.
Are they just using that? But still the developers are
still DevOps because when they use these tools and deploy their
services to the cloud or Kubernetes, still they need to
take care of those services themselves.
So they will monitor it, they will see if they are working.
If they fail, they need to recover it or or debug it
themselves, but it's much easier than before because all the
tools and services that they need are already provided in the
platform. Interesting, but this.
Platform knowledge, would that then be within that platform
engineering team, the team that's responsible for, let's
say crafting the platform, upholding it with regards to
maintenance and improving it with regards to new
technologies? Yeah, because then the like I
understand that the complexity is there like with our
environments, cloud environments or not or how we want to scale
when it comes to globally or multi regionality and even the
team landscape that we have or the micro services that we
create, there will be complexity.
And I understand that abstracting that complexity away
allows product teams to actually focus on product development.
But when it comes to dev OPS and them still being responsible, do
you think that lack of knowledge or that kind of abstraction of
the complexity can hinder them when it comes to the operational
part of things? Because I, I understand that it
can help with development, probably speed, right?
Because they don't have to install anything.
Everything is out-of-the-box unless they want to use
something new, then probably that's a bit more challenging.
But when it comes to things being operational, would they
need that platform knowledge then as well?
They need to just use the platform, not installation and
configuration of it. Got you.
So they need to know how to use for example for dashboard we
usually use Grafana. They need to know how to create
a dashboard in Grafana for example to monitor the
consumptions of their services in terms of CPU, memory or
traffic. But this is much more easier and
more basic than. How to install it?
Install the Graphana itself? Got you.
How to configure it? How to make single sign on in
Graphana with kick lock for authentication authorization?
These are the complexities that only exist inside the platform
team. Yeah, is there usually because
if I look at an internal development platform, then
indeed you get tools out-of-the-box already installed
for you. But that also reduces some of
the autonomy of a team, right? I think you gave the example of
multiple teams with different kind of technology flavours and
that's probably because they are autonomous as a team, also
isolated. And then you take that autonomy
away and you give them one platform.
It's like this is the standard that can be challenging.
With regards to autonomy then I would assume very good.
Point yeah. So in platform engineering, we
have a concept which is called golden path.
Golden Path means that the platform team provide the best
efficient way from code to production, which will cover
almost the most of the requirements of the micro
services and applications and development teams, but it is the
most of them. It means that it is possible
that one team has a specific requirement that's not
integrating the platform team and that development team.
They already have that skills and and knowledge to do that
themselves. Still they are free to do that.
Gotcha. For example, assume that there
is a specific team that are doing a computation that needed
GPU. It's very small in the company.
The platform team will not provide it, will not support it.
Even they don't know how to do it, but they that team know how
to do it. So they can't do it themselves.
So the platform team, of course, it depends on the policy of the
the company, but we say platform team and internal developer
platform usually provide the golden path.
It means that if there is a specific team that has a
specific requirement and they have the knowledge of the how to
do it, they will do it themselves.
Yeah, but then they will not have the support of the platform
team. Absolutely.
They are responsible themselves. Yeah, that makes sense.
I like that a lot because especially for looking at, I
mean, the GPU examples prime for let's say AI computing
specifically, you wouldn't need that everywhere in your
organization. So it might not be in your
internal development platform, but if you have a team that's
experimenting with it like they are dependent on it.
So they need that specifically. Without that, it's a, it's a
failure for the project most likely.
So then you need that autonomy to be able to actually get that
up and running. Very interesting when I think of
this internal development platform and kind of success
measurements, I, I wonder how you would measure success.
And I, I can give you an example of I'm now at an organization
and they have let's say this back end framework where every
service, every new service that you have is supposed to be, if
you're using that specific language you use supposed to use
this framework and it fixes logging it makes you faster.
At least that's the dream and it solves a lot of problems for
you. And then we tried that it's,
it's hard to get up and running. There's like specific knowledge
needed from that framework specifically, it's internally
developed. So there's also internal
knowledge. There's not necessarily the best
documentation like those are the challenges of this internal
framework. And with an internal development
platform, although you have a team responsible, they also
become the bottleneck for requests.
And it's hard. Or at least I wonder how you
would measure the success of a platform, right?
Because you need to iterate, you need to improve.
And I think you should do that based on a few success metrics.
Also another thing that we say in in the platform, in platform
engineering, we say platform is a product.
So it is not just infrastructure team or support team like a
traditional way that people come to the team and say, hey, I need
this, I need that. Yeah, platform team create a
product. Internal developer platform is a
product and who is the customer? The customer of this product are
the actually developers of the company.
Yeah. And the platform team treat this
product as a real customer facing product.
It means that it they need to maintain it, they need to get
feedback from the developers, they need to upgrade it to make
sure that the IT will fulfill of the requirements of their
customers. And this question that how to
measure the success of this internal developer platform.
I would say the answer is that how you measure the success of
any other product. So you need to have in contact
with your developers constantly and get feedback from them to
see what are the requirements, what are the problem, if they
need support and help to adapt this platform or not.
Yeah. So we say it is socio technical
product. It means that it's not only a
technical product that platform team just produce and put it
there. It needs to have constant
communication with their customers to make it successful.
Yeah. To help them to on board to this
platform etcetera. Interesting.
I mean, the, if I were to have, let's say a platform and I
distribute that out to the public, I don't have the
complexities of an organization and organizational policies,
right? If we have a platform and all of
a sudden management decides, OK, this new functionality needs to
be developed by the internal development platform, otherwise
you can't use it. So all the teams that do it
themselves, you can't actually do that.
Then you're kind of an item on a backlog.
And if your road map depends on it, then you have a big funnel
when it comes to requirements of this platform team and internal
platform development. Basically, I think it's going to
be challenging then managing the different stakeholder landscapes
or different priorities of product Rd. maps because you're
the backbone, right? As a platform, you're the
backbone for people to build on top of and excel with regards to
their products. And if that becomes a backbone
or if, if it is a backbone, which I think it is, it can also
become a bottleneck when it comes to progressing the
individual product Rd. maps. How?
How do you manage that? Or how would one manage that?
So also once feature of the internal develop a good internal
developer platform should have is to be self-service.
A common challenge that we see to a lot, a lot of in a lot of
companies is that the infrastructure team or IT team
are overwhelmed with too many requests from developers.
Yeah, constantly developer for anything need to send a request
to the to the IT team that I need this machine, I need that
much memory, I need that access, etcetera.
And everybody need today. Yeah, yeah.
And it's, it's not possible, especially when they scale, they
will face a real problem. And we say if you create a good
internal developer platform, everything is self-service means
that most of the need of developers, they can do it
themselves. If they want a new repository,
if they want a new capacity, if you want they want to create the
new, a new micro service. They don't need to talk to
someone or ask someone. It is there, they can go there
and then everything is self-service.
They can decide how much capacity they want, which
database they want to create or connect and they can deploy
themselves. This is one thing that I would
say it is opposite. So instead of without having
internal developer platform, it would be more blocking for them
to send all the requests to the central IT team.
But with this platform they will do most of the requirements in a
self-service way themselves. They don't need to even send a
request to any other team. And yes of course for some of
the basics it's needed before any other micro services go to
to the environment. The production environment for
example with CICD for security scanning, everything is needed
to be there before they can deploy anything.
So then you would say what would be the the time that they need
to create such a platform? And there are two approach.
They hire different engineers, create a platform team and then
make everything from scratch themselves.
It would of course take time and then every other teams or
developers will be blocked or there are actually internal
developer platform tools or projects that are ready, they
can use that. Most of these requirements are
already there. Yeah, these projects with just
few days or even few hours of configuration installation with
one package, you will have your monitoring, your authentication
authorization, your alerting. Your networking, load balancer,
internal external traffic etcetera with full automation,
yeah, then the only remaining thing is that adding a specific
tools for a specific companies or specific requirements and
customize it to have. Better alignment with your
goals. Got you.
Yeah. And these tools you're talking
about, they're not managed right.
You would still have the responsibility of it.
It's just automated in a way that it sets it up.
Yes, but still there are two ways.
Some companies they install the tool for you.
Yeah, which is internal, your internal developer platform,
they manage it for you or there are some open source projects
that you can deploy them yourself and continue
maintaining and managing yourself.
So if you. Have the capacity to create a
platform team in your company instead of starting creating
everything from scratch. You you can use some of these
projects or you can buy it, or you can use open source one.
And this platform team would be responsible to continue the
maintenance of that internal developer platform and
customization. Interest.
Adding more tools or changing the configuration then it will
be much faster than they build it from a scratch.
Yeah, or you don't have the capacity to create a platform
team for any reason you don't want to do it.
You can ask a partner or consultancy or other companies
that have such services to build the platform for you and manage
it. Interesting.
So chronologically, I think if I were to start a project that
would still go serverless, right?
Get up and running because it's small, it's low cost of
ownership, and at some point if I do a cost benefit analysis, it
might make sense to adopt Kubernetes with the
infrastructure and technology. Would that also then be a point?
I think it depends on people and scale and distribution of teams,
right When you actually start using or creating an internal
development product. There is platform.
We have also a client. Here is a a company that has a
small IT team. They decided that we don't want
to create a platform team. OK.
And they ask consultants to to build that platform for them and
to manage and update for them. And if it's a good product or
good way of creating internal development platform, they just
need to be installed once and maybe be updated regularly each
month. There is no a lot of things
because if it is there, it would work.
And then by providing those self-service tools, the
developers can easily use it and and deploy their services.
And if you use in a standard way and use popular open source
projects, then there would be a huge community how to use it,
how to maintain it, how to upgrade it.
For example, if you use for monitoring and dashboard if you
use Grafana for example, which is the most popular and common?
What even you don't need to create dashboard for each of
your services yourself. There are already dashboard that
you can download for free and you can monitor all the tools
and services you have. Yeah, if you're going this
route, because I've seen this conversation online a lot of
times actually where people are challenging cloud and
specifically the cost there, right.
Running things on the cloud doesn't mean it's going to be
cheaper. And people that migrate existing
infrastructure that is on premise one-on-one to the cloud
will actually realise that if you don't change anything, if
you don't go cloud native with the rest of your technology and
software and leverage cloud. Your costs are going to increase
substantially, right? And you can decrease them with
regards to changing whatever software you have.
But then you do have kind of that downside of potentially
vendor lock in. And I think vendor lock in, it's
a different topic. If that's actually I think a
good argument because I haven't seen many times where companies
are on such a full blown scale in the cloud and decide to fully
migrate to another cloud. I don't know if that will ever
happen, but it's still a downside nonetheless.
And then you have this camp now that says that the cloud
actually brings too many abstraction layers.
It's time to go back to bare metal.
Because cost efficiency wise, if you can have that cost of
ownership within your team and you can have that knowledge,
then that might be the best way to reduce your costs.
But then it's like a full circle, right?
We go back to the cloud and then at some point we end up on
premise again. I feel like with internal
development tools you have the flexibility to run on premise
and on cloud, but I'm not sure what you think would be best
then. If I go internal development
platform, does it make sense to have that hosted on the cloud or
should I do that on Prem or what are the dependencies there?
It depends. It depends on the requirement
that you have and it can be both.
Even some solutions are hybrid solutions.
So it's a combination of the on premises and the cloud.
For example, some architectures they suggest that you, so they
say if your workload is divided to predictable and
unpredictable, it's good to have your predictable workload in
your on premises and an unpredictable one in the cloud.
There's one architecture and also for the cost that you said
I also reading a report that most of the companies that
decide to go back from the cloud to on premises have it.
It is because tourism cost and security and at the beginning
some some people think that if they go to the cloud, they will
pay as go and everything is is fine.
Then they say no, it's not it's not the same.
For example, there is a huge discussion about how to manage
the cost and it's very important you should you should not ignore
it. Yeah, yeah.
As a deciding point that so you did a huge migration to the
cloud and you want to go back to to on premises because of the
cost maybe you did not manage the cost properly.
And if you fix that, you don't need to manage migrate back to
on premises. For example, one of the huge
factor in the cost is non production environment in off
hours, OK. And there are a lot of like.
Studies, reports, conferences, I saw that you're probably most of
the time only production environment need to be 24/7 up
and running. But your dev test acceptance or
any other non production environment, you can turn them
off during off hours. Yeah.
And it's also to achieve that it's good to have good internal
developer platform and have infrastructure as code and
Github's principle. Otherwise you would not do, you
would not be able to do that. So and also Kubernetes is a good
way. It helps a lot for for example,
for this cube wise project that they have with just one command,
I can deploy all the platform tool to the Kubernetes cluster
and with full configuration And with the terraform that I create
the Kubernetes itself, I can make an automation that every
day all the non production environments, every day at 6:00
AM create the Kubernetes cluster, deploy all the tools
and that do all the configuration and in 6:00 PM
destroy everything. Yeah.
Then also in the the weekend they will not be created.
And the studies shows that it will cost around 70% of your
cloud. Costs.
That's incredible. That's actually very decision
making things that you can have and you can decide if go to the
cloud or go back to the on premises.
Interesting. I mean then it's, it's not a
matter of traffic, right? Because production is always
going to have the most traffic compared to your non production
environments. Even if you do smoke tests or
specifically scalability tests, your production should always
have the highest traffic. Otherwise what's what's the
point of having production in the 1st place.
And it's strange to me that then the infrastructure that you have
up and running without any traffic, if you destroy that,
that it already reduces the cost amount by that much.
That is incredible. Yeah.
And automation, I fully understand that automation can
help with that. And now I also understand that
better that if you don't have automation and you start having
kind of this difference in configuration of your test
environment, your dev environment and your production
environments, that it's very hard to destroy everything and
to put them, make them be up and running again in a an easy
manner, let's say. Yeah, man, I also like that you
highlighted that kind of spiky traffic.
That's what the cloud is good for, right?
Yes, specifically seasonality. And I think the biggest example
I always think of is E com when it comes to Christmas.
People purchase things because it's gift season.
You buy all the gifts that you have to distribute to all your
friends and family specifically. So people see huge spikes in
traffic. Black Friday is another one.
People prepared the whole year for Black Friday traffic,
basically. And if you have that on premise,
then you need to have all your infrastructure, bare metal
specifically, ready for that scale.
And that's going to be a peak that you don't see any other
time of the year. That's what the cloud is good
at. But I'm wondering then,
actually, no, I think micro services have solved that
because you isolate the spiky part of your software, that's
where you then run in the crowd cloud and then everything that's
more stable, you would run on premise.
I think that's the biggest way to reduce your costs then.
Yeah, Kind of this black and white approach that people have
in looking at the cloud or looking at on premise.
I think that might be faulty then, because there are just
different parts of your software that operate differently, which
means that leverage what the cloud is good for and leverage
what on premise is good for and do it that way.
And also one of the things that they hear from developers, they
say that we work on our development locally in our
laptop and it works, but we don't know if it work in a real
Kubernetes cluster with all the other services that these micro
services interact with or not. And with a proper internal
developer platform in a Github's way, you can deploy all that
platform in a light Kubernetes cluster in your laptop as well.
Exactly. So there are some light
Kubernetes cluster for local laptop like mini cube or kind or
K or KTDS that you can replicate the whole environment with the
full automation and services that are in the real Kubernetes
cluster in your laptop. This would be much easier and
comfortable for for developers to deploy locally and see if the
application works in a real environment or not.
Yeah. If for me, the the biggest part
of what makes me productive is like comfort in the tool set
that I have, right. And with I, I think with cloud
environments, the biggest experience that I have is with
Cloud Run. Everything's in a Docker image.
And specifically when it comes to my code, I can reproduce or
test a lot of entry points that we have.
If we have something that's event based based on a Cron
something, I can write a test that shoots in the event and
actually see what happens. And I mock the database if
needed with ports and adapters. And that's then my software.
I'm I'm very comfortable with that and also confident that
when I deploy, that is going to reenact very similarly to what I
actually tested in an isolated environment.
When it then comes to Kubernetes, indeed, because you
have everything managed, I feel like that local development
environment, it's like a must have, right?
And I also have seen organizations move away from,
let's say, the full blown development test acceptance
production environments and reduce their environments.
Civic significantly leverage whatever technology and
infrastructure we have on our laptop because it's actually
quite good nowadays. Have that be your dev
environment, only have one tester acceptance environment
and then go to production already.
By kind of reducing your environments that way, you
probably significantly reduce your costs if you're on the
cloud. So that might be why I always
saw that trend, but I'd never factored in that cost might be
the biggest differentiating factor there.
Quite interesting. Even there are use cases that
you would like to have several Kubernetes cluster for several
different kind of workloads In internal developer platform,
visually divide the the tools between the platform tools and
developer tools and you put them into separate clusters.
Because on 1/2 these tools to to like have problem with each
other. And then there are different
architecture based on the size of the company and then the the
number of services they have. For example, they can be one
Kubernetes cluster only for platform tools and services and
several Kubernetes cluster for applications for different
environments. And even in my laptop I can
deploy several Kubernetes cluster.
We all do all those tools locally in just in my laptop and
exactly replicate what environment would be in my
cloud. That's perfect.
Yeah, that's kind of a final thought.
I was wondering this throughout the conversation.
As mentioned, I only have dabbled with Kubernetes in
operations when it's already up and running, right.
And from my perspective as software engineer, I haven't
really had the need to go beyond that, maybe from an interest
standpoint, but usually things that are interesting, they go on
a long list of other stuff that's interesting and they get
ticked off or they never don't. Would it be beneficial for
software engineers to kind of learn the in and outs of
Corinetti's or to what degree would you advise people to kind
of get familiar with that so? It depends how much the internal
developer platform abstract those Kubernetes specific things
from developers. Maybe one internal developer
platform will not. Yeah, and then developer should
take care and manage of more Kubernetes specific resources
than usual. For example, in in cube rise
project, I created a template for most common deployment of a
micro service that developers will develop.
So we do it by usually by helm chart.
We create a generic helm chart. This is the one that I said.
Internal developer platform also provide a unified template.
This is a template of deployment and in Kubernetes these
templates should include deployment which deploy parts
for the microservices, a service, a Kubernetes service
which is like an internal load balancer for those pods and
ingress which manage the traffic from outside the Kubernetes
cluster to this service. Automatic automatic scaling of
that application, auto scaling of application in the Kubernetes
cluster, config map for the configuration of the
application, secret for the secret and passwords and tokens
and some more tools. This is the most common package
of the deployment to Kubernetes cluster that's a good Internet
of the program should include or a platform team should provide
to developers. Then the Helm chart has the
values, which is actually the input parameters, or are the
parameters that change for different services or different
environments. Then the only thing that
developers need to provide is the value of these parameters,
of course. Yeah.
And one of the values is the name or address of the
container, the amount of resources they need.
Is there any environment variable they'd like to have in
their container? That's it then.
Then developers don't need to know anything about Kubernetes.
Yeah, but if this package is not provided in an internal
developer platform, then developer need to write a yaml
file for the Kubernetes deployment, a yaml file for
Inglis and ML file for config map etcetera.
Then they need to know a little more what are these stuff and
how to configure them, how to write them.
Yeah, the configuration options basically that you need to fill
in. Yeah, I would say it's depend on
the size of the company, how much did internal developer
platform cover all those different scenarios.
For example, if this is the workloads in Kubernetes are
different kind of workloads, deployment statefulset, diamond
set job, Chrome job is different kind of.
But the most popular or the most common one is deployment is just
deploying Kubernetes container in the Kubernetes cluster.
But maybe a platform team or Internet developer platform only
provide a template for deployment because this is most
common. And if there is one team that
they need a stateful set, diamond set, or any other kind
of workload, then they need to learn and provide that
themselves. Yeah, yeah, that makes sense.
I've really liked this conversation, which about this
was a lot of fun in kind of this journey of when to use
Kubernetes and what internal development platforms are in the
1st place. Is there anything missing that
you'd still like to share before you run off?
Yeah. I think a common pattern is that
the companies usually underestimate the importance of
the internal developer platform and automation and this kind of
templates and they start creating themselves.
And then when they want to scale, they will have a huge
problem. And they think that I always
advise that start in a bit in a good way from the beginning.
Start with the infrastructure as code principle with Git OPS
principle with DRY principle. Don't repeat yourself.
So providing a simple set of a single set of templates and only
change the parameters and values for different environments,
these can like help them a lot in the future when they want to
escape and don't postpone it for the future.
Yeah, yeah, I think it makes sense.
Thanks again for coming on and sharing.
This was a lot of fun. We're round off here.
Thank you so much for listening. If you're still here, let us
know in the comments section what you thought, like if you
liked the episode and otherwise we'll see you in the next one.