The blog seems to have a target audience of people who have never heard of the cloud, but for those of us who are already familiar with cloud, DevOps, drift, and immutable infrastructure it would be nice to see an explanation of what specifically is new here.
Terraform creates everything and hands you the keys to manage your infrastructure. Fugue continually manages your infrastructure after the deployment with the Conductor. The continuous automatic regeneration of instances make bad boots, noisy neighbors, and transient errors temporary blips rather than problems that must be manually addressed. Fugue continuously enforces your desired state of infrastructure so you don't have to.
Very interesting, I worked on a system that does provide 'truth and trust' but the first part (voluntarily destroying instances) of what you say seems like the opposite? If you want to maintain truth with everyone being aware of each other 's state but then want to voluntarily disrupt said state, wouldn't that lead to unnecessary work? Also, would be nice if you shared the data that led to such an approach (I see this removes the need for say Upgrades, but does it actually provide a benefit)? May be I'm completely off-base here.
Disclosure: I am a founder and the CEO of Luminal.
In a distributed, and therefore often largely stateless system at the instance level, the system boundary is now outside the individual instance. The performer (a series of instances over time in Fugue) is roughly analogous to a process on an individual computer. Truth and trust are maintained by knowing and controlling the state of the instances themselves with Fugue. Think of the Conductor as analogous to the kernel in a traditional OS, where providing processes CPU time and resources is a regular course of business.
As for unnecessary work, we've found that maintaining systems in place, with all the failure, complexity and configuration drift that's inevitable is much more expensive than using some of the excess capacity of a given performer. Most systems target 70% or so utilization - we use some of that excess to lifecycle.
I hope this answers the question and we're really excited to get feedback on what we're doing so it's relevant to your work.
I currently use scalr to manage a bunch of servers at the top-level (with Ansible scripts doing config and deployment), but would love for it to be configured via a bunch of config files that are revision controlled in git rather than through a UI like scalr provides. This looks exactly like it would provide this ...
Although I'm not a fan of the vocabulary you guys are using - but that may be because I'm one of those silly JavaScript people. I guess specifically, I'd love to see some screen recordings of this in action. Do you guys have any you can show off? Keep up the good work, immutability is a critical key to making any type of progress in software.
Thanks for the comments and well-wishes! We chose to use some new terms to not overload existing ones where we are introducing new concepts (Conductor, Performers, etc.). The analogues to music conceptually were so strong they seemed the right way to go. We will have lots more in the way of howto's, screen recordings, etc. in the coming weeks as we recover from launching our beta at re:Invent. Sign up for the beta and we'll send out bits with examples and runnable code in <15 mins.
We're currently evaluating Terraform for an H1 2015 rollout. This looks like another interesting option, though it might require more modification to our services than we can commit to.
Where do you think our approach will add overhead to your development? We'd love to know so that we can either explain better or get a better product match for you. With Fugue, you get a Conductor that continually monitors and conforms the environment to your declarations - we think that has a lot of value for operating your environment as opposed to just creating it.
