Fast-to-ship frameworks are how we get unmaintainable apps nowadays: 1. Slap together a demo of the app. 2. Management: "How quickly can you put this into production?" 3. You: "That cannot be accurately predicted." 4. Management: "I need a clear time-frame." 5. You: "At least four sprints." 6. Management: "Have it ready in two sprints."
Do you want to scale? Do you want to scale across n machines? Do you want to scale across n machines and not have to baby node and service health? Then you need an orchestrator. Do you hate, “well it worked on my machine” then you want images, do you want light weight images? Then you need containers. Do you want the ability to easily move between cloud providers and onprem? You want K8s.
Why not just containerize your application(s) and deploy on heroku, cloud run, cloud foundry etc? Then when/if you use k8s or nomad then do that when you need to?
9:44 "complex problems sometimes just have complex solutions" - that's called irreducible complexity, and the failed software projects I have seen frequently try to "simplify" irreducible complexity, causing the complexity to be hidden and damaging throughout the whole project.
15:30 that’s not the correct use of “exception that proves the rule”. A common example is a parking sign that says “Free parking on Sundays” which implies that the general rule is no parking.
Man reading the comments and recalling what my old coworkers say, it's like Devs never learn. The answer is almost always "it depends"... There's not a hard yes or no. I would thoroughly dislike working with the majority of you in the comments.
The hard part is when the quick and dirty MVP becomes the foundation for everything you do moving forward and management gets used to quick and dirty fixes and doesnt understand the need for a solid technical foundation.
I migrate and modernize legacy apps including runtimes, kernels, and compilers. Kubernetes is good for building a platform to reduce the cost of managing a large data center or when aiming for multi-cloud due to scale. Most products need simple container solutions like AWS ECS. As with microservices, most products should end their journey on a modular monolith. For now, only a few thousand companies across the globe need the K8S, but people have chosen to use it as a nail and hammer.
My job uses k8s. The k8s engineers claim that ecs sucks Not sure how valid that claim is. The apps we run are simple and personally I think k8s is overkill and you have to spend so much time maintaining the cluster too
@@asdasddas100 I worked for one of the biggest telecoms, which runs most products on AWS ECS. It always depends on the prerequisites, i.e. what "sucks" and what tradeoff you choose.
And I'm sure that Telecom company had an massive infrastructure team that built the whole system of deploying shit to ECS. Whereas you can handle k8s alone.
@@Sadzeih 3 teams, ~15-20 people. Currently they merge similar solutions across globe so probably more now. By handling k8s alone do you mean ready-to-go products like AWS EKS or Azure AKS? Maintaining the k8s platform built from scratch is the work of over 50 people. It took 3 years and 500+ people to build a platform on top of k8s in a bank I worked for. In the case of ready-made k8s, this should be a lower bar, but I have never used such solutions so far.
I like how you mention tcp and binary protocols. I went into writing an x11 client in Java not knowing much but now it has helped me understand that all clients have some underlying protocol.
@@MagnumCarta I'm in that awkward age where it's hard not to associate him with Boromir because I was just barely too young to know all his great roles in the 90s.
I tried HTMX yesterday for the first time. It's pretty good, but I would not know how to structure a large app with it (do I create a new .html file for the stuff I want to have old html swapped with?), or how to persist some client states that I need on the client side. I would probably have to put everything into DB, no idea.
Using JStachio which is fully compatible with Mustache. It compiles templates at compile time and can have no runtime dependency. It has partials and fragments. For example, the main parts of a dashboard are in their own html file which contains many fragments to enable swapping out html within the larger component. It works extremely well. As the templates are strongly typed and compiled, you see errors in the IDE (intellij), which has been truly awesome.
Delivered software on 12 test systems last year. Never needed Kubernetes. That doesnt mean Kubernetes is useless, but there is a tool for every situation and not a tool for every situation.
Networking is something that every dev should know. I can count on one hand the number of devs who actually understand how tcp works I have met in my current work place
TCP was a lot of fun to learn about in my mobile and wireless computer networks course in university. Since mobile communication is affected by attenuation, a direct line to the end server is really bad because of TCP's congestion threshold algorithms. One solution is to set up two channels, one between the client and a mobile base-switching station (that takes in traffic from cell towers) and from the mobile base-switching station to the end server. The base-switching station is not affected by attenuation since it often uses direct physical lines between providers. The end server's intermediate nodes in the network never throttle the connection since it remains stable from the base-switching station.
Kubernetes is not even hard. At first the concepts might be hard to grasp, but after understanding the how and the why, its all just yaml config files and running commands. Diving a little bit deeper and using k8s hooks in your code for developing k8s-native microservices is where things become a little more complex but if you are just getting started, that stuff is far into the future and by then you will be more confident about learning more. Also that stuff is what pays a lot.
It's very simple compared to a lot of other software. Takes about a week to understand the majority of the use cases. Takes years to know the edge cases.
My strategy for covering every level of complexity in a project is basically to keep a Kube deployment module in my back pocket at all times for when something gets too big or insecure and the individual Docker containers in my front pocket need managed.
I wish I was on for this stream but I was on a flight. Kuberneres is so satisfying and you might never truely get done learning it once you get into building your own operators and CRD. I was not at all interested in it until I started using it to solve all infrastructure problems and learning how to operate it. You would love it.
Honestly, K8S is often useful even for small things. The moment you want to avoid downtime during updates, K8S is useful. No, handrolling an adhoc version of a buggy subset of K8S in Ansible is NOT an option.
@@chupasaurusif you are at the level where you can handle it with docker compose then just running k8s locally and using it instead is not really more effort.
@@mudi2000a Compose has service update policies since forever. Sure it lacks proper networking to run multiple instances of the same service, but that's where service discovery comes handy (wink-wink Consul/Vault). And Ops pain to run it is tiny bit worse than to have a managed k8s cluster, on-premise ones are orders of magnitude worse.
@@chupasaurus I love my home k3s cluster which makes it easy to host my own apps in a cluster and manage ingress etc. just like running the AKS stuff at work more or less...
As a non-dev who's trying to get back into programming as a hobby, but who mostly listens to content like this channel because I like hearing some of the inside baseball of the tech world, I'm convinced that Kubernetes is a myth. It's just a silly word thrown into technobabble sentences to make simpletons like me feel stupid.
Yes, but at the same time you remove dependency hell by separating environments in application containers and allows for the automation of said containers. The alternative is doing that manually, which can be seen as insanity sometimes
I think people are confusing two things, one is understanding the concept of recursion, and the second is being able to actually use it and understand what is happening. The first is simple, “function calls itself hur, dur, easy peasy” the second is a mind melting session of doom.
@ThePrimeTime you are awsome. most of the time in this busy life i dont have time to read the tec articles but you in your video make my ife easy. Thankyou.
Simplest scales BEST. Fastest is the best for short term survival and it builds momentum if you're at all focused on investor relations. Cheapest is often good if you're already revenue positive... take a breath build your war chest and focus on simplifying all the things.
That depends on what the interest rate is. When rates are high investors care a lot about cash burn. As an employee you want the savings to come out of the cloud bill, not out of headcount
13:25 For some reason, recursion made immediate sense to me. I was using it to solve problems effectively in my first couple weeks of coding because it just came to me as a natural solution to some problems. But I absolutely struggled to understand classes in the beginning.
Big fan of networking knowledge. Im more a cloud/platform engineer, and when i get new guys, i get them to focus on rounding that knowledge out first if they haven't already. Its so critical to design, debugging, security, and just tech understand as it underpins everything.
Those who need to deploy and maintain a cluster agree it's complicated. Needed for a monolith? Nope. If you have a set of services (micro, domain, whatever size you want), with supporting software that need LB, Service Discovery, Resilience, etc. Those who use K8s agree, it really makes things easy.
For me Kubernetes solves the headache of the supporting infrastructure (like monitoring, networking, security, storage etc...) maintainability, scalability, HA, and automation for your project application(s)
"Can you deliver the features in reasonable amount of time" - knowing how much you can deliver in a given time span is a clear sign of seniority (= experience)
If you're starting green field and building it all from scratch I sort of agree, but when dealing with complexities of existing products/features that have to be maintained or migrated it can very easily turn any almost number you care to give either wildly optimistic or wildly conservative, usually experience hedges towards conservative estimates of time required in these cases.
Seniority is having the spine to explain to the boss that their business rules come second to the release of the finished product. And that the only way to get them in the estimation is to remove the estimation from the purview indefinitely
what this article really say: never trust cloud vendors, always think of advantages and disadvantages of the tech which you use in business, you make a smart decision when you as programmer have freedom of choice . I say business logic , also called as core logic of your apps is valuable , everything else doesn't matter to business. Kubernetes what it is ? In simple terms its a distribution system , yes you have heard it right. Why to use Kubernetes? Well if you have a lot of cash and legacy hardware which you want to get rid off, well then maybe it would help you, usually me and my company creqte requirement specs, and go with client trough them, and if not all box checked than we usually say in your case maybe its go better step by step and make small solutions and small prototypes and if you liked the workflow , well then go bigger. Companies often select technology without any big consideration, and thats my friend a problem.
"the exception proves the rule" comes from an old english meaning of 'prove' which is 'to test' as in missile proving grounds. It really means the exception tests the rule.
I just want to let you know that when I read "missile proving grounds", I immediately pictured two missiles in medieval armor rocking themselves vertically across a field chanting about their reasons for fighting this day upon these hallowed grounds.
Chat jippity explained it to me stating that the common use of the phrase is misusing it and a more correct usage would be a statement like “parking allowed on Sundays” is an exception to an overarching rule that shows the existence of said overarching rule (that parking is not allowed on other days). But it also explained that 1) it comes from a Latin phrase that roughly translates to “the exception confirms the rule in cases not excepted” (exceptio probat regulam in casibus non exceptis) and also that, yes, prove isn’t meant in the meaning of “shows evidence for” but in the old meaning of “tests” just like how proving grounds means testing grounds.
7 місяців тому+2
Wikipedia (best source ever) says it's disputed and noone really agrees, but this would certainly make more sense. Although usually when I find words or proverbs like this, I usually stop using them because they aren't useful for communication.
I love using K8s locally with rancher desktop and knowing that the way I deploy locally is fundamentally no different than the way I deploy in prod. Helm has been a game changer for my teams ability to find production issues longer before ever hitting production by using k3s locally
Honestly you are right about recursion. The first time around its like cursed unintuitive iteration. Probably the best way to introduce soneone to it tho, is just picking something like the little schemer or some shit like that where, due to lisps natural tendency to allow for a very intuitive construction and therefore feel for recursion, it sticks with you.
To me understanding recursion was about being able to assume that you already have another function implemented that you know the behavior of. Eg merge sort, start out with a method that sorts with another technique, then implement a naive merge sort that sorts your list using the other sort and merges the results. Realise that you need to handle edge cases (list size 1). Then swap out the other implementation for a recursive call
it depends. it's probably the side effects that make debugging recursion hard. i think that recursion which only builds a return value (an expression) requires less debugging, because it's easier to reason about
@@AG-ur1lj "Changing some value until some condition is met" changing stuff is pretty much a side effect, so yeah that's trickier to reason about but it's not because of recursion. you can make recursion look just like a loop if you pass on to the next call, what you would pass on to the next loop iteration. so it's not necessarily harder to reason about. but i get that syntax wise it would require creating a whole new function (i know that feeling in most languages). in functional programming languages you get away with this, because the syntax for creating a recursive function is about as heavy as writing a loop (only slightly heavier). loops are only a subset of what you can do with recursion. typically it's problems that work with trees that are easier with recursion. but lots of things are trees. like finding an employee's highest level manager by going through the manager's manager etc, or problems like adding 1 to every node in a tree. XML is also an example of a tree. but even in functional programming people try avoid dropping to recursion: most things, can be done with just a function call, because function definitions are values an so can be passed in and returned as values like in JavaScript (a.k.a. Higher Order functions). but also because a function call with missing parameters, results in a new function that expects the missing parameters (a.k.a. Lambda Calculus). so you get a lot of one liners like in this video. side effects (including global mutable state) are typically avoided in functional programming. you still need them to change the outside world, but they are typically confined to only a few parts of your program, and make the rest easier to reason about. bugs can still occur of course in functional programming, but a strict type system and the increased simplicity of the code makes it less likely (the whole program is basically 1 expression instead a statement like in most other Imperative programming languages). TLDR: basically it helps if the language is flexible enough to not have to write out recursion, every time you need it.
@@AG-ur1lj "Changing some value until some condition is met" changing stuff is pretty much a side effect, so yeah that's trickier to reason about but it's not because of recursion. you can make recursion look just like a loop if you pass on to the next call, what you would pass on to the next loop iteration. so it's not necessarily harder to reason about. but i get that syntax wise it would require creating a whole new function (i know that feeling in most languages). in functional programming languages you get away with this, because the syntax for creating a recursive function is about as heavy as writing a loop (only slightly heavier). loops are only a subset of what you can do with recursion. typically it's problems that work with trees that are easier with recursion. but lots of things are trees. like finding an employee's highest level manager by going through the manager's manager etc, or problems like adding 1 to every node in a tree. XML is also an example of a tree. but even in functional programming people try avoid dropping to recursion: most things, can be done with just a function call, because function definitions are values an so can be passed in and returned as values like in JavaScript (aka Higher Order functions). but also because a function call with missing parameters, results in a new function that expects the missing parameters (aka Lambda Calculus). so you get a lot of one liners like in this video. side effects (including global mutable state) are typically avoided in functional programming. you still need them to change the outside world, but they are typically confined to only a few parts of your program, and make the rest easier to reason about. bugs can still occur of course in functional programming, but a strict type system and the increased simplicity of the code makes it less likely (the whole program is basically 1 expression instead a statement like in most other Imperative programming languages). TLDR: basically it helps if the language is flexible enough to not have to write out recursion, every time you need it.
Why would you need it anyaway? Use dynamic programming for simple tasks, such as calculating Fibonacci sequence-type problems, use a FIFO queue for more complex algorithms, like traversing a tree. I struggled with pointers a lot, especially when references, lvalues and rvalues came in.
@@ThePrimeTimeagen Elixir is when everything is outside of kubernetes due to how solid the BEAM is, except your database which lives in its own dedicated Kubernetes cluster because you ended up using Vitess with regional sharding Oh, and if you are using something other than just liveview in the frontend, its probably statically typed. Aka the comfy sandwich stack
Btw looking forward to the networking course. I'm an okay developer who's ventured into many different problems, from parsing to building compilers to authentication and encryption and more. And I'm very interested in learning "how to TCP"
We recently rolled out k8s to our application stack and it works well, and achieves what it was intended to achieve. Pick the right tool for the situation.
fibonnaci sequence + memoized is how I figured out recursion better. but I will say, I have used recursion in the wild for bread crumbing on a website. it was kinda sus.
It's interesting to note that early Unix philosophy was that when faced with a choice - do I make the interface simple (and deal with complexities myself) or make the implementation simple (and throw all complexities at my user), they chose the "simple implementation". It's evident to-this-day with the C language and with UNIX signals (like, why would otherwise there would be this read() API, whose result is either what you've asked for, or "please try again"). It was a conscious decision. And boy have they been successful...
BTW Prime, "proof" used to be a term to describe testing. "The Exception that proves the rule" was an exception that tested the validity of the rule. You can still see this in militaries having "proving grounds". It's literally where they test weapons and technology.
I like Kubernetes and i decided to get really good at it, at the point to get the CKA from Linux foundation. I did it because my old company imposed kubernetes, so I got through all of this crap to know when you DON'T need kubernetes and discourage the use of it if not needed
It's funny to me that he picked Kubernetes as the example because people are more intimidated by it than they should be. Nobody understands Kubernetes of course, but it's pretty easy to get started with. It's just something that you have to actually learn. Learn like take a course and actually study it. You're not going to pick it up just looking at example code like many do with new languages. If there's anything to be intimidated by it's Rust. It's like adding 3 or 4 recursion difficulty level skills to your repertoire. That's something that takes quite a bit of practice to be proficient with.
As someone who's worked with k8s for about 10 years, I still think it's an over engineered piece of software. For my personal projects I just stick with Ansible and bare docker containers to manage my servers. Most people don't need kubernetes.
"Can we be real for a second? Managing servers sucks!" I got instantly offended. I'm realizing I might secretly be a sys admin in a Software Developer's hoodie.
I learned recursion when I was a sophomore in high school like two of my classmates understood it and had to explain it to everyone else. By the end of the class my recursion worked but I didn't understand recursion for like another 4 years after fully tell I recursively traversed a balanced tree.
The exception refines/tests the rule, which in turn validates part or nearly all your previous assumptions about your rule but it doesnt necessarily confirm it. More like It proves its value. Its a well known falacy. Its a heuristic mostly
I guess the missing point it how much it takes to learn in-demand skill and how for how long this demand will stay. Once again, the best skill you might to learn is how to be lucky.
Some of this pushback against complexity just seems like programmers not grasping that other departments have problems too, and in particular, IT people aren't free either. Automating remediation of some of the IT problems can be the difference between needing to hire 6 or 7 guys to staff a 24x7 NOC ASAP or being able to get by on just staffing business hours for a few more years with a little bit of on call work. In a traditional server setup, pushing a bug to production that makes a key service crash every few hours is an emergency, and it's going to *stay* an emergency until there's a patch. With something like k8s, that's likely going to just result in extra churn in pods until it gets patched, and the app is probably stable with just throwing some more replicas at it.
The whole `sysadmin vs developers` and `DevOps` deal is the ops guy cursing the dev guy for breaking prod at 3am. Devs just don't care as long the can deliver faster and close user stories
To prove means to test. Another way of saying an exception proves a rule, is an exception tests a rule. When an exception proves/tests a rule, that means the rule should be reassessed to see if its still accurate in the face of the exception. For example, if the rule is everyone finds recursion hard the first time the are introduced it, and an exception comes up because someone didn't find it hard. That means the rule should be re-evaluated. If everyone should find recursion hard and one person doesn't, that means the rule is wrong (as it requires all people to find it hard). However, as nearly everyone finds recursion difficult the first time, the rule should be revised to *almost everyone finds recursion hard the first time they are introduced to it. Semi-related tangent. People often get the saying the proof is in the pudding wrong, it should be the proof of the pudding is in the eating. This is because the ultimate test (proof) of a pudding's quality is how it tastes when you eat it; if it looked good but tasted bad then it's bad, if it looked bad and tasted good then its good.
I had a client ask me we need kubernetes when they literally had nothing in prod... after I got the message, i stepped outside and pondered at life and came back and said ok. I spent 2 weeks learning it only to find myself back tracking and ended up WORSE. I literally sat there, im like bro this shit is already microserviced... why are they trying to make it more complicated due to architecture. It's extremely tedious to just suddenly switch to it. not to mention the amount of fucking sheer troubleshooting just for 1 basic concept like networking for kubernetes.
The hard part of recursion is that you need to accept that the very function you're writing *already works* for "smaller" inputs. E.g., in Python: def product(nums: List[int]) -> int: return nums[0] * product(nums[1:]) if nums else 1 The invocation products(nums[1:]) has to be assumed to return the product of the tail even as you're making that happen. But if you get over that hurdle, the rest is easy (just multiply that result with the head and return).
Practical note: Python has a stack depth limit, so recursion on an unknown depth is a bad idea. IIRC it's also slower than using a loop. I love recursive code though. So clean.
Proof by induction is the hardest part of recursion. In practice, programmers don’t think about proof by induction, but their intuition ends up being a sort of automatic implementation of proof by induction.
24:30 compiler people mentioned! eh, maybe once you get deep in the industry then you do. it's pretty hard to find new grad compiler roles. but they do pay well. and there are some very high paying compiler jobs. but of course they're in AI...
Even for a normal pay, you need to reach that point that difficulty is high as well. because most of us do what most of us do and we don't risk to be in low-demand jobs. for example I do stupid C++ because it's high-demanded and fortunately high-difficulty (at least hard for me) so with medium skill-level (I don't know how u can measure this) I can get paid to be able to live which I couldn't do if I was working at McDonald or Front-End.
Recursion WAS easy. But also I was self-taught programmer who built first CRUD 1 week after learning my first thing about code, got a job 3 months after learning to code, was promoted 4 times in 2 years to senior and then lead developer.
In my experience most developers don't want to learn anything that remotely touches on infrastructure and high availability. So I'm not surprised his chat doesn't like it. If developers had their way, we'd still be dragging zip files over sftp.
recursion is easy, just learn erlang :) Easier than cycles. Just the problem should be simple to understand. Like "reverse a list". rev([1,2,3]) should return [3,2,1] Code: rev([H|T]) -> rev(T) ++ [H]; rev([]) -> [].
I started with Scheme and recursion might seem easy to grasp once you get the idea of having a base case well defined, but I think the tricky part is identifying where you need recursion in the first place. Some basic problems really scream recursion in their definition, like a factorial or Fibonacci, others are not so obvious to me. Must be a skills issue
3:37 Imo, if you're in a senior spot and you want to take full responsibility for the team's performance, you gotta build tools to do what those third parties are doing internally for your team. That's the only way you'll know where all the bugs came from and have handles to fix all of them. Kubernetes is stable enough to support most of the world's enterprise infrastructures. Build around that, not transient, expensive, platform-locked cloud SAAS is all I'm saying.
Just when I get the urge to share one of your tech video links at work, the funny NSFW commentary pops up and I have to literally force my right pinky from hitting the enter key.
My work environments must be very different from Prime's Netflix career, because I have never in my life encountered any engineer who attempted to "write the best version of the software first try". I much more often encounter people who characterize ever exerting literally any amount of cognitive effort at any point in their work as "premature optimization". I've encountered CTO's who only learned one lesson in their engineering career, early on: "don't over-engineer your solution", but instead of actually learning that lesson they just decided that the phrase itself is license to never learn how to engineer anything at all, and use it to never use their brain ever for even a moment. We aren't trying to prematurely optimize or prematurely scale or prematurely abstract. We are trying to apply the appropriate level of thought and design for the thing we are building at the moment given the known constraints and predicted risks. The appropriate amount of thought to put into design and architecture--especially interfaces--is "some thought", not "absolutely no thought at all". Not having a need to scale or not being sure your interfaces are stable yet doesn't mean you don't have to think anymore, it means incorporating those aspects into the set of considerations you are thinking about for your design. Prototyping is different from hardening, but they both require thought. A prototype "in its ideal state" will not be highly abstracted, because it's intended as a prototype. The fact that it is intended as a prototype is part of evaluating what an "ideal state" would be for the thing. You should still absolutely be seeking an "ideal state" for your prototype, given your context, by literally the definition of the meaning of the word "ideal".
The point about difficulty is a bit misleading. Difficulty acts as a natural filter and limiter of supply. By definition there are fewer people who are capable of solving hard problems. Therefore, the supply is lower and there are chances of getting a great deal. However, there are many more ways to differentiate yourself from others and limit the supply: ability to clearly communicate, organize people, motivate, strategize, etc. Also, limiting the supply by selecting a niche field often means becoming unemployable. Let say, you are a specialist in consensus algorithms. How often do companies roll out their own impl of raft? Or let say you are an expert in database internals. Now your list of potential employers shrunk to maybe 10-20 companies in the world.
24:06 well ackchually, if money = f(difficulty, demand), then this should be a 3D plot, right? With difficulty and demand being x and y axes, and then the z axis represent the money making potential
For me seeing recursion the first time was quite stunning. I thought to myself: "That´s exactly how I think about problems in real world sometimes". I was amazed that this way of thinking had been given a familiar name. I'm not sure if the people who say "it was easy to learn" perhaps knew it beforehand without realizing it.
I don't, but according to job descriptions, every company does.
Almost every technology in my CV.
Lol this is so accurate 😂
Typical frontend developer requirement on LinkedIn. Yes, frontend
My app does, but yeah most probably don’t. When users eventually find my pomodoro app I’ll be able to scale like crazy.
@@Kane0123lmao
Fast-to-ship frameworks are how we get unmaintainable apps nowadays:
1. Slap together a demo of the app.
2. Management: "How quickly can you put this into production?"
3. You: "That cannot be accurately predicted."
4. Management: "I need a clear time-frame."
5. You: "At least four sprints."
6. Management: "Have it ready in two sprints."
Lollll
yes though I am wondering the difference between next js and sveltekit . I am liking sveltekit so far but I don't know.
This is how business really works. 100%. I never use fast to ship frameworks
Management giving two sprints is being so generous
that's me in my current freelancer job
I just love the relationship between Prime and Chat.
It's like an uncle trying to explain something to his hyperactive's nephew. That's just perfect.
Well said.
Do you want to scale? Do you want to scale across n machines? Do you want to scale across n machines and not have to baby node and service health? Then you need an orchestrator. Do you hate, “well it worked on my machine” then you want images, do you want light weight images? Then you need containers. Do you want the ability to easily move between cloud providers and onprem? You want K8s.
k8s work until some architect has the bright idea to use all the toolbox of x provider, I mean, to move between cloud providers.
@@GokuMercenarioSCyes you have to to keep using standard and open source tech or the vendor lock-in can be very hard
This is the best, most concise explanation of k8s I've ever seen
You should get hired as a lead marketer because that was the clearest, most concise and most sellable way of describing K8s.
Why not just containerize your application(s) and deploy on heroku, cloud run, cloud foundry etc? Then when/if you use k8s or nomad then do that when you need to?
9:44 "complex problems sometimes just have complex solutions" - that's called irreducible complexity, and the failed software projects I have seen frequently try to "simplify" irreducible complexity, causing the complexity to be hidden and damaging throughout the whole project.
15:30 that’s not the correct use of “exception that proves the rule”. A common example is a parking sign that says “Free parking on Sundays” which implies that the general rule is no parking.
Man reading the comments and recalling what my old coworkers say, it's like Devs never learn. The answer is almost always "it depends"... There's not a hard yes or no. I would thoroughly dislike working with the majority of you in the comments.
It's tradeoffs all the way down.
It depends ON WHAT, though?
Attorney Tom the software developer: "it depends"
Appreciate your transparency and candidness, hard thing to navigate these days. Keep being you dude, you're rocking the ether
The hard part is when the quick and dirty MVP becomes the foundation for everything you do moving forward and management gets used to quick and dirty fixes and doesnt understand the need for a solid technical foundation.
exactlyyyy
Living this right now
- How many kubernetes do you need?
- YES
I migrate and modernize legacy apps including runtimes, kernels, and compilers. Kubernetes is good for building a platform to reduce the cost of managing a large data center or when aiming for multi-cloud due to scale. Most products need simple container solutions like AWS ECS. As with microservices, most products should end their journey on a modular monolith.
For now, only a few thousand companies across the globe need the K8S, but people have chosen to use it as a nail and hammer.
My job uses k8s. The k8s engineers claim that ecs sucks
Not sure how valid that claim is. The apps we run are simple and personally I think k8s is overkill and you have to spend so much time maintaining the cluster too
@@asdasddas100 I worked for one of the biggest telecoms, which runs most products on AWS ECS. It always depends on the prerequisites, i.e. what "sucks" and what tradeoff you choose.
And I'm sure that Telecom company had an massive infrastructure team that built the whole system of deploying shit to ECS. Whereas you can handle k8s alone.
@@Sadzeih 3 teams, ~15-20 people. Currently they merge similar solutions across globe so probably more now.
By handling k8s alone do you mean ready-to-go products like AWS EKS or Azure AKS?
Maintaining the k8s platform built from scratch is the work of over 50 people. It took 3 years and 500+ people to build a platform on top of k8s in a bank I worked for.
In the case of ready-made k8s, this should be a lower bar, but I have never used such solutions so far.
Yeah. There's basically 0 reason to use non-managed k8s these days. GKE or EKS are great.
I like how you mention tcp and binary protocols. I went into writing an x11 client in Java not knowing much but now it has helped me understand that all clients have some underlying protocol.
"You were born to deploy Kubernetes"
Oh man when you talked raw dogging networks I remembered using netcat back in uni, such a useful tool and so long ago that I made use of it.
"I'd rather get shit done quickly, emphasis shit."
I'd be happy to help migrate you to screen capturing in Wayland. It can be super annoying to get off x11, but it will fix that tearing. Great video!
I can't help but read Wayland and always hear Sean Bean reminding me that we ought to be off to Weyland Priory. (I know its actually Weynon Priory)
@@MagnumCarta I'm in that awkward age where it's hard not to associate him with Boromir because I was just barely too young to know all his great roles in the 90s.
Unless you’re on nvidia lol
In the company I work for, Java+HTMX is eating JS/TS jobs. React and Angular devs are moving to Java/Go/Python. They seem quite happy as well.
I tried HTMX yesterday for the first time. It's pretty good, but I would not know how to structure a large app with it (do I create a new .html file for the stuff I want to have old html swapped with?), or how to persist some client states that I need on the client side. I would probably have to put everything into DB, no idea.
@@SandraWantsCoke All depends what rendering framework you use. Some can use partials (fragments of html in the same .html file).
Using JStachio which is fully compatible with Mustache. It compiles templates at compile time and can have no runtime dependency. It has partials and fragments. For example, the main parts of a dashboard are in their own html file which contains many fragments to enable swapping out html within the larger component. It works extremely well. As the templates are strongly typed and compiled, you see errors in the IDE (intellij), which has been truly awesome.
Sounds like your websites weren’t interactive and shouldn’t have been using react/angular over a static site generator
Not sure why you jumped from php/jquery to react in the first place
Delivered software on 12 test systems last year. Never needed Kubernetes.
That doesnt mean Kubernetes is useless, but there is a tool for every situation and not a tool for every situation.
But when my simple to-do app blows up I’ll be ready.
Networking is something that every dev should know. I can count on one hand the number of devs who actually understand how tcp works I have met in my current work place
Your average dev does not really need to know how tcp works 😮
TCP was a lot of fun to learn about in my mobile and wireless computer networks course in university. Since mobile communication is affected by attenuation, a direct line to the end server is really bad because of TCP's congestion threshold algorithms. One solution is to set up two channels, one between the client and a mobile base-switching station (that takes in traffic from cell towers) and from the mobile base-switching station to the end server. The base-switching station is not affected by attenuation since it often uses direct physical lines between providers. The end server's intermediate nodes in the network never throttle the connection since it remains stable from the base-switching station.
Syn-Ack brother.
Wow, it’s rare for a SDE to know what TCP is?
we learned to write a tcp ip stack in high school, but that was back in 90ies. I am sure things have changed too lol
Kubernetes is not even hard. At first the concepts might be hard to grasp, but after understanding the how and the why, its all just yaml config files and running commands. Diving a little bit deeper and using k8s hooks in your code for developing k8s-native microservices is where things become a little more complex but if you are just getting started, that stuff is far into the future and by then you will be more confident about learning more. Also that stuff is what pays a lot.
It's very simple compared to a lot of other software. Takes about a week to understand the majority of the use cases. Takes years to know the edge cases.
What other softwares?? @@doceddie
My strategy for covering every level of complexity in a project is basically to keep a Kube deployment module in my back pocket at all times for when something gets too big or insecure and the individual Docker containers in my front pocket need managed.
I don't follow. You're doing the work to deploy to a large number of users while hiding it from management? To subvert their decisions I presume.
Recursion is hard as hell, understanding about the stack helps, but that's one step forward and two steps back in terms of complexity.
I wish I was on for this stream but I was on a flight. Kuberneres is so satisfying and you might never truely get done learning it once you get into building your own operators and CRD. I was not at all interested in it until I started using it to solve all infrastructure problems and learning how to operate it. You would love it.
Honestly, K8S is often useful even for small things. The moment you want to avoid downtime during updates, K8S is useful. No, handrolling an adhoc version of a buggy subset of K8S in Ansible is NOT an option.
Even Docker Compose can handle that if you haven't forget about HEALTHCHECK in the image.
@@chupasaurusif you are at the level where you can handle it with docker compose then just running k8s locally and using it instead is not really more effort.
@@mudi2000a Compose has service update policies since forever. Sure it lacks proper networking to run multiple instances of the same service, but that's where service discovery comes handy (wink-wink Consul/Vault). And Ops pain to run it is tiny bit worse than to have a managed k8s cluster, on-premise ones are orders of magnitude worse.
@@chupasaurus I love my home k3s cluster which makes it easy to host my own apps in a cluster and manage ingress etc. just like running the AKS stuff at work more or less...
@@chupasaurus k3s and rke2 have been pretty easy to deploy for me vs docker compose tbh.
As a non-dev who's trying to get back into programming as a hobby, but who mostly listens to content like this channel because I like hearing some of the inside baseball of the tech world, I'm convinced that Kubernetes is a myth. It's just a silly word thrown into technobabble sentences to make simpletons like me feel stupid.
Yes, but at the same time you remove dependency hell by separating environments in application containers and allows for the automation of said containers. The alternative is doing that manually, which can be seen as insanity sometimes
I'm convinced alot of tech becomes the popular standard because they like saying the word.
I think people are confusing two things, one is understanding the concept of recursion, and the second is being able to actually use it and understand what is happening. The first is simple, “function calls itself hur, dur, easy peasy” the second is a mind melting session of doom.
@ThePrimeTime you are awsome. most of the time in this busy life i dont have time to read the tec articles but you in your video make my ife easy. Thankyou.
Laughed out so loud when you threw your head back and said, "How did you just miss the point?" 😂 absolute gold!
Simplest scales BEST. Fastest is the best for short term survival and it builds momentum if you're at all focused on investor relations. Cheapest is often good if you're already revenue positive... take a breath build your war chest and focus on simplifying all the things.
That depends on what the interest rate is. When rates are high investors care a lot about cash burn. As an employee you want the savings to come out of the cloud bill, not out of headcount
13:25 For some reason, recursion made immediate sense to me. I was using it to solve problems effectively in my first couple weeks of coding because it just came to me as a natural solution to some problems. But I absolutely struggled to understand classes in the beginning.
Big fan of networking knowledge. Im more a cloud/platform engineer, and when i get new guys, i get them to focus on rounding that knowledge out first if they haven't already. Its so critical to design, debugging, security, and just tech understand as it underpins everything.
Those who need to deploy and maintain a cluster agree it's complicated. Needed for a monolith? Nope. If you have a set of services (micro, domain, whatever size you want), with supporting software that need LB, Service Discovery, Resilience, etc. Those who use K8s agree, it really makes things easy.
For me Kubernetes solves the headache of the supporting infrastructure (like monitoring, networking, security, storage etc...) maintainability, scalability, HA, and automation for your project application(s)
"Can you deliver the features in reasonable amount of time" - knowing how much you can deliver in a given time span is a clear sign of seniority (= experience)
If you're starting green field and building it all from scratch I sort of agree, but when dealing with complexities of existing products/features that have to be maintained or migrated it can very easily turn any almost number you care to give either wildly optimistic or wildly conservative, usually experience hedges towards conservative estimates of time required in these cases.
Seniority is having the spine to explain to the boss that their business rules come second to the release of the finished product. And that the only way to get them in the estimation is to remove the estimation from the purview indefinitely
what this article really say: never trust cloud vendors, always think of advantages and disadvantages of the tech which you use in business, you make a smart decision when you as programmer have freedom of choice . I say business logic , also called as core logic of your apps is valuable , everything else doesn't matter to business. Kubernetes what it is ? In simple terms its a distribution system , yes you have heard it right. Why to use Kubernetes? Well if you have a lot of cash and legacy hardware which you want to get rid off, well then maybe it would help you, usually me and my company creqte requirement specs, and go with client trough them, and if not all box checked than we usually say in your case maybe its go better step by step and make small solutions and small prototypes and if you liked the workflow , well then go bigger. Companies often select technology without any big consideration, and thats my friend a problem.
Didn't expect a 10 minutes rant about the expression "the exception that proves the rule"
Kubernetes nuts
GOTTEM
"the exception proves the rule" comes from an old english meaning of 'prove' which is 'to test' as in missile proving grounds. It really means the exception tests the rule.
Didn't know that, but do know the saying has been long since debunked as casuistry.
I just want to let you know that when I read "missile proving grounds", I immediately pictured two missiles in medieval armor rocking themselves vertically across a field chanting about their reasons for fighting this day upon these hallowed grounds.
no what the fuck? it comes from Cicero and it means what it says
Chat jippity explained it to me stating that the common use of the phrase is misusing it and a more correct usage would be a statement like “parking allowed on Sundays” is an exception to an overarching rule that shows the existence of said overarching rule (that parking is not allowed on other days). But it also explained that 1) it comes from a Latin phrase that roughly translates to “the exception confirms the rule in cases not excepted” (exceptio probat regulam in casibus non exceptis) and also that, yes, prove isn’t meant in the meaning of “shows evidence for” but in the old meaning of “tests” just like how proving grounds means testing grounds.
Wikipedia (best source ever) says it's disputed and noone really agrees, but this would certainly make more sense. Although usually when I find words or proverbs like this, I usually stop using them because they aren't useful for communication.
I love using K8s locally with rancher desktop and knowing that the way I deploy locally is fundamentally no different than the way I deploy in prod. Helm has been a game changer for my teams ability to find production issues longer before ever hitting production by using k3s locally
Honestly you are right about recursion. The first time around its like cursed unintuitive iteration. Probably the best way to introduce soneone to it tho, is just picking something like the little schemer or some shit like that where, due to lisps natural tendency to allow for a very intuitive construction and therefore feel for recursion, it sticks with you.
@20:20 your a cool guy man guy. Keep guyin man
To me understanding recursion was about being able to assume that you already have another function implemented that you know the behavior of.
Eg merge sort, start out with a method that sorts with another technique, then implement a naive merge sort that sorts your list using the other sort and merges the results. Realise that you need to handle edge cases (list size 1). Then swap out the other implementation for a recursive call
06:00 the pill wore off
The demand-difficulty graph could be 3d and the z-axis is the money you make.
Implementing recursion isn't hard, debugging recursion is hard
Maybe it would be even more appropriate to say that introducing recursion isn’t hard.
it depends. it's probably the side effects that make debugging recursion hard. i think that recursion which only builds a return value (an expression) requires less debugging, because it's easier to reason about
@@AG-ur1lj "Changing some value until some condition is met" changing stuff is pretty much a side effect, so yeah that's trickier to reason about but it's not because of recursion.
you can make recursion look just like a loop if you pass on to the next call, what you would pass on to the next loop iteration. so it's not necessarily harder to reason about.
but i get that syntax wise it would require creating a whole new function (i know that feeling in most languages). in functional programming languages you get away with this, because the syntax for creating a recursive function is about as heavy as writing a loop (only slightly heavier).
loops are only a subset of what you can do with recursion. typically it's problems that work with trees that are easier with recursion. but lots of things are trees. like finding an employee's highest level manager by going through the manager's manager etc, or problems like adding 1 to every node in a tree. XML is also an example of a tree.
but even in functional programming people try avoid dropping to recursion: most things, can be done with just a function call, because function definitions are values an so can be passed in and returned as values like in JavaScript (a.k.a. Higher Order functions). but also because a function call with missing parameters, results in a new function that expects the missing parameters (a.k.a. Lambda Calculus). so you get a lot of one liners like in this video.
side effects (including global mutable state) are typically avoided in functional programming. you still need them to change the outside world, but they are typically confined to only a few parts of your program, and make the rest easier to reason about.
bugs can still occur of course in functional programming, but a strict type system and the increased simplicity of the code makes it less likely (the whole program is basically 1 expression instead a statement like in most other Imperative programming languages).
TLDR: basically it helps if the language is flexible enough to not have to write out recursion, every time you need it.
@@AG-ur1lj "Changing some value until some condition is met" changing stuff is pretty much a side effect, so yeah that's trickier to reason about but it's not because of recursion.
you can make recursion look just like a loop if you pass on to the next call, what you would pass on to the next loop iteration. so it's not necessarily harder to reason about.
but i get that syntax wise it would require creating a whole new function (i know that feeling in most languages). in functional programming languages you get away with this, because the syntax for creating a recursive function is about as heavy as writing a loop (only slightly heavier).
loops are only a subset of what you can do with recursion. typically it's problems that work with trees that are easier with recursion. but lots of things are trees. like finding an employee's highest level manager by going through the manager's manager etc, or problems like adding 1 to every node in a tree. XML is also an example of a tree.
but even in functional programming people try avoid dropping to recursion: most things, can be done with just a function call, because function definitions are values an so can be passed in and returned as values like in JavaScript (aka Higher Order functions). but also because a function call with missing parameters, results in a new function that expects the missing parameters (aka Lambda Calculus). so you get a lot of one liners like in this video.
side effects (including global mutable state) are typically avoided in functional programming. you still need them to change the outside world, but they are typically confined to only a few parts of your program, and make the rest easier to reason about.
bugs can still occur of course in functional programming, but a strict type system and the increased simplicity of the code makes it less likely (the whole program is basically 1 expression instead a statement like in most other Imperative programming languages).
TLDR: basically it helps if the language is flexible enough to not have to write out recursion, every time you need it.
Why would you need it anyaway? Use dynamic programming for simple tasks, such as calculating Fibonacci sequence-type problems, use a FIFO queue for more complex algorithms, like traversing a tree. I struggled with pointers a lot, especially when references, lvalues and rvalues came in.
Prime I’m scared this Go arc has gone too far
It's the ultimate final stop
(Before elixir)
@@ThePrimeTimeagen Elixir is when everything is outside of kubernetes due to how solid the BEAM is, except your database which lives in its own dedicated Kubernetes cluster because you ended up using Vitess with regional sharding
Oh, and if you are using something other than just liveview in the frontend, its probably statically typed. Aka the comfy sandwich stack
Btw looking forward to the networking course. I'm an okay developer who's ventured into many different problems, from parsing to building compilers to authentication and encryption and more. And I'm very interested in learning "how to TCP"
We recently rolled out k8s to our application stack and it works well, and achieves what it was intended to achieve. Pick the right tool for the situation.
@Prime there are two types of people.
1) people who learn recursion
2) people who keep learning recursion.
I’m 2 dawg can’t figure out DP 😢😢😢
The case I remember recursion is a directory listing. Perhaps gathering file names and sizes, and calculating folder sizes.
fibonnaci sequence + memoized is how I figured out recursion better.
but I will say, I have used recursion in the wild for bread crumbing on a website. it was kinda sus.
@@mr.mirror1213bro why is this true. I can’t figure out dp, so I use recursion with memoization on leetcode
Recursion always winds you up reading a Stack Overflow post.
Recursion was easy for me, but I'd already learned loops and the stack. I then learned about the trampoline technique for avoiding stack overflow
I feel click baited 😂. Love your videos but there's no Kubernetes talk in this one haha
Thank you, saved my time x))
Sorry he doesn’t just regurgitate easy info.. you’re very new and don’t understand he’s discussing theory not simple yes no answers to spoon feed you
@@codegate615is this bait or have you got a termite up your ass? You're coming off really aggressive
😂😂
Yes he does and you missed the point of the title. Missed the point seems to be a theme with this video.
It's interesting to note that early Unix philosophy was that when faced with a choice - do I make the interface simple (and deal with complexities myself) or make the implementation simple (and throw all complexities at my user), they chose the "simple implementation". It's evident to-this-day with the C language and with UNIX signals (like, why would otherwise there would be this read() API, whose result is either what you've asked for, or "please try again"). It was a conscious decision. And boy have they been successful...
13:45 Abby. . . Abby who? Abby Normal.
That guy in chat was the exception that proved the rule that the saying "exception that proves the rule" was an easy saying to understand.
I think recursion is a lot easier to grasp if you have already learned it when you were 4 and didn't remember the struggle of learning it.
BTW Prime, "proof" used to be a term to describe testing. "The Exception that proves the rule" was an exception that tested the validity of the rule.
You can still see this in militaries having "proving grounds". It's literally where they test weapons and technology.
"is it an ad if you are selling yourself?"
no that's called something else
Building fast, creates mudd, in which you can't move fast in the future.
17:45 the hardest part about recursion is understanding recursion. For more details, see recursion.
Hehehehe
I like Kubernetes and i decided to get really good at it, at the point to get the CKA from Linux foundation. I did it because my old company imposed kubernetes, so I got through all of this crap to know when you DON'T need kubernetes and discourage the use of it if not needed
Was it worth getting the CKA, I've done the CKAD exam a couple years ago
@@dandogamerIt is worth it. You get to learn the in depth of what does manage a k8s cluster means, so 100% worth it
Prime, you live in the time after Christ. Everything is an A.D.!
14:37 insantly 1 comment and 4 likes, damn are the bots fast.
It's funny to me that he picked Kubernetes as the example because people are more intimidated by it than they should be. Nobody understands Kubernetes of course, but it's pretty easy to get started with. It's just something that you have to actually learn. Learn like take a course and actually study it. You're not going to pick it up just looking at example code like many do with new languages.
If there's anything to be intimidated by it's Rust. It's like adding 3 or 4 recursion difficulty level skills to your repertoire. That's something that takes quite a bit of practice to be proficient with.
As someone who's worked with k8s for about 10 years, I still think it's an over engineered piece of software. For my personal projects I just stick with Ansible and bare docker containers to manage my servers. Most people don't need kubernetes.
this makes sense, but what is hard and in demand? is AI hard? blockchain? quantum computing? How should I measure and pick?
"Can we be real for a second? Managing servers sucks!"
I got instantly offended. I'm realizing I might secretly be a sys admin in a Software Developer's hoodie.
I learned recursion when I was a sophomore in high school like two of my classmates understood it and had to explain it to everyone else. By the end of the class my recursion worked but I didn't understand recursion for like another 4 years after fully tell I recursively traversed a balanced tree.
The exception refines/tests the rule, which in turn validates part or nearly all your previous assumptions about your rule but it doesnt necessarily confirm it. More like It proves its value. Its a well known falacy. Its a heuristic mostly
I guess the missing point it how much it takes to learn in-demand skill and how for how long this demand will stay.
Once again, the best skill you might to learn is how to be lucky.
ArgoCD deploys to K8S for me. All I do is update a version in git for a service (via a PR, so fully approved) and it gets deployed. Very simple.
Man you’re genuinely funny
Some of this pushback against complexity just seems like programmers not grasping that other departments have problems too, and in particular, IT people aren't free either. Automating remediation of some of the IT problems can be the difference between needing to hire 6 or 7 guys to staff a 24x7 NOC ASAP or being able to get by on just staffing business hours for a few more years with a little bit of on call work.
In a traditional server setup, pushing a bug to production that makes a key service crash every few hours is an emergency, and it's going to *stay* an emergency until there's a patch. With something like k8s, that's likely going to just result in extra churn in pods until it gets patched, and the app is probably stable with just throwing some more replicas at it.
The whole `sysadmin vs developers` and `DevOps` deal is the ops guy cursing the dev guy for breaking prod at 3am.
Devs just don't care as long the can deliver faster and close user stories
To prove means to test. Another way of saying an exception proves a rule, is an exception tests a rule. When an exception proves/tests a rule, that means the rule should be reassessed to see if its still accurate in the face of the exception.
For example, if the rule is everyone finds recursion hard the first time the are introduced it, and an exception comes up because someone didn't find it hard. That means the rule should be re-evaluated. If everyone should find recursion hard and one person doesn't, that means the rule is wrong (as it requires all people to find it hard). However, as nearly everyone finds recursion difficult the first time, the rule should be revised to *almost everyone finds recursion hard the first time they are introduced to it.
Semi-related tangent. People often get the saying the proof is in the pudding wrong, it should be the proof of the pudding is in the eating. This is because the ultimate test (proof) of a pudding's quality is how it tastes when you eat it; if it looked good but tasted bad then it's bad, if it looked bad and tasted good then its good.
Highly recommend reading “the little schemer” to learn recursion
I had a client ask me we need kubernetes when they literally had nothing in prod... after I got the message, i stepped outside and pondered at life and came back and said ok.
I spent 2 weeks learning it only to find myself back tracking and ended up WORSE. I literally sat there, im like bro this shit is already microserviced... why are they trying to make it more complicated due to architecture. It's extremely tedious to just suddenly switch to it.
not to mention the amount of fucking sheer troubleshooting just for 1 basic concept like networking for kubernetes.
The hard part of recursion is that you need to accept that the very function you're writing *already works* for "smaller" inputs. E.g., in Python:
def product(nums: List[int]) -> int:
return nums[0] * product(nums[1:]) if nums else 1
The invocation products(nums[1:]) has to be assumed to return the product of the tail even as you're making that happen. But if you get over that hurdle, the rest is easy (just multiply that result with the head and return).
Practical note: Python has a stack depth limit, so recursion on an unknown depth is a bad idea. IIRC it's also slower than using a loop.
I love recursive code though. So clean.
“wishful thinking” as my prof calls it is one of the biggest roadblocks but it’s not the end. there’s many more afterwards.
The hardest part of recursion is The hardest part of recursion
Your whistle scared my cat.
By learning, experiencing complex solutions, you can truly appreciate simpler solutions.
Proof by induction is the hardest part of recursion. In practice, programmers don’t think about proof by induction, but their intuition ends up being a sort of automatic implementation of proof by induction.
24:30 compiler people mentioned!
eh, maybe once you get deep in the industry then you do. it's pretty hard to find new grad compiler roles. but they do pay well. and there are some very high paying compiler jobs. but of course they're in AI...
Even for a normal pay, you need to reach that point that difficulty is high as well. because most of us do what most of us do and we don't risk to be in low-demand jobs.
for example I do stupid C++ because it's high-demanded and fortunately high-difficulty (at least hard for me) so with medium skill-level (I don't know how u can measure this) I can get paid to be able to live which I couldn't do if I was working at McDonald or Front-End.
Recursion WAS easy. But also I was self-taught programmer who built first CRUD 1 week after learning my first thing about code, got a job 3 months after learning to code, was promoted 4 times in 2 years to senior and then lead developer.
1 minute about kubernetes and 15 about generalizations and exceptions
When you try recursion and it's not working the way you want and you start shouting profanity over and over, you're technically re-cursing.
In my experience most developers don't want to learn anything that remotely touches on infrastructure and high availability. So I'm not surprised his chat doesn't like it. If developers had their way, we'd still be dragging zip files over sftp.
recursion is easy, just learn erlang :)
Easier than cycles.
Just the problem should be simple to understand.
Like "reverse a list".
rev([1,2,3]) should return [3,2,1]
Code:
rev([H|T]) -> rev(T) ++ [H];
rev([]) -> [].
change, difficult complex to simply difficult problems that people don't want to do. Or even things people are scared to do and needed.
K8s is not that hard and it’s really cool. I recommend every back end engineer should learn it.
The trick is to view it not as a platform, but as something you build a platform on top of. With a few operators and CRDs the verbosity goes away.
"thats barely an appendage" got me XD
"Just give the number" has some serious "just give me the .exe" energy.
I found kube to be difficult when i first started with containerization a year ago. I think i can probably pull it off now.
I started with Scheme and recursion might seem easy to grasp once you get the idea of having a base case well defined, but I think the tricky part is identifying where you need recursion in the first place. Some basic problems really scream recursion in their definition, like a factorial or Fibonacci, others are not so obvious to me. Must be a skills issue
3:37 Imo, if you're in a senior spot and you want to take full responsibility for the team's performance, you gotta build tools to do what those third parties are doing internally for your team. That's the only way you'll know where all the bugs came from and have handles to fix all of them. Kubernetes is stable enough to support most of the world's enterprise infrastructures. Build around that, not transient, expensive, platform-locked cloud SAAS is all I'm saying.
Just when I get the urge to share one of your tech video links at work, the funny NSFW commentary pops up and I have to literally force my right pinky from hitting the enter key.
Was this an ad?!?! Completely unexpected! 😂
My work environments must be very different from Prime's Netflix career, because I have never in my life encountered any engineer who attempted to "write the best version of the software first try".
I much more often encounter people who characterize ever exerting literally any amount of cognitive effort at any point in their work as "premature optimization".
I've encountered CTO's who only learned one lesson in their engineering career, early on: "don't over-engineer your solution", but instead of actually learning that lesson they just decided that the phrase itself is license to never learn how to engineer anything at all, and use it to never use their brain ever for even a moment.
We aren't trying to prematurely optimize or prematurely scale or prematurely abstract. We are trying to apply the appropriate level of thought and design for the thing we are building at the moment given the known constraints and predicted risks. The appropriate amount of thought to put into design and architecture--especially interfaces--is "some thought", not "absolutely no thought at all".
Not having a need to scale or not being sure your interfaces are stable yet doesn't mean you don't have to think anymore, it means incorporating those aspects into the set of considerations you are thinking about for your design. Prototyping is different from hardening, but they both require thought.
A prototype "in its ideal state" will not be highly abstracted, because it's intended as a prototype. The fact that it is intended as a prototype is part of evaluating what an "ideal state" would be for the thing. You should still absolutely be seeking an "ideal state" for your prototype, given your context, by literally the definition of the meaning of the word "ideal".
The point about difficulty is a bit misleading. Difficulty acts as a natural filter and limiter of supply. By definition there are fewer people who are capable of solving hard problems. Therefore, the supply is lower and there are chances of getting a great deal.
However, there are many more ways to differentiate yourself from others and limit the supply: ability to clearly communicate, organize people, motivate, strategize, etc.
Also, limiting the supply by selecting a niche field often means becoming unemployable. Let say, you are a specialist in consensus algorithms. How often do companies roll out their own impl of raft? Or let say you are an expert in database internals. Now your list of potential employers shrunk to maybe 10-20 companies in the world.
24:06 well ackchually, if money = f(difficulty, demand), then this should be a 3D plot, right? With difficulty and demand being x and y axes, and then the z axis represent the money making potential
For me seeing recursion the first time was quite stunning.
I thought to myself: "That´s exactly how I think about problems in real world sometimes".
I was amazed that this way of thinking had been given a familiar name.
I'm not sure if the people who say "it was easy to learn" perhaps knew it beforehand without realizing it.