1. 12
  1.  

  2. 4

    Rumours of our demise are, as usual, exaggerated. Nice to be mentioned, though!

    1. 3

      I’m still a very happy SmartOS user!

      1. 2

        I’m not very familiar with Illumos, could you elaborate on why the author mentions it as “dead”? I can see that the repositories still have daily activity and the issue tracker too (https://www.illumos.org/projects/illumos-gate/activity).

      2. 3

        I’m a happy user of Ansible, and despite having hundreds of VMs to take care of in the past, I’ve never felt any pain about it. To keep the desired state, Ansible scripts where running hourly with Jenkins, and it worked well.

        I cannot compare with Chef or Puppet that I’ve never used, anybody have more experience on the limitations mentioned?

        1. 3

          Yeah, the recommendations and justifications in that article seem a bit random and biased. Ignoring Ansible and it’s ease of use and relatively quick learning curve (compared to Puppet esp), and requiring a pull model when the premise is to find ‘good enough’ tools doesn’t make a whole lot of sense to me (as do non of those generic recommendation/advice articles like this one in the first place).

          The bit about Kubernetes and using config management instead is silly.

        2. 1

          Why not run database as a service, like these big providers provide

          1. 2

            Seconded. The article mentions:

            Unfortunately, the interesting parts of software are all about state. You don’t casually kill and start containers for your database. Again, you need the configuration manager.

            So you’re going to run a configuration manager. The question, then, is whether you need Kubernetes as well?

            Just push states out of your services and use what cloud providers offer. Message queues, database, object storage… Then your application will happily work on Kubernetes. Although, I recognize that you can also run applications that are stateful (other than databases) and you need to handle those too.

            1. 2

              100% agree that until you reach scale (a large large scale) a database as a service is the best path forward. There’s so much that goes into running a production ready database that a service like RDS just takes off your plate.

              That said, I kow that some people have run into issues where RDS in particular just couldn’t handle the throughput (even working with AWS support). It was a few years ago, but I talked to someone who was running something like 500 TPS on Oracle and RDS just didn’t work out for them. But they tested and tried before moving to running their own database servers.