Getting to cloud today is not difficult. If you’re an individual looking to spin up a test environment in the cloud, for instance, the barrier to entry is quite low.

But when you have an application that calls on numerous services to perform, and allows access to multiple users in multiple roles – not to mention the number of changes made to numerous components of the application — the complexity makes it difficult to do cloud right. Automation is critical to managing this type of infrastructure environment, but certain steps must be followed for a cloud infrastructure to be truly dynamic.

As the cloud began, development organizations needed a way to build their applications in the cloud. Then, they needed a way to monitor the applications, to make sure they were doing what they were supposed to do. Then, there needed to be a way to manage the infrastructure, such as having the ability to change the infrastructure and the ability to decide who can make that change. According to Josh Stella, CEO of cloud infrastructure orchestration startup Fugue, organizations layer on these additional kinds of control features and management features, cobbling an inefficient solution together from point solutions for build and monitoring, when they should be striving to achieve dynamic infrastructure. Stella describes the term as “an automation of the system where you’re no longer thinking about infrastructure, it’s just automatically responding, self-healing, self-enforcing to the environment.” And, he noted, everyone inevitably ends up going there if they go far and deep enough to the cloud.

“What Fugue did is at the very beginning,” he said, “we addressed the very hardest problem, which is how do you fully automate the whole stack and make it so that you can add the new services cloud providers come up with quickly over time and integrate those into that solution. And it turns out when you do that, the control, management, monitoring and build stuff become kind of side effect. …  If you start trying to glue-code these things together and you end up with this sort of Rube Goldberg machine of point solutions and glue code.”

There are two main components to Fugue. The first is Fugue Conductor, which Stella said can be thought of as an orchestration engine, though he also thinks of it as being like an operating system kernel on a traditional computer. “In the Fugue model, all interactions with the APIs go through the Conductor and it knows the state of everything, it enforces the state of everything and it builds everything,” he said. “It does all the provisioning; it does all the teardown. It does all the automated healing over time.

Fugue suggests setting up the Conductor in its own AWS account for security reasons. Conductor has zero network attack surface and does not listen on any ports. The way you talk to the Conductor, Stella said, is through messaging. A user can send it a signed, asynchronous SQS message and when Conductor detects an inbound message, it will only read it if it’s properly signed with correct credentials, he said.

The second piece is called Composition, in which users define their configuration as code. Behind Composition is Fugue’s own DSL statically typed language and a compiler that will let users know if they’re trying to do something that AWS won’t allow. “A great example is .. if you try to deploy to a region that doesn’t exist, the compiler will reject it and tell you, ‘No, there is no region US West 4.’ You might have meant US West 1 or 2,” Stella said.

Fugue also has released a new Team Conductor that gives control of multiple AWS accounts as well as multi-user role-based access.

Stella gave an example of Fugue Conductor in action.  “It would be, ‘I want to have only these certain ports open on my firewall,’ and somebody goes into the AWS console or runs a script, or is a bad guy and breaks in and opens a hole, a back door, to open another port. Within 30 seconds Fugue is going to see that that has happened and it’s going to log it, it’s going to alert on it, and it’s going to fix it. This ‘over time’ automation of the environment is the hard part; that’s the important part. If you don’t have that, even if you automate your provisioning, you don’t really have infrastructure as code, because you never know past the moment of creating whether it’s changed. And so you can’t trust your code to tell you what’s in your infrastructure. With Fugue you can.”

About David Rubinstein

David Rubinstein is editor-in-chief of SD Times.