Tag: DevOps

Flux7 and AWS Present High Performance Computing Immersion Day

Flux7 and AWS Present High Performance Computing Immersion Day

Array ( [0] => WP_Term Object ( [term_id] => 90 [name] => Blog [slug] => blog [term_group] => 0 [term_taxonomy_id] => 90 [taxonomy] => category [description] => [parent] => 0 [count] => 413 [filter] => raw ) [1] => WP_Term Object ( [term_id] => 4468 [name] => Uncategorized [slug] => uncategorized [term_group] => 0 [term_taxonomy_id] => 4468 [taxonomy] => category [description] => [parent] => 0 [count] => 413 [filter] => raw ) )

from Flux7 DevOps Blog

Consul Connect Integration in HashiCorp Nomad

Consul Connect Integration in HashiCorp Nomad

At Hashiconf EU 2019, we announced native Consul Connect integration in Nomad available in a technology preview release. A beta release candidate for Nomad 0.10 that includes Consul Connect integration is now available. This blog post presents an overview of service segmentation, and how to use features in Nomad to enable end-to-end mTLS between services through Consul Connect.

Background

The transition to cloud environments and a microservices architecture represents a generational challenge for IT. This transition means shifting from largely dedicated servers in a private datacenter to a pool of compute capacity available on demand. The networking layer transitions from being heavily dependent on the physical location and IP address of services and applications to using a dynamic registry of services for discovery, segmentation, and composition. An enterprise IT team does not have the same control over the network or the physical locations of compute resources and must think about service-based connectivity. The runtime layer shifts from deploying artifacts to a static application server to deploying applications to a cluster of resources that are provisioned on-demand.

HashiCorp Nomad’s focus on ease of use, flexibility, and performance, enables operators to deploy a mix of microservice, batch, containerized, and non-containerized applications in a cloud-native environment. Nomad already integrates with HashiCorp Consul to provide dynamic service registration and service configuration capabilities.

Another core challenge is service segmentation. East-West firewalls use IP-based rules to secure ingress and egress traffic. But in a dynamic world where services move across machines and machines are frequently created and destroyed, this perimeter-based approach is difficult to scale as it results in complex network topologies and a sprawl of short-lived firewall rules and proxy configurations.

Consul Connect provides service-to-service connection authorization and encryption using mutual Transport Layer Security (mTLS). Applications can use sidecar proxies in a service mesh configuration to automatically establish TLS connections for inbound and outbound connections without being aware of Connect at all. From the application’s point of view, it uses a localhost connection to send outbound traffic, and the details of TLS termination and forwarding to the right destination service are handled by Connect.

Nomad 0.10 will extend Nomad’s Consul integration capabilities to include native Connect integration. This enables services being managed by Nomad to easily opt into mTLS between services, without having to make additional code changes to their application. Developers of microservices can continue to focus on their core business logic while operating in a cloud native environment and realizing the security benefits of service segmentation. Prior to Nomad 0.10, job specification authors would have to directly run and manage Connect proxies and did not get network level isolation between tasks.

Nomad 0.10 introduces two new stanzas to Nomad’s job specification—connect and sidecar_service. The rest of this blog post shows how to leverage Consul Connect with an example dashboard application that communicates with an API service.

Prerequisites

Consul

Connect integration with Nomad requires Consul 1.6 or later. The Consul agent can be run in dev mode with the following command:

bash
$ consul agent -dev

Nomad

Nomad must schedule onto a routable interface in order for the proxies to connect to each other. The following steps show how to start a Nomad dev agent configured for Connect:
bash
$ sudo nomad agent -dev-connect

CNI Plugins

Nomad uses CNI plugins to configure the task group networks, these need to be downloaded to /opt/cni/bin on the Nomad client nodes.

Envoy

Nomad launches and manages Envoy, which runs alongside applications that opt into Connect integration. Envoy acts like a proxy to provide secure communication with other applications in the cluster. Nomad will launch Envoy using its official Docker container.

Also, note that the Connect integration in 0.10 works only in Linux environments.

Example Overview

The example in this blog post enables secure communication between a web application and an API service. The web application and the API service are run and managed by Nomad. Nomad additionally configures Envoy proxies to run alongside these applications. The API service is a simple microservice that increments a count every time it is invoked. It then returns the current count as JSON. The web application is a dashboard that displays the value of the count.

Architecture Diagram

The following Nomad architecture diagram illustrates the flow of network traffic between the dashboard web application and the API microservice. As shown below, traffic originating from the dashboard to the API is proxied through Envoy and secured via mTLS.

Networking Model

Prior to Nomad 0.10, Nomad’s networking model optimized for simplicity by running all applications in host networking mode. This means that applications running on the same host could see each other and communicate with each other over localhost.

In order to support security features in Consul Connect, Nomad 0.10 introduces network namespace support. This is a new network model within Nomad where task groups are a single network endpoint and share a network namespace. This is analogous to a Kubernetes Pod. In this model, tasks launched in the same task group share a network stack that is isolated from the host where possible. This means the local IP of the task will be different than the IP of the client node. Users can also configure a port map to expose ports through the host if they wish.

Configuring Network Stanza

Nomad’s network stanza will become valid at the task group level in addition to the resources stanza of a task. The network stanza will get an additional ‘mode’ option which tells the client what network mode to run in. The following network modes are available:

  • “none” – Task group will have an isolated network without any network interfaces.
  • “bridge” – Task group will have an isolated network namespace with an interface that is bridged with the host
  • “host” – Each task will join the host network namespace and a shared network namespace is not created. This matches the current behavior in Nomad 0.9

Additionally, Nomad’s port stanza now includes a new “to” field. This field allows for configuration of the port to map to inside of the allocation or task. With bridge networking mode, and the network stanza at the task group level, all tasks in the same task group share the network stack including interfaces, routes, and firewall rules. This allows Connect enabled applications to bind only to localhost within the shared network stack, and use the proxy for ingress and egress traffic.

The following is a minimal network stanza for the API service in order to opt into Connect.

hcl
network {
mode = "bridge"
}

The following is the network stanza for the web dashboard application, illustrating the use of port mapping.

hcl
network {
mode = "bridge"
port "http" {
static = 9002
to = 9002
}
}

Configuring Connect in the API service

In order to enable Connect in the API service, we will need to specify a network stanza at the group level, and use the connect stanza inside the service definition. The following snippet illustrates this

“`hcl
group "api" {
network {
mode = "bridge"
}

service {
name = "count-api"
port = "9001"

connect {
sidecar_service {}
}
}

task "web" {
driver = "docker"
config {
image = "hashicorpnomad/counter-api:v1"
}
}
“`

Nomad will run Envoy in the same network namespace as the API service, and register it as a proxy with Consul Connect.

Configuring Upstreams

In order to enable Connect in the web application, we will need to configure the network stanza at the task group level. We will also need to provide details about upstream services it communicates with, which is the API service. More generally, upstreams should be configured for any other service that this application depends on.

The following snippet illustrates this.

“`hcl
group "dashboard" {
network {
mode ="bridge"
port "http" {
static = 9002
to = 9002
}
}

service {
name = "count-dashboard"
port = "9002"

connect {
sidecarservice {
proxy {
upstreams {
destination
name = "count-api"
localbindport = 8080
}
}
}
}
}

task "dashboard" {
driver = "docker"
env {
COUNTINGSERVICEURL = "http://${NOMADUPSTREAMADDRcountapi}"
}
config {
image = "hashicorpnomad/counter-dashboard:v1"
}
}
}
“`

In the above example, the static = 9002 parameter requests the Nomad scheduler reserve port 9002 on a host network interface. The to = 9002 parameter forwards that host port to port 9002 inside the network namespace. This allows you to connect to the web frontend in a browser by visiting http://<host_ip>:9002.

The web frontend connects to the API service via Consul Connect. The upstreams stanza defines the remote service to access (count-api) and what port to expose that service on inside the network namespace (8080). The web frontend is configured to communicate with the API service with an environment variable, $COUNTING_SERVICE_URL. The upstream's address is interpolated into that environment variable. In this example, $COUNTING_SERVICE_URL will be set to “localhost:8080”.

With this set up, the dashboard application communicates over localhost to the proxy’s upstream local bind port in order to communicate with the API service. The proxy handles mTLS communication using Consul to route traffic to the correct destination IP where the API service runs. The Envoy proxy on the other end terminates TLS and forwards traffic to the API service listening on localhost.

Job Specification

The following job specification contains both the API service and the web dashboard. You can run this using nomad run connect.nomad after saving the contents to a file named connect.nomad.

“`hcl
job "countdash" {
datacenters = ["dc1"]
group "api" {
network {
mode = "bridge"
}

 service {
   name = "count-api"
   port = "9001"

   connect {
     sidecar_service {}
   }
 }

 task "web" {
   driver = "docker"
   config {
     image = "hashicorpnomad/counter-api:v1"
   }
 }

}

group "dashboard" {
network {
mode ="bridge"
port "http" {
static = 9002
to = 9002
}
}

 service {
   name = "count-dashboard"
   port = "9002"

   connect {
     sidecar_service {
       proxy {
         upstreams {
           destination_name = "count-api"
           local_bind_port = 8080
         }
       }
     }
   }
 }

 task "dashboard" {
   driver = "docker"
   env {
     COUNTING_SERVICE_URL = "http://${NOMAD_UPSTREAM_ADDR_count_api}"
   }
   config {
     image = "hashicorpnomad/counter-dashboard:v1"
   }
 }

}
}
“`

UI

The web UI in Nomad 0.10 shows details relevant to Connect integration whenever applicable. The allocation details page now shows information about each service that is proxied through Connect.

In the above screenshot from the allocation details page for the dashboard application, the UI shows the Envoy proxy task. It also shows the service (count-dashboard) as well as the name of the upstream (count-api).

Limitations

  • The Consul binary must be present in Nomad's $PATH to run the Envoy proxy sidecar on client nodes.
  • Consul Connect Native is not yet supported.
  • Consul Connect HTTP and gRPC checks are not yet supported.
  • Consul ACLs are not yet supported.
  • Only the Docker, exec, and raw exec drivers support network namespaces and Connect.
  • Variable interpolation for group services and checks are not yet supported.

Conclusion

In this blog post, we shared an overview of native Consul Connect integration in Nomad. This enables job specification authors to easily opt in to mTLS across services. For more information, see the Consul Connect guide.

from Hashicorp Blog

Flux7 Case Study: Technology’s Role in the Agile Enterprise

Flux7 Case Study: Technology’s Role in the Agile Enterprise

Technology in the Agile EnterpriseThe transition to becoming an Agile Enterprise is one that touches every part of the organization — from strategy to structure and process to technology. In our journey to share the story of how we at Flux7 have moved through the process, today we will discuss how we have adopted specific supporting technologies to further our agile goals. (In case you missed them, check out our first two articles on choosing a Flatarchy and our OKR journey.)

While achieving an Agile Enterprise must be rooted in the business and must be accompanied by an agile culture (more on that in our next article in the series), a technology platform that supports agility can be a key lever to successful Agile transformation.

At Flux7, this means both technologies that support communication and learning for teams to be agile and agile technology automation. Flux7 uses a variety of tools, each with its own specialty for helping us communicate, collaborate and stay transparent. We’ll first take a look at each of these tools and the role it plays, and then we’ll share a couple of ways in which some of these tools come together to create agility.

Agile Communication

As a 100% remote organization, communication is vital to corporate success. As a result, we use several tools to communicate, share files, documents, ideas and more.

  • Slack enables us to communicate in near real-time sharing files, updates, links and so much more. Slack is a go-to resource for everything from quick questions to team updates and accolades.
  • OfficeVibe allows employees to communicate feedback to the organization anonymously. At Flux7 we take feedback gathered from the OfficeVibe LeoBot very seriously and aim for top scores as a measure of our success in creating a thriving culture.
  • Gmail is used for less real-time communication needs, and for communicating with external parties (though we also use Slack channels with our customers); Google Calendar communicates availability and; Google Meet is used widely for internal and external meetings.
Agile Collaboration

Working closely together from a distance may sound antithetical, but with the help of several tools, our teams are able to collaborate effectively, boosting efficiency and productivity. Our favored tools for collaboration are:

  • Trello helps us collaborate on OKRs and customer engagements and is where our teams are able to visualize, plan, organize and facilitate short term and long term tasks.
  • Google Drive allows us to collaborate in real-time as our documents are automatically saved so that nothing can ever be lost. In fact, Flux7 has a main door to Google Drive called the Flux7 Library, which is where all of our non-personnel resources and documents are stored. This is just one way we ensure resources are at employees’ fingertips, helping us to stay transparent, agile and innovative.
  • Zapier automates workflows for us. For example, we make extensive use of its Trello PowerUps to automate things like creating new Trello cards from Gmail messages or updating Trello cards with new Jira issues.
  • GitHub Repositories host and track changes to our code-related project files and GitHub’s Wiki tools allow us to host documentation for others to use and contribute. In fact, the Flux7 Wiki page is hosted in a Git Wiki. The Flux7 Wiki is home to a wide variety of resources — from a Flux7 Glossary to book reviews, PeopleOps tools and more.
  • HubSpot is a marketing automation and CRM solution where sales and marketing teams communicate and collaborate on everything from new sales leads to sharing sales collateral.

Agile Metrics and Measurements
At Flux7 our mantra is to experiment more, fail cheap, and measure results accurately. Helping us to measure accurately are:

  • Google analytics gives Flux7 valuable detail about our website visitors, giving us clear insights into what our visitors care most about. HubSpot analytics also gives us website data. As our CRM, when this data is paired with sales pipeline activity data, it gives us an incredibly rich view of the customer journey, helping us hone business strategy.
  • Slack analytics give Flux7 insight into how the team uses Slack. For example, how many messages were sent over the last 30 days, where conversations are happening and more.
Agile Management & More

Continuous learning and growth are central to Flux7’s culture and values of innovation, humbleness, and transparency. As such, we also have the technology to facilitate ongoing learning with:

  • The Flux7 internal e-book library where employees can check out e-books and audiobooks for ongoing education. Flux7 utilizes Overdrive to secure our online Internal Library. Topics range from Marketing and Business to IT and DevOps Instructional Resources. (For more on our Library, please refer to our blog: Flux7 Library Drives Culture of Learning, Sharing)
  • Flux7 also uses BambooHR to store peer feedback; anyone can initiate feedback by asking another peer to provide it. The feedback is stored in BambooHR and only the recipient can see it and turn the feedback into actionable results. BambooHR also contains important files like team assignments, who is on vacation, and recorded All-Hands meetings.
  • We use Okta for single sign-on, LastPass for password management, HubStaff for tracking time on projects, QuickBooks for finance, and more.
Bringing It All Together

IT automation is core to all we do at Flux7 and is instrumental in bringing together many of these tools. To give you an example, forecasting data from HubSpot is automatically sent to Slack with a Zapier integration that allows us to automatically see just-in-time forecasting data. We can share newly closed deals with the broader Flux7 team over Slack this way, too.

We have also integrated Git with Trello such that change notifications are sent as updates to the appropriate Trello card(s), keeping the right team members updated. Trello, in turn, notifies all relevant team members of the updated card information, automatically keeping all team members updated.

At Flux7, we believe in the value of cloud computing and removing levels of management from the process altogether. In fact, we are extremely serverless as a company — with only one server for our website — which allows us to focus less on IT tasks like managing servers and more on delivering value to our customers and employees.

While there are many elements to becoming an Agile Enterprise, technology plays a pivotal role in communication, collaboration, and productivity. As the pace of the market continues to accelerate, agility can only be driven through flexible technologies that help us better anticipate and react to change. Don’t miss the fourth article in our series on the role of culture in building an Agile Enterprise. Subscribe to our blog below and get it direct to your inbox.

Subscribe to the Flux7 Blog

from Flux7 DevOps Blog

HashiCorp Consul Enterprise Supports VMware NSX Service Mesh Federation

HashiCorp Consul Enterprise Supports VMware NSX Service Mesh Federation

Recently at VMworld 2019 in San Francisco, VMware announced a new open specification for Service Mesh Federation. This specification defines a common standard to facilitate secure communication between different service mesh solutions.

Service mesh is quickly becoming a necessity for organizations embarking upon application modernization and transitioning to microservice architectures. Consul service mesh provides unified support across a heterogeneous environment: bare metal, virtual machines, Kubernetes, and other workloads. However, some organizations may choose to run different mesh technologies on different platforms. For these customers, federation becomes critical to enable secure connectivity across the boundaries of different mesh deployments.

We have partnered with VMware to support the Service Mesh Federation Specification. This blog will explain how services running in HashiCorp Consul service mesh can discover and connect with services in VMware NSX Service Mesh (NSX-SM).

What is Service Mesh Federation

consul service mesh federation

Service Mesh Federation is the ability for services running in separate meshes to communicate as if they were running in the same mesh. For example, a Consul service can communicate with an NSX-SM service running in a remote cluster in the same way it would communicate with another Consul service running in the same cluster.

How Does Consul Enterprise Support Service Mesh Federation

Service Sync

The first step towards supporting federation is Service Sync: sharing which services are running on each mesh. To accomplish this, Consul Enterprise implements the Service Mesh Federation Spec via the new Consul federation service. The Consul federation service communicates with NSX-SM’s federation service to keep the service lists in sync so that each mesh is aware of each other’s services.

consul service mesh federation service

First, Consul sends the foo service to the remote federation service and receives the bar service.

consul service sync

Next, Consul creates a Consul bar service to represent the remote bar service.

Inter-Mesh Communication: Consul to NSX-SM

With services synced, Consul services can now talk to remote services as if they were running in the same cluster. To do this, they configure their upstreams to route to the remote service’s name.

In this example, the Consul foo service wants to call the NSX-SM bar service. We configure an upstream so that port 8080 routes to bar:

service {
name = "foo"
connect {
sidecar_service {
proxy {
upstreams = [
{
destination_name = "bar"
local_bind_port = 8080
}
]
}
}
}
}

Then from the foo service, we simply need to talk to http://localhost:8080:

$ curl http://localhost:8080
<response from bar service>

Under the hood, we’re using the Consul service mesh sidecar proxies to encrypt all the traffic using TLS.

Consul connect to nsx service mesh

Inter-Mesh Communication: NSX-SM to Consul

From the bar service running in NSX-SM, we can use KubeDNS to talk to the foo service in Consul:

$ curl foo.default.svc.cluster.local
<response from foo service>

This request will route to the Consul Mesh Gateway and then to foo’s sidecar proxy. The sidecar proxy decrypts the traffic and then routes it to the foo service.

Conclusion

Service mesh federation between Consul Enterprise and NSX-SM allows traffic to flow securely beyond the boundary of each individual mesh, enabling flexibility and interoperability. If you would like to learn more about Consul Enterprise’s integration with NSX-SM, please reach out to our sales representatives to schedule a demo.

For more information about this and other features of HashiCorp Consul, please visit: https://www.hashicorp.com/products/consul.

from Hashicorp Blog

Reimagining Experimentation Analysis at Netflix

Reimagining Experimentation Analysis at Netflix

Toby Mao, Sri Sri Perangur, Colin McFarland

Another day, another custom script to analyze an A/B test. Maybe you’ve done this before and have an old script lying around. If it’s new, it’s probably going to take some time to set up, right? Not at Netflix.

ABlaze: The standard view of analyses in the XP UI

Suppose you’re running a new video encoding test and theorize that the two new encodes should reduce play delay, a metric describing how long it takes for a video to play after you press the start button. You can look at ABlaze (our centralized A/B testing platform) and take a quick look at how it’s performing.

Simulated dataset that shows what the distribution of play delay may look like. Note that the new encodes perform well in the lower quantiles but worse in the higher ones

You notice that the first new encode (Cell 2 — Encode 1) increased the mean of the play delay but decreased the median!

After recreating the dataset, you can plot the raw numbers and perform custom analyses to understand the distribution of the data across test cells.

With our new platform for experimentation analysis, it’s easy for scientists to perfectly recreate analyses on their laptops in a notebook. They can then choose from a library of statistics and visualizations or contribute their own to get a deeper understanding of the metrics.

Extending the same view of ABlaze with other contributed models and visualizations

Why it Matters

Netflix runs on an A/B testing culture: nearly every decision we make about our product and business is guided by member behavior observed in test. At any point a Netflix user is in many different A/B tests orchestrated through ABlaze. This enables us to optimize their experience at speed. Our A/B tests range across UI, algorithms, messaging, marketing, operations, and infrastructure changes. A user might be in a title artwork test, personalization algorithm test, or a video encoding testing, or all three at the same time.

The analysis reports tell us whether or not a new experience made statistically significant changes to relevant metrics, such as member behavior, or technical metrics that describe streaming video quality. However, the default reports only provide a summary view of the data with some powerful but limited filtering options. Our data scientists often want to apply their knowledge of the business and statistics to fully understand the outcome of an experiment.

Instead of relying on engineers to productionize scientific contributions, we’ve made a strategic bet to build an architecture that enables data scientists to easily contribute.

The two main challenges with this approach are establishing an easy contribution framework and handling Netflix’s scale of data. When dealing with ‘big data’, it’s common to perform computation on frameworks like Apache Spark or Map Reduce. In order to reduce the learning curve of contributing analyses, we’ve decided to take an alternative path by performing all of our analyses on one machine. Due to compression and high performance computing, scientists can analyze billions of rows of raw data on their laptops using languages and statistical libraries they are familiar with like Python and R.

Challenges with Pre-existing Infrastructure

Netflix’s well-known experimentation culture was fueled by our previous infrastructure: an optimized framework that scaled to the wide variety of use cases across Netflix. But as our experimentation culture grew, so too did our product areas, users, and ambitions around more sophisticated methodology on measurement.

Our data scientists faced numerous challenges in our previous infrastructure. Complex business logic was embedded directly into the ETL pipelines by data engineers. In order to replicate results, scientists had to delve deep into the data, code, and documentation. Due to Netflix’s scale of over 150 million subscribers, scientists also frequently encountered issues while fetching data and performing custom statistical models in Python or R.

To offer new methods to the community and overcome any existing engineering barriers, scientists would have to run custom scripts outside of the centralized platform. Heavily used or high value scripts were sometimes converted into Shiny apps, allowing easy access to these novel features. However, because these apps lived separately from the platform, they could be difficult to maintain as the underlying data and platform evolved. Also, since these apps were generally written for specific use cases, they were difficult to generalize and graduate back into the platform.

Our scientists come from many backgrounds, such as neuroscience, biostatistics, economics, and physics; each of these backgrounds has a meaningful contribution to how experiments should be analyzed. Instead of spending their time wrangling data and conducting the same ad-hoc analyses multiple times, we would like our data scientists to focus on contributing new and innovative techniques for analyzing tests, such as Interleaving, Quantile Bootstrapping, Quasi Experiments, Quantile Regression, and Heterogeneous Treatment Effects. Additionally, as these new techniques are contributed, we want them to be effortlessly leveraged across the Netflix experimentation community.

Previous XP architecture: all systems are engineering-owned and not easily introspectable

Reimagining our Infrastructure: Democratization Across 3 Tracks

We are reimagining new infrastructure that makes the scientific development experience better. We’ve chosen to break down the contribution framework into 3 steps.

1. Getting Data with the Metrics Repo
2. Computing Statistics with Causal Models
3. Rendering Visualizations with Plotly

Democratization across 3 tracks: Metrics, Stats, Viz

The new architecture employs a modular design that permits data scientists to contribute using SQL, Python, and R, the tools of their trade. Users can contribute metrics and methods directly, without needing to master data engineering tools. We’ve also made sure that both production and local workflows use the same code base, so reproducibility is a given and promotion to production is just a pull request away.

New XP architecture: Systems highlighted in red are introspectable and contributable by data scientists

Getting data with Metrics Repo

Metrics Repo is an in-house Python framework where users define programmatically generated SQL queries and metric definitions. It centralizes metrics definitions which used to be scattered across many teams. Previously, many teams at Netflix had their own pipelines to calculate success metrics which caused a lot of fragmentation and discrepancies in calculations.

A key design decision of Metrics Repo is that it moves the last mile of metric computation away from engineering owned ETL pipelines into dynamically generated SQL. This allows scientists to add metrics and join arbitrary tables. The new architecture is much more flexible compared to the previous Spark based jobs. Views of reports are only calculated on demand and take a couple minutes to execute, so there are no migrations or backfills when making changes or updates to metrics. Adding a new metric is as easy as adding a new field or joining a different table in SQL. By leveraging PyPika, we represent each table as a Python class that can be customized with filters and additional joins. The code is self documenting and serializes to JSON so it can be easily exposed as an API.

Calculating Statistics with Causal Models

Causal Models is an in-house Python library that allows scientists to contribute generic models for causal inference. Previously, the centralized platform only had T-Test and Mann-Whitney while advanced statistical tests were only available via scripts or Shiny apps. Scientists can now add their statistical models by overriding two functions in a model subclass. Many of the models are simple wrappers over Scipy, but it’s flexible enough to do arbitrarily complex calculations. The library also provides helper methods which abstract accessing compressed or raw data. We use rpy2 so that models can be written in either R or Python.

We do not want data scientists to have to go outside of their comfort zone by writing Spark Scala or Map Reduce jobs. We also want to leverage the large ecosystem of statistical libraries written in Python and R. However, many analyses have raw datasets that don’t fit on one machine. So, we’ve implemented an optional compression layer that drastically reduces the size of the data. Depending on the statistic, the compression can be either lossless or tunably lossy. Additionally, we’ve structured the API so that model implementors don’t need to distinguish between compressed and uncompressed data. When contributing a new statistical test, the data scientist only needs to think about one comparison computation at a time. We take the functions that they’ve written and parallelize it for them through multi-processing.

Sometimes statistical models are expensive to run even on compressed data. It can be difficult to efficiently perform linear algebra operations in native Python or R. In those cases, our mathematical engineering team writes custom C++ in order to speed through those bottlenecks. Our scientists can then reference them easily in Python via pybind11 or in R via Rcpp.

As a result, innovative methods like Quantile Bootstrapping and OLS with heterogeneous effects are no longer confined to un-versioned controlled notebooks/scripts. The barrier to entry is very low to develop on the production system and sharing methods across metrics and business areas is effortless.

Rendering Visualizations with Plotly

In the old model, visualizations in the experimentation platform were created by UI engineers in React. The new architecture is still based on React, but we allow data scientists to contribute arbitrary graphs and plots using Plotly. We chose to use Plotly because it has a JSON specification that is implemented in many different frameworks and languages, including R and Python. Scientists can pick and choose from a wide variety of pre-made visualizations or create their own for others to use.

This work kickstarted an initiative called Netflix Vizkit to create a cross-library shared design that lowers the barrier for a unified look and feel in contributions.

Many scientists at Netflix primarily use notebooks for day to day development, so we wanted to make sure they could perform A/B test analysis on them as well. To ensure that the analysis shown in ABlaze can be replicated in a notebook, with e run the exact same code in both environments, even the visualizations!

Now scientists can easily introspect the data and extend it in an ad-hoc analysis. They can develop new metrics, statistical models, and visualizations in their notebooks and contribute it to the platform knowing the results will be identical because their exact code will be running in production. As a result, anyone at Netflix looking at ABlaze can now view these new contributions when looking at test analyses.

XP: Combining contributions into analyses

Next Steps

We aim to accelerate research in causal inference methodology, expedite product innovation, and ultimately delight our members. We’re looking forward to enhancing our frameworks to tackle experimentation automation. This is an ongoing journey. If you are passionate about the field, we have opportunities to join our dream team!


Reimagining Experimentation Analysis at Netflix was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

from Netflix TechBlog – Medium https://medium.com/netflix-techblog/reimagining-experimentation-analysis-at-netflix-71356393af21?source=rss—-2615bd06b42e—4

Announcing Clustering for Terraform Enterprise

Announcing Clustering for Terraform Enterprise

Today we are announcing the beta version of Clustering for HashiCorp Terraform Enterprise. Increasingly, organizations are adopting Terraform Enterprise as their standard provisioning platform and the new Clustering functionality enables them to easily install and manage a scalable cluster that can meet their performance and availability requirements. The beta version of Clustering supports installations of Terraform Enterprise in AWS, Azure, and GCP.

This blog will discuss the clustering capability in Terraform Enterprise, including:

A Horizontally Scalable, Redundant Cluster

Until today, Terraform Enterprise followed the industry standard of a single instance appliance. This was acceptable at first, but as organizations expand their usage of Terraform Enterprise and it becomes their central provisioning platform across business units, the requirements around performance and availability increase. Organizations expect to be able to:

  • Scale Terraform Enterprise horizontally to keep up with ever-growing workloads
  • Trust Terraform Enterprise will always be available to provision their most critical infrastructure

The new Clustering functionality in Terraform Enterprise meets both of these needs.

Scale to Meet Demand

As organizations look to spread the benefits of Terraform Enterprise across their businesses, performance becomes a top concern. Even with the largest instances available, end-users can experience sluggishness in the UI and long wait times for runs to complete.

Running Terraform Enterprise as a cluster solves these performance issues by spreading the workload across multiple nodes. All API requests, background processes, and Terraform runs are fanned out across the cluster, allowing any number of concurrent end-users and runs to be supported.

In fact, our default installation pattern now includes configuration options to enable autoscaling groups. Giving organizations the ability to respond to spikes in demand without human intervention.

Better Availability

Terraform Enterprise is responsible for the infrastructure behind some of the world’s most critical applications. Before today, organizations relied on a pair of instances with one acting as a passive standby to make sure Terraform Enterprise was always available.

While sufficient for some, the risk was too high for many organizations. The existing strategy required too much downtime to promote the passive instance, and then there was always the question of what would happen if both instances were lost.

Running Terraform Enterprise as a cluster mitigates these risks. The provided installer provisions nodes across availability zones by default, and running Terraform Enterprise across three or more nodes ensures zero downtime for most common failure events.

Easier to Install & Manage

Installation is now as simple as a terraform apply from an operator’s machine. Instead of configuring a single instance from the command line, operators can now use an official module from the Terraform Module Registry to deploy an entire cluster to AWS, Azure, or GCP.

That same Terraform config can then be edited later to reconfigure the cluster. For example, increasing the maximum size of the auto-scaling group before rolling Terraform Enterprise out to a new business unit.

Please see the public documentation or watch the demo below to see how simple it is now:

The journey begins and ends with infrastructure as code, just as it should.

Next Steps

While the Clustering beta already represents a big leap forward, we have bigger plans as we continue to build out the platform.

More Configuration Options

The Terraform modules we provide today are meant to cover the requirements of most straightforward solutions; however, they will not work out of the box for some unique situations. Operators are welcome to fork our modules to make them work for their environment, but our goal is to make the official modules extensible enough to eliminate this need.

HA without External Dependencies

The current Clustering Beta is the most reliable version of Terraform Enterprise we have ever built, but it still requires an external PostgreSQL server and blob storage to achieve a high level of availability. Our goal is to remove these external dependencies to make installing a highly available cluster even simpler.

Simpler Backup and Restore Procedure

Operators can expect to see our new snapshot tooling in beta over the next six weeks. Rather than relying on vendor-specific backups, we are building our own tool that makes your data completely portable. Controllable via the command line or an HTTP API, the new functionality will be the key to smooth production upgrades.

Getting Started

We are excited to release the beta version of clustering for Terraform Enterprise to help organizations with scalable performance, high availability, and simple install and management of the application. To learn more about clustering in Terraform Enterprise refer to the documentation here.

For more information on Terraform Enterprise or to get started with your free trial, visit the Terraform product page.

from Hashicorp Blog

Announcing Cost Estimation for Terraform Cloud and Enterprise

Announcing Cost Estimation for Terraform Cloud and Enterprise

Today we're releasing Cost Estimation for HashiCorp Terraform Cloud and HashiCorp Terraform Enterprise. Cost Estimation provides organizations insight into the cost implication of infrastructure changes before they’re applied. Included in this release is integration with policy as code workflows via Sentinel to enable preventative cost-control policies to be automatically assessed against changes.

Organizations that are using an infrastructure as code approach to manage their multi-cloud provisioning, compliance, and management requirements can find it challenging to understand the cost implications of a change before it is applied. Many have been relying on after-the-fact alerts from their cloud provider, using dedicated third party services that continually monitor changes in cost, or potentially waiting until they receive their end of month bill to understand the cost impact of their changes. This new capability now enables teams who manage their self-service infrastructure to view an estimate of changes in monthly cost from their cloud provider before applying any change. HashiCorp’s Sentinel allows cost-centric policies to be created and then automatically enforced in the Terraform workflow. Administrators then have the ability to approve significant changes or to completely prevent specific workspaces from exceeding predetermined thresholds.

This blog will discuss the cost estimation capability and the workflow including:

Pre-emptive cost visibility

One common challenge of cloud infrastructure adoption is enabling the practitioners deploying the changes to understand the financial impact of the changes they’re applying. Many no longer require direct access to the console of the cloud provider, so they don’t see the billing related details of the resources they are provisioning until long after those resources have been deployed. This can create a situation where those responsible for financial governance need to work with DevOps teams to retrospectively reduce the cost profile of infrastructure after it has been deployed. A task that is now more complicated and carries more risk than if there had been earlier intervention.

Addressing it from a more proactive standpoint, organizations can take the shift left approach: IT Ops researches problems that impact cost, collate and collect the data to formalize policies and influence actions across all DevOps teams, and enable everyone in the organization to take consistent actions based estimated infrastructure costs and company policy.

All teams using Terraform Cloud and Enterprise can now see an estimate of changes before they are applied by enabling “Cost Estimation” within the settings of their Terraform Organization:

Settings

Understanding the cost impact of changes

Once Cost Estimation is applied to an Terraform organization, all future runs will include an estimate of the updated total monthly cost for the resources that have changed, along with a separate estimate of the change in cost:

Cost Estimation

In the above example, you can see that the total monthly cost has increased by $14.98/mo, which brings the total cost of those resources up to $37.44/mo. This change increases the maximum allowed size of an Auto Scaling Group on AWS from 3 instances to 5. A simplified example of that config looks like:


resource "aws_autoscaling_group" "prod-web-servers" {
name = "prod-web-servers"
max_size = 5
min_size = 0
desired_capacity = 0
}

It’s worth pointing out that it is only the max_size argument which has changed here, the min_size and desired_capacity have remained as zero. While in effect this most likely means there is no immediate cost impact from this change (in this example zero is the desired capacity so there should be no instances running). The other consideration is that dynamic scaling rules could change this at any time up to the maximum threshold. As a result the estimate takes the maximum potential footprint into consideration when calculating the change.

Now practitioners applying a change can have before-the-fact visibility into the potential cost impact of a change. This makes it easier to identify simple mistakes in configuration that could have significant financial implications, collaborate with other business units to keep costs aligned with forecasts, and support early intervention and remediation workflows at the most cost effective and lowest risk time to adjust implementation.

Enforcing cost controls with HashiCorp Sentinel

Sentinel is a Policy as Code framework that’s integrated into multiple product offerings from HashiCorp. Sentinel within Terraform enables an organization to define policies that are enforced against infrastructure between the plan and apply phases of a Terraform run. Compared to many tools that scan existing infrastructure for policy infractions, Sentinel proactively prevents provisioning of out-of-policy infrastructure and gives teams the confidence that all changes they deploy and within the organization’s policy

These latest enhancements with cost estimation expand on that capability to ensure consistent financial governance is applied to infrastructure changes.

Escalation workflows for expensive changes

It can be difficult to find the right pragmatic balance between allowing teams the agility to provision the infrastructure they need with keeping costs aligned with the expected value of a project. This can then lead to approval workflows that require oversight from an individual or team to determine if changes in cost are reasonable, which in turn can slow delivery and in itself increase the cost of implementation.

A Policy as Code approach that takes advantage of the cost estimation features of Terraform means organizations can now set guidelines on what is an acceptable change that requires review and then only escalate when a change is in breach of the standard policy. This frees up time in the approval workflow by ensuring that team is only required to review genuine escalations, and the practitioners responsible for implementation are able to self-service in-policy changes with confidence.

In the example below you see a Terraform run which has breached a “soft” policy check:

Policy Soft Fail

You can see the failed state here is against the cost-control/modest-increases policy, and the entire run has now been halted and placed into a “Policy Override” state. This is because this policy has been written to prevent any single change that increases the cost more than $500/mo.

For this run to proceed, a Terraform user with admin or policy author permissions will be required to review the plan, provide an optional explanation for why the policy is being overridden, and then ultimately click “Override & Continue”.

The code to implement the policy is:

“`
import "tfrun"
import "decimal"

main = rule {
decimal.new(tfrun.costestimate.deltamonthlycost).lessthan(500)
}
“`

In this example, the recently announced tfrun import is used, along with the new decimal import to ensure working with data types that are consistent for dealing with currency. The next part is to access the change in monthly cost that has been estimated for this run ( tfrun.cost_estimate.delta_monthly_cost) and ensure it is less than 500.

Applying strict cost controls and automated oversight

There may also been known cost thresholds that should never be breached, and an automatic escalation into an approval workflow where a review would be unnecessary. An example could be preventing workspaces that are managing “development” environments from ever exceeding a maximum estimated monthly cost. With such a policy in place, developers have the freedom and confidence to experiment with any infrastructure configuration they desire without the risk of uncomfortable conversations later. It also expands their autonomy in self-service workflows as a breach in policy allows them to make pragmatic decisions about what infrastructure may be able to be deprovisioned to free additional budget for the new changes they wish to deploy.

Here you can see an example of a Terraform run that has had a policy “hard” fail:

Policy Hard Failure

The hard failure in this instance is the cost-control/max-budget policy which has been defined to prevent the total estimated monthly cost from exceeding $10,000/mo. The code to implement this policy is:

“`
import "tfrun"
import "decimal"

main = rule {
decimal.new(tfrun.costestimate.proposedmonthlycost).lessthan(10000)
}
“`

The code here is very similar to the previous example with two notable differences:

  • the value of tfrun.cost_estimate.proposed_monthly_cost which provides an estimated aggregate cost of the resources running in the workspace, rather than just the expected change in total cost.
  • the comparison value is updated to 10,000 (up from 500).

The video below demonstrates the cost estimation workflow with Sentinel policies and enforcement:

Getting Started

You’ve seen just a glimpse of the workflows supported by the cost estimation and policy features available as part of Terraform Cloud and Enterprise, and how they enable teams to self-service changes in dynamic environments while also giving them the confidence that they will stay within guidelines set by their organization.

For more information on Terraform Cloud and Terraform Enterprise or to get started with your free trial, visit the Terraform product page. To learn more about Terraform visit the HashiCorp Learn platform and see it in action.

from Hashicorp Blog

Announcing Terraform Cloud

Announcing Terraform Cloud

Earlier this year we announced Terraform Cloud Remote State Management: a free platform for users to more easily collaborate on Terraform configurations through remotely stored, versioned, and shared Terraform state files. Today, we’re excited to announce the full release of Terraform Cloud.

This release brings new features to enable Terraform user and teams to collaborate on and automate Terraform workflows. It includes remote operations, VCS connection, and unlimited workspaces, delivered through a web based application.

Terraform Cloud is free to get started and available today. You can sign up directly in the application here.

Here’s a short demo showing off some of the new features and workflow:

Background

Terraform began as an open source tool first released in 2014. We could not have predicted the tremendous community of contributors and users from around the world that would form around this tool. Today, the Terraform repository has almost 25,000 commits from almost 1,300 contributors.

The next development, Terraform Enterprise, introduced a powerful, scalable solution to address the needs of businesses using the open source tool. It made collaboration among teams easier and gave businesses governance control over their deployments. Some of the largest organizations in the world use Terraform Enterprise for provisioning, and compliance and management of their infrastructure.

Having served both individuals with Terraform Open Source and large organizations with Terraform Enterprise, we saw a new need to be met: the teams and businesses that fit in between. Today, with Terraform Cloud, we hope to bridge that gap by taking the best workflow for Terraform and making it accessible to everyone. This new product is free to use and includes features that help users and teams move quickly and collaborate on Terraform, while also making it easier to get started.

Features

Terraform Cloud is free to use for teams of up to 5 users and includes automation and collaboration features:

Automation
– VCS Connection (Github, Gitlab, Bitbucket)
– Remote Plans and Applies
– Notifications/Webhooks
– Full HTTP API

Collaboration
– State Management (Storage, History, and Locking)
– Collaborative Runs
– Private Module Registry
– Full User Interface

The automation features help streamline the workflow for deploying infrastructure as code with Terraform: store code in VCS and Terraform Cloud can automatically start runs based off pulls/merges. Additionally, users can trigger runs from the command line, the API, or from within the application UI.

The collaboration features help teams work together. With Terraform Cloud, teams of developers and operations engineers can collaborate on remote terraform runs through the VCS driven review/approval process. The private module registry allows those teams to easily share configuration templates and collaborate asynchronously using remote state file storage.

Paid Upgrades

On top of the freely available features there are two paid upgrades for Terraform Cloud: Team and Governance— As part of this launch we will be giving a free trial of these upgraded features to users until January 1, 2020.

The first upgrade is Team and it allows you to add more than 5 users, create multiple teams, and control permissions of users on those teams. The team upgrade is for organizations that need to enforce RBAC (Role Based Access Control).

The next upgrade available is Team & Governance. It includes the team upgrade as well as the ability to use Sentinel and Cost Estimation. Sentinel is a policy as code framework for enforcing fine-grained rules against your infrastructure, which can help organizations enforce compliance and manage costs. Cost Estimation gives users an estimated cost of infrastructure before it is provisioned. Sentinel and Cost Estimation can be used in conjunction for enforcing cost management policies against your infrastructure. See our offerings page for a detailed comparison between Terraform packages.

Improved Workflow

Terraform Cloud brings users a new workflow to streamline infrastructure provisioning:

First, Terraform users define infrastructure in a simple, human readable configuration language called HCL (HashiCorp Configuration Language). Users can choose to write unique HCL configuration files from scratch or leverage existing templates from either the public or private module registries.

Most users will store their configuration files in a VCS (Version Control System) and connect that VCS to Terraform Cloud. That connection allows users to borrow best practices from software engineering to version and iterate on infrastructure as code, using VCS and Terraform Cloud as a provisioning pipeline for infrastructure.

Terraform can be configured to automatically run a plan upon changes to configuration files in a VCS. This plan can be reviewed by the team for safety and accuracy in the Terraform UI, then it can be applied to provision the specified infrastructure.

Conclusion

Terraform Cloud marks the continued evolution of Terraform. To date, the depth and breadth of ecosystem and community around Terraform has driven global adoption. Now, those users want to work with the tool in teams and drive even more complex automation. We hope to meet those needs with this release. You can sign up for Terraform Cloud today here.

Also, in celebration of the launch we will be randomly selecting from anyone who signs up for Terraform Cloud today to win a HashiCorp Terraform SWAG package.

from Hashicorp Blog

Announcing HashiCorp Consul Service on Azure

Announcing HashiCorp Consul Service on Azure

We are pleased to announce the new HashiCorp Consul Service (HCS) on Azure, which is now in private beta. HCS on Azure enables Microsoft Azure customers to natively provision HashiCorp-managed Consul clusters in any Azure region directly through the Azure Marketplace. As a fully managed service, HCS on Azure lowers the barrier to entry for an organization to leverage Consul for service discovery or service mesh across a mix of VM, hybrid/on-premises, and Kubernetes environments while offloading the operational burden to the site reliability engineering (SRE) experts at HashiCorp. Azure-native identity and billing integrations enable an organization to adopt Consul without introducing any additional administrative burden.

HashiCorp Consul: Multi-Cloud Service Networking Platform

Consul’s service networking capabilities enable an organization to connect and secure services across any runtime platform or public cloud provider. HCS on Azure enables users to more easily leverage Consul’s key capabilities, including:

  • Service Discovery: Provide a service registry with integrated health checking to enable any service to discover and be discovered by other services

  • Service Mesh: Simplify service networking by shifting core functionality from centralized middleware to the end points. Consul’s service mesh functions include:

    • Dynamic Traffic Management: Enable advanced traffic management to support different deployment strategies and improve application resiliency
    • Service Segmentation: Encrypt communications and control access across services with mutual TLS and a native Envoy integration.
    • Observability: Enable networking metric collection to provide insights into application behavior and performance without code modifications
    • Mesh Gateway: Route traffic transparently and securely across Azure regions, private data centers, and runtime environments like AKS, Azure Stack, and HashiCorp Nomad.

HCS on Azure: How Does it Work?

HCS on Azure leverages the Azure Managed Applications platform to enable a user to natively provision Consul through the Azure console, while interfacing with the HCS control plane behind the scenes to perform the deployment and carry out all necessary operational tasks:

How HCS on Azure works under the hood

After subscribing to HCS on Azure within the Azure Marketplace, a user can create a Consul cluster by just selecting a few options to indicate the desired Azure region, Consul version, and network details:

Create an HCS on Azure cluster

Once the user initiates a cluster creation, the HCS control plane will be notified. The integration with the Azure Marketplace allows HCS to provision Consul servers directly into a resource group in the user's Azure subscription:

HCS on Azure cluster details

After the provisioning step completes, any authorized user can view and interact with Consul via the standard Consul Web UI within the Azure console:

HCS on Azure Consul Web UI

Workflows to support backups, monitoring, federation, access control, and TLS encryption will be detailed in a future publication when HCS on Azure becomes generally available.

Benefits for Azure Customers

HCS on Azure enables any organization that runs at least part of its infrastructure in Azure to adopt Consul with a minimum of operational overhead, which in turn enables it to increasingly focus resources on the applications and workloads that are the primary concern of the business. Integrations with Azure identity and billing systems enable a seamless Azure-native experience for existing customers, allowing them to harness HashiCorp’s operational expertise without adding any additional administrative complexity. These advantages apply to single region VM-based Azure environments in need of basic Service Discovery as well as more complex multi-environment scenarios that require Service Mesh-related features like dynamic traffic routing and service segmentation.

Consul’s Mesh Gateway feature can be particularly beneficial to users that are running multiple Kubernetes or AKS environments, enabling multi-cluster service discovery and request routing. Mesh Gateway enables secure traffic routing across environments based on the service-level identity rather the IP address. This effectively flattens the network and renders the per-environment IP address management strategy irrelevant. This pattern applies equally to any mix of VM, hybrid/on-premises, and Kubernetes environments. Kubernetes-based deployments also benefit from Consul’s support for the Microsoft Service Mesh Interface, which enables a user to define Consul Connect intentions in a custom Kubernetes resource that can be directly managed with kubectl or Helm.

Next Steps

HCS on Azure is currently in private beta. If you are interested in participating in the private beta, please contact your HashiCorp account representative for more information. To sign up for status updates and to be notified as HCS develops, please visit the HCS on Azure landing page. If you are new to HashiCorp Consul, please visit the Consul Learn Documentation to get started!

from Hashicorp Blog

IT Modernization and DevOps News Week in Review

IT Modernization and DevOps News Week in Review

IT Modernization DevOps News 13


Last week Werner Vogels, AWS CTO, spelled out in an interview with WSJ CIO Today the Company’s Path to the Cloud Business. A fascinating read, Vogels shares how Amazon’s early IT challenges led to Amazon Web Services, which has become a revenue engine for Amazon. According to the company, AWS has generated $8.4 billion in sales last quarter. A good read if you’re on your own cloud evolution. 

To stay up-to-date on DevOps best practices, CI/CD and IT Modernization, subscribe to our blog here:
Subscribe to the Flux7 Blog

DevOps News

  • A couple weeks ago we brought you news of Splunk’s SignalFX acquisition. Splunk this week continued its buying spree with an announcement that it will acquire Omnition. Described as a stealth-mode operation, Omnition will give Splunk distributed tracing capabilities for microservice application monitoring.
  • According to a blog announcement, Atlassian is making several updates to its cloud platform including:
    • New premium plans for many of our cloud products with advanced features and support
    • New free plans of Jira Software, Confluence, Jira Service Desk, and Jira Core
    • Discounted prices for academic and non-profit customers
    • New tools that strengthen control, security, and trust
  • Pulumi announced GA of version 1.0 of its Infrastructure as Code platform. Pulumi 1.0 includes new capabilities to help development and operations teams overcome organizational silos and grow productivity, reliability and security with familiar programming languages and open-source tools and frameworks.

AWS News

  • AWS launched a large improvement to how AWS Lambda functions work with Amazon VPC networks, updating the service to change the way that functions connect to VPCs. AWS is now leveraging Hyperplane to provide NAT capabilities from the Lambda VPC to customer VPCs. The change in mapping will result in improvements to function startup performance and more efficient usage of elastic network interfaces. The update is rolling out to all existing and new VPC functions, at no additional cost.
  • Amazon EKS made two announcements. The service now allows operators to assign IAM permissions to Kubernetes service accounts, giving pod level access control when running clusters with multiple co-located services. And, Amazon EKS now supports Kubernetes version 1.14.6 for all clusters.
  • Amazon announced that its AWS Config solution now provides automatic remediation. Giving operators the ability to associate remediation actions with AWS Config rules, remediation activities can be automatically taken without manual intervention.
  • Amazon introduced a price reduction for EFS infrequent access storage class. Last week AWS dropped its storage prices for EFS IA by 44%. According to a blog announcement, EFS IA storage prices now start at $0.025/GB-month.
  • Amazon QuickSight has new features for improved asset organization; enhanced anomaly detection capabilities; a new Word Cloud chart type to represent categorical fields; and has added support for Favorites that allow you to bookmark your dashboards and analyses.

Flux7 News

  • Read Flux7’s newest article on, The CIO’s Role in the Making of an Agile Enterprise. Lead, follow or get out of the way. A phrase famously coined by George Patton and later by Chrysler’s Lee Iacocca, it is also an apt prescription for the challenges CIOs face as organizations look to become agile enterprises. With the path to agility often running directly through IT, the CIO stands front and center in an organization’s transition to enterprise-wide agility. Read how CIOs can make the most of this situation.
  • For CIOs and technology leaders looking to dive deeper into leading the transition to an Agile Enterprise, Flux7 has also published a new paper on How CIOs Can Prepare an IT Platform for the Agile Enterprise. Download it today to learn how an agile enterprise architecture that supports agility with IT automation and DevOps best practices can be a key lever to helping IT engage with and improve the business.

Download the Paper Today

Written by Flux7 Labs

Flux7 is the only Sherpa on the DevOps journey that assesses, designs, and teaches while implementing a holistic solution for its enterprise customers, thus giving its clients the skills needed to manage and expand on the technology moving forward. Not a reseller or an MSP, Flux7 recommendations are 100% focused on customer requirements and creating the most efficient infrastructure possible that automates operations, streamlines and enhances development, and supports specific business goals.

from Flux7 DevOps Blog