Fugue and Ludwig Internals¶
How Does Fugue Work?¶
How does Fugue work?
Fugue runs on a virtual machine (EC2 instance) inside your Amazon Web Services account and uses cloud APIs to build, update, and enforce your infrastructure.
There are two main components to Fugue: the CLI, which is installed locally, and the Fugue Conductor, which is installed in your AWS account. Take a look at the System Architecture page to read more about Fugue’s components and how they operate.
Is Fugue an SaaS / PaaS?
Fugue is a software product, not Software as a Service (SaaS) or Platform as a Service (PaaS). You run the Fugue software inside your own cloud account. Fugue does not “call home” to Fugue, Inc. or any third party; we’ve taken this approach to meet the requirements of our more complex and security-conscious customers.
We put a lot of effort into making Fugue easy to adopt and run. With Fugue, you get the simplicity of a PaaS without the limitations that can affect your application architecture and often prohibit you from customizing your infrastructure.
How does Fugue enforce infrastructure?
Fugue continuously inspects your running cloud infrastructure and compares it to the declarations in your composition. Whenever Fugue identifies a difference between what you’ve declared and what’s running, it returns your infrastructure to the way it should be. To see when such events have occurred, check the Fugue broker logs, as shown in the Fugue User Guide’s Logging chapter.
How does Fugue do all of this “continuously and automatically”?
Your Ludwig composition represents the desired state of your cloud infrastructure. Fugue runs in your AWS account and continuously monitors your infrastructure to compare its current state against the desired state declared in the composition. If there are differences, Fugue automatically corrects them to match the desired state and notifies you of the changes.
Does Fugue “call home”?
No, Fugue does not “call home.” The Fugue CLI is installed on a client machine you control, such as your laptop or an EC2 instance within your AWS account, and the Fugue Conductor runs on another EC2 instance within your AWS account. There are no open ports on protocols on the Fugue Conductor. The Fugue Conductor and Fugue CLI communicate with each other using the AWS API, but neither component sends information back to Fugue, Inc. or anyone else.
How does Fugue handle security?
Fugue is designed from the ground up to be a secure system. The Fugue security model values risk avoidance over risk reduction, and best practices for defense-in-depth are followed. The exact security posture of a running Fugue instance depends on some choices you can make as a user, but we recommend the following best practices:
- Do not enable any inbound TCP connections to the Fugue Conductor. Not even SSH. All communication required with it can be done via asynchronous messages, object storage, or similar. These resources are all protected by privileged AWS API calls, and the Fugue CLI handles all of this communication for you. Troubleshooting or other exceptional circumstances may require exceptions to this rule, but they should be just that – exceptions.
- Run Fugue in a dedicated AWS account, apart from those used for your actual application infrastructure. This way, application accounts can vend a privileged role to the Fugue account, but the application accounts cannot control the privileged Fugue account. Using the Consolidated Billing feature, you can easily separate concerns among accounts but have one bill to pay.
How do Compositions work?¶
How does Ludwig work?
The short answer is that Ludwig is Fugue’s programming language. It uses a very simple syntax in files called compositions to automatically build, update, and maintain your declared infrastructure.
Take a look at the Ludwig Programming Guide for a more in-depth exploration of Ludwig, how it works, and to view some examples of Ludwig compositions.
What is “infrastructure as code”?
Infrastructure used to be just infrastructure. It meant servers sitting in a rack, with cables and routers between them and some cables going to the outside world. Making tweaks to the infrastructure actually required physical changes. This is undesirable for obvious reasons, which is why we turned to software-defined infrastructure: that way, it is possible for software to make changes to the infrastructure, instead of having to make hardware changes. The core idea is that the infrastructure is defined by code, in our case this means Ludwig. This approach allows at-a-glance visibility into what the infrastructure is like along with version control, compliance and policy enforcement, auditing, automation, and abstraction.
Why did you write your own language?
We wrote Ludwig to provide a customized solution for cloud automation. At Fugue, we gave developing Ludwig a lot of consideration. We knew that new languages impose a burden, though we strive to make Ludwig easy to learn. We decided to develop Ludwig after we reasoned that Fugue is a new kind of software, with a new approach to thinking about and solving cloud automation problems.
To read more about our thinking on this check out Why Ludwig? in the Ludwig Programming Guide.
Why should I care that Ludwig is “statically typed”?
Ludwig is statically typed, as every value is known at compile time (i.e., before the program runs). This allows Ludwig’s compiler to check the static types prior to running a composition (Ludwig file) in AWS, preventing a large class of potential errors.
While no type system can prevent all errors, in Ludwig every value has a type and each of these is checked. Additionally, Ludwig has type inference, which means that the compiler can infer the type of a value from how it’s used. That way, the number of type annotations the programmer has to write is kept to a bare minimum.
Do I need to be a programmer to write Ludwig?
In the most common Ludwig use cases, examples are provided. Users can edit the values in the text (Ludwig) file to meet their specific configuration needs. That being said, if you want to extend our libraries or build files with more complex patterns, some programming experience (in any language) can be very useful.
How does Ludwig compare to common programming languages?
In general, Ludwig is a bit different when compared to common programming languages such as Python, Java, and C/C++. Since value immutability is an important property of the language, it is closer to languages such as Erlang or Haskell.
In addition, Ludwig is a functional language and does not have the concept of an object or class. There is only data, and functions that consume and produce said data. This means that the language is relatively simple, but powerful. That said, you do not need to have a working understanding of functional programming to use Ludwig.
Can I create my own Ludwig libraries?
Yes, this option is available for advanced users. Contact firstname.lastname@example.org for additional details.
Where can I find other Ludwig libraries?
Existing Ludwig libraries are included in the Fugue installer and listed in the documentation under the Fugue Standard Library. At present, Fugue does not include a system to share any 3rd-party libraries.