A New Paradigm for Cloud: Architecting Control ... New Paradigm for Cloud: Architecting Control Resilience ... architecture-in-action across multiple AWS ... Architecting Control Resilience at Scale ...

Download A New Paradigm for Cloud: Architecting Control ...  New Paradigm for Cloud: Architecting Control  Resilience ... architecture-in-action across multiple AWS ... Architecting Control Resilience at Scale ...

Post on 06-Feb-2018




2 download

Embed Size (px)


  • 2017 Fugue Inc. // www.fugue.co

    A New Paradigm for Cloud: Architecting Control & Resilience at Scale with Fugue

    W H I T E PA P E R

    When you decide to migrate to the cloud, use a hybrid cloud

    model, or architect from the start in the cloud, youre thinking

    about your systems designthe infrastructure choices

    youve made and will make to support application integrity.

    Known problem spaces present thorny questions and partial,

    often convoluted, answers for every cloud architect making

    these choices. Mistakes are expensive. The path to a resilient

    architecture is a labyrinth. Architecture needs to be flexible

    enough to adapt to rapid, ongoing change but characterized by

    a sustainable core design and by time-tested cloud principles.

  • A New Paradigm for Cloud: Architecting Control & Resilience at Scale with Fugue 2 / 14A New Paradigm for Cloud: Architecting Control & Resilience at Scale with Fugue

    The specific challenges are familiar. Youve got to plan for a dynamic operations environment, where scaling pain isnt just about horizontal and vertical capacity. Right now and into the next decade, its about scaling smartly amid tool, service, and component complexity, where these tools, services, and components change frequently and unpredictably. Youve got to establish an ecosystem that accommodates those continuous infrastructure transitions and user growth. Youve got to future proof by making software that lasts because it implements best cloud practices and can be renewed and refreshed easily. Youve got to know infrastructure state with confidence and accuracy in order to make cost-effective decisions as you continue to tune and develop apps or respond to changing market demands. Youve got to ensure resilience against misconfiguration, drift, unexpected interference, and outage. Youve got to manage security responsibilities and compliance requirements in an automated, reproducible manner. Youve got a lot on your mind.

    This paper zeroes in on cloud architecting pain points and demonstrates that Fugue is a system that responds comprehensivelynot in piecemeal, point-solution fashion. Fugue takes a new approach to infrastructure orchestration for enterpriseswith a typesafe, compiled language, a process model, and an enforcement enginethat reduces cloud footprint and drives application performance.

    With Fugue, security isnt merely a bullet point in a list of features, but a principle upon which system design is centered. Controlled access to shared resources is critical, especially when multiple operators and accounts are involved. Policy as code through typesafe, compiled, language libraries; secure collaboration through role-based access controls; and fortified permissions through replicable and auditable language abstractionsall form layers of security for enterprises operating at scale in the cloud.

    SEE FIGURE 1: An Overview of Fugue

    PART I

    Orchestrating Complexity at ScaleConsider the evolution and proliferation of cloud services and their relentless pace of development. Cloud providers offer improved and new options ev-ery year, sometimes multiple times a year, as do third party vendors. Some services are more successful than others. Most lend themselves to elastic scaling, with parameters that may require attention.

    Horizontal and Vertical Growth

    A common, elastic service is Amazon Web Services Auto Scaling Groups (ASGs), which easily automates horizontal scaling based on demand within limits a user can specify. Vertical scaling, on the other hand, requires a bit more in terms of manual intervention. With ASGs, you can create several launch configurations that specify different instance sizes, addressing your vertical needs, and perhaps build a Lambda function that updates the launch configuration. Its trickier if youre using reserved instances, as you may be stuck in the same instance family. And, when you resize instances in Amazon Web Services (AWS) in any scenario, there are a series of compatibility issues, considerations with attaching and detaching volumes, as well as manual stop/suspend/restart actions to keep in mind. The cloud architect has to think about those vertical scaling intricacies within enterprise systems. Theyre entirely doable, but they have a time-consuming, manual cost. You can be left wondering whether youre saving money by utilizing only whats needed or whether you have overemployed instance sizing to account for spikes, as happens routinely with servers in traditional data centers. Estimating should be a science fed by sound, abundant data, but it often ends up feeling like an art.

    Tool, Component, and Services Growth

    Tackling scaling problems comprehensively requires that we think about these typical modes

  • 3 / 142017 Fugue Inc. // www.fugue.co

    of scaling within the context of clouds proliferation of services. Amid a software release schedule of your own thats likely aggressive, youre making relatively straightforward choices about horizontal scaling and more complicated choices about vertical scaling in an environment of increasing, ubiquitous, overlapping services and the constant availability of new point solutions, some of which your developers are actively using. Youre concerned about which members of your team should manage each potential environment. These factors combined create complexity at scale. Thats the reality in the cloud that isnt easy to orchestrate. Those point solutions tend to tackle a specific problem in your cloud build stage or in your cloud monitoring or in your cloud management, but not in all of those at once.

    Fugue Tackles Complexity

    In this complicated context, Fugue approaches scaling realities holistically, taking advantage of the fact that cloud services are programmable resources. You can code cloud services succinctly with Fugues easy-to-learn language, Ludwig, using compositions to define architectural patterns and libraries already formulated to best practices, but also able to be customized to your systems needs in minutes. You can collapse an elaborate operational sequence into a simple function. You can import an elaborate operational pattern in a single statement. You can author a simple policy to define access and authorization throughout your entire organization. You can get helpful compiler error messages without spending a dime on provisioningmessages that teach you how to better tweak infrastructure configuration. You can run, update, terminate, and replicate your architecture-in-action across multiple AWS accounts with easy, logical commands. By these means, you orchestrate complexity at scale.

    For example, with CloudWatch and SNS expressions in Ludwig, you can ensure a notification when your apps CPU utilization passes a mark, then you can update ASG instance parameters, like group size (horizontal scaling) and instance type (vertical scaling) with a Ludwig function, while at the same time swapping out or modifying other loosely coupled services, if desired, in moments. Then, you can replicate those changes globally via Ludwig

    abstractions, with the assurance that your scaled infrastructure is exactly what youve specifiedno lingering configurations, no uncertainty.

    Immutability Streamlines Complexity

    Fugue employs immutable patterns across its interactions with your application infrastructure. It takes a view of cloud services as disposable resources and acts on them accordingly. Doing so, where its practical, is one of Fugues essential benefits. For example, using the `fugue update` command updates the infrastructure of a running process connected to version one of a composition to match the infrastructure specified in version two of a composition. Updates may be destructive or mutative. A mutative update is an update-in-place for resource properties that can be changed (e.g., VPC tags). A destructive update is one in which the resource properties cannot be changed, so the entire resource is destroyed and replaced with a new one (e.g., an entire ASG with t2.medium instances updated to m4.xlarge instances or a VPC CIDR block replaced with another). This strategy of resource replacementwhere it makes senseis immutable infrastructure in action. Immutable patterns automatically integrated into your system, via another Fugue mechanism, enforcement (discussed in the next section), ultimately optimize your costs and the integrity of your applications deployment. Cruft buildup and uncertainty are eliminated with clean, immutable destruction and replacement cycles that provide clarity when you orchestrate changes to your system at scale.

    The same benefits of immutability hold true when replicating whole architectural patterns for development, testing, and production environments, for disaster recovery purposes as well explore shortly, and for enterprise-scale, geographically diverse deployments. When you assign cleanly abstracted configurations of numerous cloud services in a Ludwig file and then easily convert the given pattern into a Ludwig module, that module can be imported in one line into other Ludwig files. You can swap different modules in and out of composition versions and test them. Youre not modifying infrastructure patterns in the runtime. Youre efficiently versioning your architectural

  • A New Paradigm for Cloud: Architecting Control & Resilience at Scale with Fugue 4 / 14A New Paradigm for Cloud: Architecting Control & Resilience at Scale with Fugue

    patterns that you can test with the compiler at no actual infrastructure costs, then terminating an old pattern and running a new one, again with no in situ modifications. Destroy and replace.

    PART I I

    Knowing Infrastructure State with CertaintyImagine the operations control center in a giant power plantfeeding distributed networks, with dependencies everywhere. Critical to its function are automated mechanisms that constantly check, report, and regulate the state of turbines, generators, cooling equipment, feed pumps, containment structures, and so on. They provide a source of truth on the plants state of operations. If something unexpected occurs, a variety of notifications, reboots, and failsafes are standing by; they spring into action, taking restorative measures to ensure the plant returns to standard operation specifications or appropriate alternatives. Humans in the control center begin all troubleshooting with a knowledge of actual system state in real time and with automated mechanisms already in action to counter unexpected, potentially disastrous events.

    In cloud computing, this analogy is powerful for architecting well. Having an operations control center to responsively manage complex, scaled applications with real time knowledge of infrastructure state and with automated tasking that enforces configuration is a foundational hub cloud architects need. But, its often the missing piece in a systems architecture, the lack of which necessitates all sorts of costly investigative work. Knowing infrastructure state with certainty in real time is the fastest, clearest route to ensuring a systems fidelity.

    How Infrastructure Is Known

    Fugue enables your entire cloud infrastructure to be known at any time. It is:

    declared in compositions (.lw) with Ludwig and compiled for error checking before expensive provisioning, then

    governed as a process via the Fugue CLI (a Fugue process is an instance of a infrastructure composition that the Conductor works to build and maintain), then

    implemented and enforced via the Conductor, which behaves as the control center for application state.

    To be enforced means that infrastructure state is automatically returned to whats designated in a compositions Ludwig declarations, should unplanned and unwanted changes occur. This is one of the Conductors primary responsibilities. Only by running new composition processes or updating existing ones, as youve seen, can configuration details vary. Fugue eliminates configuration drift and manual, human mistakes with enforcement. You always know whats running with no ambiguity.

    SEE FIGURE 2: Fugues Enforcement of Straying Infrastructure

    How does enforcement really work? The Conductor is comparable to a kernel at the infrastructure layer. It runs on an instance inside your cloud account and within its own isolated network, which it creates. A single Conductor can seamlessly replicate configurations across multiple accounts. It has no open ports and outbound communications are solely with cloud provider APIs. In reality, its a collection of components, including one that executes against cloud service APIs (the broker) and one that reads what their current state is (the reflector) on a continual, automated schedule. They are the write and read components of the Conductors virtual machine and, through them, the Conductor establishes the truth of a system, a known state of infrastructure.

  • 5 / 142017 Fugue Inc. // www.fugue.co

    Inverse Configuration Tracking

    You also can think about Fugues system of guarantees as an inverse configuration management database (CMDB). With other approaches to tracking change, authorized people establish individual configuration items (CIs) for a running system and record them. With Fugue, first you build whats in essence a CMDB, and then the Conductor uses that CMDB to build your configuration items (CIs). So,

    system administrators create policy governing authorized personnel and access.

    authorized personnel devise a CMDB for a complete, controlled system (a Fugue composition).

    the Conductor makes the configuration in the CMDB a reality (a Fugue process).

    other maintainers & auditors can view the configuration directly through the composition code.

    For the cloud architect, regardless of the conceptual comparisons, infrastructure state is always known with certainty since the Conductor is always enforcing the declarations in your compositions. Youve got an undisputed source of truth.

    Other Views of Your Infrastructure

    While a Fugue composition is your constantly verified infrastructure outlay, its worth noting that on the Fugue CLI, you can simply type lwc and a Ludwig file (.lw) name to see the complete, compiled code for that file. You can use Fugues verbose -v flag and --dry-run flag as in fugue -v run --dry-run example.lw to see your compiled compositions process mapped out in JSON with all infrastructure details. If there are errors, the compiler will catch them here before you provision any actual infrastructure and run up any AWS cost. And, once Fugue has built and is operating your infrastructure, you can use fugue status with various flags to get more information about your infrastructure during the actual build or tear-down process.

    PART I I I

    Meeting Shared Security Responsibilities for Multiple UsersArchitecting for robust security is a pressing challenge with scaled cloud deployments. AWS frequently reminds its users that cloud security is a shared responsibility. It offers global and service level options with all kinds of granular settings to ma...


View more >