101–110 of 248 posts
Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.
Earlier quoted context omitted.
To be fair, arrogance seems to be quite popular in systemd as well
Sure, but saying "I won't merge this because I don't want my software to be compatible" seems to be strange. Would you not accept say changes to your Makefile to support BSD or Windows or Linux?
Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.
After you accept that all these tools were built for overworked and stressed people who don't really have the time to learn things deeply, it becomes much easier. In fact, most of the programming ecosystem and systems administration works like this. Try focusing on "what do I want?", get a superficial understanding on how the tool works, then try to apply that knowledge to your search engine query. For example: Say y…
Earlier quoted context omitted.
Sure, but saying "I won't merge this because I don't want my software to be compatible" seems to be strange. Would you not accept say changes to your Makefile to support BSD or Windows or Linux?
It depends. Trying to avoid being compatible with Systemd would be strange. Simply not valuing at all -- if it works, that's okay, but you won't add any Systemd-specific code -- is a different thing.
If it is some obscure compatibility we are talking about, I can understand it. If it is a defacto or official standard, then no. Regardless of whether I use Systemd or not (my primary OS uses launchd...), its usage in Linux distributions is currently widespread.
Not wanting to develop compatibility yourself, I can understand. No discussion about it.
Not wanting to include compatibility PRs is a recipe for hostility, and ultimately, a fork. There's a nuance here that it could lead to a lead dev importing PRs for software they don't use or understand but other than that, it seems the way to go if you want an inclusive and gentle environment.
Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.
Sure. None of the things you mentioned are DevOps. DevOps is two things: 1. Applying the methods of modern software development (version control, automation, DSLs...) to operations (provisioning, config, deployment, monitoring, backups...). 2. Reducing silo barriers between devs and ops groups so that everyone is working together as a team, rather than blaming each other for poor communication and the resulting messe…
When you boil the Cloud, DevOps, CloudOps, SecOps, *Ops, CI, CD, Containers, VMs, and all the other technologies we've devised over the past ten years, you always end up at the basic building blocks.
You eventually come to the conclusion that all we're really doing with all these new tools is adding software layers on top of those building blocks in an attempt to make them easier and faster to consume.
And how have we done overall?
Not bad, if you ask me. Some solutions are overkill for most people (K8s is an example of over kill for a start up and even an SME.) But Terraform, Ansible and GitLab (CI) are something I'm currently developing a highly opinionated video training course on because I believe they strike the right balance of improving on prior experiences without taking the absolute piss.
Earlier quoted context omitted.
For me containerization was always about deterministic environments and ease of deployment instead of performance and clustering. But even with these advantages I am currently not using any solution for that. For cloud services this is probably a good idea, even for users to a degree if the provider doesn't already give you a fitting box. But otherwise it is not a must have in my opinion. Maybe that is a mistake and…
> For me containerization was always about deterministic environments and ease of deployment instead of performance and clusterin This! I come from the embedded world with a bit of webui and having yocto for the embedded reproducibility and docker for the infrastructure, I am so happy. No more uncertainty when moving to another machine or upgrading my DEV machine. Nope Everything running right everywhere. Some script…
Can anyone offer a good guide to DevOps for people who don't directly use these tools but work with engineers who do and would like to learn more? The whole ecosystem of servers, cloud infrastructure (and all of the different offerings there), Docker, Kubernetes, CICD tools etc is a bit overwhelming to get into.
Would you be willing to have a quick chat? I'd pay for your time, of course. I need to gather feed back from people looking to develop their skills into the CloudOps space and understand what it is they're looking for.
Earlier quoted context omitted.
After you accept that all these tools were built for overworked and stressed people who don't really have the time to learn things deeply, it becomes much easier. In fact, most of the programming ecosystem and systems administration works like this. Try focusing on "what do I want?", get a superficial understanding on how the tool works, then try to apply that knowledge to your search engine query. For example: Say y…
This is how you end up with low-staying-value understanding built on shaky, fragile footing.
For a very long time there was a gaping security hole in Docker: anyone who could run a container could mount anything on the underlying host as root. This says to me that Docker (the company) don’t really consider any use cases beyond “fooling around on a personal laptop”. Meanwhile other container projects took seriously from day 1 that they would need to run in production. Docker (the company) certainly helped to…
Earlier quoted context omitted.
After you accept that all these tools were built for overworked and stressed people who don't really have the time to learn things deeply, it becomes much easier. In fact, most of the programming ecosystem and systems administration works like this. Try focusing on "what do I want?", get a superficial understanding on how the tool works, then try to apply that knowledge to your search engine query. For example: Say y…
This is how you end up with low-staying-value understanding built on shaky, fragile footing.
"I call it 'modern software development practices!'"