Thursday, June 30, 2016

Red Hat Summit: Red Hat Identity and Access Management

Smite I Pal and Ellen Newlands talk identity management at Red Hat Summit.

In this session Red Hat’s Ellen Newlines and Dmitri Pal discussed Red Hat's identity management portfolio from a near-term perspective, and presented the long-term roadmap—along with some advice for implementing identity management.

These are some highlights and quotable moments from the talk.

Identity management is complex but it’s something you need to do to protect your environment and, ultimately, the assets of your organization. Red Hat is focusing on making IdM automated and cost effective so that customers can focus on their business. It’s Red Hat’s job to provide the expertise.

The areas of vision:


You need to be able to authenticate from different types of credentials including passwords, certificates, smart cards and OTP tokens. And use single sign-on using Kerberos, SAML, and OpenID connect. Weave together multiple operating systems, multiple credentials, multiple authentication schemes (including a trust relationship between IdM and Active Directory in a Microsoft environment). 

Managed security.

Consistent Delivery

If you have consistency in the identities and access to them, you can deliver to systems, service

s, and applications together with policies to control access and privilege escalation. The goal is to make the use of this environment relatively seamless (even given the complexity).

Managed Security

The challenge is the management of identities in a complex interoperable world. The keys, the certificates, the other secrets need to be automatically provisioned, tracked, and rotated on an as-needed basis.

DevOps Enablement

Developers need to have the tools to build the next generation of containerized and non-containerized applications with authentication and the consistent delivery of security. If the developer can’t do this, what they’re doing isn’t much use in a production environment.

Some guidance for identity management:

  • Single source of identities. Don’t copy pass words around! It also makes it much easier for audit when identities are in a single place. 
  • Single sign-on is good. You need to protect the keys to the kingdom, but once you’ve established, use it as much as possible.
  • Don’t put passwords into files. Instead use Kerberos or certificates, or fetch secrets on the fly. When you build applications and stitch things together, think about how they’re going to talk with each other. It requires a bit more effort but don’t be afraid to move forward.
  • Automate your operations. We are in an era where changes are happening in real-time. Continuous integration and deployment of applications are needed to meet these business needs. Adopt the tools you need to do things in a simple, repeatable way. (For example, Ansible.)
  • Integrate applications so that applications can interface with each other in the context of the user. These interactions need to be managed—which is where an IdM Fabric, as shown below, comes in.

Identity Management Fabric.

Wednesday, June 22, 2016

Getting Started with DevOps (for devs) at Red Hat Summit

This post shares some highlights from Decomposing DevOps: Understanding How to Get Started, a session that I gave at Red Hat Summit in San Francisco this week together with Dylan Silva of Ansible by Red Hat.

Screen Shot 2016 06 22 at 10 52 24 AM

Our general approach in this session was to look at DevOps on-ramps first from a primarily developer-centric perspective and then from a more ops-oriented one. These aren’t mutually exclusive especially given that DevOps inherently commingles dev and ops concerns to a certain degree. Nonetheless, thinking about these two different constituencies is one useful way to frame the discussion.

For the dev-centric point of view about DevOps (which is what I’ll cover in this post), I find that a manufacturing metaphor provides useful insights. Whether building a car or building an application, what are some of the important principles to follow?

The first is automation. Worker productivity in automotive manufacturing has doubled in something like the past 20 years. Automating repeatable processes has simultaneously improved predictability and quality. (I guess it’s an exception to the “Better, faster, cheaper: Pick two” rule.) Similarly, developer automation that leads to an iterative CI/CD pipeline with build/test/approve/deliver/deploy stages leads to both faster and higher-quality software delivery.

Screen Shot 2016 06 22 at 1 45 43 PM

W. Edwards Deming, one of the original champions of statistical quality control, once said that “Without data you’re just another person with an opinion.”

Measurement and metrics are likewise a key ingredient in an iterative software development pipeline. DevOps metrics were actually the topic of a separate birds of a feather session discussion that I led with my colleague William Henry. A full discussion is beyond the scope of this post, but when thinking about collecting data it’s useful to step back and consider your most important objectives and then design a plan from that starting point. 

The automotive industry, like others, has embraced the idea of modularity and reuse; about half of all cars are built on a modest number of platforms that share key components and design elements across models and across brands. We see this same modularity in the concept of microservices—small, autonomous, bounded context services that communicate through APIs. Even when microservices aren’t adopted in their purest form, automated DevOps pipelines work most effectively when deployments can be small, frequent, and generally decoupled from other deployments. 

If DevOps can be thought of as transitioning software development from craftwork to a more industrialized set of processes, then the place where new cloud-native apps run can be equally thought of as morphing from a workshop to a factory. This factory has characteristics such as the following:

  • Software-defined infrastructure and/or public cloud
  • Automation
  • Application lifecycle management
  • Developer experience including self-service
  • Application services (databases, messaging, integration, mobile)
  • Container ecosystem
  • Orchestration and resource control
  • Management

There’s enormous innovation happening in all these areas across a wide range of open source communities. However, making all this consumable for developers is certainly a challenge. That’s a big reason why, in a study of DevOps early adopters conducted last year for Red Hat, IDC found that 80 percent expected PaaS to play a crucial role in enabling DevOps because “Platform-as-a-Service (PaaS) cloud infrastructure, self-service developer platform and  tools, and lifecycle management with DevOps processes—speeding time to value for both developers and operations."

That’s exactly what OpenShift does by bringing together technologies such as Red Hat Enterprise Linux, docker-format containers, kubernetes orchestration, CICD pipelines, and developer tooling. Features include:

  • Self-service
  • Multiple interaction models
  • Polyglot, multi-language support
  • xPaaS services
  • Immutable, container-based platform
  • Automation for application builds, deployments, scaling, and health management
  • Persistent storage option

The result? Developers get up and running quickly and gain access to the platform and tools that they need to be productive without sweating the details of the underlying infrastructure.

Tuesday, June 21, 2016

What are the right metrics for DevOps?

5569561425 305949e779 z

If you’ll be at Red Hat Summit check out our BoF and other DevOps sessions.

Ask about metrics for DevOps and the natural reaction is to jump to familiar technology-focused measurements. Uptime. Code deploys per hour, day, or month. Deployment failure rate. Even lines of code.

Certainly, it’s important to have metrics.

DevOps works because continuous iteration and improvement is fundamentally a more rapid and flexible approach to software development than slow rigid project cycles. However, fully realizing this approach to developing and deploying software means putting in place the measurement systems, technologies, and metrics to present actionable insights that can then be acted on appropriately. Adding to the complexity is the need to present appropriate metrics for different audiences such as developers, operations, and business leaders.

Tracking narrow technical indicators can indeed be useful as part of tracking the success of your DevOps initiatives. Analysis may point to trend lines that are pointing in bad directions. An increased number of failures that lead to customer-facing outages can hardly be anything but a negative indicator. Conversely, continuous improvements in measurements such as time to deploy new services are a good indicator that a DevOps initiative is helping to produce positive outcomes.

However, one needs to be careful about overly focusing on easy-to-measure numbers that aren’t necessarily particularly correlated with business outcomes. It can be useful to step back. What are you really trying to accomplish? What’s important to you?

Are you most focused on the deployment velocity of new services? Is improved code quality or more rapid security updates the more pressing factor behind your DevOps? Or are you taking a broader organizational view that emphasizes cross-team collaboration?

These are some of the questions that we’ll be asking as part of what’s sure to be a spirited discussion at the How to Know if Your DevOps is Working birds of a feather session that I’ll be moderating along with Red Hat’s DevOps Strategy Lead, William Henry.

Also be sure to check out the many other Summit sessions related to DevOps.

I’ll be co-presenting with Ansible GM Todd Barr in Getting Started with DevOps. We’ll be talking about on-ramps from both primarily developer-centric perspectives (with a focus on OpenShift) as well as more ops-centric ones (with a focus on Ansible). Other DevOps sessions include:

There are also a variety of sessions that directly focus on how organizations are successfully making use of Red Hat products to implement DevOps today. These include:

Finally, I’d just note that a big reason that DevOps is such a hot topic right now is that it’s part and parcel of a host of interrelated technology, architectural, and business model changes that generally fall under the term digital transformation. Containers, container management, microservices, software defined infrastructure, mobile, and the internet of things are among the technologies that dovetail with DevOps to enable organizations to deliver new digital services quickly and cost effectively. There are lots of Summit sessions on those topics too. Check them out.

Photo credit: Fickr/CC

Thursday, June 16, 2016

Newsletter Issue #6 - Red Hat Summit, OpenShift and more

Read it and/or subscribe!

The end of cattle vs. pets

6830903723 eb2df17454 z

Metaphors and models have finite lifespans. 

This usually happens for one of two reasons.

The first is that metaphors and models simplify and abstract a messy real world down to especially relevant or important points. Over time, these simplifications can come to be seen as too simple or not adequately capturing essential aspects of reality. (This seems to be what’s going on with the increasing pushback on “bimodal IT.” But that’s a topic for another day.)

The other reason is that the world changes in such a way that it drifts away from the one that was modeled.

Or it can be a bit of both. That’s the case with the pets and cattle analogy as it’s been applied to virtualized enterprise infrastructure and private clouds. 

The “pets vs. cattle” metaphor is usually attributed to Bill Baker, then of Microsoft. The idea is that traditional workloads are pets. If a pet gets sick, you take it to the vet and try to make it better. New-style, cloud-native workloads, on the other hand are cattle. If the cow gets sick, well, you get a new cow.

Pets and cattle roughly corresponded to the Systems of Record and Systems of Engagement taxonomy proposed by consultant Geoffrey Moore (of Crossing the Chasm fame). The former were stateful, big, long-lived, scale-up, and managed/maintained at the individual machine level. The latter were assumed to be stateless, small, transitory, scale-out, and managed at the level of the entire application (with individual VM instances destroyed and recreated in the event of a problem).

As an initial pass at distinguishing between traditional transactional apps and those designed along more cloud-native lines, the metaphor isn’t a bad one. I've argued that “ants” is a better fit than “cattle” because it captures the idea that individual service instances are not only disposable but they work together cooperatively to perform tasks. However, the overall concept of long-running mutable instances vs. short-lived disposable ones would seem to capture an essential distinction.

It still does, but as we as an industry continue to evolve DevOps practices and services-oriented architectural patterns for software defined infrastructure and orchestrated pools of containers, the metaphor is breaking down for several reasons. 

State matters

Many of the components/instances of a cloud-native application should be designed so that they are stateless. That is, they should use ephemeral storage—which is to say storage and data that only sticks around for the life of the instance itself. However, no one’s claiming that the data doesn’t need to live somewhere. For example, in twelve factor app parlance, there’s the concept of a backing service which "is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached)."

As we move to containerized infrastructures, the stateful vs. stateless dichotomy becomes particularly important because containers are explicitly designed to be immutable. As Keith Tenzer describes in this post about OpenShift v3 persistent storage: "Docker images are immutable and it is not possible to simply store persistent data within containers. When applications write to the Docker union file system, that data is lost as soon as the container is stopped.”

However, it’s still possible to associate persistent data with containers so that an entire application can be containerized. Keith goes on to note that:

OpenShift v3 supports using persistent storage through Kubernetes storage plugins. Red Hat has contributed plugins for NFS, ISCSI, Ceph RBD and GlusterFS to Kubernetes. OpenShift v3 supports NFS, ISCSI, Ceph RBD or GlusterFS for persistent storage. Kubernetes deploys Docker containers within a pod and as such, is responsible for storage configuration. Details about the implementation of persistent storage in Kubernetes can be found here.

Kubernetes allows you to create a pool of persistent volumes. Each persistent volume is mapped to a external storage file system. When persistent storage is requested from a pod, Kubernetes will claim a persistent volume from the pool of available volumes. The Kubernetes scheduler decides where to deploy the pod. External storage is mounted on that node and presented to all containers within pod. If persistent storage is no longer needed, it can be reclaimed and made available to other pods.

Most cloud-native applications require there to be persistent storage somewhere. While one can assume that it’s provided through a service running somewhere else, a platform supporting the development of complete cloud applications needs to provide persistence mechanisms within that platform.

Virtualization and cloud/software defined infrastructure convergence

Software-defined infrastructure technologies, also made initial simplifying assumptions in other areas such as networking architectures and the maintenance of running instances. Some of this was a sincere, if sometimes naive, desire to dump legacy encumbrances. However, it was also about getting an MVP out the door in a rapidly changing world. 

We’re seeing today the reintroduction of virtualization features required for “enterprise use cases” into projects such as OpenStack. Thus, Neutron (OpenStack networking) isn’t just about flat networking architectures and current versions of OpenStack support live migration of instances whether using shared storage or block-based storage associated with a single image. The fact that many of the same technologies such as the KVM hypervisor in Linux bridge enterprise virtualization and cloud technologies simplifies the bridging of the two worlds. (Of course, it’s probably increased the complexity of OpenStack relative to what it would look like in a purist cloud-only world. Such a purist OpenStack would also likely not be very useful.)

The continued evolution of the new application platform

Perhaps most of all though, the metaphor is breaking down because the idea that there are two canonical application architectures seems increasingly simplistic. 

I’ve already covered how persistent storage is an important component of most modern cloud-native applications. 

It’s also the case that many new applications will indeed be decomposed into lightweight single-function microservices that expose public APIs. However, getting to that point will be an evolution. Martin Fowler, who helped popularize the microservices term, has even argued for a “Monolith First” strategy in some cases, including for projects that are big enough to justify a shift to microservices over time. As a result, blanket statements about horizontal app scalability and disposable services don’t apply universally—even for apps that are greenfield and reasonably considered cloud-native.

Applications also have substantially different patterns that relate to how instances are clustered together using technologies such as Kubernetes (which OpenShift uses as its orchestration layer). Some types of applications are batch oriented in the vein of traditional high performance computing/grid while others are composed from multiple layers of services communication through APIs. There’s also considerable variety not only in the absolute scale of application components being scheduled and orchestrated, but also in the variety of the components (large, small, frequency of scheduling, etc.) and requirements related to quality-of-service, latency sensitivity, and so forth.

In short, while there are certain patterns that we tend to associate with cloud-native applications, there’s also much variety and even divergence in key aspects. Furthermore, it turns out that some traditional enterprise application characteristics such as persistent state and tightly-coupled components continue to play a role even for greenfield cloud apps. 

It’s not cattle and pets out there. It’s a whole menagerie!

Photo credit:

Wednesday, June 08, 2016

Presentation: The New Platform-You Ain't Seen Nothing Yet

The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. Today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of recent developments, including containers and Docker, distributed resource management, and DevOps tool chains and processes. The resulting infrastructure and management framework must be optimized for distributed and scalable applications, take advantage of innovation stemming from a wide variety of open source projects, span hybrid environments, and be adaptable to equally fundamental changes happening in hardware and elsewhere in the stack.

From CloudExpo, New York City

Links for 06-08-2016

Hybrid and IoT themes from CloudExpo

Screen Shot 2016 06 08 at 11 46 32 AM

There are a couple of themes that I seem to keep running into and this week at CloudExpo was no exception. Neither is exactly new. In fact, the first is something that some of us have been saying for a very long time. But both seem to have crossed some threshold to become a widely-understood normal.

The first of these is the acknowledgement that computing is heterogeneous and hybrid. From my perspective, this is barely worth remarking upon at this point with so many companies flinging around the word “hybrid” with wild abandon—however newly they’ve come to this particular reality. 

At this point, let me mention that I wrote a piece for CNET titled “There is no Big Switch for Cloud Computing” in 2009 when I was still an analyst. The Big Switch in question being the title of Nick Carr’s book in which he laid out the argument for an electric grid-like utility for computing. And my now-employer, Red Hat, has likewise been talking about portability across hybrid physical, virtual, private, and public cloud environments for almost as long.

Nonetheless, IBM’s Phil Jackson felt the need to emphasize the hybrid theme in his CloudExpo keynote. By itself, this probably wouldn’t have caught my attention given how many vendors are now belatedly embracing hybrid environments in their pitches. 

However, by coincidence, I also got into a conversation with John Mark Troyer, formerly of VMware and a generally smart guy. It started with his comment about “multi cloud” being a driver of projects like Kubernetes and DCOS (Mesos). He added that he was mostly thinking about "how conventional wisdom has shifted quickly from AWS-only to multi-cloud” and that "despite recent Oracle-Google ruling, cloning a hostile API is still not for the faint of heart."

He’s right. It wasn’t that long ago that there was a significant school of thought that the AWS API was key to any cloud strategy. That was essentially the whole basis of Eucalyptus’ business plan—allow organizations to build an AWS-compatible cloud. (HP bought Eucalyptus in 2014.) 

There are a variety of reasons why API compatibility with AWS largely dropped off the cloud agenda. That discussion would deserve its own piece. Suffice it to say though that there’s effectively been an ongoing and steady movement away from the view of cloud as a homogenized commodity toward something that’s hybrid in place, hybrid in service type (IaaS, PaaS, and SaaS), and hybrid in the types of capabilities offered, and hybrid in the audience for which it’s designed.

The second is that IoT discussions can be maddeningly unfocused. It’s about so many largely orthogonal topics that it’s hard to talk about technologies, business models, ecosystems, etc. associated with IoT except in the most general sense. Sure, we can define it as the interface between the physical and the digital world or we can discuss how IoT uses data to gain insights and optimize actions. But that’s really broad. As my colleague Kurt Seyfried wrote me: "Saying IoT is like 'Shipping of Things,' aka every business using the post/delivery system... It's too generic to be useful."

As I wrote after the MIT Enterprise Forum’s Connected Things 2016 event: "IDC’s Vernon Turner admitted that "It is a bit of a wrestling brawl to get a definition.” (For those who don’t know IDC, they’re an analyst firm that is in the business of defining and sizing markets so the fact that IDC is still trying to come to grips with various aspects of defining IoT is telling.) 

We’ve had something of the same issue with cloud. (I also wrote “Just don’t call them private clouds” in 2009.) And I imagine that, at the end of the day, we’ll muddle through in more or less the same way. But it’s worth at least observing that consumer wearables and smart home devices have little in common with industrial IoT solutions. For that matter, it’s unclear the degree to which solutions associated with healthcare, retail, agriculture, “smart cities,” and logistics/transportation will have in common beyond some sensor technology.