171–178 of 178 posts
Earlier quoted context omitted.
You might not make it your day job but you should definitely understand the fundamentals of how your whole stack works. Everything from transistors to eyeballs.
Your original suggestion didn’t sound didactic in nature. I did enough deploying Perl apps that way to consider it a huge waste of time. No thanks!
Earlier quoted context omitted.
You can manage and reason about ~2000+ servers without Kubernetes, even with a relatively small team, say about 100 - 150, depending on what kind of business you're in. I'd recommend either Puppet, Ansible (with AWX) and/or Ubuntu Landscape (assuming that your in the Ubuntu ecosystem). Kubernetes is for rather special case environments. I am coming around to the idea of using Kubernetes more, but I still think that i…
> You can manage and reason about ~2000+ servers without Kubernetes, even with a relatively small team, say about 100 - 150 Oh wow, so uh... I'm managing around 1000 nodes over 6 clusters, alone. There's others able to handle things when I'm not around or on leave and meticulously updated docs for them to do so but in general am the only one touching our infra. I also do dev work the other half of the week for our co…
Hehe, you lack skill in empire building. You know "leading a team of highly motivated team of 50+ devops engineers". The kind of talent that postpones patching until you are back from vacation. Or deploying config change that needs at least two rollbacks before finally going in.
Earlier quoted context omitted.
I like devops. It means you get to get ahead of all the issues that you could potentially find in cybersecurity. Sure it's complicated, but at least you'll never be bored. I think the hardest part is that you always feel like you don't have enough time to do everything you need to.
DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business (perpetually understaffed) and as “last minute complicated requests that sound simple enough” and “oops our requirements changed” dumping grounds for engineering teams. Plus, the ops side has a lot of challenges that can really be a different beast compared to the applica…
That’s why we aim to call it DevOps, so that you can take all that into account from the start of the project?
Earlier quoted context omitted.
But envoy configs are unreadable abominations, why would you choose it? How did you even learn how to configure it? It's documentation is so confusing.
Envoy is designed with the intent that a machine is dynamically reconfiguring it at runtime. It is not designed to be configured directly by a human. The tradeoff is that you can do truly zero downtime configuration changes. Granted, this is important to a very small number of companies, but if it's important to you, Envoy is great.
Where would one take a machine to dynamically reconfigure envoy? How would one configure it?
> The tradeoff is that you can do truly zero downtime configuration changes.
So... just like with nginx?
Earlier quoted context omitted.
DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business (perpetually understaffed) and as “last minute complicated requests that sound simple enough” and “oops our requirements changed” dumping grounds for engineering teams. Plus, the ops side has a lot of challenges that can really be a different beast compared to the applica…
> DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business This is one of those explanations that sounds reasonable but when you actually experience it you realize the explanation makes no sense. If you're "running behind of technical debt" you'll always feel understaffed no matter how much staffing you have. And adding more st…
> no matter how much staffing you have
That’s not what I said. I said that there tends to be not enough staff. Businesses are more willing to hire software engineers (shipping features = revenue) than hiring DevOps people (keeping the lights on).
> tech debt doesn’t really exist.
Well that’s news to me. I’m pretty sure it exists. It has an entire Wikipedia article, and that article doesn’t agree with your definition.
And yes, more staff would help. Hiring me literally helped my organization fix its lack of monitoring and alerting because nobody had time to address the problem during my team’s day to day responsibilities.
Your assertion that it’s not management’s fault is absurd. Management is by definition the bearer if ultimate responsibility. Every problem in any business is something where the buck stops at management.
If I ship something with long term problems because management told me to work faster and meet the deadline, that is directly management’s fault. Even me shipping something bad on my own volition is management‘s fault indirectly: they hired the wrong talent (me), or maybe they assigned me to the wrong project where my expertise wasn’t good enough, or they misjudged risks and didn’t leave enough contingency buffer or didn’t make a plan for what to do if we fail.
The way businesses view humans are as machine-like resources of labor (Human Resources), they don’t view you as an individual with emotions and thoughts and feelings. When they hire someone they have quantitative measures surrounding that person: how likely are they to perform well, burn out and quit, steal from the company, get run over by a bus, etc. The corporate system actually dictates that management is responsible for the way it arranges and commands its human machines.
Earlier quoted context omitted.
DevOps teams are always running slightly behind and rarely getting ahead of technical debt because they are treated as cost centers by the business (perpetually understaffed) and as “last minute complicated requests that sound simple enough” and “oops our requirements changed” dumping grounds for engineering teams. Plus, the ops side has a lot of challenges that can really be a different beast compared to the applica…
> Plus, the ops side has a lot of challenges that can really be a different beast compared to the application side. That’s why we aim to call it DevOps, so that you can take all that into account from the start of the project?
Almost every company works with the “throw stuff over the wall to DevOps” mentality. The word “DevOps” is meaningless.
Earlier quoted context omitted.
Envoy is designed with the intent that a machine is dynamically reconfiguring it at runtime. It is not designed to be configured directly by a human. The tradeoff is that you can do truly zero downtime configuration changes. Granted, this is important to a very small number of companies, but if it's important to you, Envoy is great.
This makes no sense. Where would one take a machine to dynamically reconfigure envoy? How would one configure it? > The tradeoff is that you can do truly zero downtime configuration changes. So... just like with nginx?
When I worked in this area a while back - Ingess Controllers and Ingress / a custom type we made because Ingress was too limited.
We didn't use nginx because it would drop requests and mess up connections during certain config reloads. With a custom controller, Envoy never dropped a connection or request we didn't explicitly tell it to (excepting network reliability of course). For context a slow day for us was many billions of requests.
When I was choosing ingress controller few years ago, I think it was the most popular ingress controller by far, according to various polls. As I didn't have any specific requirements, I chose it and it worked for me. Over years I've used few proprietary annotations, so migrating away going to be a bit of pain. Not awesome news.