There are layers of architecture you use, and then layers abstraction you add all by yourself :
doku over dyson over terraform over kubernetes over digitaloceans
Maybe you can remove two or three layers.
The Cult of Kubernetes
171–180 of 338 posts
Re: The Cult of Kubernetes
#172Earlier quoted context omitted.
You've signed an > 99.9% availability SLA with a customer and a service like Elastic Beanstalk or Heroku isn't sufficient for your needs.
Technically, the cloud in general probably isn't for you, since none of them guarantee more than 3x9's on any of their services.
Yup, meant to say >= 99.9%. Of course most businesses operate more like what Cloudflare makes explicit with it's "100%" SLA. Architect for 3 nines and then just pay the penalty when the 3 nines architecture doesn't hit 4 nines.
Re: The Cult of Kubernetes
#173I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to…
The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do…
> “do what you want, as long as k8s is up, what you run in your pods is your problem, not ours”
Until somebody cyberattacks those pods and steals all personal data of your users because the devs didn't bother to apply security patches. But hey, it's not your problem. You are not responsible for the pods. k8s is still up.
Re: The Cult of Kubernetes
#174Earlier quoted context omitted.
Are there any side effects from preloading pages when hovering over the link?
Probably? I don't have side effects on hyperlinks though.
The "Pages not preloaded" page notes that it excludes addresses with query strings just in case they run some action that you might not want to trigger on hover. You can override the default behavior if you know it's not an issue.
I'm reminded of a post from a few years ago where someone's website had a table of items with [delete] links and would take database actions based on GET requests to those URLs. Who cares? It looks the same to a human browsing it.
And then it got crawled by a search engine which followed all the links to see where they went.
But if you're not doing anything unusual like that, I don't see how prefetching HTML would cause any problems.
Re: The Cult of Kubernetes
#175Earlier quoted context omitted.
Let's make a movement to bridge the fundamental divide between Dev and Ops.. we can call it OpsDev.
You are forgetting Cybersecurity team. Now, that's a fun party. SecOpsDev.
You jest but a dev chucking an insecurable thing over the fence to ops is very common. I will bet that’s how there are so many open MongoDB’s out there.
Re: The Cult of Kubernetes
#176I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…
The best way I can desct K8s is language agnostic J2EE.
Re: The Cult of Kubernetes
#177I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…
Completely valid points, and I agree to all of them. Alas, as other commenters have pointed out, the issue is devs at smaller companies deploying smaller products buying into the idea that they need k8s. I believe that it is the community's duty to educate these devs on what k8s is and when it is needed.
There is a use case where its really the best solution I've seen so far, say you need to cluster a long running stateful service. Its written in C so making it stateless is absolutely non-trivial. So simply load balancing won't work. Docker swarm could work but compared to Kubernetes stateful sets who is actually using docker swarm or other clustering technology for scaling stateful services.
Re: The Cult of Kubernetes
#178These posts about kubernetes are so ridiculous. Installing kubernetes on multiple servers is not difficult, and understanding the components is pretty straightforward if you've ever worked on a distributed system.
If you don't want to be in the "cult", dont use it. Meanwhile i'll be writing service and deployment yamls and avoiding all the proprietary expensive aws bs.
Re: The Cult of Kubernetes
#179I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to…
The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. It is typical for devs. Meanwhile ops have to support every half-arsed tyre-fire technology until the end of time, because a dev wanted to try it once, and now it’s in prod with users relying on it. Kubernetes is in a sense the pushback against that “do…
The company I work for went even further. Ops doesn't support anything in public cloud past the basic connectivity to the corporate network. Everything created in public cloud is the product/dev team's responsibility. Kubernetes? Not their problem.
Re: The Cult of Kubernetes
#180step 1) keeping a service up and running is hard. we have all these issues and it seems like we are struggling to do simple things step 2) only if there was some magic tech that could solve all these issues. and have a cool name. and we could put it on out resumes... drum roll: K8Sssssss step 3) bro. it’s working. i don’t really understand what it’s doing but look at all the containers we are running. and the config.…
Yesterday I caught up with an old friend from where I grew up, for the first time in 12 years. He said many good things about Kubernetes. He's working for a Swiss bank, and managing an ops team. In his case, I think k8s makes sense. Then there's me. Doing remote work, struggling to sort out visas, wishing I could have his kind of life and stability, wondering how it all went wrong. To get a job like his requires expe…
there is more than one type of dave. there is the “jump on it, run it in production and make it the next guy’s problem dave” and there is the “play with it to learn what it is in a safe context/env dave”. you can definitely stay up-to-date with tech without betting the farm on it.
2nd thought is that as an employer you don’t want one trick ponies. You want people that understand the fundamentals and can learn and adapt. i will take a person that has good fundamentals, is curios and constantly learning over a person that knows a technology every day of the week.