4 ms·

> developers are forced to borrow time from writing code and redirect it towards managing the issues associated with highly complex, multi-factor developer tool

> developers are forced to borrow time from writing code and redirect it towards managing the issues associated with highly complex, multi-factor developer toolchains held together in places by duct tape and baling wire. This, then, is the developer experience gap. The same market that offers developers any infrastructure primitive they could possibly want is simultaneously telling them that piecing them together is a developer’s problem The past had a solution for this: the system administrator. He could design and implement robust and simple systems to provide infrastructure and tooling for developers to deploy their code. But this isn't "cool" any more. You have to use tens of self-service bleeding edge (read unproven and unstable) concept tools bought from the players who have the most money to invest in tech conferences, blog posts, astroturfing, evangelists, etc, and pretty much nothing left to pay their own developers. For example try telling people they would be better off with their code being packaged and delivered by a Debian package instead of a container image - see how fast they consider you a crazy preacher from the past.

Uberphallus 6y ago
> For example try telling people they would be better off with their code being packaged and delivered by a Debian package instead of a container image - see how fast they consider you a crazy preacher from the past. Where I work we create Debian packages, then prepare an image installing it from the Dockerfile. In our defense, our test systems are physical, our CI/CD chain is containerized, and production will move from physical to containers soon.
chillfox 6y ago
System administrators are still around outside of Silicon Valley. And we still do that thing of managing servers, build systems, and assisting developers get their code from git to production (usually by setting up an automated process).
jcelerier 6y ago
How do Debian packages isolate ? Can you make sure that e.g. app1 won't replace app2's config file with its own (if, say, both app1 and app2 need ImageMagick with different policies) ?
- disgruntledphd2 6y ago
  I really do wonder how often this happens. Like, I know that Python is particularly prone to this, and if you have multiple languages needing C/C++ based libraries then I guess this is a concern. But how many people have experienced this to an extent that containerisation seems like the right solution most of the time?
  - AnHonestComment 6y ago
    Why wouldn’t containerization be the right solution? A “container” is an archive (eg, tarballs) of the contents, a hash chain of the construction, and some config data about cgroups and namespaces to run it with. Turn off the parts you don’t want — I usually turn off virtualized networking, for instance. It’s a more lightweight package that doesn’t have versioning problems and doesn’t require crazy installation scripts — what benefit is traditional Debian packaging supposed to have?
  - closeparen 6y ago
    I’m convinced that the real reason is all the cruft in packaging systems and opinions among their domain experts that are specific to the needs of distro maintainers. “Docker Build” could produce DEB packages as a target and they would be fine 99% of the time.
    - rleigh 6y ago
      They wouldn't. There's far more to a Debian package than simply aggregating a bunch of files into a container and calling it a day. Making sure it's all correctly split into runtime, library, development, documentation, debug etc. parts, and ensuring that each part has the correct dependencies upon other packages in the system is a much more involved task. But it's this part that adds most of the value compared with simply building from source. Making a "package" is easy. But the real point of packaging is integration with the wider system, and that part requires actual effort. Docker doesn't even attempt it. Docker is easy and convenient primarily because it pretends that problem doesn't even exist. It does the easy 10% of the job while ignoring the 90% of the work that takes the time and effort.
devonkim 6y ago
Sysadmins were supposed to “go away” after transitioning to the cloud. Instead, what I’ve observed is that so many years ago companies hired more and more developers that wound up trying to solve problems sysadmins long ago solved with little attention from developers that many are reinventing or rediscovering. This is one reason how we wound up with so many management systems like Puppet, Chef, Ansible, etc. But the market for sysadmins is completely soaked in corporate IT professionals whom really only have maybe 20% skill coverage with what smaller tech companies want or need. When it comes to delivering software, companies have found they want / need strong sysadmin knowledge domain with a strong software development background - this is the rise of the “devops” and SRE disciplines. What really bums me out is that long ago the term sysadmin applied to software developers as well - people on Unix systems that wrote C and other systems code that used bash to string together software fast. So in a lot of senses, the creation of bash is a form of the developer-sysadmin construct done quite well. But today, with our fractured, mercurial software ecosystem we see so many competing tools that largely do things 90%+ the same way in practice for hardly any real advantage over each other. Every option can easily manage hundreds of machines in some odd seconds or a few minutes, after all. But there’s a cultural problem that’s become a bifurcation into engineer castes over time. Go to conferences, social networks, and meet-ups for developers vs sysadmins - the tone and tenor of topics is completely different. Developer conferences have a smattering of deeply concerned talks but a majority are bright, cheery, and exploratory in tone and the side conversations match up. Sysadmins oftentimes stuck in cost centers are as a rule grumpy and even belligerent, and the side conversations remind me more of the hallways of a VA hospital than Bell Labs.

Uberphallus 6y ago

> For example try telling people they would be better off with their code being packaged and delivered by a Debian package instead of a container image - see how fast they consider you a crazy preacher from the past. Where I work we create Debian packages, then prepare an image installing it from the Dockerfile. In our defense, our test systems are physical, our CI/CD chain is containerized, and production will move from physical to containers soon.

chillfox 6y ago

System administrators are still around outside of Silicon Valley. And we still do that thing of managing servers, build systems, and assisting developers get their code from git to production (usually by setting up an automated process).

jcelerier 6y ago

How do Debian packages isolate ? Can you make sure that e.g. app1 won't replace app2's config file with its own (if, say, both app1 and app2 need ImageMagick with different policies) ?

disgruntledphd2 6y ago
I really do wonder how often this happens. Like, I know that Python is particularly prone to this, and if you have multiple languages needing C/C++ based libraries then I guess this is a concern. But how many people have experienced this to an extent that containerisation seems like the right solution most of the time?
- AnHonestComment 6y ago
  Why wouldn’t containerization be the right solution? A “container” is an archive (eg, tarballs) of the contents, a hash chain of the construction, and some config data about cgroups and namespaces to run it with. Turn off the parts you don’t want — I usually turn off virtualized networking, for instance. It’s a more lightweight package that doesn’t have versioning problems and doesn’t require crazy installation scripts — what benefit is traditional Debian packaging supposed to have?
- closeparen 6y ago
  I’m convinced that the real reason is all the cruft in packaging systems and opinions among their domain experts that are specific to the needs of distro maintainers. “Docker Build” could produce DEB packages as a target and they would be fine 99% of the time.
  - rleigh 6y ago
    They wouldn't. There's far more to a Debian package than simply aggregating a bunch of files into a container and calling it a day. Making sure it's all correctly split into runtime, library, development, documentation, debug etc. parts, and ensuring that each part has the correct dependencies upon other packages in the system is a much more involved task. But it's this part that adds most of the value compared with simply building from source. Making a "package" is easy. But the real point of packaging is integration with the wider system, and that part requires actual effort. Docker doesn't even attempt it. Docker is easy and convenient primarily because it pretends that problem doesn't even exist. It does the easy 10% of the job while ignoring the 90% of the work that takes the time and effort.

devonkim 6y ago

Sysadmins were supposed to “go away” after transitioning to the cloud. Instead, what I’ve observed is that so many years ago companies hired more and more developers that wound up trying to solve problems sysadmins long ago solved with little attention from developers that many are reinventing or rediscovering. This is one reason how we wound up with so many management systems like Puppet, Chef, Ansible, etc. But the market for sysadmins is completely soaked in corporate IT professionals whom really only have maybe 20% skill coverage with what smaller tech companies want or need. When it comes to delivering software, companies have found they want / need strong sysadmin knowledge domain with a strong software development background - this is the rise of the “devops” and SRE disciplines. What really bums me out is that long ago the term sysadmin applied to software developers as well - people on Unix systems that wrote C and other systems code that used bash to string together software fast. So in a lot of senses, the creation of bash is a form of the developer-sysadmin construct done quite well. But today, with our fractured, mercurial software ecosystem we see so many competing tools that largely do things 90%+ the same way in practice for hardly any real advantage over each other. Every option can easily manage hundreds of machines in some odd seconds or a few minutes, after all. But there’s a cultural problem that’s become a bifurcation into engineer castes over time. Go to conferences, social networks, and meet-ups for developers vs sysadmins - the tone and tenor of topics is completely different. Developer conferences have a smattering of deeply concerned talks but a majority are bright, cheery, and exploratory in tone and the side conversations match up. Sysadmins oftentimes stuck in cost centers are as a rule grumpy and even belligerent, and the side conversations remind me more of the hallways of a VA hospital than Bell Labs.