You Don’t Need Kubernetes

Kubernetes is powerful. You might not need it though. Serverless functions are dope. @devagr is gonna kill me for this one...
ALL MY CONTENT IS FILMED LIVE ON TWITCH AT / theo
ALL MY BEST MEMES ARE ON TWITTER FIRST / t3dotgg
ALL THE COOLEST PEOPLE ARE IN MY DISCORD t3.gg/discord
ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg
Everything else (instagram, tiktok, blog): t3.gg/links
Ty for edit Mir!!!

[@jocke8277]

You're wrong, I need kubernetes to successfully manage my blog.

[@maccalsa1]

🤣

[@lutfiikbalmajid]

Only blog?

[@smash3689]

@@lutfiikbalmajid blog is all it takes

[@BusinessWolf1]

what

[@mightycryptowall]

🤣

[@elmax5748]

When he says he would have to hire primagen, that isnt a metaphor for infra-engineers. All big companies have to hire primagen eventually, he is the only one who can do it.

[@mosescosme8629]

this is my favorite comment

[@remyschrader9286]

No... there is another kzbin.info/www/bejne/rIe9hJWqptyha9E

[@t3dotgg]

Omfg

[@pronerdjay]

I want to like this comment but it is currently at 69 and i can't ruin it.

[@danvilela]

@@pronerdjay now you can

[@nexxel]

You're wrong Theo. I have 9 users on my app 😱of course I need Kubernetes!!

[@doc8527]

No, K8s wouldn't work, you need K9s

[@stefanalecu9532]

@@doc8527 add some corgis while you're at it It won't help your infrastructure, but it will be cuter

[@ReneHoffmann194]

No k9s is only to understand what is going on in your k8s, not kidding ​@@doc8527

[@AlphaWatt]

Love this kind of content and perspective man. This and the CSS frameworks video were huge helps to me. Thanks for the time!

[@JeffryGonzalezHt]

Extremely fair. I find Kubernetes killer feature is managing human complexity - a place I do a lot of work has > 2k developers. A few hundred teams. Enterprisey. Kubernetes is great for them. Much more team autonomy, and almost forces better architecture (less coupling, etc.). Frankly, the unneeded complexity I see most often in those environments is reaching for SPA frameworks (Angular, React, etc.) to build shoddy MVC apps that live in a browser at way too much cost where a Rails or MVC or whatever app would do the same job. But I really like Kuberentes. I have a cluster in my basement - (and not arguing with your point at all) - but I sometimes feel like the "oh it's too hard!" thing is coming from privileged developers that have never had to deal with infrastructure at all.

[@BosonCollider]

For those "unnecessary use of SPA framework" cases, I like to recommend HTMX, simply because it sort of forces you to think in a non-SPA way

[@kkoppa]

We moved cloud providers twice and have ~40 microservices! Being on k8s saved our butts for these migrations honestly.

[@boohoo5419]

dude you have no clue how much is wrong with this statement. devs are such noobs these days lol.. real men run there stuff on bare metal and microservice are the current trend everybody will mock 10 years from now.. microservices are the new JAVA. they are for idiots that have more money then brain!

[@ramymawal8295]

your company is a good example of a company that NEEDS k8s what Theo here meant is the same recurring problem in software: Don't solve your own problem the way someone else solves a different problem, find the problem then the correct solution.

[@barreltitor1419]

@@ramymawal8295 realistically a lot of apps would be built shittily like that and would require massive refactoring to get it kubernetes ready instead of architecting your infrastructure well from the start.

[@joshbedo8291]

Ive worked at a lot of large companies in NYC and k8 was definitely an improvement from docker images on ECS. I had to setup ECS for the daily beast and it was kind of a nightmare. For anything other than enterprise that stuff is generally overkill. We had to support 120k RPS so thats why we needed to switch from haproxy to nginx, add a redis cache layer, and add ECS with auto scaling groups.

[@otockian]

ECS is fucking awful, having used it extensively. Nothing but constant problems with it.

[@andrewgodman]

ECS is good if you need to have some basic scaling of persistent containers. I’d recommend that over jumping in to k8s unless you absolutely need to. Signed a dev who’s managed k8s in small and medium (but growing) startups

[@jcs184]

Why not just plain old ec2 with auto scaling?

[@MrHamsterbacke756]

What do you dislike about ECS? Thinking about using it for a new project.

[@joshbedo8291]

@@MrHamsterbacke756 It's easier than K8 ECS basically just makes it easier to manage EC2 instances with images etc. It's not too bad K8 definitely has a lot more you need to learn but it's also when you need more control... you don't need more control unless you have inhouse servers etc. for example my friend works for UPMC they have mainframes and all in-house servers nothing on AWS and they use K8 to manage everything.

[@GuneyCanGokoglu]

I generally agree with the idea of choosing the right tool for the right job, I just wanted to mention there are a lot of managed options for running a k8s cluster like GKE autopilot that can also scales down to 0 which will solve all the issues you raised about k8s. But yeah, for an app that requires 1-2 services k8s is generally is an overkill.

[@Dan-rx8wf]

I need k8s to keep infrastructure complex - JOB SECURITY... you know lol

[@anyadatzaklatszjutub]

lol so much of everything is just (useless) abstractions to make people busy

[@aaronsmith1474]

This is the way.

[@VictorMartinez-zf6dt]

At my current job we’ve been serverless from day one. First with amplify and then with sst. It’s reaped massive dividends, and embracing event driven architectures and data modeling up front has made life so much easier from a developer experience.

[@robertshuxley]

I feel the same way about Redux. Our company has a very simple UI with simple functionalities and the ones who built our frontend were hardcore Redux purists and all the boilerplate code just slows us down

[@mihailmojsoski4202]

Redux is a pain in the ass to setup but when you have it you sure are glad to have it because you can do a lot of magic with it. For example I added it to my admin dashboard and used persist middleware, hooked up SSE endpoints (websockets would work here too) that subscribed to database changes, added some middleware that updated data when post requests were made and it did 0 unnecessary requests to refresh the data other than the ones that were for the SSE endpoints

[@DefinitelyNotAMachineCultist]

Try Zustand.

[@RaZziaN1]

@@mihailmojsoski4202 All of that were done 10 years ago will way less overhead.. You don't need redux for that.

[@tobiasbergkvist4520]

I'm using microk8s for side projects to keep hosting costs low and not have my side projects interfere despite running on the same server. Also makes it easier to come back to my side projects a year later with everything related to deployment being explicitly defined in yaml files. Requires close to 0 maintenance.

[@glycincheck7127]

Do you host on a VPS?

[@tobiasbergkvist4520]

@@glycincheck7127 Yeah, I'm hosting on a Hetzner VPS

[@glycincheck7127]

@@tobiasbergkvist4520 ah kenn ich

[@SandraWantsCoke]

@@glycincheck7127 Sowas hab Ich auch vor. AWS scheint teuer zu sein (versuche es gerade mich in das ganze einzulesen)

[@timschupp2080]

This exactly is the way to go! In my experience 8-10x cheaper than choosing managed providers & way more flexible.

[@dallinhumphrey3204]

Awesome video, I love the crossover when you get into the business side of why and when you need something.

[@carloslfu]

Great video! Well said. IMO, one of the most important traits of great software engineers is good business-oriented decision-making and tradeoffs.

[@nicholaswood3250]

I think Kubernetes is fine for small/medium size teams as long as you are letting Google or Amazon manage it for you. I have set up K8S clusters from scratch, and I think the real awful, difficult stuff comes from having to deal with the really subtle, difficult problems K8S was designed to manage. You always need to fully understand what you’re getting into either way. I also yell at everyone who wants to use K8S that they should keep their database as far away from it as possible, because it was specifically designed to service stateless applications- K8S was very specifically not designed for DBM. Manage your database separately no matter how large your org is.

[@erdemarslan3371]

Your content is so valuable. Thank you.

[@PatrikTheDev]

I’m like the absolute opposite of Prime. My whole dev team wanted to self-host everything and run a custom cluster, I vetoed that and we went with Vercel + PlanetScale and a few other managed services (Pusher, EAS, though I try to rely on as little as I can). It was really hard to explain the correlation between infra cost and the cost of developer productivity, now I have a video to send people in these situations. Thanks!

[@pieter-venter]

Please do send the video!

[@joshuaborseth]

@@pieter-venter lol, i cant tell if youre confused, or if you are taking a shot at the video?

[@pieter-venter]

@@joshuaborseth just joking around and acting dumb

[@joshuaborseth]

@@pieter-venter you’re a silly goose

[@ArielBenichou]

I really like your content. As a developer who don’t have a senior to guide me, your insights are very valuable Thanks

[@zaktoob]

Like any technology, it really depends on how you choose to implement and maintain it. K8s need not be extremely complicated. It solves a lot of issues very neatly - scalability, redundancy and keeping upgrades rolling in with minimal (potentially even zero) downtime. For a lot of use cases, lambda/serverless is OK, but requires a lot of forward planning if you require state. K8s is not scary!

[@ambars5747]

Another superb video! As a freelance fullstack dev (mostly for small to medium startups) I try to keep K8s as a last resort infra option. Usually Serverless or FAAS gets the job done quickly, cheaply and well enough to keep going for quite a while. Still use Terraform extensively though - it's super handy to have some kind of IAAC - e.g. to be able to spin up a new environment with TF. I often find myself pushing back against all the K8s hype, because everyone and their uncle wants to jump on the K8s bandwagon. As you so rightly pointed out, except for a few (i.e. some enterprise-level) use cases, all that complexity and cost just don't make sense. Thanks for the great content. Subbed.

[@themarksmith]

Excellent vid and topic - would love to see more like this!

[@rc23789]

Thank you 🙏 for actually talking about this problem.

[@StephaneArcher]

Thank you for this type of video

[@codecae2]

Totally agree that Kubernetes isn't always needed. However, Kubernetes has become more of a means of becoming cloud native, as opposed to just an orchestration/infrastructure solution. The benefits of the cloud native approach are more about protecting your investment in time an effort than tactically responding to cost trade-offs during standard operations and maintenance. The diagrams you've used to promote your position are mainly with consideration to onboarding and creation/maintenance of a solution, but it does not necessarily include the costs you inherit when applying an exit strategy to a vendor-native solution you no longer are able to use to use. As products evolve, which we know they always do, this doesn't always line up with outside influences that can derail a project entirely. If when 'sustaining your business', you need to move from one vendor-oriented product to another (often for reasons out of your control -- pricing, compliance, regulation, sour contract negotiations, etc), the exit strategy itself can case a business to endure EXORBINANT hidden costs that can come out of nowhere; not to mention the unexpected cost of reimplementing interfaces against something else. Kubernetes (no question) has higher operational costs, but like any OpEx challenge, the long term savings in having a vendor-agnostic stack that is not beholden to the whims of a shiny, narrowly scoped vendor-oriented solution has its benefits as well.

[@romanmunar]

Convincing someone more senior than me is the hardest part when moving over to a hosted service/vendor.

[@dandogamer]

Yeah ofc, your trying to push someone elses opinion when they are trusting their own because its backed by experience. So you need to take some part of the software that's overly complex and make a POC with it and show them why its better. Chances are this will lead to curiosity and questions which might make you realise that their choice does seem better suited or you have solutions to their problems

[@SeanSchade]

Spot on! Knowing when to use these technologies is key.

[@TusharParekhtpar2014]

Really nice viewpoint ! It really makes sense ! Thank you !

[@decoyslois]

That’s an amazing insight. Your infrastructure slows you down, and as a startup, avoiding that as a competitive advantage. Really nice way of thinking about it.

[@flavioneto1081]

this was a great video Theo, I think going into more tech decisions content would indeed be very valuable, especially since it's somewhat scarce

[@benheidemann3836]

I completely agree with the sentiment you express at the end of the video, we need to talk more about these kinds of topics.

[@jasonseparovic6345]

Interesting video. I’m working on a 1 engineer startup right now and running a bare metal kubernetes cluster. Vitess, Kafka, ES, keycloak, react, maybe like 10 nodejs microservices including a websocket and Kafka proxy. I actually went this route because I thought it would be more cost effective but comparing initial monthly costs of planet scale, upstash, pusher, etc, to the bare metal hosting for a prod and staging cluster, they do look quite attractive. I have some concerns around latecy to the db though and ability to keep my app close to the db. As for kubernetes bring up, I didn’t find learning and building on kubernetes too demanding, and you only have to build your deployment scripts once, but I do have concerns around ongoing management of the cluster as we add users to the system. Probably time I should be spending on new features and not infra. I’d probably keep kubernetes for the ingress and microservices, but maybe it’s worth offloading the rest of the infra to cloud services to save on time. I’d probably go the opposite route, keep it in house until it becomes a pain to manage

[@andre-le-bone-aparte]

Not the video I wanted, but the one I needed. Thank you!

[@samcalder6946]

This is the best take in the history of takes. You sir have earned a subscription.

[@zwhitchcox]

One tool that will help eliminate micro services is bullmq…the use case you mentioned with cron jobs can be solved with repeat jobs, and it has other task queueing/load balancing functionality…it uses redis for its state management, and most hosting platforms provide managed redis instances

[@EanSchuessler]

Those who ignore Kubernetes are doomed to re-implement it.

[@usher-p]

This is amazing! We should have more of these talks

[@j0hannes5]

Thank you! And more vids about business decisions would be very welcome. Also - having never used Kubernetes, I would like to understand: why is there maintenance required? what is happening that you need to respond to?

[@aprilmintacpineda2713]

Theo: websockets can't be run on a lambda (goes to suggest pusher and the like) AWS API Gateway: Am I a joke to you? 🤣🤣

[@codewithguillaume]

I always had TROUBLE to pronounce the name... That was a bad signal 😂 Should I make a video reaction again about this video? haha

[@EhteshamShahzad]

Man, I have gotten so much value from your videos. 🙌

[@CleanRapMusic]

I don't know man kubernetes has made my life SO much easier. Plus it has allowed me to take control of the entire lifecycle from beginning to end and automate basically everything.

[@hugot8226]

Not so ranted about Firebase finally 😏 Thanks for the video Theo 😎

[@yapdog]

Big thumbs up on this video, challenging the status quo as defined by the "big 5." SUBSCRIBED

[@theDrewDag]

One year later, this video continues to be pure gold. Thank you, Theo.

[@cedricvillani8502]

Architecture must be rethought before vou begin refactoring the code. Does this new approach to application architecture suck resources and money, as well as adding a great deal of risk? Yes. However, the risk-reward scale typically leans to the reward side if the life of an application is 10-15 years (which it is for most enterprises). The effort of both rearchitecture and refactoring for an application with long-term use will pay for itself many times over. However, enterprises in the US are not wired for long-term investiture. Most enterprises opt for lift and shift versus refactoring for cloud native. Enterprises are rewarded based upon earnings, and the lower the cost of new software development and IT, the more earnings they can claim-short term. Fortunately, despite naïve attempts at understanding the architecture of large complex systems, everything is pretty much kept at social media length, and whether we like it or not the “Everything as a Service “ (XaaS) is here and has been happening (US is a bit stubborn but not dumb ), so if you have a server somewhere at a data center, I would not expect it to be there for too much longer. We are at a “Moore’s Law” type of paradigm when it comes to Networking. As demand and speed increases, we just can’t have average KZbin Joe running around a data center trying to find room to plug-in cable,😂But this can change if we decide to break up large corporations or get hit with a massive coronal mass ejection lol. I would learn about how statistics lie depending on who is drawing ✍️ before you make any kind of large purchase, that’s about all I can say. TBH a bit sick of saying it, but the fine art of distraction is not lost here. (Not this particular Channel ❤ Theo)

[@dyto2287]

Tbh, I run my own personal k8s cluster so it is easier to quickly spin up some tools or services that I need. Creating new VMs and maintaining them is slow. As for product building, main use cases I believe would be: - Your backend has a mixed stack (e.g. Go for API, Python for ML, Node for SSR, etc...). - You are making a security, government or healthcare project where you require good observability of different services you run. - You make custom solutions for your customers for which you need k8s to easier maintain zillion of different environments and deployments.

[@Ca-rp7bv]

You are wrong Theo, over-engineering everything is what makes impossible to fire me

[@tradeordie]

So true. People always trying to optimize before they launch/have any users

[@autohmae]

Totally agree, but over time the industry knowledge is expanding and tooling for running things on Kubernetes and Kubernetes itself exist and will standardize over time (like good industry trusted operators for standard software), the cost or maybe I should say overhead of running things on Kubernetes will go down. That said: sharing of that knowledge has been much slower than I expected when Docker got started in the early days. I was still surprised how we ended up first with VMs instead of containers. I had been running Linux containers (wasn't called that yet) all the way back when it was Linux VServer project. And after having said that... I also agree I don't think we might ever reach the level of simplicity of running something like Docker compose (serverless is a different story), but people want more features than Docker compose as well. The (virtual) hardware cost of running things on Kubernetes will also go down a bunch if/when we get to the point of proper managed multitenant Kubernetes.... I predict in less than 5 releases from now people will start to work on that. It depends on things like id-mapped volumes for usernamespaces. Their are to many people who want Kubernetes (the features it offers, you can see it with the big players managed Kubernetes offerings and the smaller players offering managed Rancher with Kubernetes) and have lots of things they don't want to manage themselves about Kubernetes which could all be handled by a managed service provider. Probably includes ready made gitops templates. But hey, I'm just guessing of course. 🙂

[@jacobmar2797]

Preach. 100%. Subscribed.

[@ungyi9352]

Good point about looking for right tools. K8 is great, but not for everyone. Tools like Azure container app looks promising. It runs on top of k8, but simplifies things. Thank you.

[@andredias5061]

Man that explanation using Uncle Prime is incredible, I never thought about that

[@Propherex]

I maintain 3 startups at a time. There was A LOT OF PAIN without Kubernetes! If you keep it simple and basic, developers will be able to handle Kube on their own. You just provide the framework and continue coding. Add some tools and you'll have everything you need: version management, builds, pipelines, just keep everything close to native and it'll be safe, fast and cheap! I remember being skeptical at first, so I understand the tone of the video, but it is a skill issue ;) Using Lambda and thinking in serverless architecture changes the way of programming, in my opinion for a better one.

[@RobHarrison]

You’re right in many ways. Small things can be built in almost any way and overcomplexity early is often fatal. However big things need knowledge encapsulation, and starting that knowledge encapsulation too late will also slow you down and can also be fatal. There are a lot of other ways to do configuration as code outside of kubernetes. When teams of multiple people are delivering software to other teams to deploy though, kubernetes and other tools serve as a good shared contract to exchange and manage that configuration.

[@RobHarrison]

I remember the bad old days when a company would have servers which no one knew how to rebuild should something go wrong. Doing deployments on that shit was scary as hell and rebooting was not fun either.

[@RobHarrison]

Having stuff run on others services does mean that there is a gap in the knowledge encapsulation. When the 3rd party forces upgrades there has to be someone there to maintain. You then need to train maintainers in lambda or app engine or whatever. If you’re writing huge swathes of config specific for a 3rd party service then you’re just moving learning and knowledge encapsulation from K8s to proprietary formats, but stuff still needs to be configured.

[@RobHarrison]

I’ve seen a lot of projects “move fast” and then find out the code is in such a mess they can’t even write something bigger without a refactor or rewrite. Sometimes the fastest thing overall is the move slower at the beginning.

[@ds_7]

Love it! Great content

[@O_Eduardo]

Totally agree. I'm the one who will ALWAYS look through tech problems/issues in that way. The majority of our problems DO NOT ASK for complexities created by F.A.N.Gs engineers/employees, and many of those solutions are not a optimal even for their cenarios. That mindset extends for any other contexts in web development not only infrastructure.

[@ivanc3176]

Are you calling me kuberneedy

[@and1play5]

Correct, K8s is for big scale things, most devs don’t need it (nor can afford time x money in cloud)

[@webdeveloperninja9220]

Great advice

[@mustafazakiassagaf1757]

google cloud run is a big game changer for me. i just need to code my backend as usual and just need to containerized it and i don't need to think about the infra.

[@sea0920]

So, just like planet scale, upstash, pusher, etc, we are outsourcing infra problem to Kubernetes. Not sure why Theo is against Kubernetes.

[@kendrickcaranicas4562]

Last third of the video was content everyone needs to hear.

[@rained23JMTi]

I am in a company that I consider a small tech team and use Kubernetes, I had a nightmare dealing with k8s for my project as it started with k8s when I joined. Luckily I was leading a different project and ditched k8s and moved to serverless, while we are busy developing and releasing features, the other team had to deal with the infra thing nightmare.

[@nsttt]

How do you manage to ship videos about the topics I need to hear about 😂. Great video as always Theo

[@jww0007]

watch the vod

[@rumplstiltztinkerstein]

he asks the viewers for ideas. That's why it's so relatable.

[@jamiepine]

music to my ears

[@italosantos4381]

I couldn’t agree more, kubernetes is not necessary for most of the companies out there and it’s hard to maintain, glad to hear you say that

[@mylodev]

this was beautifully edited

[@mohamed_elmardi]

Cloud Run is really cool, it's basically serverless docker images, you can deploy any docker image and its gonna be self-managed

[@user-gs3lm7gt5e]

This is good point, I had an opportunity to deploy docker image on GCP and i went two ways, one being set up the GCP infra myself, other publish docker image on Cloud Run. Needless to say that Cloud Run is more effective and cost efficient

[@caiodallecio]

Agree with pretty much everything, however in places that are not the USA, Canada, or Europe, the cost of hosted services is ridiculous, so you have to get scrappy, sometimes lambda won't do, then Kubernetes is your best friend to spin up a bunch of containers while keeping infra costs under control.

[@alekseykostyuk3806]

Absolutely agree. But sometimes it's not a "Company", but a CV driven IT/Ops engineer, which decides that he needs K8S and manager simply have no clue what it means. I believe AWS Lambda and Fargate are the solution for 97% of the problems. Also - check GCE, they have introduced a simplified k8s for users. K8S should be use by IT only if the problem at hand is something like "build my own cloud".

[@remyschrader9286]

Let's see.. 🤔 can I manage uphill to persuade my boss to sign off on this recurring expense exposed to overages that they (and probably me) don't understand.. -- OR -- Can I learn a 200k engineer skillset on the company's dime? Decisions, decisions!

[@eructationlyrique]

I'd say that people tend to overestimate their need to scale. They think about scaling to 100 000 000 user before they have 100k. Before considering serverless infrastructure, consider that while it's easy to scale, it's ultimately expensive for what it is. The most sensible option is simple infra over serverless or k8s. If and when you need to scale, you can then make the necessary changes to scale, and since you know what need to scale and by how much, you're in a better position to make the right choices. In any case, a monolithic, simple infrastructure can usually handle much more traffic than most people expect by scaling vertically.

[@asdqwe4427]

This is the best take!

[@PapaVikingCodes]

Love this. We are marred in terraform and containers and for some big projects that overhead killed our ability to make progress. Nightmare. Nimble first. Complex when needed.

[@plexq]

The issue I have with lambdas in serverless is that the IaC systems I've used, CDK and Terraform, and then things like Amplify are slow painful and don't work very well. The refresh cycle I've experienced with lambda is very very slow and makes my development life kind of a huge pain in the ass. So far, life seems to be the best if I'm just using regular old EC2 instances with ALBs with some amount of IaC automation in terraform for standing up a new environment for my back end, and CloudFront for my front end, which, I know - is serverless, but it's serverless for the piece that is easy to make serverless - static content. This has always been the case in web services - put your static stuff on a separate high I/O instance with lots of network, and put your CPU intensive stuff on a machine with more CPU. I found that ECS was a total nightmare with redeploy times in the tens of minutes sometimes, and whilst GKE was okay - it was still a pile of work compared to just provisioning EC2 instances, and running my server. Plus other things in Google Cloud just don't work nearly as well as AWS. With regular EC2 (or equivalent) periodic updates to OS packages, and just spinning up new instances every so often seems to take care of most of the operational concerns with ease. Must less hassle than trying to automate the crap out of everything and spending 10x the time on the automation as it would have been just to maintain the instances manually. Just my personal experience...

[@feligoros]

Back when I first saw some videos from Theo, I was kinda skeptical about the quality of the content, seemed a bit biased and trust-me-I-know-it-all-ish. But damn you are dropping some good knowledge nowadays. Definitely subscribing, keep it up man!

[@dustymccord]

Good topic. I like your shorter content opinion pieces. Have you shared your thoughts on monorepos? That’s a hot topic.

[@JoeSmith-kn5wo]

I work at one of the FAANGS. I see this all the time with our external customers/partners. They have a 3-tier web app, and think they need Kubernetes. I feel like I need to share this video with many of our partners/customers. Most of them could make their life’s easier by just going completely serverless.

[@adiriakya9724]

I generally agree with you. for most opensource services like databases, no need k8s even it support Statefullset its a waste of time and money. as for services, depends how many you have and what it the relationship between them. k8s is a great tool to deploy larger infrastructure (5 services or more), coupled with a simple CD solution it's really good. if you have a small service, dont bother not because k8s is hard to learn or to deploy (it's very simple actually) but just take one machine, run your stuff, get clients, grow and then reevaluate.

[@don17525]

You call 5 services or more a threshold for a large infra? lol

[@adiriakya9724]

@@don17525 lager, not large. please ready. (lol)

[@don17525]

@@adiriakya9724 yeah I definitely need a lager to understand what you’re saying 😂 Nevertheless, 5 is still minuscule for considering K8s. Cheers mate 🍻

[@raulcontreras2717]

Fully agree with you

[@alexenax1109]

Love this!

[@paulsalele3844]

Imma use that Primagen costs analogy 😂

[@alanhoff89]

I don't need k8s because I'm building my own k8s from scratch

[@alanhoff89]

@@yzeerkd dude.. It was a joke about programmers always building their own stuff.

[@yzeerkd]

@@alanhoff89 intentionally or not you kind of describe the problem with anti k8s thinking. Skip it over and you're destined to make your own crappy version of it if you build a distributed system

[@joshhardin666]

I understand this from the perspective of a business, but what about us homelab users who specifically want to self-host our own scalable services, without using cloud providers. I have hardware, I have bandwidth, I don't want to pay a vps or a cloud provider every month for my plethora of personal projects that don't make me any money. I want a home cloud that provides scalable instancing of application stacks. is k8s not a good fit for that? I'm NOT hiring engineers for this.

[@A5tr0101]

I get it, beeen feeling a lot of the same problems in the team im apart of, Google cloud auth updates, now we have to update 17 repositories!

[@noext7001]

how do you deploy go microservice with k8s ? serious question

[@lilililliilil]

Always thank u❤

[@9r1nc3w1ll]

I totally agree.

[@KangoV]

We use ArgoCD which manages 3 K8S clusters (AWS, Google cloud and Azure). We just update the version of a service it Git and ArgoCD sees the change (once merged) and does the rest. Yes, we are multi-cloud with failover. Woooooo.

[@thejusunnivelan7193]

I know this probably isn't the best place to ask this, but could you, one day maybe, spend some time explaining what a mono-repo is, and why that tool exists?? I know that people studying CS through college struggle with the git technology and how it is implemented at the largest of scale, so it would be really helpful outside of just me. :) Thank you

[@yanfoo]

What would be A good solution to have an owned PostgreSQL database (not hosted externally)? I usually deploy a VM (e.g. Bitnami PSQL appliance) on VMWare (or VirtualBox in the case of a smaller company); what are your thoughts about that?

[@alexandersemionov5790]

The problem is in many companies devs Want to test stuff out and the next cool thing is kubectl. If management doesn’t see that, they will fall for the shiny thing and approve the unknown expensive tech. Unfortunately I was expensive for a few customers, due to me testing new cool sh… out in the past

[@Mixesha001]

Like any tool is solves specific problems, has you said the issue is that it seems to become a go to because big names using K8 to solve their problems. However GAFFA problems aren’t everyone problems. K8 is great to scale high traffic app and complex infrastructure. It is the same with Redux etc Serverless solving small stuff out there without using K8. The issue with K8 is that it require infra devs as the architecture become more and more complicated. K8 should be the end goal when nothing can scale as much as you need or you need to make a more complicated architecture, which might be a pain in the butt in the future.

[@rikschaaf]

If what I need of my application is to have 0 downtime, even during deployments, if I want centralized authentication and authorization, if I want centralized logging, metrics and alerting, if I want an abstraction layer on top of storage to manage data replication, snapshots and backups, then that is doable without K8S, but K8S does make it a whole lot easier. Whether you should manage a K8S platform yourself though is another question

[@maximenadeau9453]

Docker swarm.

[@JorgeLuisMachadoTorres]

Have to agree with this one, not everyone needs a kubernetes cluster

[@voidpunch1324]

Nice, i'll keep this video in mind when someone mentions Kubernenetes and ask my opinion.

[@0nepeop1e]

i am happy with docker compose 😂

[@sircalvin]

i run (as a hobby project) a 1v1 service for the game tf2, and its the only project ive ever needed kubernetes for, and its for nothing on the site, its only used for creating game servers dynamically

[@Jaxbulid]

100x100 agree

[@ihsen]

Serious question, how would I build a SaaS startup then? I have an app in a container that needs a PostgreSQL. If I don't use k8s, what should I do?

[@mihailmojsoski4202]

docker-compose? or just install postgres on an regular Linux VPS maybe

[@j3k2006]

I only know AWS, so how about RDS and ECS (or insert other vendors' equivalent here)

[@ambars5747]

If you already have a containerized app, there are quite a few options to run that in the cloud without having to use K8s. For example, Google Cloud Run is explicitly built for this use case. AWS Lambda also lets you bring your own container image since Dec 2020. Both of these have fairly generous free tiers to experiment with.

[@ihsen]

For more context, running just one container on the cloud is no problem. But the app does not support multiple clients. Every client should have his own instance with a separate database (important for data protection). That means when a client signs up a new instance should be fired up with a separate url. Would appreciate any tips that solve this problem 🙏

[@Flip97rza]

As a FE dev, I would say its the same logic as you'd have with jQuery vs using full-fledged JS framework like Vue or React. Once you know how to effectively use it and you are at the beginning of a new side-project for example, then there is no choice go back with jQuery even if its capable of all requirements. Same with docker/k8s. If you know how to set it up quickly, the basic stuff you only need, go for it. A different story is running k8s on your own infrastructure vs SaaS. You can begin with SaaS and then split or go full with your own i12e. In the end, its only about the price and redundancy 😏