[inopinatus]

Unfortunately this leads to language binaries & libs being distributed by the developer with the application. Sysadmins then install the whole massive hairball in /opt as a single unit and never update it until the developer provides a point release. Which never happens because the dev team has been disbanded, they're all on new projects now.

If you don't think that's a problem in the real world, you ain't seen 95% of enterprise IT.

(This problem not confined to Ruby)

[hosh]

We're in the age of technologies like Chef, Puppet, and virtual machines. Said hairballs are described by code, and versionable.

And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.

[inopinatus]

I appreciate your butt-kicking energy! However, I must note: configuration idempotency tools that regard infrastructure as code are not new. I think you'll find that the inadequacy of cfengine, puppet & chef to the task is why they are not universally used. Devops is a very young discipline and these tools are the stepping stones toward a more coherent model of component deployment. I'm not saying they're crap, just that we can and will do better. Chef is probably the best effort so far, although I am unconvinced by the client/server variant.

In particular, none of them yet solve the problems of client application deployment. They are also implicated in the VM sprawl many cloud users experience.

Finally, they have convinced some developers that systems administration is something they can do themselves. Experience consistently proves this wrong; I've lost count of developers out of their depth, asking for rescue from suboptimal deployment decisions and needing rescuing. Either that or they discover a penchant for systems admin as well, and thus become devops people (this is what happened to me). I've seen the latter happen most often in the ISP world; perhaps network engineers have that mindset.

Personally I foresee a stronger role for packages as an output from continuous integration pipelines (another young discipline).

[hosh]

Ah, so if by client you mean end-user devices ... yeah. I am not sure Chef or Puppet solves it. On the other hand, my world has been focused on web and mobile apps, so end-user apps tend to use browsers that are already on the end-user device.

I'm not sure what you mean by clients though and how that relates to VM sprawl.

It's true that some developers are convinced that sys admin is something they can do themselves. However, it goes the other way around too, that sys admins think they know what is best for the app. It's better all around if devs actually gain an understanding at the issues with sys admin, and sys admins get some development skills.

As far as the server-side goes, once nice thing about using something like Chef or Puppet is that you can create a miniature version of the production environment on the developer's laptop. You won't run into the same kind of issues when you are scaling out, but you can at least make sure that you are running everything rather than always developing things in isolation.

[atsaloli]

Can you tell us more about this problem of client application deployment, please? I work with CFEngine quite a bit and it can deploy server and client components. What issues are you running into?