8 ms·

AnsibleWorks Raises $6M

121 points by tomaac 13y ago

giulianob 13y ago
Good for them! Ansible is amazing and everyone I've shown it to so far love it because it's just so much simpler to use than the alternatives. As soon as I found out about the project (before AnsibleWorks was even founded) I knew these guys were gonna be well off.
lyra- 13y ago
They deserve this so much ! For their amazing work and amazing support across irc/github/mailinglist <3
grey-area 13y ago
I tried Ansible just last week for automating server config and setup as it happens and was really impressed. I was using shell scripts previously but like the idea I can just spin up a server and from the base OS, run a deploy which will install everything I need from a local recipe, including configuring and restarting services, and have the server ready to use in a few minutes. It took a few hours to learn the ins and outs of their concept of playbooks (just simple recipes for deployment), but I liked the way you can nest these so once you have a setup for say Postgresql that you like it is usable in any other recipes combined with other components. The best bit is that it can be run multiple times when new configs are added - this means any config changes to say nginx can be done on the playbook and then replayed to send them to the server(s), over and over till the recipe is right. This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation. It'd be great if VPS providers had a library of Ansible playbooks - perhaps AnsibleWorks should consider having a library of playbooks which they manage on their website for common OS/setups and are downloadable from there? Their examples don't really cover all the bases as yet (I wanted Nginx/Postgresql for example), and it'd be nice if whatever setup you want there's already a playbook ready for. I'm sure similar things are possible in other comparable tools like Chef and Puppet, but I liked that Ansible requires nothing on the server, doesn't require git etc. and has a simple declarative language rather than a dsl to learn - the configuration language is very simple - you can start just by executing commands and installing packages and build up from there. Would anyone care to compare to Chef/Puppet for those who haven't used them?
- INTPenis 13y ago
  I've used Puppet in a network of a few hundred hosts, mixed Linux and FreeBSD, and I can't complain. However, I also started using ansible shortly after it came out and I much prefer their push model. One sad note about the fast open source development we all love so much though, I setup ansible when it was still in 0.x, everything worked fine. Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy. Everything had changed and I couldn't even get it to work. Not even after purging all the installed files of ansible. So now I have some studying to do. :)
  - grey-area 13y ago
    Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy. Thanks for the heads up, I'll be sure to test before updating ansible in future. I suppose going from 0.x to 1.x you can expect some breakage, but hopefully after 1.0 formats will be pretty stable?
  - mpdehaan2 13y ago
    Note: author of Ansible here. I'd be interested in feedback as to what that was specifically, can you stop by our mailing list perhaps? If it was the 0.X conditional support getting that in line was a very major priority, to streamline it so we all have something we like going forward. In general, we take a pretty hard line on backwards compatibility -- though some things with regard to "only_if" were pretty legacy and I think you'll like the newness a lot more. Anyway, please do stop by the list! Thanks!
  - adient 13y ago
    Puppet supports a push model using mcollective. You can also just use ssh the same as ansible and use any CF tool to "push" changes.
    - mpdehaan2 13y ago
      Well, it's a message bus, and requires initial setup, so you don't get the zero-boostrapping capability, and require the agent to stay running and have an open port continuously open to the server. Yes, you can initiate local runs on other CM tools, but with ansible the multi-tier orchestration and rolling updates can be accomplished from the central server without it -- just set it up and run from a laptop.
taude 13y ago
I've been interested in trying this out as I've been mostly tinkering with Chef and Puppet... Can anyone who's worked with Puppet/Chef and Ansible offer some insights?
- donjigweed 13y ago
  Same basic concept as the others. Ansible has Playbooks to Chef's Recipes. Ansible has Vars to Chef's data bags, and template files just like Chef or Puppet. For some reason, Ansible just ends up being much simpler to get going with. Probably because you write playbooks in a very straightforward yaml syntax, and the topology is not client-server - you just run Ansible right from your local terminal, like running knife I guess, with chef-solo. Just look at the documentation on their site, there's basically 3 or 4 pages you need to read before you're writing playbooks. I've worked with all three, Ansible is far and away the only sane one if you ask me.
- andyl 13y ago
  I started with Chef, then switched to Puppet, then to Ansible. They all do similar things, but for me, Ansible was simplest and most productive. Things I like best: Ansible relies on SSH and not a custom messaging system. Ansible requires no software to install/monitor on the remote systems. Ansible configs generally smaller and simpler, based on YAML and not a custom config file format. Also I found it to be simple to extend Ansible with custom modules written in Ruby and Bash.
- tszming 13y ago
  I have been using chef (solo/server) for 2 yrs and started playing with ansible two weeks ago, so far, my comments: Pros: - ansible's creator is very active and helpful in github/mailing list in answering issues/questions; for chef, reproducible bugs can't even get an acknowledgement from opscode [1], free users are not their priority IMO - simple in design, able to deploy multiple targets without a centralized monster like chef-server, you just need SSH - batteries included, e.g. aws, linode, mysql, postgresql tasks Cons: - ansible is more buggy and still under heavy development - documentation is confusing, e.g. current ansible latest is 1.2.2 but documentation showing features only appear in 1.3 - no playbook dependency handling - build in modules are helpful but not really extensible [2] - the creator is helpful but sometimes opinionated [3] [1] http://tickets.opscode.com/browse/CHEF-3204 http://tickets.opscode.com/browse/CHEF-3204 [2] https://github.com/ansible/ansible/issues/3776#issuecomment-22264220 https://github.com/ansible/ansible/issues/3776#issuecomment-... [3] https://groups.google.com/forum/#!searchin/ansible-project/group_vars$20default/ansible-project/Gd_7P3Ei_Vs/5DsDiCS-w8AJ https://groups.google.com/forum/#!searchin/ansible-project/g...
dschep 13y ago
I really want to use ansible (currently using salt), but I'm still waiting for the apt_repository pr[0] to get merged. [0] https://github.com/ansible/ansible/pull/3783 https://github.com/ansible/ansible/pull/3783
- borplk 13y ago
  can you elaborate on why you are moving away form salt?
  - BozeWolf 13y ago
    Would like to hear that as well. In my current project, vagrant is being provisioned with ansible. We chose ansible because it's easy to extend and its written in python. This project runs on freelancers, so its important the next django developer understands the provisioning system and custom modules as well. For some reason I tend to prefer the idea of being more "abstract" like Salt is. So my private project (server+vagrant) is being provisioned with Salt. Like borplk i'm interested in opinions of people which have experience with both.
    - mpdehaan2 13y ago
      I'd be interested in hearing what you mean about being more abstract, but I think you'll like the simplicity angle. In general, we build things with the goal of readability by diverse levels of skill and busy-ness -- to make things readable like a book and easy so you don't forget something in Ansible 6 months after you wrote it, and so you can dive in, get something done, and dive out. We've got some IT managers saying they can tell employees to do X, Y, and Z, and not knowing Ansible, can still read the playbook. So, it should be fine for your freelancer case I'm sure. This is also why there is no graph dependency system, just handlers and notifies, so you can read things top to bottom.
  - liyanage 13y ago
    Same here, I'd be interested to hear why you're moving in that direction. I heard great things about Ansible and would love to try it, but in some of the environments I work in, using GPL software (especially v3) is not possible (in other environments it is perfectly fine). Because I'd like to use the same system in all environments I work in, and because I strongly prefer a Python-based system, I'll probably go with Salt. If there were a different licensing option than GPL, I'd look into Ansible first, based on all the comments I read about it so far.
purephase 13y ago
I love the concept, but I couldn't figure out how to make the server inventory dynamic. I tag a lot of instances and want to use the AWS API to grab a list of tagged instances to automatically build the server inventory on execution. Since the instances are so variable (auto-scaling etc.) I see that as a killer feature. Maybe I have to dig deeper, but I spent some time evaluating it against Chef/Puppet etc. and I couldn't find anything.
- giulianob 13y ago
  The folks at the google group or IRC channel are super helpful. Ask there and you will usually get an answer fairly quick.
- bhangm 13y ago
  not sure how long ago you tried it out, but ansible has an ec2 inventory script bundled along with it, that you can use instead of maintaining static manifests. This script plugs into the AWS API to get you a list of instances and metadata. Along with that, comes all the goodness of tags and pattern matching, so you can do stuff like tag_Name_DB*:&tag_type_slave to select all database slaves (if you had tags called "Name" and "type" for example)
  - purephase 13y ago
    That's awesome. I just spent some time going through the getting started section for each project so in my haste I missed all the best parts. Back to it!
- bryanlarsen 13y ago
  If server manifest is executable, it executes the script rather than reading it.
  - purephase 13y ago
    Seems silly in hindsight to not consider that. ;)
- 13y ago
topfunky 13y ago
I'm the open source curriculum coordinator at Pluralsight. We would love to commission a video to help devops people learn and use Ansible. Email geoffrey@pluralsight.com if you're interested.
- zhynn 13y ago
  Email sent! I would love to do this.
gosub 13y ago
The two things that makes me prefer ansible over chef/puppet/cfengine are: 1) being push based 2) working via shell over ssh. There is a definite vantage, with a small install base, in not having to setup a server on either side and being able to control the process from the "admin" machine. What would make ansible perfect for me would be ditching yaml and use python directly. It would be easier to extend and control programmatically, without the awkward variables and looping constructs it uses in yaml.
- bryogenic 13y ago
  If you really want to do that way you can, they explicitly call out that kind of functionality on their APIs and Integration's page. http://www.ansibleworks.com/docs/api.html http://www.ansibleworks.com/docs/api.html > Advanced programmers may also wish to read the source to ansible itself, for it uses the Runner() API (with all available options) to implement the command line tools ansible and ansible-playbook.
- adient 13y ago
  You can use any CF tool over ssh, this is not unique to ansible. In doing so, you can also "push" to any CF tool. You can also push by using more integrated tools, such as mcollective with puppet.
  - pessimizer 13y ago
    You don't push to ansible, you push from ansible to a server that has never heard of ansible.
  - njharman 13y ago
    Given enough effort, you can do any 'X' with any 'Y'. The point is the design, future design, etc. all support that way and make it easy and robust out of the box.
SEJeff 13y ago
Props to Michael and team. More options for python deployment and config management is a good thing.
txutxu 13y ago
Hello, one question: How it's going to affect, this raising, to the ansible project? I mean, I like what I've used until now of ansible. I currently do not need the GUI. Is the ansible project going to continue it's development and licensing model? is there any possibility on ansible (without GUI) going "fremium" or any other functionality limitation with the time? I just ask because I know that funds does not use to come for free and there use to be directives and guidelines which may affect a project... I wish ansible is unaffected by the funders thoughts, even if I wish all the best for the ansibleWorks products too. Congrats for the fund!
- mpdehaan2 13y ago
  We're following exactly the same track record as before, and this was important in finding the right people to work with in the VC community. We have already announced AWX, which is commercial software, and you can read about it at http://www.ansibleworks.com/ansibleworks-awx/ http://www.ansibleworks.com/ansibleworks-awx/ -- it's downloadable now and you can use it for up to 10 nodes free. Basically the cutoff is ansible and ansible-playbook should be completely usable for all kinds of teams, but if you find the GUI useful, or want the REST API, or role based access control -- typically things enterprise companies do want, you have a product you can buy that adds a lot of value add on top. We're going to continue merging in all kinds of great pull requests and features, and continue to expand the language where we need to, and modules. One example of this is we recently were able to hire James Cammarata, who has been maintaining Cobbler, to work full time on just the OSS bits! Another example of this is all of our support guys are also helping out on things like IRC, and helping with producing new example content and modules. All the recent modules for OpenStack are an example of one of these things. Nothing is going to change in terms of licensing or the community at all, if anything, it allows us to have a lot more resources, help promote Ansible more, and move faster. But yes, we're going to have a really awesome product as well, and I think lots of Ansible users are going to be quite interested in taking a look at it.
  - txutxu 13y ago
    I'm glad to read this. Seems as a sincere and clear explanation to me. Which is a big plus. I'll look forward to the progress of ansibleWorks and I think the free until 10 servers model, is great to let the product be tested and even used in little projects. Succes!
andrewflnr 13y ago
I like Ansible, but I have to ask: Is $6M a lot for this sort of thing? It sounds like a lot to me for a GUI tool and "REST endpoint", whatever that means in this context. Is there enough of a market to return $6M x10 or whatever it takes to make the investment worthwhile? p.s.: I know this post could sound like veiled contempt, but I really am just curious and a trifle perplexed.
- josephlord 13y ago
  I have no connection to Ansible or the deal but I think that you are probably forgetting the team that got them to the current state, their future potential and what they can do with 6M.
- 3am 13y ago
  It doesn't seem to be a overly large round of funding. Look at comparable rounds at Puppet Labs & Opscode (so you'd probably want to look at Bs since the market is more validated now). Similar business models, and they should be valued similarly, too.
akurilin 13y ago
Big fan of Ansible, it's great that they'll have more resources to keep making the product even better.

121 points by tomaac 13y ago

Good for them! Ansible is amazing and everyone I've shown it to so far love it because it's just so much simpler to use than the alternatives. As soon as I found out about the project (before AnsibleWorks was even founded) I knew these guys were gonna be well off.

lyra- 13y ago

They deserve this so much ! For their amazing work and amazing support across irc/github/mailinglist <3

grey-area 13y ago

I tried Ansible just last week for automating server config and setup as it happens and was really impressed. I was using shell scripts previously but like the idea I can just spin up a server and from the base OS, run a deploy which will install everything I need from a local recipe, including configuring and restarting services, and have the server ready to use in a few minutes. It took a few hours to learn the ins and outs of their concept of playbooks (just simple recipes for deployment), but I liked the way you can nest these so once you have a setup for say Postgresql that you like it is usable in any other recipes combined with other components. The best bit is that it can be run multiple times when new configs are added - this means any config changes to say nginx can be done on the playbook and then replayed to send them to the server(s), over and over till the recipe is right. This avoids the biggest problem with fragile servers which is an agglomeration of config changes and ad-hoc installations over original setup scripts. The playbook becomes your server config documentation. It'd be great if VPS providers had a library of Ansible playbooks - perhaps AnsibleWorks should consider having a library of playbooks which they manage on their website for common OS/setups and are downloadable from there? Their examples don't really cover all the bases as yet (I wanted Nginx/Postgresql for example), and it'd be nice if whatever setup you want there's already a playbook ready for. I'm sure similar things are possible in other comparable tools like Chef and Puppet, but I liked that Ansible requires nothing on the server, doesn't require git etc. and has a simple declarative language rather than a dsl to learn - the configuration language is very simple - you can start just by executing commands and installing packages and build up from there. Would anyone care to compare to Chef/Puppet for those who haven't used them?

INTPenis 13y ago
I've used Puppet in a network of a few hundred hosts, mixed Linux and FreeBSD, and I can't complain. However, I also started using ansible shortly after it came out and I much prefer their push model. One sad note about the fast open source development we all love so much though, I setup ansible when it was still in 0.x, everything worked fine. Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy. Everything had changed and I couldn't even get it to work. Not even after purging all the installed files of ansible. So now I have some studying to do. :)
- grey-area 13y ago
  Just a couple of weeks ago I had to modify that ansible configuration for the first time since the setup so I pulled a fresh copy. Thanks for the heads up, I'll be sure to test before updating ansible in future. I suppose going from 0.x to 1.x you can expect some breakage, but hopefully after 1.0 formats will be pretty stable?
- mpdehaan2 13y ago
  Note: author of Ansible here. I'd be interested in feedback as to what that was specifically, can you stop by our mailing list perhaps? If it was the 0.X conditional support getting that in line was a very major priority, to streamline it so we all have something we like going forward. In general, we take a pretty hard line on backwards compatibility -- though some things with regard to "only_if" were pretty legacy and I think you'll like the newness a lot more. Anyway, please do stop by the list! Thanks!
- adient 13y ago
  Puppet supports a push model using mcollective. You can also just use ssh the same as ansible and use any CF tool to "push" changes.
  - mpdehaan2 13y ago
    Well, it's a message bus, and requires initial setup, so you don't get the zero-boostrapping capability, and require the agent to stay running and have an open port continuously open to the server. Yes, you can initiate local runs on other CM tools, but with ansible the multi-tier orchestration and rolling updates can be accomplished from the central server without it -- just set it up and run from a laptop.

taude 13y ago

I've been interested in trying this out as I've been mostly tinkering with Chef and Puppet... Can anyone who's worked with Puppet/Chef and Ansible offer some insights?

donjigweed 13y ago
Same basic concept as the others. Ansible has Playbooks to Chef's Recipes. Ansible has Vars to Chef's data bags, and template files just like Chef or Puppet. For some reason, Ansible just ends up being much simpler to get going with. Probably because you write playbooks in a very straightforward yaml syntax, and the topology is not client-server - you just run Ansible right from your local terminal, like running knife I guess, with chef-solo. Just look at the documentation on their site, there's basically 3 or 4 pages you need to read before you're writing playbooks. I've worked with all three, Ansible is far and away the only sane one if you ask me.
andyl 13y ago
I started with Chef, then switched to Puppet, then to Ansible. They all do similar things, but for me, Ansible was simplest and most productive. Things I like best: Ansible relies on SSH and not a custom messaging system. Ansible requires no software to install/monitor on the remote systems. Ansible configs generally smaller and simpler, based on YAML and not a custom config file format. Also I found it to be simple to extend Ansible with custom modules written in Ruby and Bash.
tszming 13y ago
I have been using chef (solo/server) for 2 yrs and started playing with ansible two weeks ago, so far, my comments: Pros: - ansible's creator is very active and helpful in github/mailing list in answering issues/questions; for chef, reproducible bugs can't even get an acknowledgement from opscode [1], free users are not their priority IMO - simple in design, able to deploy multiple targets without a centralized monster like chef-server, you just need SSH - batteries included, e.g. aws, linode, mysql, postgresql tasks Cons: - ansible is more buggy and still under heavy development - documentation is confusing, e.g. current ansible latest is 1.2.2 but documentation showing features only appear in 1.3 - no playbook dependency handling - build in modules are helpful but not really extensible [2] - the creator is helpful but sometimes opinionated [3] [1] http://tickets.opscode.com/browse/CHEF-3204 http://tickets.opscode.com/browse/CHEF-3204 [2] https://github.com/ansible/ansible/issues/3776#issuecomment-22264220 https://github.com/ansible/ansible/issues/3776#issuecomment-... [3] https://groups.google.com/forum/#!searchin/ansible-project/group_vars$20default/ansible-project/Gd_7P3Ei_Vs/5DsDiCS-w8AJ https://groups.google.com/forum/#!searchin/ansible-project/g...

dschep 13y ago

I really want to use ansible (currently using salt), but I'm still waiting for the apt_repository pr[0] to get merged. [0] https://github.com/ansible/ansible/pull/3783 https://github.com/ansible/ansible/pull/3783

borplk 13y ago
can you elaborate on why you are moving away form salt?
- BozeWolf 13y ago
  Would like to hear that as well. In my current project, vagrant is being provisioned with ansible. We chose ansible because it's easy to extend and its written in python. This project runs on freelancers, so its important the next django developer understands the provisioning system and custom modules as well. For some reason I tend to prefer the idea of being more "abstract" like Salt is. So my private project (server+vagrant) is being provisioned with Salt. Like borplk i'm interested in opinions of people which have experience with both.
  - mpdehaan2 13y ago
    I'd be interested in hearing what you mean about being more abstract, but I think you'll like the simplicity angle. In general, we build things with the goal of readability by diverse levels of skill and busy-ness -- to make things readable like a book and easy so you don't forget something in Ansible 6 months after you wrote it, and so you can dive in, get something done, and dive out. We've got some IT managers saying they can tell employees to do X, Y, and Z, and not knowing Ansible, can still read the playbook. So, it should be fine for your freelancer case I'm sure. This is also why there is no graph dependency system, just handlers and notifies, so you can read things top to bottom.
- liyanage 13y ago
  Same here, I'd be interested to hear why you're moving in that direction. I heard great things about Ansible and would love to try it, but in some of the environments I work in, using GPL software (especially v3) is not possible (in other environments it is perfectly fine). Because I'd like to use the same system in all environments I work in, and because I strongly prefer a Python-based system, I'll probably go with Salt. If there were a different licensing option than GPL, I'd look into Ansible first, based on all the comments I read about it so far.

purephase 13y ago

I love the concept, but I couldn't figure out how to make the server inventory dynamic. I tag a lot of instances and want to use the AWS API to grab a list of tagged instances to automatically build the server inventory on execution. Since the instances are so variable (auto-scaling etc.) I see that as a killer feature. Maybe I have to dig deeper, but I spent some time evaluating it against Chef/Puppet etc. and I couldn't find anything.

giulianob 13y ago
The folks at the google group or IRC channel are super helpful. Ask there and you will usually get an answer fairly quick.
bhangm 13y ago
not sure how long ago you tried it out, but ansible has an ec2 inventory script bundled along with it, that you can use instead of maintaining static manifests. This script plugs into the AWS API to get you a list of instances and metadata. Along with that, comes all the goodness of tags and pattern matching, so you can do stuff like tag_Name_DB*:&tag_type_slave to select all database slaves (if you had tags called "Name" and "type" for example)
- purephase 13y ago
  That's awesome. I just spent some time going through the getting started section for each project so in my haste I missed all the best parts. Back to it!
bryanlarsen 13y ago
If server manifest is executable, it executes the script rather than reading it.
- purephase 13y ago
  Seems silly in hindsight to not consider that. ;)
13y ago

topfunky 13y ago

I'm the open source curriculum coordinator at Pluralsight. We would love to commission a video to help devops people learn and use Ansible. Email geoffrey@pluralsight.com if you're interested.

zhynn 13y ago
Email sent! I would love to do this.

gosub 13y ago

The two things that makes me prefer ansible over chef/puppet/cfengine are: 1) being push based 2) working via shell over ssh. There is a definite vantage, with a small install base, in not having to setup a server on either side and being able to control the process from the "admin" machine. What would make ansible perfect for me would be ditching yaml and use python directly. It would be easier to extend and control programmatically, without the awkward variables and looping constructs it uses in yaml.

bryogenic 13y ago
If you really want to do that way you can, they explicitly call out that kind of functionality on their APIs and Integration's page. http://www.ansibleworks.com/docs/api.html http://www.ansibleworks.com/docs/api.html > Advanced programmers may also wish to read the source to ansible itself, for it uses the Runner() API (with all available options) to implement the command line tools ansible and ansible-playbook.
adient 13y ago
You can use any CF tool over ssh, this is not unique to ansible. In doing so, you can also "push" to any CF tool. You can also push by using more integrated tools, such as mcollective with puppet.
- pessimizer 13y ago
  You don't push to ansible, you push from ansible to a server that has never heard of ansible.
- njharman 13y ago
  Given enough effort, you can do any 'X' with any 'Y'. The point is the design, future design, etc. all support that way and make it easy and robust out of the box.

SEJeff 13y ago

Props to Michael and team. More options for python deployment and config management is a good thing.

txutxu 13y ago

Hello, one question: How it's going to affect, this raising, to the ansible project? I mean, I like what I've used until now of ansible. I currently do not need the GUI. Is the ansible project going to continue it's development and licensing model? is there any possibility on ansible (without GUI) going "fremium" or any other functionality limitation with the time? I just ask because I know that funds does not use to come for free and there use to be directives and guidelines which may affect a project... I wish ansible is unaffected by the funders thoughts, even if I wish all the best for the ansibleWorks products too. Congrats for the fund!

mpdehaan2 13y ago
We're following exactly the same track record as before, and this was important in finding the right people to work with in the VC community. We have already announced AWX, which is commercial software, and you can read about it at http://www.ansibleworks.com/ansibleworks-awx/ http://www.ansibleworks.com/ansibleworks-awx/ -- it's downloadable now and you can use it for up to 10 nodes free. Basically the cutoff is ansible and ansible-playbook should be completely usable for all kinds of teams, but if you find the GUI useful, or want the REST API, or role based access control -- typically things enterprise companies do want, you have a product you can buy that adds a lot of value add on top. We're going to continue merging in all kinds of great pull requests and features, and continue to expand the language where we need to, and modules. One example of this is we recently were able to hire James Cammarata, who has been maintaining Cobbler, to work full time on just the OSS bits! Another example of this is all of our support guys are also helping out on things like IRC, and helping with producing new example content and modules. All the recent modules for OpenStack are an example of one of these things. Nothing is going to change in terms of licensing or the community at all, if anything, it allows us to have a lot more resources, help promote Ansible more, and move faster. But yes, we're going to have a really awesome product as well, and I think lots of Ansible users are going to be quite interested in taking a look at it.
- txutxu 13y ago
  I'm glad to read this. Seems as a sincere and clear explanation to me. Which is a big plus. I'll look forward to the progress of ansibleWorks and I think the free until 10 servers model, is great to let the product be tested and even used in little projects. Succes!

andrewflnr 13y ago

I like Ansible, but I have to ask: Is $6M a lot for this sort of thing? It sounds like a lot to me for a GUI tool and "REST endpoint", whatever that means in this context. Is there enough of a market to return $6M x10 or whatever it takes to make the investment worthwhile? p.s.: I know this post could sound like veiled contempt, but I really am just curious and a trifle perplexed.

josephlord 13y ago
I have no connection to Ansible or the deal but I think that you are probably forgetting the team that got them to the current state, their future potential and what they can do with 6M.
3am 13y ago
It doesn't seem to be a overly large round of funding. Look at comparable rounds at Puppet Labs & Opscode (so you'd probably want to look at Bs since the market is more validated now). Similar business models, and they should be valued similarly, too.

akurilin 13y ago

Big fan of Ansible, it's great that they'll have more resources to keep making the product even better.