[ryan_lane]

I'll follow-up with a post about how we're working without a master. We need neither SSH, nor a master.

We're very heavily using autoscaling, which makes SSH a no-go. Ansible has Tower for this, but it's proprietary. We /could/ use a salt master for autoscaling, but we prefer masterless in this situation because it scales better.

[mpdehaan2]

ansible-pull is available for those that need to invert the architecture, though we're finding most users in companies who need autoscaling can afford Tower. Price points are definitely important in that regard, but ansible-pull does exist for those that would rather go the pure OSS route.

Tower is also free for up to 10 nodes. See my comments above about why we went that route - being able to build products versus having to become a consultancy or support outfit makes it easy to keep ansible to be easy to understand and rock solid, and most people are quite happy with that split.

[ryan_lane]

Open core also has its set of issues. For most open core products I've used over time the community starts creating alternatives to the proprietary products and the upstream slows its acceptance of open code. The upstream will also tend to spend most of its time working on proprietary features.

Whether or not tower costs money, it's still a worry of being a single point of failure for autoscaling, which is part of why we avoided masters.

[mpdehaan2]

We've never held back anything from Ansible, really. Rather, Tower is more of a product on top that provides some extra enterprise features that most of our user bases don't need (but they should try it, because they might!).

I think if you see things like Windows being part of Ansible proper, it's clear we're not holding that back. But there are also tools the OSS community can't build easily, things that involve coordination around database schemas and (ick!) status meetings and UX mockups.

Yes, communities can build them, but occasionally, just occasionally, companies can build them better. And this is one of those cases. Our business model basically funds Ansible and also makes Tower significantly more capable that way, and it only becomes something you need when you can afford it. And it's not so much because we're a company, because I've got tons of awesome folks working in 100% full time, and that's a lot of power to build good stuff. Most likely your company employs a few folks as well :)

So on the "open core" comment, Ansible won't, for instance, ever have proprietary modules. That's something we said we don't do. Ever.

As for Tower, the small guy isn't going to need it yet. He's probably ok with pure Jenkins fronting the show. The big guy probably needs it and a super-well-tested environment and a guy to call when it has issues.

I don't know anything about other communities you've been a part of, but I think our track record shows what goes where and people are comfortable with it. Ansible isn't open core. It's the real deal. We take that seriously.

Yet, I think the general assumption that all software has to be purely 100% open is flawed, but that in general, open source communities can build some things in GREAT fantastic ways, and certain layers do benefit from being free software. But companies need to exist. Including yours! (Though I do love me some Uber).

Anyway, ansible-pull is indeed an option if you wanted to go that wrote, or even doing image builds with Packer. Both popular options for immutable systems and/or autoscaling, sans commercial bits.

But is commercial software dirty? Heck no. Ask any SaaS company :)

[icebraining]

But is commercial software dirty? Heck no. Ask any SaaS company :)

The pedantic in me feels compelled to point out that commercial SaaS doesn't have to mean closed; the company I work for is a good example, where our products and service are based on an third-party AGPL licensed software called Odoo[1] (and are therefore AGPL licensed themselves).

In any case, we do use Ansible here, and are happy with it :)

[1] https://www.odoo.com/

[malraux]

How are you building your AMIs?

We're using Ansible and building the AMIs on a dedicated ec2 instance (started for a build and shut down afterwards). The AMIs are fully baked and environment information is configured via user_data in the launch configuration.

We use SSH to communicate with the build instance as a result, but I'd rather spend time during the build than during start-up of a new instance.

[markhellewell]

Not the person you asked the question of, but we’re building AMIs (and VMware images) using packer.io (via the masterless puppet provisioner). It works nicely and with a minimum of fuss.

[Rapzid]

You might want to look at the new life cycle states: http://aws.amazon.com/blogs/aws/auto-scaling-update-lifecycl... . That should make it possible to bootstrap via SSH now. as to whether or not you'd want to.. That's another matter :)