Orchard and Fig are joining Docker(blog.docker.com)
blog.docker.com
Orchard and Fig are joining Docker
http://blog.docker.com/2014/07/welcoming-the-orchard-and-fig-team/
Good and bad news:
- Orchard close
- First Docker office in Europe.
- Fig continue up&running
- New Developer Experience group
13 comments
Is fig the authoritative way to deploy a bunch of Docker instances for a fairly basic stack - web server, DB, elasticsearch ?
I started off thinking about Ansible, but it seems most people on #docker were using Fig. But I dont know what people are doing in production
I started off thinking about Ansible, but it seems most people on #docker were using Fig. But I dont know what people are doing in production
The APIs are pretty simple. You could most likely write the orchestration you wanted in a shell script full of calls to curl, or do the same in a nicer scripting language with a decent JSON and http library. I'm working on a very simple orchestrator along the lines for my own needs, as well as a Sinatra application that serves nginx configs to load-balance all the containers running a particular image on a set of hosts.
There are many tools in this space, but it's also not hard to write your own - you're just wiring together some REST APIs.
There are many tools in this space, but it's also not hard to write your own - you're just wiring together some REST APIs.
Fig works in production, but it's not our focus. We wrote a blog post on it a while back - it's Orchard-specific, but covers what you need to think about, especially in the "Configuring for deployment" section:
https://www.orchardup.com/blog/develop-and-deploy-an-app-wit...
https://www.orchardup.com/blog/develop-and-deploy-an-app-wit...
Are you planning on retaining fig in its current form or probably merging it into Chef/Ansible?
In the long term, do you believe that having a very specific CM tools is going to be better than supporting something having a lit of mind share?
In the long term, do you believe that having a very specific CM tools is going to be better than supporting something having a lit of mind share?
Is fig going to stick around and be improved, or are Ben and Aanand going to drop it and make something slightly similar right into Docker? We're currently not using it, but maybe we should.
A bit of both. Fig is going to stick around, but over time parts of it will find their way into Docker. It won't be deprecated unless there's a better official solution.
Thanks, I appreciate the honest and direct answer. If we're looking to replace a bash hack now (which works but isn't the prettiest), would you recommend diving into Fig or waiting until Docker becomes Figgier?
Oh, I'd absolutely recommend diving into Fig. We'll have a lot of Fig users to transition over once it happens, and want to make sure it's a smooth (i.e. documented) process.
I hope Fig or something like it makes it's way into official Docker tools.
After wrestling with "Makefile orchestration" for Docker containers then discovering Fig, it's clearly a useful tool.
After wrestling with "Makefile orchestration" for Docker containers then discovering Fig, it's clearly a useful tool.
Question - has anyone gone whole hog on deploying containers? If so, are you using something like CoreOS or something else to deploy them?
I always thought this was Orchard: http://www.orchardproject.net/
I was also very confused, and the first google search for Orchard was the one you came across. My first thought was, "this is an .Net CMS, I thought docker was unix-based?"
Then I was like, Okay, let's go see what "Fig" is. None of the links on the first search page were for Fig. I got everything from food websites, stock codes, to random content-spam URLs with Fig in it.
I'm sorry, but these guys really picked bad names for their products. It's really ridiculous because those names have well-established meanings. Sure, if they get famous enough, their rankings will make their alternate-meaning of those words bubble up. But until then, they're invisible to most of the web.
Heck, the linked article doesn't even have a link to Orchard, but rather to a blog post on their domain. If anyone really struggles, here are their links:
http://www.fig.sh/ https://www.orchardup.com/
*Edit: Searching for "Fig Software" led me to software companies with "Fig" in it, and some Facebook pages. Again, not the actual Fig I was looking for.
Then I was like, Okay, let's go see what "Fig" is. None of the links on the first search page were for Fig. I got everything from food websites, stock codes, to random content-spam URLs with Fig in it.
I'm sorry, but these guys really picked bad names for their products. It's really ridiculous because those names have well-established meanings. Sure, if they get famous enough, their rankings will make their alternate-meaning of those words bubble up. But until then, they're invisible to most of the web.
Heck, the linked article doesn't even have a link to Orchard, but rather to a blog post on their domain. If anyone really struggles, here are their links:
http://www.fig.sh/ https://www.orchardup.com/
*Edit: Searching for "Fig Software" led me to software companies with "Fig" in it, and some Facebook pages. Again, not the actual Fig I was looking for.
http://blog.docker.com/2014/07/welcoming-the-orchard-and-fig... features links to Orchard and Fig in the first sentence.
I'm pretty sure the Orchard link wasn't there when I first read the article. I distinctly remember searching through the page for Fig and Orchard. The way I actually found Orchard was through the linked blog post near the bottom of the article, then cut out the blog part of the URL to go to their main domain.
Naming projects without any collisions is really hard to do, unless you like names like 'e31239'.
This is great news for the Docker community, and for Ben and Aanand. I knew Ben at university, great guy. With them looking after Developer Experience, I'm excited to see what's next for Docker.
This is brilliant news. fig is really handy, and I'm hoping this means we now have an officially blessed way to manage multi container setups.
As an Orchard customer, I'm really happy about this. Orchard is a cool service, but their customer service is pretty amateuristic. I think they have all the potential of upping their game given sufficient resources (which I assume they are now getting). If Orchard becomes the go-to "just dump them containers in our cloud" solution for Docker, then great times are ahead!
EDIT: oh fuck, they're shutting down? damn, that's shitty. Also the link from the docker.com blog post to https://www.orchardup.com/blog/orchard-is-joining-docker is broken, and no info at all on https://www.orchardup.com/blog. Typical.
EDIT: oh fuck, they're shutting down? damn, that's shitty. Also the link from the docker.com blog post to https://www.orchardup.com/blog/orchard-is-joining-docker is broken, and no info at all on https://www.orchardup.com/blog. Typical.
Very sorry you had to hear it from HN - we had our email, blog post etc. ready to go out but there was a scheduling mishap. We also emailed our active customers from last month in advance yesterday.
The space has matured a lot, so there are some great alternatives out there. Happy to help you migrate - give me a shout at [email protected]
The space has matured a lot, so there are some great alternatives out there. Happy to help you migrate - give me a shout at [email protected]
Release Orchard backend as open source? Note: Consider why fig took off and Orchard didn't...
No one wants to be stuck on a provider that might not succeed and have to migrate to a different one unless the new provider is drop-in compatible. It is nice that you are providing migration instructions and help, but the very idea of being at the mercy of an acquired platform's team is what stops me from trying such services in the first place (after being burned by ep.io, 30loops, etc.).
No one wants to be stuck on a provider that might not succeed and have to migrate to a different one unless the new provider is drop-in compatible. It is nice that you are providing migration instructions and help, but the very idea of being at the mercy of an acquired platform's team is what stops me from trying such services in the first place (after being burned by ep.io, 30loops, etc.).
The nice thing about using Docker is that everything is drop-in compatible. You can push your images to a provider such as Tutum or Google Cloud and they'll be able to run. If you've written any software that used the Docker remote API on Orchard, you can just point that are your own Docker daemon and it'll keep on working.
If that were really true, the migration instructions would be more along the lines of "change the endpoint URL to your new provider", or "push this one button and authenticate", instead of https://www.orchardup.com/docs/moving
That said, kudos to the Orchard team for making it as easy as they did, I'll just stress again that the fear that migrating would be even more involved was what stopped me from trying their service in the first place.
There are several ways of addressing that fear:
1. Be so big that you know the service is unlikely to be shut down or acquired (that just leaves the usual lock-in concerns over future price hikes and the like, which isn't going to happen until the market stops growing).
2. Ensure that a fluid marketplace of drop-in replacement competitors exists (an Open Source release of the backend helps with this)
3. Document how easy it is to switch away from the get go, not just when you're shutting down: see https://web.archive.org/web/20140209113413/https://orchardup... and http://www.joelonsoftware.com/articles/fog0000000052.html
That said, kudos to the Orchard team for making it as easy as they did, I'll just stress again that the fear that migrating would be even more involved was what stopped me from trying their service in the first place.
There are several ways of addressing that fear:
1. Be so big that you know the service is unlikely to be shut down or acquired (that just leaves the usual lock-in concerns over future price hikes and the like, which isn't going to happen until the market stops growing).
2. Ensure that a fluid marketplace of drop-in replacement competitors exists (an Open Source release of the backend helps with this)
3. Document how easy it is to switch away from the get go, not just when you're shutting down: see https://web.archive.org/web/20140209113413/https://orchardup... and http://www.joelonsoftware.com/articles/fog0000000052.html
Not sure that was the reason.
By using Orchard, we allowed ourselves to avoid doing any server management at all. Even without a drop-in replacement, the alternative would have been to set up our own Linux servers somewhere and learn to secure them and to securely send Docker images over and all that. Assuming Orchard wouldn't break overnight, the only real risk we took was that maybe no more decent competitors would pop up in the space and we'd be forced to put our own Docker on an EC2 anyway.
If your biggest risk is to be forced to choose your only alternative, but later, then that's not a very grave risk is it?
By using Orchard, we allowed ourselves to avoid doing any server management at all. Even without a drop-in replacement, the alternative would have been to set up our own Linux servers somewhere and learn to secure them and to securely send Docker images over and all that. Assuming Orchard wouldn't break overnight, the only real risk we took was that maybe no more decent competitors would pop up in the space and we'd be forced to put our own Docker on an EC2 anyway.
If your biggest risk is to be forced to choose your only alternative, but later, then that's not a very grave risk is it?
Only if you've eliminated various PaaS offerings from consideration as an alternative for avoiding administration costs.
Hi! I admit that when the blog post was down, there was this part of me deep down that feared that it was going to say "we'll pull the plug this weekend, good luck!". That might have made my comment feel a bit too bitter. Sorry about that.
We saw a bunch of nice alternatives pop up actually - and admittedly we were already in the process of moving over to one (Tutum, probably, unless you have better ideas :D), because we realised that you two are much better coders than you are hosting providers :)
Congrats on the move and good luck with the London office!
We saw a bunch of nice alternatives pop up actually - and admittedly we were already in the process of moving over to one (Tutum, probably, unless you have better ideas :D), because we realised that you two are much better coders than you are hosting providers :)
Congrats on the move and good luck with the London office!
Why are you shutting down Orchard? Seems like a great service.
Is Docker going to have its own thing like Orchard?
Is Docker going to have its own thing like Orchard?
If it's a really useful service somebody could re-implement their API as a new open-source backend that existing clients could use. (Personally I don't know why you wouldn't just make a couple bash scripts and a makefile to manage these things, but I guess not everyone's into making their own sausages)
I really love fig, it is a great tool to easily deploy multiple containers without a hassle and without having to know the intricacies of the docker command line. I nowadays use it for all my projects. Great to see it joining Docker. Very cool.
SO pleased for Ben & Aanand, this is the best possible outcome for Orchard/Fig. Brilliant news.
Great news that Orchard are staying in London and there is now a European Docker office.