Hacker News new | ask | show | jobs
by agentultra 4205 days ago
It happens every time.

As soon as you hit an environment where there are > 20 people using the system you need a plethora of tools and systems involved which remove the terms, "simple" and "lightweight," from the specification.

Access control, authentication, auditing, operations... you can't eschew complexity by ignoring it.

I've learned this time and again. If you start out with "simple" and "lightweight" you're going to hit that "enterprise wall" and really pay the price of not considering those requirements up-front. The price of either re-writes or layers of out-of-band processes and tools for orchestrating light-weight systems that were not designed to be composed in such a way. It's quite painful and terrifyingly complicated.

Update: In the case of Docker/Rocket... I think these are just early iterations. I wouldn't be surprised if even Rocket becomes bloated as they realize they cannot design for simplicity when complexity is a requirement.

3 comments

The difference is that some technologies use encapsulation and abstraction to manage complexity, while others vomit megabytes of configuration on the floor.

Of course Docker in an enterprise will never be as simple as running a Rails app on your Macbook, but it provides an encapsulation primitive that looks as powerful for deployment as object orientation and functional programming were for development.

SICP lecture #1: we manage complexity through means of abstraction and means of combination. Docker is a means of abstraction, and it leaks less than the others we have so far (Chef cookbooks, etc.) We haven't quite figured out what the means of combination is. It won't be trivial - writing programs certainly isn't - but it will be better than handrolled assembly.

> but it will be better than handrolled assembly.

Definitely. And I think if we can move more to discussions along the lines of "how do we best abstract/encapsulate/handle the inevitable complexity," rather than "wow, this technology looks like it will solve all our problems," that would be great.

I know the latter sounds absurdly simplistic, but I still hear an awful lot of it around.

> I wouldn't be surprised if even Rocket becomes bloated as they realize they cannot design for simplicity when complexity is a requirement.

That was pretty much what I was trying to get at with the question of how a "Rocket ecosystem" would address these requirements. I think vidarh makes a valid point that these could be met by tools outside the container system that are better suited...but I am curious as to what this combination of tools would be.

We just need more people experimenting and more enterprises willing to adopt some of these technologies on small, easily contained projects to get some field experience with them.

I think we're finally seeing the first iterations of the operating system disappearing into the network... an idea that has been touted for some decades.

Rocket is simple because they externalize the complexity. Rocket itself is simple and will stay simple. It's not much more than a tarball.

The Rocket ecosystem will be necessarily complex.