Thursday, March 13, 2014

Links for 03-13-2014

Monday, March 10, 2014

Links for 03-10-2014

Monday, March 03, 2014

Devs and automated Ops

Over at CIO, Stephanie Overby presents a GE Capital case study in which

The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.

7249435726 91f8f3e818

DevOps is often thought of as the breaking down of walls between operations and development. As such, it’s the IT equivalent of other types of integrated teams—an organizational style that goes in and out of fashion but is more in that out at the moment.

Looking at DevOps this way is… well, not wrong exactly but it misses important points. It’s worth stipulating here that there’s not yet a broad industry consensus around what DevOps. Nonetheless, it’s broadly recognized that historical boundaries between developers and operators and—as important—between the tooling that they use are rapidly breaking down.

Let me lead into my point with another quote from the article.

The project not only proceeded quickly -- the application was delivered within several months -- it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well. 

Note the repeated use of the word automation.

A naive view of DevOps (which corresponds to how it was often discussed a few years back) was that DevOps was about the merging of developer and operator roles into one. The developer grabbed the production SQL database root password and the operator started churning out PHP. But that’s not really the DevOps story.

Much remains to be written and discovered on this topic. (By myself and others.) But one way that I increasingly think about DevOps is that the architects and operators build the infrastructure, setup developer self-service, automate scaling and deployments and then get out of the way.

For example, here’s how Paypal’s Ryan Granard described their approach with Red Hat’s OpenShift PaaS at GigaOm Structure last June:

Our concept is you walk up to a portal, you pick the product that you want to work on. You're not asking VMs and RAM. You just say, I want to work on Wallet. In minutes, we have you up and running in a fully connected container and you're developing. That's the key. That's a real benefit to just the speed of innovation and ultimately not having developers or testers or any of these folks do anything that's not part of what their role fundamentally is.

Viewed through this lens, DevOps can be seen as not necessarily about developers becoming amateur DBAs or operations folks slinging a lot of code. It’s true that some of the newer management and operational tooling—think Puppet, Chef, Foreman, and so forth—is lighter weight and perhaps more suited to a degree of joint dev and ops use. However, it’s also clear that DevOps is about automating the relevant subset of operations for developers and providing easy-to-use instrumentation and controls that let them make effective us of that underlying infrastructure.

photo: CC/flickr by M Ray http://www.flickr.com/photos/mray/7249435726/

Video: Translating Open Source Value to the Cloud



Here's a video of the talk I gave at the Linux Collaboration Summit in 2013. I'll be giving a new presentation on How OpenStack is Paralleling Linux Adoption (and how it isn't) in a few weeks at this year's event in Napa.

Podcast: Cross-realm trust with Dmitri Pal and Ellen Newlands

Ellen Newlands and Dmitri Pal handle product management and engineering respectively for Red Hat Identity management. In this podcast they discuss cross-realm trust, a new feature in Red Hat Enterprise Linux 7.0 (currently in beta), which centralizes identity and makes integrating identity management from Linux with Active Directory and managing it much easier than it has been in the past. We also cover some of the work that Red Hat is doing around one-time passwords.

Listen to MP3 (0:12:02)
Listen to OGG (0:12:02)

[Transcript]

Gordon:  We're going to be starting to talk about some of the new features coming down the road in RHEL 7, Red Hat Enterprise Linux 7, that's scheduled to ship later this year. Today, we're going to talk about one of the new security features in RHEL 7, namely, cross‑realm trust.
Maybe, get a high level view to start off. Ellen, why don't you explain what it is and why people care about it?
Ellen Newlands:  Microsoft’s Active Directory is installed in many, many of our customers' accounts. In addition, of course, customers also are using Red Hat Enterprise Linux.
One of the things that we will be shipping in the latest version of RHEL, which will be RHEL 7, is the ability to easily integrate identity management from Linux with Active Directory, something that centralizes identity and makes the management of those identities much easier than it has been in the past.
Gordon:  Dmitri, could you tell us at a reasonably high level what this cross‑realm trust is?
Dmitri Pal:  Cross‑realm trust is the capability of the identities from one domain to access systems and resources in another domain. So instead of systems having to be directly connected to the Active Directory as they have been in the past, we can have a central server that would manage those systems while enabling users to come from Active Directory and access those systems and access the resources provided by those systems, for example, NFS and things like that.
Gordon:  From the point‑of‑view of a system admin, how is what they can do with cross‑realm trust simplified or different from how they would do things today?
Dmitri:  Today, with the solutions that are available, Linux systems are usually joined directly into an Active Directory domain. That means that they need to be managed through the Active Directory tools or found by the tools related to or integrated with the Active Directory.
In some cases, that's the preferred method, but that requires the protocols that are driven from Active Directory. Linux systems have their native needs in terms of POSIX attributes, the SELinux capabilities, the sudo capabilities. Linux systems are really not exactly the same as Windows systems, so turning Linux systems into Active Directory directly requires a lot of remapping things.
We had a solution for managing Linux systems, but it was isolated. The idea is to provide the best‑of‑breed services for the Linux systems on one hand, and to enable the users from Active Directory to access those systems on the other hand. It's the best‑of‑breed of both worlds.
Gordon:  This is really a way of essentially federating identities.
Dmitri:  Yes, but using domain‑to‑domain. It's federation on the Kerberos level. It's domain federation rather than other ways of federating like SAML or OpenID. This is on a lower level, on the infrastructure level rather than on the application level.
Gordon:  Is there a particular audience for this type of approach versus other approaches? In other words, who's been asking us to do this?
Dmitri:  The main consumer is the part of the organization which is responsible for the infrastructure, for maybe cloud services or storage services, the things that provide the fabric required for the enterprise to do their business. The applications can be on the top of that, consuming the cloud or the big data that is running on top of this infrastructure.
Clearly, having a set of the systems that constitute the infrastructure as a part of Linux and joined into the Active Directory through the trusts is that domain audience.
Gordon:  Ellen, what have you been hearing in terms of demand for this?
Ellen:  One of the things that I find quite interesting is we are now in the high‑touch beta phase for RHEL 7. A number of the customers who have shown a great deal of interest in this particular capability, the cross‑realm trust, are in banking, telecommunications, retail, healthcare, and public sector.
What we find is that these are accounts where Active Directory may be what we call the authoritative source for compliance.
But there's a large infrastructure component for Linux that also wants to be involved in the higher levels of compliance but managed with the Linux capabilities. As Dmitri explained, there are certain native Linux capabilities, like automate and sudo, et cetera, that this enables that area of the corporation to maintain while still falling under the corporate architecture where maybe Active Directory is the authoritative source.
We've seen a lot of interest from generally very large customers who have a complex or heterogeneous environment.
Gordon:  That's pretty common these days.
Ellen:  Yes it is. It seems like very, very few customers have only one vendor or one operating system Linux is very often in a division or the development group or whatever in a wider context.
Dmitri:  I want to add one important factor of the cross‑realm Kerberos trust. That kind of a deployment allows great integration from whatever solution the enterprise has at the moment to the future vision and the future architecture. By deploying identity management in Red Hat Enterprise Linux that comes with Red Hat Enterprise Linux 7.0, you can establish this trusted domain and then gradually move your systems into that domain.
One of the important things is that you don't need to move to the latest versions of Linux. You can serve with this solution both the latest the version, the 7.0, and the latest version of RHEL 6. You also can integrate earlier Red Hat Enterprise Linux versions as well as non‑Linux systems.
Gordon:  This highlights what the analysts are telling us. What we see is an idea that IT is increasingly hybrid, and that solutions that force homogeneity are increasingly uninteresting, nonviable even, at customers.
Ellen:  That's absolutely true. Increasingly, it's a heterogeneous world. Increasingly, also, the corporate boundaries are somewhat porous. The ability to move in and out of vendors' various environments is very valuable, especially when we offer centralized management. It takes less time, less work and is easier to manage and, to some extent, update.
Gordon:  I would be remiss and some of my friends would disown me if I didn't mention that Red Hat Summit is coming up mid‑April in San Francisco. For listeners who are interesting in this sort of thing, there are going to be a lot of great sessions around identity management at Red Hat Summit.
Ellen:  Yes, indeed. Dmitri will be doing demonstrations not only of the new cross‑realm trust coming out in RHEL 7. One of the other features that I think is interesting is, we've done some work in what we call OTP, which is one‑time password capability.
Dmitri, would you like to explain a little bit about why that would be of value?
Dmitri:  We have been working on the one‑time password technologies and integrating them directly into the identity management solution for quite some time. It's not going to be available in Red Hat Enterprise Linux 7.0, but it is in a stage of development that is ready for us to talk about that.
It's coming down the road. It's pretty solid technology right now. We will demonstrate it in the booth at the conference.
The main value is that you can authenticate with two‑factor authentication, like a token fob that you have or a token that you have on your smartphone, and then acquire, as a result of this authentication, Kerberos trust, that would allow your enterprise single sign‑on between different services within your enterprise.
In the past, there has been no solution that allowed you to do that in an integrated fashion. There has always been a password hidden somewhere. You authenticate with two factors. With that you unlock a password, and then that password is played against Active Directory or LDAP or any kind of authentication server.
With identity management in Red Hat Enterprise Linux, we are building it in such a way that it is single stack. That's pretty powerful. There is a lot of potential in this technology going forward.
Ellen:  By the way, I think everybody in your listening audience will know that two‑factor authentication increases your security.
Gordon:  Pretty dramatically
Ellen:  Very dramatically.
Gordon:  Thank you for your time today. Anything else either of you would like to share?
Dmitri:  Come to the conference, join us in the booth, and join us at the talks that we'll have during the course of the summit. There will be some labs, also, dedicated to identity management. See you there. Thank you.

Ellen:  Looking forward to seeing you at summit. Thank you.

Links for 03-03-2014