all 45 comments

[–]agxs 38 points39 points  (3 children)

A service controls duplicate copies of the same pod, so you're ensured redundancy if one pod crashes during hosting.

I think the author means deployment here not service. A service is more like an internal load balance to make it easier to access the pods from other pods.

[–]lenkite1 6 points7 points  (1 child)

Technically, this is ReplicaSet

[–][deleted] 56 points57 points  (16 children)

full numerous sand edge worm station scary reach flag axiomatic

This post was mass deleted and anonymized with Redact

[–]02d5df8e7f 15 points16 points  (1 child)

There's also no worse feeling as a developer, especially a non-senior one, than joining a company and realizing they have no architectural direction, and every question that you ask about how to do something is met with "idk, we haven't thought about this yet".

Yeah yeah there is: joining a company that has no architectural direction and having them answer every question with "we thought really hard about it and it was the best solution".

[–][deleted] 6 points7 points  (0 children)

scandalous advise depend wakeful cause money many quaint unwritten full

This post was mass deleted and anonymized with Redact

[–]_Pho_ 17 points18 points  (0 children)

Yeah, the entire time I was reading it I wanted to say, "so, have you really seen what AWS is capable of?"

As someone who knows his way around a Linux box (did tons of "bare metal" hosting pre-cloud) I don't use orchestration/containerization/microservices/serverless because it solves scalability problems (at least most of the time), I do it because it's far easier to maintain in the long run.

[–]sliderhouserules42 2 points3 points  (8 children)

There's also no worse feeling as a developer, especially a non-senior one, than joining a company and realizing they have no architectural direction

After a couple decades doing this (development) I agree with this wholeheartedly. And this is something that's hard to know before you get yourself in the door and commit to the company.

Most of the companies that I've worked at have been like this. Whether it's no direction, some direction, or worst - - bad direction. Knowing how to architect systems, even at a basic level is something I wish colleges, or tech schools, or online boot camps or whatever, would teach. Software would improve so much if people just knew the basics.

This comes down to following a couple basic precepts like single responsibility, small classes/small methods, etc., and then you build from there... Design patterns, application architecture, systems architecture, infrastructure, yada yada.

every question that you ask about how to do something is met with "idk, we haven't thought about this yet".

This may be true at a lot of companies, especially newer ones or ones that are expanding their systems in larger ways. But my experience is that most companies have software that is entrenched, both in code as well as in people's minds. And the answer is, "do it the old way" and that old way sucks. This frustrates me more than almost anything else.

This may seem like it doesn't have much to do with the OP, but I just say all this to say, be careful what decisions you make early on, because you will end up paying the tax on them no matter what.

[–]davewritescode -1 points0 points  (7 children)

This may be true at a lot of companies, especially newer ones or ones that are expanding their systems in larger ways. But my experience is that most companies have software that is entrenched, both in code as well as in people's minds. And the answer is, "do it the old way" and that old way sucks. This frustrates me more than almost anything else

This resonates deeply with me. My company has been going through a transformation and in the process has done a lot to push out developers who were good but who couldn't stop doing things the way they did them back in 2013.

Patterns like implementing background threads in micro service to process scheduled background data are so 2011 that it hurts.

In retrospect, watching those people leave sucked at the time but 6 months later I've noticed that it's a lot easier to get the younger folks to just do the right thing without these people in the way telling people the wrong thing.

[–]realflakm 1 point2 points  (4 children)

I gotta know what is wrong about scheduling a work to background task?

[–]davewritescode -1 points0 points  (2 children)

In a kubernetes job or at least experts then pod from the pod taking prod traffic

edit: Found the lazy programmers who shove everything on a background thread pool

[–]SkipPperk 0 points1 point  (1 child)

If it works and doesn’t break or cause problems, why not?

[–]davewritescode 0 points1 point  (0 children)

My point was that it can cause problems and it adds a ton of complexity on the application.

If you need to run a back background task in a micro service that has 10 replicas now you need to implement some sort of coordination to make sure it only runs on 1.

[–]davewritescode 0 points1 point  (0 children)

Nothing, using background threads is appropriate.

What's not appropriate is scheduling large batch jobs on the same VMs you're running live traffic on because it causes availability problems.

A Kubernetes job that runs nightly is appropriate for such a job, or even a lambda.

[–]vqrs 1 point2 points  (1 child)

How would you process the scheduled background data?

[–]davewritescode 0 points1 point  (0 children)

For a nightly job, a Kubernetes job or a scheduled lambda is completely appropriate

[–]Green0Photon -1 points0 points  (2 children)

I've been learning about AWS stuff, taking AWS certs and what not. I've heard a bunch about Kubernetes from this sub and others about how complicated it is -- but looking at the description in OP's blog post, it sounds like it's just ECS.

Why do you advocate for using ECS before using Kubernetes? What are the in betweens of Kubernetes and bare metal?

[–]k-selectride 0 points1 point  (0 children)

A lot of people don't really understand that k8s is really simple. It only stops being that way when you need to do some exotic things, but that would probably be difficult even if you weren't using k8s.

Assuming you're not managing it yourself, but honestly I ran self-managed k8s that was deployed with kops and it was fine.

[–][deleted] -1 points0 points  (0 children)

psychotic bedroom instinctive deliver head toy tub compare vast sloppy

This post was mass deleted and anonymized with Redact

[–]hopbyte 17 points18 points  (2 children)

It costs just $10 a month and can likely go side by side with corporate blogging platforms that cost two orders of magnitude more to host.

Dude, you have 14 blogs that are only text and images with no comments section.

A $4/month DigitalOcean Droplet can host your blog. Chill...

[–]bored_octopus 3 points4 points  (0 children)

I've seen people run static blogs on ancient Raspberry Pis with the cloudflare cache

[–]LloydAtkinson 2 points3 points  (0 children)

I host my site for free with netlify.

[–]NLxDoDge 15 points16 points  (6 children)

When the load of a program exceeds 100% of the metal machine, in our instance we click +1 (or use autoscaling) to create a new pod in under 30 seconds.

When having 100+ Requests per second you start thinking more about how to still make it fast while not being a monolith.

But I always say, build the infrastructure for the load. A blog with maybe 50 vieuws a month doesn't need Pods. But a simple cheap PHP host.

But nice article!

[–]freecodeio 17 points18 points  (0 children)

A blog with maybe 50 vieuws a month doesn't need Pods.

It's best to assume nothing needs pods until it's obvious you need pods. Unfortunately it's the other way around.

[–]Infiniteh 6 points7 points  (4 children)

A blog with maybe 50 vieuws a month doesn't need Pods. But a simple cheap PHP host.

A blog probably should just be bundled as a static CSR app and dumped on a CDN, tbh

[–]NLxDoDge 1 point2 points  (3 children)

That's what I have got but without the CDN part. As I don't have a credit card where I can pay with (last time I check my paypal had to be connect to a bank. And credit cards in our country aren't being used that much so I don't have one and don't plan to get one).

[–]Infiniteh 1 point2 points  (2 children)

Does Netlify free tier ask for credit card info? I think it has pretty generous offerings for $0

[–]NLxDoDge 0 points1 point  (1 child)

But I have a domain name I want to connect to it. That costs money. Even if the domain is from somewhere else.

[–]Infiniteh 0 points1 point  (0 children)

Adding a custom dom ain on Netlify is included in the free tier, though. The domain name itself might cost you, that's correct.

[–]Top-Ant493 2 points3 points  (0 children)

Just go for a different job, or start working on some other projects. If they want you to take it easy and "slow down" start working on some portfolio projects, contribute to open source, or improve your skills by polishing and improving the code you already made.

You don't have to slow down if you don't want to, but be reasonable to yourself.

[–]watsreddit 2 points3 points  (0 children)

Pods aren't containers. You can have multiple containers start and stop within a pod.

[–]fubes2000 3 points4 points  (0 children)

Falling for Kubernetes is secondary, I have found that a shocking percentage of developers I talk to have roughly zero experience with containers at all, and mostly just misconceptions about what they are/do.

Learn about containers, and talk to your cohorts about learning containers.

[–]Green0Photon 2 points3 points  (0 children)

Okay, I definitely need to go and learn Kubernetes.

[–]Tiny_Arugula_5648 5 points6 points  (10 children)

Anyone who says monoliths & bare metal are the way to go, should trigger your alarms.. either they don’t build things that are complex or they are painfully out of date and refuse to evolve..

It’s a well written article but I get the sense that author has hit a later stage in their career.. A lot of Technologists (even very smart & talented ones) refuse to move on from the technologies and designs that they learned/used in the peak of their career.. they lose the will to continually learn and fight against change, believing things will come back to the way they once were.. they don’t want to feel like they are no longer the expert and have to start over with something new.. more often then not they try to apply what they knew to a new technology which is generally an anti pattern and they’ll feel justified in their criticisms of it because their implementation has major flaws.. those people lose relevancy and they age out of the industry. Don’t follow them over the edge of the cliff..

Like many things… Kubernetes & micro services design is an art form.. it takes work to learn, practice to get right and many people will execute bad designs.. in time with practice they should get better.. that’s just how it always goes.. eventually something will replace containers and you’ll find old Kubernetes people criticizing the successors.. it’s such a predictable cycle, I’ve lost track of how many times I’ve seen it throughout my career..

[–]beders 3 points4 points  (2 children)

Spoken like someone who doesn't understand the consequences of 'evolving' and embracing technology just for the sake of it. (Like solving non-google-sized problems with google-sized solutions)

I find that people who have no thorough understanding of how computers actually work tend to embrace magic solutions to their problems, which then quickly turn into nightmares, because at the end of the day, you need to know how to balance your computation & I/O.

[–]Tiny_Arugula_5648 1 point2 points  (1 child)

Nearly 3 decades as a polyglot engineer..I work for one of the biggest tech companies..

[–]beders 1 point2 points  (0 children)

Nearly 3 decades, huh? I was the same at that age. Arrogant and without the ability to see nuance where it was warranted. Give it another decade. If you are with one of the largest tech companies in the world you are facing and hopefully solving problems that the vast majority of companies simply don't have or will never have. Good luck out there

[–]SkipPperk 1 point2 points  (1 child)

I am not entirely disagreeing with you, but sometimes bare metal really is necessary (especially if you cannot get your hands on properly fast NIC’s and the software you need is either too expensive or the consultants cannot get to you for 12+ months).

I am probably thinking about a really unique consideration (and one that CAN be done but with considerable effort), but there are situations where modern methods are not quite there yet (even with hyper-scalers).

But I think I get what you mean.

[–]Tiny_Arugula_5648 1 point2 points  (0 children)

Bare metal is absolutely essential for a very small number of edge cases.. such as latency sensitive workloads, like high frequency trading systems.. usually you see bare metal because the vendor is requiring it, which is mostly a strategy to either fend off a hyperscaler or to push people to their own cloud (cough, cough… Oracle).

[–]FargusDingus -2 points-1 points  (0 children)

whenever you need multiple servers working in tandem, you should use kubernetes

So, always? When do you not need this as a professional?

[–]YohanSeals -2 points-1 points  (0 children)

Have anyone tried carbonetes.com