|
Kubernetes on Windows, on the other hand, is a nuisance. Joining nodes to the cluster works but every K8s add-on I download (the latest being VCP) assumes all nodes are Linux and spreads nonsense around, forcing me to edit the deployments or daemonsets they create to add OS filters.
|
#
¿
Jul 27, 2018 15:28
|
|
|
|
| # ¿ May 3, 2024 17:50 |
|
|
Bhodi posted:if you actually know how to install and manage kuberbetes jesus let me hire you please because 95% of candidates have flubbed the "what network layer provider did you decide on" because they used EKS or equiv and it's all done for you How would you feel about "flannel because it was the first one I tried and it worked?" I don't have k8s on my resume, no sir.
|
|
#
¿
Sep 29, 2018 03:57
|
|
|
Bhodi posted:Thanks, I hate it See, if I showed 12 factor to some of the devs I work with, they'd tell me it was a beautiful dream but this is real world and they can't write apps like that. It's only self-evident if you already get it. Otherwise, you go right ahead sucking up 64gb Java heaps and complaining that the infrastructure team won't give you enough resources.
|
|
#
¿
Sep 29, 2018 06:47
|
|
|
If they have the privileges. Given the described level of disfunction, we can't take that for granted.
|
|
#
¿
Oct 9, 2018 01:10
|
|
|
freeasinbeer posted:But at the same time they all want a year’s retention because it sounds cool. You don't need original live data for that though. You can summarize it in ever-larger batches and use the summary data for capacity planning. You want to know how Aug 2019 compared to Aug 2018, not how some random hour compared to the previous year.
|
|
#
¿
Sep 27, 2019 15:52
|
|
|
Re container chat, my org is still in its infancy in containerizing workloads. I've been advocating Kubernetes because, when I tinkered with Swarm, I couldn't imagine it scaling up to the number of different teams I would hope would eventually be using our container environment. Is there something easier to live with for an on-prem deployment than Kubernetes that can still support multiple siloed teams deploying to it?
|
|
#
¿
Dec 18, 2019 00:54
|
|
|
We use a handful of Puppet modules from the community, but we always try to get a feel for who the author is and what level of commitment they have to the project. If it's some rando who just wanted to solve a problem and walk away, we either fork it ourselves, or steer clear. When it's someone who makes a living as a Puppet consultant, or has been making frequent commits for years and seems to be on top of things, then it's good to go.
|
|
#
¿
Apr 19, 2020 23:15
|
|
|
Why take work home with you?
|
|
#
¿
Oct 31, 2020 23:17
|
|
|
If you have time, and there's a guy in your company who does Puppet, could you get away with asking for 15 minutes of his time to talk about it? Then you could say "I haven't used Puppet, that's another group, but I think it's a neat idea and I've spent time with those guys because I wanted to learn about it." Nobody has to know that you only did so for the interview, and it makes it clear that you're a guy with initiative and drive to learn. I'm the Puppet evangelist in my company and we use it as an intermediate step in a server build. We start with a base image, Puppet manages configuration items in the OS or standard infrastructure tools, and then it gets handed to an application team. It's not intrinsically a task runner, though now there's a separate Puppet Tasks tool that does what it says on the tin. With the enterprise version of Puppet, you can get deeper into server provisioning. I think there's a lot of overlap in this space. Ansible and Puppet have a lot of overlap but there are edge cases where you'd pick one over the other. Puppet (the company) is busy trying to turn Puppet (the tool) into a CI/CD system, but based on what I've done with the free Puppet, if I was using it with Octopus, the idea would be that Puppet configured the server so that it had everything needed for Octopus to deploy to it, and Octopus deployed the application.
|
|
#
¿
Dec 20, 2020 06:02
|
|
|
That's one of the reasons I've become a huge fan of the five whys - you take personal blame out of it. Even if the outage was really and completely someone's fault, even if I caused it because I was the dumbass who didn't realize I was logged into production when I deleted the tables, you take the time to say, "Why did Zorak screw up like that? Was he overworked? Undertrained? Documentation not in place?" Edit: Which in turn means that management should immediately quash anyone who just wants to blame people.
|
|
#
¿
May 27, 2021 22:50
|
|
|
12 rats tied together posted:the question at the heart of devops is "what if we didn't have to do all that stupid bullshit?" which serves the dual function of highlighting all of the stupid bullshit as well as making enemies of people whose entire career is doing stupid bullshit My job is currently readying for war over whether "governance to keep people from blindly including any NPM package they want, directly from public repos into builds" is or is not stupid bullshit. I'm not sure "we probably wouldn't detect NPM attacks in a timely fashion anyway" is as good a defense as they think it is.
|
|
#
¿
Nov 20, 2021 16:09
|
|
|
Newf posted:someCommand is running on MY computer. Er, no it isn't. The difference in the two ways of using ssh is that one gets you an interactive session and one runs a single command and then closes the connection. The command runs on the remote server either way.
|
|
#
¿
Nov 26, 2021 07:41
|
|
|
That sort of interview question worries me, because I can talk conceptually, but I can't white board or write pristine code worth a drat. I usually get the algorithm straight in my head and then trial-and-error the hell out of it.
|
|
#
¿
Jan 27, 2022 04:18
|
|
|
I hate how many of those empty cliches keep getting reused like they mean something. "We're sticking with Oracle because we need their database software, and using them for everything gives us one throat to choke." Have we ever been happy with their support on anything? No? What good is having this alleged one throat to choke if we can't actually put any pressure on their metaphorical windpipe?
|
|
#
¿
Feb 22, 2022 15:58
|
|
|
I started writing scripts in Perl 4. The idea of a human-readable file format that can encode complex data structures and be parsed by almost any language feels vaguely miraculous to be.
|
|
#
¿
Jun 17, 2022 18:34
|
|
|
Every post it's a new low with you.
|
|
#
¿
Jul 29, 2022 06:11
|
|
|
"I think applying for this director position demonstrates that I have the will to power. Thinking that a director has meaningful power demonstrates my Kafkaesque understanding."
|
|
#
¿
Aug 25, 2022 01:13
|
|
|
Vulture Culture posted:I hate to say this because I absolutely would not want someone doing this to me, but on the issue of follow-ups, you kind of have to act you're the TAM's boss, or at least like they're a consultant working on your dime (which they basically are). Sometimes stuff happens, but if they miss a committed follow-up, nudge them and if it takes more than one reminder, nudge their boss. Have calls above their level about how you're not happy with the level of engagement. As a nuclear option, your TAM is not set in stone and you can push to get a new one assigned (this obviously has career implications for your TAM, so don't do this lightly). Came here to say this. I agree with "don't do this lightly" but sometimes it's the only answer. We had a VMware TAM at the beginning of the year who did nothing but tell us to open support tickets, tell us that VMware support was good and fine and we just weren't working with them properly, and ask us when we were going to be done with our ESXi 7 upgrades. It took a couple months but we booted him off our account, and while the new guy isn't the equal of our 2019 TAM, he's at least useful.
|
|
#
¿
Dec 15, 2022 20:16
|
|
|
FISHMANPET posted:*Laughs in higher Ed/Shibboleth* Look, after IFS went nowhere, Umich really needed something that would fetch some mind share. Let them have something.
|
|
#
¿
Feb 2, 2023 03:32
|
|
|
Quebec Bagnet posted:Slows down attackers to give you time to prepare a defense, much like irregular stairs in a medieval castle You're saying I have stairs in my git repo?
|
|
#
¿
Jun 21, 2023 19:17
|
|
|
We're still rolling out Puppet and I am acutely aware that I am deploying 2017's solution in 2023. The problem is we're still supporting 2015's architecture so, yeah, this feels like an improvement, even though specific pockets of development are running genuinely modern apps in the cloud. ${job} is a land of contrasts.
|
|
#
¿
Jun 28, 2023 16:29
|
|
|
I came to Puppet late, but having looked at docs covering earlier versions, I don't mind not having to mastermind an enterprise Puppet deployment in 2008.
|
|
#
¿
Jun 29, 2023 16:43
|
|
|
Docjowles posted:Today on "I thought you assholes said the cloud would be better", devs are complaining that the latency between the parts of the preprod environment that we've migrated to AWS and those that have not yet is unacceptable and their apps and tests are constantly timing out. Our latency to us-east-1 is ~14ms and short of changing the laws of physics I can't do much here buddy. I'm sorry you no longer enjoy sub-millisecond latency between boxes in the same rack but that's kind of what we signed up for here. 14ms is still pretty fast! I've seen this going past me, too. My team isn't officially responsible but it's amazing to watch people complain about how their new cloud systems don't perform, and then they post a flow diagram showing that a process requiring 5 calls is now basically alternating between on-prem and cloud with each call, so yeah, you're picking up a fair degree of latency there, duh.
|
|
#
¿
Jul 18, 2023 18:55
|
|
|
I'm a Puppet user and once I wrapped my head around it, I got to like it well enough. Enterprise at scale was indeed expensive - something north of $100 a node for a few, maybe $75/per at scale, and that was a few years back. At that time, Ansible tower was in the same ballpark. Puppet's owned by Perforce, Ansible by RedHat/IBM, so while Ansible probably has a more secure future, I wouldn't feel great about paying for either.
|
|
#
¿
Dec 13, 2023 05:39
|
|
|
Vulture Culture posted:The problem with most of the managed services in most major clouds is that aside from opaque repackaging of other services, most of what they give you aren't fully-baked products. They're building blocks with few opinions, which are great when you're trying to construct business processes, and absolutely awful when you're trying to build humane user experiences for your developers. The most valuable products are still the things that could have come from a 2004-era Google paper: S3, DynamoDB, anything you build for intentionally that lets you forget about scale. Once you get cross-cutting concerns like backup and data retention involved, every other product manages to somehow make scaling harder just by existing. This explains a lot about our ROSA experience, which seems to require handholding for anything but the most trivial operations.
|
|
#
¿
Jan 26, 2024 18:17
|
|
|
I'm working on giving my team members better goals in our performance management system this year, and one of the themes I hit on is that I want to recognize the people who are out there learning new stuff, documenting it, and helping us improve. If you just want to show up and do what you're told, that's not awful, you aren't going to be on a PIP or some dumb thing like that, but you should expect your year-end review to reflect that other coworkers are doing more and/or better than you are.
|
|
#
¿
Feb 28, 2024 21:49
|
|
|
Warbird posted:Question for the room: I distinctly remember “never ever ever run a database in a container” being common wisdom back in the mid 20teens. That’s clearly no longer a problem and I find myself wondering if that was ever an actual issue and things have changed, or it was a misunderstanding of the tech/an old engineer’s tale. What’s the word there? I instinctively doubt all "never ever evers" because there are niche use cases for all sorts of stuff. I know I was pushing hard against DBs in containers when the DBAs I support first asked about it because I correctly doubted that they understood the container stack. They just thought containers were a new type of VM. I'd ask what persistent storage model they had in mind and how it would interact with our infrastructure, and they'd be surprised they were even expected to know the answer to that question, because they didn't manage storage. Even back then, though, there were always people reporting success in specific use cases.
|
|
#
¿
Mar 1, 2024 16:49
|
|
|
Our security managers have been decent, and are happy to help me gang-tackle developers and application engineers who ignore best (or even third -best) security practice. Some of our security engineers are just wretched, though. One keeps sending out vulnerability reports with boilerplate text saying "please find vulnerability details and affected servers attached." He never attaches the list. I have to ask every time. Sigh.
|
|
#
¿
Mar 4, 2024 19:26
|
|
|
Gucci Loafers posted:It feels so dirty. Never feel bad about playing the game. These companies would lay you off without hesitation if it helped their bottom line. You owe them no more consideration than that. It's a wide open field until you start work at the new job. (I used to say until you get a signed offer letter, but I've heard tell of signed offers being withdrawn by the hiring company, so screw 'em.)
|
|
#
¿
Apr 1, 2024 18:52
|
|
|
|
| # ¿ May 3, 2024 17:50 |
|
|
We have dedicated architects and they have exactly this problem. With no skin in the game, and not being attached to a specific dev team, they can't effectively control the direction things go in, they can just help or hinder deployment once the app is mostly written. I don't think it's been a particularly successful organization.
|
|
#
¿
Apr 2, 2024 05:14
|
|