AWS today closed out its first re:Invent keynote with a focus on edge computing. The company launched two smaller appliances for its Outposts service, which originally brought AWS as a managed service and appliance right into its customers’ existing data centers in the form of a large rack. Now, the company is launching these smaller versions so that its users can also deploy them in their stores or office locations. These appliances are fully managed by AWS and offer 64 cores of compute, 128GB of memory and 4TB of local NVMe storage.

In addition, the company expanded its set of Local Zones, which are basically small extensions of existing AWS regions that are more expensive to use but offer low-latency access in metro areas. This service launched in Los Angeles in 2019; starting today it’s also available in preview in Boston, Houston and Miami. Soon, it’ll expand to Atlanta, Chicago, Dallas, Denver, Kansas City, Las Vegas, Minneapolis, New York, Philadelphia, Phoenix, Portland and Seattle. Google, it’s worth noting, is doing something similar with its Mobile Edge Cloud.

The general idea here — and that’s not dissimilar from what Google, Microsoft and others are now doing — is to bring AWS to the edge and to do so in a variety of form factors.

As AWS CEO Andy Jassy rightly noted, AWS always believed that the vast majority of companies, “in the fullness of time” (Jassy’s favorite phrase from this keynote), would move to the cloud. Because of this, AWS focused on cloud services over hybrid capabilities early on. He argues that AWS watched others try and fail in building their hybrid offerings, in large part because what customers really wanted was to use the same control plane on all edge nodes and in the cloud. None of the existing solutions from other vendors, Jassy argues, got any traction (though AWS competitors would surely deny this) because of this.

The first result of that was VMware Cloud on AWS, which allowed customers to use the same VMware software and tools on AWS they were already familiar with. But at the end of the day, that was really about moving on-premises services to the cloud.

With Outposts, AWS launched a fully managed edge solution that can run AWS infrastructure in its customers’ data centers. It’s been an interesting journey for AWS, but the fact that the company closed out its keynote with this focus on hybrid — no matter how it wants to define it — shows that it now understands that there is clearly a need for this kind of service. The AWS way is to extend AWS into the edge — and I think most of its competitors will agree with that. Microsoft tried this early on with Azure Stack and really didn’t get a lot of traction, as far as I’m aware, but it has since retooled its efforts around Azure Arc. Google, meanwhile, is betting big on Anthos.

Overview of the Breach

In late April 2019, Docker — the widely used container platform that lets engineering teams build, ship, and run applications in isolated environments — announced that an unauthorized party had gained access to one of its databases. Approximately 190,000 user accounts were affected. The exposed data included:

• Usernames
• Hashed passwords
• GitHub and Bitbucket OAuth access tokens (for a subset of affected users)

Docker disclosed the incident through its Support Center and via direct notification to potentially affected users, rather than through its main blog or social media channels — a communications decision that drew criticism from the security community.

What Was Compromised and Why It Matters

Usernames and Hashed Passwords

For users whose only exposed data was a username and a hashed password, the immediate risk was relatively limited — provided Docker used a strong hashing algorithm (such as bcrypt) with appropriate salting. Hashed passwords are not directly usable by an attacker; however, weak or commonly used passwords can still be cracked through dictionary attacks or rainbow table lookups. Users who reused their Docker password on other services faced a much higher risk of credential stuffing attacks on those accounts.

GitHub and Bitbucket Access Tokens — The Higher-Risk Exposure

The more serious concern involved OAuth access tokens for GitHub and Bitbucket. Docker Hub supports automated builds — a feature that links a Docker Hub repository to a source code repository on GitHub or Bitbucket so that a new container image is built automatically whenever code is pushed. These integrations rely on OAuth tokens that grant Docker Hub permission to read (and sometimes write) to the linked repositories.

According to reporting by Bleeping Computer, depending on the permissions granted to each token, a malicious actor in possession of these tokens could potentially:

• Read private source code repositories
• Modify repository contents, including injecting malicious code into build pipelines
• Trigger downstream supply-chain attacks affecting consumers of those Docker images

Docker stated that it revoked all known compromised access tokens promptly upon discovering the breach, which should have prevented active exploitation of those tokens after the revocation point. However, any access that occurred before revocation cannot be ruled out without a thorough audit of repository access logs.

Recommended Remediation Steps

Docker advised affected users to take the following actions. Even if you were not directly notified, these are good security hygiene practices for any Docker Hub account holder:

1. Change your Docker Hub password immediately. Choose a strong, unique password not used on any other service.
2. Check for password reuse. If you used the same password elsewhere, change it on those services as well. Consider using a password manager.
3. Reconnect GitHub and Bitbucket integrations. If your account used automated builds, revoke the existing OAuth connection and re-authorize it to generate a fresh token. Do this from the settings pages of both Docker Hub and the respective source code platform.
4. Audit your repository access logs. Review recent activity in your GitHub or Bitbucket repositories for any unexpected commits, branch modifications, or access from unfamiliar IPs.
5. Enable multi-factor authentication (MFA). Where supported, enable MFA on Docker Hub, GitHub, and Bitbucket to add a layer of protection beyond passwords alone.
6. Review OAuth token permissions. Apply the principle of least privilege when re-authorizing integrations — grant only the repository permissions that are actually required for the automated build workflow.

Broader Implications: Supply Chain Security

This incident is a clear example of why supply chain security matters in a containerized DevOps workflow. Automated build pipelines that connect source code repositories to image registries are a powerful productivity feature — but they also represent a trust boundary that attackers can exploit. If a token with write access to a repository is compromised, an attacker could inject malicious code that ends up packaged into a Docker image and pulled by downstream users, potentially at scale.

Teams that rely on Docker Hub automated builds or similar CI/CD integrations should treat OAuth tokens as high-value secrets, rotate them regularly, and monitor for anomalous repository activity as part of standard operations.

Context: Timing and Disclosure Approach

The breach was disclosed during a particularly active period for Docker. The company had just announced a partnership with Arm on April 24, 2019, aimed at simplifying deployment to cloud, edge, and IoT environments running Arm-based processors. DockerCon, the company’s annual container industry conference, also ran from April 29 to May 2. Docker’s choice to disclose the breach via its Support Center rather than its main communications channels was noted by observers as a way of limiting the incident’s visibility during a high-profile week for the company.

Regardless of the communications strategy, the incident highlights that even infrastructure vendors trusted to secure development pipelines are not immune to breaches — and that users of any platform bear responsibility for applying available security controls on their own accounts.

Further Learning: Docker Security

If this incident has prompted you to review your Docker security posture more broadly, consider exploring dedicated training on container security practices, including image scanning, secrets management, runtime security, and network policy configuration. DevOpsSchool offers a course titled Deep Dive into Docker Security that covers advanced Docker security topics for practitioners.

What Is Cloud Spanner?

Google launched the public beta of Cloud Spanner in February 2017, making the service available on Google Cloud Platform (GCP) to help cloud customers maintain consistent, distributed databases across multiple data centers. Cloud Spanner joined Google’s existing managed database portfolio alongside Cloud SQL, Cloud Datastore, and Cloud Bigtable.

The core promise of Cloud Spanner is that it eliminates a long-standing trade-off in distributed systems design: the forced choice between relational databases that provide strong transactional consistency and NoSQL databases that offer simple horizontal scaling and data distribution. Cloud Spanner aims to deliver both in a single, fully managed service.

“When building cloud applications, database administrators and developers have been forced to choose between traditional databases that guarantee transactional consistency, or NoSQL databases that offer simple, horizontal scaling and data distribution. Cloud Spanner breaks that dichotomy, offering both of these critical capabilities in a single, fully managed service.”

— Deepti Srivastava, Google Product Manager for Cloud Spanner

The Technology Behind Cloud Spanner: TrueTime

One of Cloud Spanner’s most distinctive engineering features is its use of TrueTime, Google’s proprietary time synchronization technology. TrueTime relies on atomic clocks and GPS receivers to supply highly accurate time readings to master servers in each data center. These servers exchange readings and negotiate a common reference time, which solves the clock skew and time coordination problems that typically prevent region-spanning databases from maintaining strong consistency.

Traditional distributed databases struggle with time coordination because network latency and imprecise system clocks make it difficult to establish a strict global ordering of transactions. TrueTime addresses this by bounding clock uncertainty, allowing Cloud Spanner to assign globally consistent timestamps to transactions and enforce external consistency without locking across regions.

Proven at Google Scale Before Public Launch

Although the public beta only launched in February 2017, Google stated it had already been running Spanner internally for several years, testing it with hundreds of applications and petabytes of data spread across data centers around the world. At the time of the announcement, Google reported that internal Spanner deployments supported tens of millions of queries per second and underpinned critical services including AdWords and Google Play.

Pricing Model

Cloud Spanner pricing at public beta launch was structured around three dimensions:

• Compute node-hours — billed per provisioned node per hour
• Storage consumption — charged for the total data stored
• External network egress — charged for data transferred out of the service

Key Capabilities and Benefits

Google highlighted the following capabilities for Cloud Spanner at the time of the public beta launch:

• Strong transactional consistency across regions — eliminates eventual-consistency caveats common in distributed NoSQL stores
• Horizontal scaling without migrating to a non-relational data model — teams can scale out while retaining SQL semantics
• Fully managed infrastructure — reduces operational overhead for hardware and software management, allowing engineering effort to focus on application logic
• High availability and disaster protection — data is replicated across multiple zones and regions
• Integrated security — includes data-at-rest encryption, Identity and Access Management (IAM) controls, and audit logging
• Multi-language client libraries — available at launch for Java, Go, Python, and Node.js, among others

Target Use Cases

Google positioned Cloud Spanner as an appropriate fit for organizations running MySQL or PostgreSQL deployments that were hitting the limits of vertical scaling and traditional replication strategies. Specific verticals and workload types highlighted at launch included:

• Global web services requiring consistent reads and writes across geographic regions
• Financial services where transactional integrity is non-negotiable
• Retail, manufacturing, and wholesale distribution — JDA (now Blue Yonder), a supply chain software vendor, was cited as an early customer, noting Cloud Spanner’s ease of provisioning and scalability for omni-channel supply chain solutions

Competitive Context

The launch of Cloud Spanner was widely interpreted as a significant move in Google Cloud’s effort to compete with Amazon Web Services and Microsoft Azure in the enterprise and hyperscale database market. By offering a managed service combining relational consistency with NoSQL-style horizontal scale, Google provided a differentiated option that neither AWS nor Azure matched directly at the time of launch. AWS Aurora and Azure SQL Database offered managed relational databases, but neither used a comparable globally-distributed, externally-consistent architecture at that point.

Summary

Cloud Spanner’s public beta represented a notable moment in managed database history: a production-proven, globally distributed relational database — previously available only inside Google — becoming accessible to external developers and enterprises. Its TrueTime-based architecture, strong consistency guarantees, and fully managed operations addressed pain points that had historically forced engineering teams to choose between scalability and consistency.

For teams evaluating large-scale relational workloads on Google Cloud Platform, Cloud Spanner remains a key service to consider, particularly where geographic distribution and strong consistency are both required.

Visual Studio 2017 Officially Released on March 7

After a series of release candidates, Microsoft officially launched Visual Studio 2017 on March 7, 2017. The date was deliberately chosen to coincide with the 20th anniversary of the original Visual Studio release in 1997 — a version that shipped with tools including Visual J++, Visual FoxPro, Visual InterDev, and Visual C++.

The release represented a major milestone not just in terms of age, but in the scope of changes Microsoft made to modernize the IDE, improve startup and solution-load performance, and expand support for modern development workflows including containers, cloud, and cross-platform .NET development.

What the Final Release Candidate Introduced

The last release candidate before the formal launch (build 26206, released February 7, 2017) focused primarily on stability and bug fixes, but it did include two notable feature additions:

• dotnet new Templating Engine (.NET Core): The final RC included integration of the new dotnet new templating engine for .NET Core projects. This allowed developers to scaffold new projects from a wider range of templates directly from the command line, improving the CLI-based development experience.
• Redgate SQL Prompt: Microsoft bundled the Redgate SQL Prompt into the release, providing IntelliSense-style code completion for SQL queries and scripts. This was a notable addition for developers working with SQL Server databases directly inside the IDE.

Bug Fixes in Build 26206

Beyond new features, the final RC addressed a range of bugs across several areas:

VSIX and Extension Projects

Developers building or maintaining Visual Studio extensions (VSIX projects) received targeted fixes in this build. Issues affecting debugging and build pipelines for extension projects were resolved, making it more reliable to develop and test extensions against the new VS2017 host.

.NET Core and ASP.NET Core

Several bugs affecting .NET Core and ASP.NET Core project workflows were fixed, including:

• Problems saving project files correctly
• NuGet package restore and resolution issues
• Bugs in the .NET Core command-line tooling integration

These fixes were important given that .NET Core support was one of the headline features of VS2017 and was still maturing at the time of release.

How to Get Visual Studio 2017

At the time of the release candidate, Microsoft offered two upgrade paths for developers:

1. In-place update: Developers already running an earlier VS2017 RC could update directly from within the IDE using the built-in update notification.
2. Fresh installer download: A standalone installer was available from Microsoft’s official website for clean installations.

VS2017 introduced a new modular installer that replaced the monolithic setup experience of previous versions, allowing teams to install only the workloads and components they actually needed — significantly reducing install size and time.

Why VS2017 Mattered for DevOps Teams

For DevOps and platform engineering teams, Visual Studio 2017 was significant for several reasons:

• Faster startup and load times: Microsoft made substantial performance investments, reducing the time to open the IDE and load large solutions.
• Improved .NET Core tooling: With .NET Core becoming the primary target for cross-platform and containerized workloads, better tooling integration mattered for CI/CD pipeline reliability.
• Docker and container support: VS2017 improved integration with Docker tooling, making it easier to develop and debug containerized ASP.NET Core applications locally.
• Live Unit Testing: Introduced in the Enterprise edition, this feature ran unit tests automatically in the background as code was edited, shortening the feedback loop without leaving the editor.

Further Reading

Full release notes for VS2017 RC build 26206 were published by Microsoft and detail every change included in that build. Developers evaluating the release or maintaining extensions should consult the official Microsoft documentation for the authoritative list of breaking changes and API updates.

Docker Datacenter (DDC) received a significant update alongside Docker Engine 1.13, bringing enterprise-grade features across secrets management, image security, networking, application deployment, image distribution, and platform usability. Below is a detailed breakdown of each major feature area.

Integrated Secrets Management

DDC 1.13 includes first-class, integrated secrets management that spans the full application lifecycle — from development through to production. Teams can store sensitive data such as passwords, API keys, and TLS certificates securely on the cluster, then inject those secrets directly into services at runtime without embedding them in images or environment variables.

Developers reference secrets using the familiar Docker Compose file format, making handoff to operations teams straightforward. On the enterprise side, DDC adds:

• Lifecycle management via the UI: Create, update, and delete secrets through the Universal Control Plane (UCP) dashboard.
• Label-based access control: Granular permissions allow you to restrict which users and services can access a given secret.
• Audit logging: All access to secrets is logged via syslog, providing a clear audit trail for compliance requirements.

Image Security Scanning and Vulnerability Monitoring

Building on the existing Docker Content Trust feature, DDC 1.13 adds Docker Security Scanning — binary-level scanning of images and all their constituent layers. The scanner works as follows:

1. Bill of Materials (BOM) generation: Each image is analysed and a complete list of packages and their versions is recorded.
2. CVE database cross-reference: The BOM is checked against multiple Common Vulnerabilities and Exposures (CVE) databases to flag known issues.
3. Ongoing monitoring: The stored BOM is rechecked regularly. If a new vulnerability is published against an already-scanned package, affected users can be notified without needing to re-push an image.

System administrators can also connect their CI pipelines and build systems to the scanning service through the new registry webhooks feature (covered below), enabling automated vulnerability gating before images are promoted to production.

HTTP Routing Mesh (HRM) — Now Production-Ready

Previously experimental, the HTTP Routing Mesh (HRM) graduates to production status in this release. HRM extends Docker’s existing swarm-mode network routing mesh by enabling hostname-based routing of HTTP traffic to the correct backend service — similar in concept to a Layer 7 load balancer or ingress controller.

New capabilities in this release include:

• UI-based HRM management: Configure hostname routing rules for a service directly from the DDC admin dashboard.
• HTTPS pass-through via SNI: Route TLS traffic without terminating the connection at the mesh, preserving end-to-end encryption.
• Multiple HRM networks: Isolate different applications using separate HRM networks.
• Sticky sessions: Route repeated requests from the same client to the same backend service instance.

Compose for Services (Stack Deployment)

DDC 1.13 significantly expands support for stacks — multi-service applications defined as groups of services, networks, and volumes. Using Docker Compose file format version 3.1 (.yml), teams can:

• Define multi-service applications in a single Compose file, including secrets references introduced in Compose v3.1.
• Deploy stacks via both the UCP UI and the Docker CLI (docker stack deploy).
• Manage the full lifecycle of a stack — and its individual services, tasks, networks, and volumes — directly from the UCP dashboard after deployment.

This workflow closes the gap between developer and operations tooling: developers author the Compose file, and operations teams deploy it into production without translation or reformatting.

Content Cache (Satellite Registry Caching)

For organisations with engineering teams spread across multiple geographic locations, pulling images from a central registry thousands of miles away introduces latency and consumes significant bandwidth. DDC 1.13 addresses this with satellite registry content caches.

Key characteristics of the content cache feature:

• Per-user or location-based assignment: Caches can be assigned to individual users, or users can select the nearest cache themselves.
• High availability support: Caches can be configured in HA mode to eliminate a single point of failure.
• Cache chaining: For complex, multi-tier datacenter environments, caches can be chained together — a regional cache pulling from a central cache rather than the origin registry directly.

Registry Webhooks

DDC 1.13 adds a comprehensive webhook system to Docker Trusted Registry (DTR), enabling integration with external systems and CI/CD pipelines. Webhook events include:

• Image push and pull events on specific repositories
• Security scanning completion events (pass or fail)
• Repository creation and deletion
• System-level events such as garbage collection

By triggering on scan events, teams can build automated pipelines that block promotion of a vulnerable image to a production repository, or notify on-call engineers when a newly published CVE affects an image already running in production.

Usability Improvements

Beyond the headline features, this release delivers a number of quality-of-life improvements for both developers and platform administrators:

• Cluster and node metrics: CPU, memory, and disk usage are now visible at both the cluster level (dashboard summary) and per-node level. Nodes can be sorted by resource usage to quickly identify contention or failures.
• Rolling update improvements: Services can now be rolled back automatically during a failed rolling update, and status notifications keep operators informed throughout the process.
• Simplified DTR installation: The UCP UI now provides a copyable Docker Trusted Registry install command, reducing configuration errors during initial setup.
• Expanded LDAP/AD support: Additional LDAP and Active Directory configuration options are available directly within the UCP UI, reducing reliance on CLI-only configuration.
• Cloud deployment templates: One-click deployment templates for AWS and Azure allow organisations to stand up a DDC cluster in minutes.

Demo Video Series

Docker published a Docker Datacenter demo video series walking through these new features in detail. The playlist covers secrets management, security scanning, HRM configuration, stack deployment, and content caching in practical walkthroughs.

Note: Docker Datacenter has since been superseded by Docker Enterprise and subsequently Mirantis Kubernetes Engine (MKE) following Mirantis’s acquisition of Docker Enterprise in 2019. The features described here — secrets, security scanning, HRM, and stack deployment — have evolved significantly in later versions. Refer to current Mirantis documentation for up-to-date guidance.

Jenkins Usage Grew Significantly in 2016

The Jenkins project’s 2016 Community Survey revealed strong momentum for the open-source automation server across three dimensions: deeper adoption within organizations already using Jenkins, net-new adoptions, and growth driven specifically by Continuous Delivery (CD) initiatives.

Key figures from the survey:

• 85% of respondents said their organization’s use of Jenkins had increased over the prior year.
• 54% of practitioners implementing Continuous Delivery were using Jenkins as their primary automation engine.
• 90% considered Jenkins mission-critical to their business.
• 96% used Jenkins for build tasks.
• 62% used Jenkins for deployment activities.
• 36% used Jenkins for operations tasks.

Sacha Labourey, CEO and co-founder of CloudBees, attributed the growth to the broader DevOps movement: “As an ever-increasing number of teams implement DevOps, we are seeing them naturally turn to Jenkins as the de facto business-critical solution for Continuous Integration and Continuous Delivery. The survey and increasing usage statistics reflect how adoption continues to grow despite an already massive installed base, all while the community’s involvement keeps increasing.”

Jenkins 2 and Pipeline Support: The Catalyst for Growth

Jenkins creator and CloudBees CTO Kohsuke Kawaguchi pointed to the Jenkins 2 release—launched in early 2016—as a turning point. Jenkins 2 introduced native Pipeline support, giving teams a powerful, scriptable way to define and manage their entire CD workflow as code.

“Early in 2016, the community invested in Jenkins 2, adding Jenkins Pipeline support to enable the leading automation engine with the power and ease of use to support organizations implementing Continuous Delivery and DevOps,” Kawaguchi said. “The 2016 Jenkins Community Survey results indicate the investments are showing a return for both existing and new users through the expanded use of Jenkins within organizations.”

New Pipeline Features: Declarative Syntax, Graphical Editor, and Shared Libraries

Alongside the survey results, the Jenkins project announced a significant update to Jenkins Pipeline aimed at lowering the barrier to entry for Continuous Delivery. The release introduced three major capabilities:

1. Declarative Pipeline Syntax

The new declarative syntax offers a structured, opinionated way to write Jenkinsfiles. Unlike the fully Groovy-based scripted pipeline, the declarative format uses a predefined, human-readable structure that makes pipelines easier to write, read, and validate—especially for teams less familiar with Groovy scripting.

A minimal declarative pipeline looks like this:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'make build'
            }
        }
        stage('Test') {
            steps {
                sh 'make test'
            }
        }
        stage('Deploy') {
            steps {
                sh 'make deploy'
            }
        }
    }
}

2. Graphical Pipeline Editor (Blue Ocean)

The release included an initial version of a graphical editor, part of the Blue Ocean project—a redesigned user experience for Jenkins. The editor allows teams to define and visualize CD pipelines without writing code directly, making pipeline authorship accessible to a wider range of practitioners, including those without strong scripting backgrounds.

Kawaguchi described the goal: “Declarative Pipeline combines the power and flexibility of Jenkins Pipeline with the simplicity of Blue Ocean. Defining and evolving Continuous Delivery pipelines is made not only easier but also pleasant, which is an important milestone for making Continuous Delivery accessible for everyone.”

3. Shared Pipeline Libraries

Shared pipeline libraries allow teams to extract common pipeline logic into reusable code that can be referenced across multiple Jenkinsfiles. This promotes consistency and reduces duplication in organizations running many pipelines—particularly valuable in large enterprises with dozens or hundreds of projects following similar build and deploy patterns.

Why This Mattered for DevOps Teams

The combination of survey results and feature announcements painted a clear picture of Jenkins’ strategic direction at the start of 2017: move from a plugin-heavy, UI-driven CI server to a programmable, pipeline-first automation platform. The declarative syntax and graphical editor addressed two distinct user segments—experienced engineers who want code-defined pipelines and less experienced users who need a visual interface—while shared libraries served platform engineering teams managing CD at scale.

For DevOps practitioners evaluating or already running Jenkins, these changes signaled that pipeline-as-code was becoming the primary supported workflow, not an add-on. Teams still relying on freestyle jobs and manually configured build steps had a clear migration path toward reproducible, version-controlled pipelines.

Further Reading

If you are new to Jenkins Pipeline or looking to deepen your knowledge, the official Jenkins Pipeline documentation is the most reliable starting point. The Blue Ocean documentation covers the graphical editor in detail.

Overview

No software is immune to bugs, and Docker is no exception. In January 2017, Docker container management received a pair of incremental but meaningful improvements: a security patch for a privilege-escalation vulnerability in runC, and a set of usability and bug-fix updates shipped as part of Docker 1.13. Together, they highlighted two persistent challenges in container environments — security depth and operational maturity.

CVE-2016-9962: runC Privilege-Escalation Vulnerability

In mid-January 2017, Docker responded to a security vulnerability in runC, the low-level container runtime, identified as CVE-2016-9962. The flaw could theoretically allow privilege escalation from a container to its host, and, in a worst-case scenario, provide a foothold for an attacker to move laterally within a corporate network.

Docker rated the severity of the bug as minor and released a fix in Docker 1.12.6. Exploiting the vulnerability required an attacker to first compromise the code running inside a container and control how that code was placed there — a significant prerequisite that limited real-world exposure.

What Made Exploitation Difficult

According to Edward Haletky, CEO and principal analyst at TVP Strategy (Austin, Texas), exploiting CVE-2016-9962 required first compromising the container’s code supply chain:

“In order to exploit CVE-2016-9962 in an attack, one must first compromise the code and the means by which the code is placed within the container.”

— Edward Haletky, TVP Strategy

Haletky stressed that patching alone is insufficient: container images should be evaluated for security before they enter any environment, and code security testing should be a standard part of the container deployment pipeline.

“Just patching or using SELinux is not enough of an answer. We need control and security testing of every aspect of container deployment.”

— Edward Haletky, TVP Strategy

Defense in Depth in Practice

Alex Witherspoon, VP of Platform Engineering at FlightStats Inc. (Portland, OR), noted that his organization was not affected by the vulnerability because complementary security controls were already in place:

“For us, other security systems not based in Docker were available to help negate any ill effect here. We also use New Relic and APM as a way to detect bad behavior in the environment, so we can automatically block or deny a bad actor.”

— Alex Witherspoon, FlightStats Inc.

Witherspoon’s approach illustrates the principle of defense in depth: layering independent security controls — firewalls, runtime monitoring, anomaly detection — so that no single vulnerability creates a complete breach.

Docker 1.13: Incremental but Important Updates

Released in late January 2017, Docker 1.13 bundled several quality-of-life improvements alongside the security work in 1.12.6. The key changes fell into four areas:

1. Backward-Compatible CLI

Docker 1.13 introduced backward compatibility for the Docker command-line interface, meaning that scripts and tooling built against older CLI versions would continue to work. Chris Riley, Director of Solutions Architecture at cPrime (San Francisco), commented:

“We stick with newer versions, but this will probably be very helpful for admins who are not constantly updating Docker.”

— Chris Riley, cPrime

2. Simplified Commands and Disk Management

The CLI was restructured with cleaner, more logical command groupings. Disk usage had been a recurring complaint among Docker users — dangling images, stopped containers, and unused volumes consuming space with no easy cleanup path. New commands in 1.13 targeted this directly.

“I have had a lot of clients complain about disk usage when using Docker, and [some of the new] commands are meant to help this issue and will be helpful. This is a nice refactor as they expand their API, and [it] helps keep things organized and focused.”

— Chris Riley, cPrime

3. Improved Container Log Access

Docker 1.13 also simplified how container logs are accessed, making it easier to integrate Docker logging with external monitoring and observability platforms — an important step for production operations teams.

4. Docker for AWS and Azure: General Availability

Docker for Amazon Web Services and Docker for Microsoft Azure both graduated from beta to general availability with the 1.13 release. Riley viewed this as a strategic move:

“The fact that [Docker is] targeting the ops side and the two largest cloud providers is smart. We have been waiting for this to compete with Kubernetes on AWS and Amazon ECS.”

— Chris Riley, cPrime

5. DNS Bug Fix

One fix that did not appear prominently in Docker’s own release notes — but mattered to practitioners — was a resolution of an intermittent DNS lookup failure in containers. Witherspoon described the issue:

“Some containers would rarely, but very painfully, fail to resolve certain DNS lookups for no apparent reason. It seems better now — time and testing will tell.”

— Alex Witherspoon, FlightStats Inc.

Intermittent DNS failures are notoriously hard to reproduce and diagnose in distributed systems, making this fix particularly valuable for production workloads that depend on service discovery.

The Broader Context: A Rapidly Evolving Ecosystem

The pace of Docker releases in this period reflects how quickly the container ecosystem was maturing. FlightStats had adopted a policy of tracking and deploying updates to both containers and the Docker daemon itself — a strategy that required accepting frequent churn in exchange for staying current with security patches and feature improvements.

“Docker is still very young and changing rapidly.”

— Alex Witherspoon, FlightStats Inc.

That observation — made in early 2017 — was accurate for the time and serves as a useful reminder that operational practices around any fast-moving platform must account for continuous change. Automated update pipelines, image scanning, and layered security controls are not optional extras; they are baseline requirements for running containers safely at scale.

Key Takeaways

• Patch promptly: CVE-2016-9962 was rated minor, but waiting to apply Docker 1.12.6 unnecessarily extended exposure.
• Layer your defenses: Firewalls, SELinux/AppArmor, runtime monitoring (APM), and image scanning together reduce the blast radius of any single vulnerability.
• Scan images before deployment: Since exploiting runC-class bugs requires compromising the container’s code supply chain, shifting security left — scanning images in CI/CD — is a direct mitigation.
• Monitor disk usage: Docker’s new cleanup commands in 1.13 addressed a real operational pain point; incorporate regular pruning into your container lifecycle management.
• Track DNS behavior: Intermittent DNS failures in containers can be difficult to attribute; update to releases that include DNS fixes and monitor resolution latency as a standard metric.

Nothing is immune to change, including software delivery practices. As DevOps continues to mature, for example, and become more deeply ingrained in the enterprise, new revelations are discovered and expanded upon throughout the industry. However, three basic tenets will always remain at the core of DevOps: people, processes and tools. While each of the three is equally important to a DevOps transformation, we found this week’s top news dives specifically into the DevOps toolchain.  Continue reading to learn which configuration management tools to choose and how to use the toolchain to scale successfully. Even with all the hype around DevOps, we still haven’t forgotten about another popular method – Agile (or, is it a mindset?).

Continue reading for more on the latest DevOps news and trends, and, as always, stay tuned to all the news coming from @ElectricCloud on DevOps and Continuous Delivery throughout the week.

1) What is DevOps? Gene Kim Explains

Gene Kim is an author of the popular DevOps Novel, The Phoenix Project, and the upcoming DevOps Handbook, currently scheduled for release in October. He was formerly the founder and CTO of Tripwire, but these days you can find him writing books, organizing the DevOps Enterprise Summit, and working on research and other projects as a co-founder of IT Revolution.

2) The Secret to Successful Scaling: Use the DevOps Toolchain to Become a Well-Oiled Machine

One of the most exciting challenges young companies face is the prospect of scaling up. Successful growth is not just about gaining traction, but about implementing a smart business model that allows you to expand your customer base without increasing overhead at the same rate. Ideally, a scalable strategy will enable exponential revenue growth alongside more incremental cost increases.

3) An Agile Dilemma: Mindset or Method?

There’s an intriguing dialogue happening in the world of Agile software development that may be relevant for anyone interested in how business works in a rapidly changing world. For those readers who are not familiar with Agile, this innovative approach to creating software emerged out of a February 2001 gathering of seventeen software developers in Snowbird, Utah. Among them were Jeff Sutherland and Ken Schwaber, the coauthors of what has come to be known as Scrum, and Ward Cunningham, the originator of the wiki, which became popularized with the explosive growth of Wikipedia.

4) DevOps Experts Unite on Video Podcast Series

To remain competitive in today’s software-driven economy, organizations of all sizes are investing in DevOps to become better at releasing software. Although the ROI is evident in the IT and business performance of organizations that have successfully implemented DevOps practices, the journey still can be challenging.

5) Select The Best Configuration Management Tools For Your Company

Choosing the best configuration management tools is not easy. There is a raft of options on the market, ranging from simple command-line interface scripting tools to full-blown packaging and provisioning systems, as well as application release automation and orchestration tools. The key to selecting the best configuration management tools is to focus on what the organization needs are and analyze which of the many offerings will suit your enterprise.

6) A Transformation Journey to Modernized IT | @BigDataExpo #Cloud #BigData #DigitalTransformation

Improving end-user experiences and leveraging big data analytics helps Aimia head off digital disruption and improve core operations and processes. The next BriefingsDirect Voice of the Customer digital business transformation case study examines how loyalty management innovator Aimia is modernizing, consolidating, and standardizing its global IT infrastructure.

7) New IT Salary Research Shows Most DevOps Practitioners Earn $100K or More

Puppet recently released its 2016 DevOps Salary Report which indicates that most DevOps practitioners in the United States earn $100,000 or more in annual salary. The annual report also found that 43 percent of IT managers earn $150,000 or more, up from 26 percent last year. The salary report is based on data gathered from more than 4,600 respondents to the survey.

8) Small Things Matter: What Developers Should Really Care About

Hey boy, are you doing microservices? Sure you are. Everybody does. Have you moved to 4-tier architecture already? Are your applications cloud-native? Have you container-dockerized yourself? All of it? Then, I bet you also have strong DevOps culture. Of course, none of these could be achieved without Management 3000.0 and Modern Agile. Oh boy, you’re so awesome! But wait, wait. We’re not done yet. You’re using Marathon or Kubernetes, right? And Big Data, you have to do Big Data! What about your APIs? Are they RESTful enough?

9) Testing In Production Comes Out Of The Shadows

For enterprise testing organizations, the world of software development is somewhat similar to the world of legalized marijuana. There’s a saying in the legal pot world: “Out of the shadows and into the light.” This is used to describe the way users of illegal weed are now able to come out of hiding and talk about their usage in public without fear of reprisal.

10) Agile in Dispersed or Distributed Teams

Cross-cultural team building enables collaboration and teamwork in dispersed or distributed agile teams. You need to invest to get the best out of a dispersed team argues Nienke Alma, a people oriented Agile enthusiast working as a Scrum master and agile coach. Several more people wrote about what is needed to make agile work with dispersed or distributed teams.

Overview

Continuous Enterprise Development in Java, subtitled “Testable Solutions with Arquillian,” is aimed at Java EE developers who want to build, test, and continuously deliver enterprise applications. The book is logically divided into two distinct parts: a foundational section covering concepts and tooling, and an implementation-focused section that walks through building a full JEE application layer by layer.

Part One: Foundations (Chapters 1–4)

The opening chapters establish context before any code appears. Topics covered include:

• The inherent difficulties of testing Java EE (JEE) applications in realistic container environments
• Software development lifecycle concepts and the role of continuous integration
• Types of testing — unit, integration, and end-to-end — and when each applies
• Testing frameworks: JUnit and TestNG
• Build tooling: Maven and JBoss Forge
• Version control: Git receives a dedicated section, though other VCS tools are not covered
• A thorough introduction to Arquillian, described in the book as “an innovative and highly extensible testing platform for the JVM”

ShrinkWrap: Programmatic JEE Archives

One of the stronger introductory sections covers ShrinkWrap, an API that lets developers create deployable JEE archives — JARs, WARs, and EARs — programmatically at test time. This removes the need to maintain separate deployment descriptors just for testing and is central to how Arquillian manages in-container test deployments.

Chapter 3: Writing and Deploying with Arquillian

An entire chapter is dedicated to writing business code alongside its Arquillian integration tests and deploying the result. The toolchain used throughout this chapter leans heavily on the Red Hat ecosystem:

• JBoss Forge for scaffolding and building the application
• JBoss Application Server for local deployment
• JBoss Developer Studio for deployment to Red Hat’s OpenShift cloud platform

Readers who prefer vendor-agnostic tooling may find this chapter limiting, as the examples are tightly coupled to JBoss and Red Hat products.

Part Two: Building the JEE Application (Chapters 5–12)

The second half of the book is structured around building a complete JEE application, with each chapter tackling one architectural layer or concern:

• Chapter 5 — Persistence layer (JPA and relational data)
• Chapter 6 — Integration with NoSQL databases
• Chapter 7 — Services layer (EJBs and CDI)
• Chapter 8 — REST services
• Chapter 9 — Security
• Chapter 10 — User interface
• Chapter 11 — Live deployment

Consistent Chapter Structure

Each chapter in Part Two follows a repeatable pattern, which makes the book easy to navigate as a reference:

1. Technology introduction — a concise explanation of the JEE component or API being used
2. Use cases and business requirements — what the application needs to do
3. Implementation — code walkthroughs for the feature
4. Testing with Arquillian — integration tests that validate the implementation inside a real container

This four-step rhythm is one of the book’s structural strengths, making it straightforward to find where implementation ends and testing begins.

What Works Well

• Strong JEE coverage: The author demonstrates clear command of JEE components. The technology introductions in Part Two are concise and accessible without being superficial.
• Deep Arquillian expertise: All Arquillian examples are well-explained, and the ShrinkWrap introduction in particular is a highlight of the book.
• Valuable external references: Certain chapters point readers to authoritative external resources. The security chapter references PicketLink, and the REST chapter references the Richardson Maturity Model — both useful for developers who want to go deeper.

Limitations and Criticisms

• Heavy Red Hat / JBoss bias: The book’s examples are almost exclusively tied to JBoss and Red Hat tooling. Developers working with other application servers or build tools will need to mentally translate much of the practical content.
• Subtitle vs. content mismatch: The subtitle promises a focus on “Testable Solutions with Arquillian,” but the book devotes substantial space to application development concepts in general. Arquillian-specific testing is only one thread running through the book rather than its central focus.
• No coverage of non-JEE frameworks: The book does not address how Arquillian integrates — or whether it integrates usefully — with popular non-JEE frameworks such as Spring or Google Guice. This is a significant gap for teams whose codebases mix JEE and non-JEE components.

Who Should Read This Book

This book is best suited for Java EE developers who are already working within or comfortable adopting a JBoss/Red Hat stack and want a practical guide to adding Arquillian-based integration testing to their workflow. It is less useful as a general Arquillian reference for developers working outside the JEE ecosystem or those on alternative application servers.

If your team is already invested in JEE and wants to understand how to continuously develop and test enterprise applications end-to-end — from the persistence layer through to live deployment — this book provides a coherent, well-structured path to get there.