hoverfly actually looks very nice. Other projects in this space are either a ton of setup, language specific, or SaaS only. My main motivation was I needed something stupid simple to get up and running in minutes instead of hours.
hoverfly looks a lot easier than most of the more popular solutions out there.
I'm not an expert in Rust or dotNet Core but I can give a bit of insight. At the time (2016) Rust wasn't as visibly used in production as it is today. Also from my understanding over the past few years a lot of new features have gone into Rust which makes it more viable these days.
As far as dotNet Core, it is used at AXP but generally not in our high performance environments. Not saying it couldn't as I'd have to do a lot more research to say one way or another on that. But I'd say that's the primary reason it wasn't added to the list.
My apologies: I missed the 2016 reference -- I wouldn't have recommended dotNetCore three years ago and I'm only now waking up to the power of and speed of Rust and didn't realize just how young it is. I'm still a little amused that Go was the only language not in use already that was considered but understand that the list of possible high performance alternatives was indeed short... shorter than I realized.
All good. There were a lot of factors to creating the list, Enterprise use and readiness was one big one. So we narrowed it down to what we thought were the best choices. Always the possibility we missed something, but thats true of any decision like this.
Are you on the AMEX team(s) in question? I am always interested in knowing all of the factors that were part of the decision in why a team chose the language or platform it did and if, after a respectable period of time, everyone is still happy with the choice or if there's buyer's remorse and what greener pasture languages/platforms (or problems with the selected stack) are bringing on those second thoughts.
Yeah, thoughts and opinions are my own of course but overall we've had good experiences.
I tried to insert some of the benefits we are seeing into the article in different pieces but now that we are several years later have it running in production. We are happy with the decision. In my opinion, there are even some newer things we didn't write in Go that I kind of wish we did.
The reasons we choose Go are holding true, and I can't say enough about how the performance and low GC times out of the box is something that is very beneficial. At least for my use cases.
Thanks for the thoughts, I'll have to think pretty heavily on the pay-only service. There are many companies out there that have done well with a try before you buy model.
You make a valid point with the fact that we have already open sourced our product so a free tier is giving away even more.
> Companies pay ridiculous amounts for things as trivial as chatrooms, so if you're automating away DevOps/System-Administration, you can charge a decent chunk of change that will come cheaper than say $4,000 per month for a senior system administrator.
So very true. I guess when you put it that way $1 per monitor is a pretty low price and I think you're right we may just be going too cheap and labeling ourselves wrong.
> To me it seems like an automatic server-monitoring service that detects and tries to fix errors.
Thats good advice though one part confused me. Are you saying our pro package is too cheap or too expensive?
Right now the main difference between our pro and free accounts is the number of monitors available. With free you can only have 2 whereas with pro there is no limit except that each monitor costs.
Thanks, that helps a ton with a future direction where our monitors are server based. What we have right now is all external monitors. Think along the lines of Pingdom but a lot more types of monitors.
Right now we don't have any demo, but you can sign up and if you like it you can choose to upgrade. Upgrade gives you more monitors and more intervals but everything else is the same between free and non-free accounts.
I'd like to see it as well (screenshots would be fine, a demo better, of course) but I'm not going to bother taking the time and trouble to sign up just to be able to see if I might like it.
I realize I'm only a single person but I would think many others are the same way so it would seem that you're unnecessarily putting up roadblocks to acquiring customers.
That is some good feedback, we have a bounty open to revise the "responsiveness" of our site. To make it work a bit better cross platform. We move pretty fast I doubt it would take us very long to have that fixed up.
I can't speak for others, but I can for Factor.io’s twist... (1) It is Open Source + Hosted + Pro. (2) The recipes ("workflows") can include multiple steps, sequential, and parallel activities; not just limited to if-this-then-that. (3) Workflows are defined programmatically using a Ruby-DSL. (4) You can create both actions and listeners (like events/monitors), though some of the others support this too. (5) It's been around for 2+ years, built with feedback from 100+ dev teams, and used by 1000s.
hoverfly looks a lot easier than most of the more popular solutions out there.