[dsr_]

Will you stop calling me a liar if I correct that from "the costs" to "your costs"? I am assuming that you are growing, and I think there's a provable assumption that for high levels of service, hiring someone else to do it is more expensive than in-house.

[morgante]

That's an entirely different statement than your original one. Saying "the costs of cloud service are zooming up" disingenuously makes it sound like the price of cloud services are going up.

[dsr_]

Thanks for the charitable interpretation of my words.

[user5994461]

> hiring someone else to do it is more expensive than in-house.

Except you're gonna need between 10 and 100 people to recreate the service in-house, not just one.

Trying to re-do something from scratch in-house is always more expensive than just buying the product.

[majewsky]

I get the sentiment, but it really depends: For some services, it's very true. For other services, careful problem analysis will show that you only need one or two features from the full package, which then can be replaced by a very small shell script.

[ismail-khan]

Can you give an example where a shell script would solve the problem? Curious to know

[majewsky]

Last month, I needed to add a periodic job to a simple Rails app to snapshot some data and send it to another system. I discussed the design with a colleague, a Rails expert, who went into the pros and cons of various worker-queue configurations. In the end, I added a hidden API call, and deployed a shell script along the lines of

  while true; do
    curl https://rails.app/do/the/thing
    sleep 3600
  done

The actual version is slightly larger because of error checking etc., but that's the gist. So that's one example of replacing (or rather: avoiding) a distributed system (an asynchronous job queue) with a small shell script.

I don't mean to say that shell scripts always can replace more complex systems, but sometimes they're enough.