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.