Hacker News new | ask | show | jobs
by lmilcin 1744 days ago
> But the same is true of all the other orchestration tools isn't it?

Of course. The difference being how complicated it is to deal with problems.

For example I find it is way easier to deal with problems with Ansible compared to Chef.

So, assuming that both get me what I need, I prefer Ansible because it is less drag for when I have least time available to babysit it (which usually happens at least opportune moment).

What I am trying to say is that, just because it works for you now doesn't mean it will not end in a disaster at some time in the future. It is not my position to tell you if the risk is acceptable for you. But I personally try to avoid situations from which I cannot back easily.

If I have a script that starts an application on a regular VM I KNOW I can fix it whatever may happen to it. Not that I advocate running your services with a script, I just mean there is a spectrum of possible solutions with tradeoffs and it is good to understand those tradeoffs.

Some of those tradeoffs are not easily visible because they may only show themselves in special situations or, opposite, be so spread over time and over your domain that you just don't perceive the little drag you get on everything you do.

I find that if there is any overarching principle to build better solutions it is simplicity.

Presented with two solutions to the problem, the simpler solution is almost always better (the issue being the exact definition what it means to be simpler).

For example, I have joined many teams in the past that had huge problems with their applications. I met teams that were very advanced (they liked overcomplicating their code) and I met teams that could barely develop (they had trouble even writing code, did not know or use more advanced patterns).

I found that it is easier to help teams that had huge problems but wrote stupid code because it is easier to refactor stupid simple code that beginner developers write than it is to try to unpack extremely convoluted structures that "advanced" developers make.

I think similar applies to infrastructure.

For example, when faced with an outage I would usually prefer simpler infrastructure that I know I understand every element of.