Download - A New Paradigm for Cloud: Architecting Control ... · PDF fileA New Paradigm for Cloud: Architecting Control & Resilience ... architecture-in-action across multiple AWS ... Architecting

©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, you’re thinking

about your system’s design—the infrastructure choices

you’ve 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. You’ve got to plan for a dynamic operations environment, where scaling pain isn’t just about horizontal and vertical capacity. Right now and into the next decade, it’s about scaling smartly amid tool, service, and component complexity, where these tools, services, and components change frequently and unpredictably. You’ve got to establish an ecosystem that accommodates those continuous infrastructure transitions and user growth. You’ve got to future proof by making software that lasts because it implements best cloud practices and can be renewed and refreshed easily. You’ve 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. You’ve got to ensure resilience against misconfiguration, drift, unexpected interference, and outage. You’ve got to manage security responsibilities and compliance requirements in an automated, reproducible manner. You’ve got a lot on your mind.

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

With Fugue, security isn’t 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 abstractions—all 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. It’s trickier if you’re 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. They’re entirely doable, but they have a time-consuming, manual cost. You can be left wondering whether you’re saving money by utilizing only what’s 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 / 14©2017 Fugue Inc. // www.fugue.co

of scaling within the context of cloud’s proliferation of services. Amid a software release schedule of your own that’s likely aggressive, you’re 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. You’re concerned about which members of your team should manage each potential environment. These factors combined create complexity at scale. That’s the reality in the cloud that isn’t 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 Fugue’s 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 system’s 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 provisioning—messages 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 app’s 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 you’ve specified—no 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 it’s practical, is one of Fugue’s 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 replacement—where it makes sense—is 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 application’s 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 we’ll 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. You’re not modifying infrastructure patterns in the runtime. You’re efficiently versioning your architectural


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 plant—feeding 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 plant’s 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, it’s often the missing piece in a system’s 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 system’s 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 what’s designated in a composition’s Ludwig declarations, should unplanned and unwanted changes occur. This is one of the Conductor’s primary responsibilities. Only by running new composition processes or updating existing ones, as you’ve seen, can configuration details vary. Fugue eliminates configuration drift and manual, human mistakes with enforcement. You always know what’s running with no ambiguity.

SEE FIGURE 2: Fugue’s 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, it’s 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 Conductor’s virtual machine and, through them, the Conductor establishes the “truth” of a system, a known state of infrastructure.


Inverse Configuration Tracking

You also can think about Fugue’s 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 what’s 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. You’ve got an undisputed source of truth.

Other Views of Your Infrastructure

While a Fugue composition is your constantly verified infrastructure outlay, it’s 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 Fugue’s verbose -v flag and --dry-run flag as in fugue -v run --dry-run example.lw to see your compiled composition’s 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 make a system less vulnerable, as do other cloud providers. But, the majority of users who have big deployments don’t take full advantage of security options or use them in an optimized way because it’s highly complicated to do so and to ensure consistency in doing so.

Fugue is developing architectural patterns in Ludwig modules that integrate best security practices, for example, around security group implementations. An architect can use and tweak those or completely customize a module for improved security then reproduce that module with one line of code across compositions. Being able to quickly replicate and share consistent security parameters in this way throughout many dev, test, and production environments is an architecting advantage.

Using Ludwig Abstractions to Simplify and Fortify Permissions

Let’s get more specific on this point. Consider permissions and AWS’s Identity and Access Management (IAM) service. The fastest bits to rot are permissions. Permissions have a tendency to get opened and not get closed again. Reclaiming that is a tough problem, but it starts with knowing what you‘ve granted to team members. You can specify permissions with IAM policies or use pre-canned IAM policies that may or may not address what you want to do—what actions you want performed upon which resources. IAM is great software that’s hard to spoof,


but more granular management of permissions with it is time-consuming. When you need to be atomical rather than categorical about permissions—granting a few users read access to a particular S3 bucket or part of a bucket, granting others some control of ELBs, etc.—that level of complexity begs for abstraction. You can write atomically with Ludwig, then easily reuse those IAM abstractions and tweak definitions. You’ll have a complete and known view of all permissions and control of those in your composition code. Again, that means simplified replication and automation across sprawling, multi-user deployments. Instead of trusting human checks everywhere, you’re trusting an enforced, declarative system.

Another Layer of Protection with Enterprise Features

Excellent security across teams is layered. A cloud architect planning this seamlessly and in advance is great strategy. While you can have Ludwig IAM functions and security group patterns defined, known, and reproducible via compositions, Fugue offers a Team Conductor that includes Role-based Access Controls (RBAC) and multi-account management capabilities to further support teams that are working on different parts of systems or applications.

Fugue’s multi-account capabilities allow customers to manage their AWS infrastructure using a single, consistent interface—that is, a single Conductor—regardless of how resources are instantiated across different users’ AWS accounts. The fugue run command in the Fugue CLI has an optional flag that allows you to specify the account you wish to target when you run a given composition. Using many accounts governed by the same Conductor gives teams both flexibility and control in distributing workloads. Complementing this is RBAC. Teams with sensitive workloads may wish to restrict their members’ access to AWS and to certain Fugue functions based on roles and responsibilities. RBAC works with the multi-account feature: You can author RBAC policy that limits the actions a user can perform on specific accounts the Conductor is managing. So, if Alice is an administrator in the admin group, she can perform any operation on any

resource that Fugue knows about. But Bob, as a web developer and user in the webDev group, can only run, update, and kill compositions in the web account; he isn’t permitted to manage compositions in other accounts.

To use RBAC, you use Ludwig. You declare users and authorizations applied to users via Fugue-provided RBAC policy types and attach the policy to the Conductor using the RBAC CLI commands. The Conductor will evaluate the attached policy and create (or remove) users, as well as authorize their actions, based on your declarations. You also can create pseudo-groups in your Ludwig RBAC policy declarations, which allow you to apply authorization policies to a group of users rather than to each user individually.

An enterprise is able to establish well articulated practices with these collaboration features that fortify system security by managing human intervention in ways that are difficult to bypass on accident or with intention. You’re using code, in advance of resource provisioning, and a few commands to resolve a major, “on the ground” pain point for large teams.

Managing Compliance

Another especially daunting pain point for cloud architects within the broad scope of security concerns involves compliance. Ensuring compliance with laws protecting people and data—HIPAA, PCI-DSS, and FISMA, for example—is a precision undertaking that can encompass cloud resource attributes like encryption settings, allowed resources types, and network configuration. Current approaches to address complex regulatory requirements frequently utilize point solutions rather than holistic solutions that integrate with an organization’s existing DevOps and business processes.

Fugue’s validations feature empowers organizations to define and automatically enforce compliance policies for their cloud infrastructure within an existing workflow or otherwise. The feature checks infrastructure definitions at multiple points across the resource lifecycle to prevent non-compliant


infrastructure from being created. In effect, validations codify policies.

Typically implemented at the module level in Ludwig, validations are expressions that you can use to assert properties about values. With validations, you can perform automated checks such as ensuring AWS resource attributes or metadata contain a specific value or are within a range of values, as well as enforcing policies around resource creation. Developers can use validations locally when working on new compositions to certify that those compositions are compliant before interacting with the Conductor. If a composition does not comply with any of the policies defined by a validation, the process is not instantiated.

SEE FIGURE 3: How Val idat ions Work

Validations can be enforced across multiple teams and accounts. All accounts managed by a Team Conductor we reviewed in the previous section can be subject to validations made specific to that Conductor. And, the ability to add and remove validations controlled by that Conductor can be limited to specific users via RBAC. All this tightens the architecture around compliance objectives ensuring safe and secure team collaboration.

Consider HIPAA compliance in particular. AWS provides all the tools necessary to guarantee that Protected Health Information (PHI) can be transmitted and stored securely in principle. But ensuring that a given architecture actually complies with HIPAA can be a grueling process, generally implemented by way of arduous monitoring, reporting, and manual fiddling. Ludwig’s validations can assist greatly. Rather than constantly examining running infrastructure or grepping untyped configuration files, we can rule out certain HIPAA-violating conditions at compile time simply by registering HIPAA-validating functions in imported modules. And this leads to a rapid logical conclusion: if AWS provides the facilities to comply with HIPAA, and we can write individual validations that assert that all HIPAA-compliant properties are met, then we can create a stand-alone policy that asserts HIPAA

compliance and use it anywhere we might need, triggered by a single statement like import Fugue.HIPAA.AWS in a composition.

Vars and Passwords

As code sharing and collaboration services like Github and Bitbucket are becoming more and more prevalent in software development ecosystems, cloud architects hear stories time and again of organizations accidentally committing passwords and secrets into their code repositories. Even in an environment where you may not be using third-party services to store your code, it’s still considered an ill-advised and insecure practice to hardcode passwords into your software.

For example, database passwords shouldn’t be hard-coded for many reasons. If you write passwords into your code, every software developer who works on the project will know that password. For many organizations, this can be a security nightmare. As far as operations and system administration are concerned, if you ever want to change or rotate your password, you’ll have to redeploy your entire application just for a simple configuration update. Wouldn’t it be great if there were a way to securely store those passwords in one place and have it available to all of your instances?

Vars is Fugue’s replicated key/value store that has features and semantics that make it useful for coordination, configuration sharing, credential synchronization, and more. You can put values into the key/value store while taking advantage of Vars’ built-in encryption system to manage database passwords securely. The straightforward process to do so is laid out in Scalable Cloud Ops with Fugue, published by The Pragmatic Programmers, but a visual summation is shown here:

SEE FIGURE 4: Secure Password Management

010101 111001 000110


Security in the Fabric

Finally, more peace of mind for cloud architects comes embedded in security native to Fugue itself. Fugue has no open ports. It uses asynchronous communications. It manages the creation and modification of cloud resources with role-based access control. No one can go into the AWS Console and override your security groups or other declared infrastructure choices without that change being caught, reported, and reverted.

You can think of the Conductor itself as being much like a kernel (but, for a global cloud computer) in that it creates Fugue processes, manages them, and can destroy them. This provides a clear line between user space, in which Fugue processes are initiated, and kernel space, where the control over those processes is held. Just as with a traditional kernel OS, kernel space is considered hands-off for most direct interactions, so that the system is safe and remains in a known-good state.

PART IV

Planning for Failure: Fugue Speeds Disaster RecoveryEfficient disaster recovery (DR) depends on a system architected for unexpected, but graceful failure by using high availability design patterns. In such patterns, multiple components can fail with minimal disruption to the system. Redundancy is the key to counter single points of failure and more widespread outages, but it can be expensive if managed poorly. AWS services have robust features to detect failure, automate deployment to multiple Availability Zones, ensure durable storage, make clients fault tolerant, and aid in replication and right-sizing. Actually taking advantage of them and deciding on the best, most optimized combination of specific service features for DR is no small task. Making good, cost-effective decisions is very much dependent upon knowing

exactly what you have—recall our discussion on knowing infrastructure state completely and with certainty.

Having that complete, clear view of your system, what’s built, with known configuration via a Fugue composition is a step that helps you quickly get an optimized recovery plan implemented. With Fugue, you can codify many resilient architecture patterns that work with your service definitions. You can respond to outages fast with swappable and easily deployed composition sets giving you an immediate replication of whole environments that’s automated in your build system.

It’s worth noting too that Fugue also allows you to manage multiple, dynamic cloud environments that span numerous AWS accounts and to define services across multiple regions however you want. If you have a single deployment that needs to cross regions (for example, in a DR strategy that requires a two-region footprint with an IPSec tunnel between the regions), you can define them in one place with Ludwig.

Finally, when unsafe or aberrant behavior unfolds on the other side of a cloud API indicating a provider outage, a Fugue Conductor, following its core design, automatically errs on the side of caution and stops work immediately—popping the metaphorical circuit breaker. Each Conductor, comparing actual infrastructure state for an application against declarations in a composition (the source of truth), cannot verify consistency. When a Conductor consumes messaging that indicates its view of the world is inaccurate, it halts all change. As the core service disruption calms and a Conductor’s view of the world is restored, it’s designed to take a single resume command and continue work without missing a beat. Since all change was halted, since its async messages were not marked as read, and since the design is idempotent and stateless, a Conductor can start operating on a message again with nothing corrupted. That aids in speedy recovery.


PART V

Fugue & Enterprise EngagementFugue is available now. You can build, manage, enforce, and terminate your cloud workloads at scale, continuously and automatically with it. The free Basic Conductor allows you to experiment with a single AWS account and provides support for a single user. Fugue’s engineers and representatives will work with you to implement Fugue patterns that make spin up and tear down of dev and test environments truly quick and painless. We’re also here to help your enterprise dramatically reduce the complexity that accompanies large, sprawling deployments in production. Transition efficiently to the cloud with Fugue or build there from the start, taking full advantage of cloud’s native flexibility and scale.

Fugue’s Basic Conductor and Team Conductor are both available now. While the Fugue Basic Conductor is free, the Fugue Team Conductor is available for purchase and includes multi-account capabilities, Role-based Access Controls (RBAC), and upcoming features like validations. In addition, you’ll have access to comprehensive, enterprise-level support. Regardless of your requirements, we’re here to help you identify the best option for getting started.

Check out our resources too at https://fugue.co/resources/ where you can review our explanatory webinars, books from O’Reilly and The Pragmatic Bookshelf, demos, videos, white papers, one sheets, and other materials. Get started today, radically simplifying your cloud ops.


A New Paradigm for Cloud: Figures 1-4

A P P E N D I X

The following diagrams outline the powerful impact Fugue

will have on your cloud management. Fugue’s CLI and

Conductor build and operate infrastructure according to your

commands, enforce straying infrastructure, automate regulatory

compliance, and enable secure password management.


FIGURE 1: An Overview of Fugue

As shown, you define infrastructure in compositions, tailor policies suitable to your environments, and issue commands on Fugue’s

CLI. The Conductor takes it from there—building, operating, enforcing, and tearing down infrastructure via processes. It provides a

concise, accurate view of an application’s cloud footprint, its workloads in multiple accounts at any given time, and automatically

returns straying infrastructure to desired declarations.

P O L I C I E S C O M P O S I T I O N S

T E A M C O N D U C T O RC O M P L I A N C E & R B AC P O L I C I E S

P R O C E S S E S

WO R K LOA D BWO R K LOA D A

Attach Policy

Account 1 Account 2

API Calls

Create / ModifyProcess

User View

WO R K LOA D C

F U G U E C L I

A D M I N O R U S E R S

CLI

EN

TC

ON

DU

CTO

RA

WS

AC

CO

UN

TA

WS

AC

CO

UN

TS


FIGURE 2: Fugue’s Enforcement of Straying Infrastructure

In this series, the Conductor (center) builds, manages, and enforces composition declarations (left), checks running

infrastructure on a schedule (right), notices an attacker’s changes not defined in the composition, and responds by

rebuilding the manipulated components.

USER

UNAPPROVEDCHANGE

You declare your system in a Fugue composition.

CONDUCTOR

System is created. Every 30 seconds, your system is compared to the declarations in your composition.

An unapproved change modifies part of your system.

The Conductor sees drift and rebuilds the missing component.

FUGUE COMPOSITION RUNNING INFRASTRUCTURE

30 Seconds

30 Seconds

30 Seconds


FIGURE 3: How Val idat ions Work

Validations are Ludwig expressions used to

implement internal ops rules and external compliance

policies. They can be imported as a library into a

Fugue composition or loaded directly onto the

Conductor for additional security. The Ludwig compiler

(lwc) provides an error and useful message if a validation

is violated. No infrastructure is created until the

correction is made and the policy honored.

YOU

R LO

CA

L MA

CH

INE

CO

ND

UC

TOR

SIMPLE CLIENT SIDE VALIDATIONS

CONDUCTOR SIDE VALIDATIONS

L I B R A R I E S VA L I DAT I O N L I B R A R I E SC O M P O S I T I O N L I B R A R I E S VA L I DAT I O N

L I B R A R I E SC O M P O S I T I O N

L I B R A R I E S VA L I DAT I O N L I B R A R I E SC O M P O S I T I O N

User View

010101010101010001011

parse, rename, typecheck, simplify

compute output nodes

validate output nodes

Compiled Output

Sent to Conductor

Snapshot

Sent to ConductorUploaded by Admin

Compiled Output

Processed by Conductor

Processed by Conductor



validate output nodeslwc

L I B R A R I E S VA L I DAT I O N L I B R A R I E S

VA L I DAT I O N L I B R A R I E SC O M P O S I T I O N

010101010101010001011



validate output nodes

Compiled Output

lwc

lwc

010101010101010001011

Compiled Output

Discarded

010101010101010001011


FIGURE 4: Secure Password Management

As a distributed variable service bundled with the Fugue client package, Vars functions as a service registry, service discovery

tool, configuration synchronization service, and lock service all in one. You also can use Vars to securely share secrets or manage

passwords as shown. Vars can be used independently of Fugue as well.

INSECURE PASSWORD MANAGEMENT

SECURE PASSWORD MANAGEMENT

D E V E LO P E R

V E R S I O NC O N T R O L

F U G U EC O N D U C T O R

.lw......password:“!password”...

C O M P O S I T I O N

D E V E LO P E R

V E R S I O NC O N T R O L

F U G U EC O N D U C T O R

.lw......password:Vars.VarsKey...

C O M P O S I T I O N

AW SK M S

Decrypt Password

Encrypt Password

Download - A New Paradigm for Cloud: Architecting Control ... · PDF fileA New Paradigm for Cloud: Architecting Control & Resilience ... architecture-in-action across multiple AWS ... Architecting

Top Related