Friday, April 11, 2014

Links for 04-11-2014

Thursday, April 10, 2014

Podcast: ownCloud with CTO and co-founder Frank Karlitschek

Based on the popular ownCloud open source file sync and share community project, ownCloud was founded in 2011 to give corporate IT greater control of their data — combining greater flexibility, openness and extensibility with on premise servers and storage. In this podcast their CTO and co-founder discusses how this project and product helps companies and individuals choose where their data is hosted.

MP3 version [12:24]
OGG version [12:24]

Wednesday, April 09, 2014

Links for 04-09-2014

Presentation: How OpenStack is paralleling Linux adoption (and how it isn't)

I gave this presentation at the Linux Collaboration Summit in Napa last month. It brings together various thoughts for a couple of earlier blog posts of mine. When I have time, I'll put up an annotated version.

OpenStack is paralleling and will likely continue to parallel the adoption of another open source project that has become enormously popular and successful—namely Linux. The parallels are educational and useful in that they lend insight into the rate at which adoption takes place and what we might expect successful adoption to look like. At the same time, this session will provide appropriate caveats about assuming that OpenStack can be viewed as just a latter-day Linux. By applying this sort of historical perspective, we can better understand what might be the most effective approaches to collaboration, community-building, and cooperation moving forward.

Monday, April 07, 2014

Links for 04-07-2014

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

Monday, February 24, 2014

Links for 02-24-2014

Tuesday, February 18, 2014

5 ways in which OpenStack doesn't parallel Linux

Last month, I wrote a post discussing the parallels between OpenStack and Linux. Briefly, these are the following:

  • Part and parcel of a new approach to computing
  • Adoption rates won’t be uniform
  • It takes time
  • About community as much as technology
  • Open source development is an incremental process
  • Commercial distributions make consumption by businesses possible
  • Need for complementary components and integration

A number of folks have pointed out that there are differences too. To which I say "I agree!" From my perspective, here are five of the most salient deltas.

Opst blogimage opst parallel linux 700x400 11851957 0114 jw

1. Open source is now ubiquitous and part of the landscape. In 2001, Microsoft CEO Steve Ballmer was giving interviews like the one he gave to the Chicago Sun Times in which he said "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches." In 2001, Gartner analyst George Weiss was writing that between 2003 and 2005, "enthusiasm for Linux will increase selectively... However, their enthusiasm will be tempered by the entrenched position of Unix, which has already achieved mission-critical scalability and availability, by the strong Windows 2000 upgrades in the pipeline, and by the potentially heavy cost of migrating to Linux." My point here isn't to pick on anyone in particular (well, maybe Steve Ballmer) but to highlight that, circa 2001, Linux and open source generally faced an environment that ranged from skeptical to unremittingly hostile outside of (mostly) leading-edge technology adopters like Wall Street. Today, by contrast, open source is used widely--ubiquitously even--and companies like Google and Facebook would not even be feasible in open source's absence. In short, OpenStack's birth and maturation is taking place in a much more welcoming environment than did Linux'.

2. Open source is in the enterprise. And not just some enterprises in some industries. According to Red Hat's data, "more than 90% of Fortune 500 companies use Red Hat products and services." That's just Red Hat. (And, one suspects, there are open source pockets at most, if not all, of the remaining 10 percent.) Here's what Gartner is now writing about open source software in their Hype Cycle for Open-Source Software, 2013:

Continuing a trend over the past 10 years, the open-source software (OSS) model continues to expand and affect market segments across nearly the entire IT industry spectrum. For example, Linux was the first widely acknowledged success of open source in many IT organizations, and it remains the flagship of OSS success; however, the list of "industry-changing" OSS solution continues to grow year after year as well. Today, projects like the Apache Web Server, the JBoss Application Server, MySQL RDBMS, Eclipse IDE, MongoDB, and many more show the broad influence that OSS continues to have on the industry as a whole.

3. Open source is driving innovation. Historically, open source was more about commoditizing and democratizing technology approaches that already existed and were proven in the world of proprietary software. BSD and then Linux did so to proprietary Unix but they are hardly the only example. OpenOffice, the Apache web server, and MySQL database all didn't initially drive the state of the art forward so much as they drove price points dramatically downwards--and thereby greatly increased the number of people and organizations that had access. This dynamic remains true for some open source software, but the collaboration that the open source development model makes possible is now driving industry innovation in so many areas. In data storage and analytics, almost all of the interesting new approaches are in open source. And that's true also with building IaaS clouds where OpenStack is gaining so much attention. OpenStack isn't about mimicking a proprietary IaaS. There isn't such a thing outside of a few big public cloud providers (and, with the exception of Microsoft, they all make extensive use of open source as well). 

4. OpenStack is for the datacenter. So far, I've mostly discussed how the milieu in which OpenStack plays is different from the one in which Linux operated at first. There are some differences in the projects themselves too. Linux has probably had its greatest impact as a server operating system, but there's nothing inherent to Linux that limits it to that role. Indeed, the fact that someone could spin up Linux on an old PC and tinker with it arguably had a great deal to do with its grassroots encroachment into the server room. In the modern era, variants of Linux appear in everything from mobile devices to Mars Rovers. OpenStack, designed as it is for datacenter infrastructure, is more expressly tailored to run on a (moderately large) pool of servers. It's also more likely to enter the datacenter by the front door as a result. 

5. The OpenStack community is different from the Linux kernel one. Finally, it's worth observing that the OpenStack project's organization differs significantly from that of the Linux kernel. There are some similarities in that large commercial organizations (not least of all Red Hat) make significant contributions to both projects. But the Linux kernel runs as a sort of "benevolent dictatorship" (reflecting its roots) while OpenStack is governed by a foundation established for the project (reflecting its establishment primarily by a number of companies coming together). The difference also reflects how the Linux kernel has a singular identity and purpose while OpenStack is more of a framework for a number of sub-projects and includes more rapidly changing technology. In some ways, OpenStack looks more like a distribution than a single open source project--although that comparison fails in a number of respects as well.

Different doesn't mean better or worse. It means different. I always favor looking for historical parallels because they can be instructive and offer a window to the future. It's equally important though to understand the differences in the environment between yesterday and today, as well as between the things being compared themselves. In the case of Linux and OpenStack, there are lessons to be drawn for OpenStack by looking at Linux adoption so long as they're not slavishly drawn.  

Links for 02-18-2014

Monday, February 17, 2014

Links for 02-17-2014

Friday, February 14, 2014

Links for 02-14-2014

Tuesday, February 11, 2014

Links for 02-11-2014

Thursday, January 23, 2014

Links for 01-23-2014

Tuesday, January 21, 2014

Links for 01-21-2014

Thursday, January 16, 2014

Links for 01-16-2014

Wednesday, January 15, 2014

Links for 01-15-2014

Monday, January 13, 2014

What Red Hat's up to with partners and AWS Test Drive

The AWS Test Drive Program is a way to easily try out enterprise software. To quote AWS:

Test Drive simplifies clients’ access to complex IT environments, using the programmable infrastructures of AWS. Test Drive enables customers to rapidly deploy a private sandbox environment containing pre-configured ISV server applications that are ready to Demo and use. Test Drive labs are provided from the APN partner ecosystem, providing rapid provisioning of private IT environments. In a few minutes you can login and start using the software, following a guided tour Video and Lab Manual.

Test Drives labs have been developed by our APN Consulting and Technology partners and are provided free of charge for educational and/or demonstrational usage. Each Test Drive includes around a half a day’s use of free AWS server time for using live enterprise solution stacks, from the industry’s leading ISVs and SIs. You can return here and try any or all of the Test Drives at any time, so feel free to experiment, explore and learn.

The basic idea behind Test Drives is that you can get free limited-time access to complex enterprise software and work through a scripted use case to evaluate that software quickly. Software can then be purchased through AWS Marketplace or other channels. AWS Test Drive is a fairly new program. It was rolled out relatively quietly last year. 

Quoting Red Hat North America Channel Sales Senior Director Bob Wilson, The VAR Guy writes: "The test drives lend themselves to complex solutions, so partners that have offerings that require multiple steps, components and complexity to display to an end customers are optimal candidates," he said. "However, any solution-based offering that solves a specific customer issue would make a good test drive."

Red Hat's announcement today is for new test drives with three of our largest North American Partners. Mark Enzweiler, Red Hat's senior vice president, Global Channel Sales:

We've enjoyed working with CITYTECH, Shadow-Soft, and Vizuri to develop these initial solutions, and are eager to develop additional Test Drives with other partners. We believe these Test Drives are invaluable, they enable partners to use their expertise in pulling together complete solutions to solve complex customer challenges and illustrate how easily customers can use these tools to migrate to the cloud.

 

Punting on the Cam

Punting on the Cam by ghaff
Punting on the Cam, a photo by ghaff on Flickr.

This is from my trip to the UK last fall. I plan to be in London and Belgium in a few weeks for at least some of the end of Jan/beginning of Feb open source extravaganza set of events.

Links for 01-13-2014

Friday, January 10, 2014

Why you need a cloud management platform

I put this post up on the Red Hat OpenStack blog. If you haven't checked this blog out, give it a look and consider subscribing. 

Cloud infrastructure and cloud management. As an industry, we conflate these two things far too often.

This is understandable up to a point. Cloud computing architectures are relatively new and new architectural approaches often involve figuring out how functions are best partitioned and how they relate to each other. The process tends to be pragmatic; that’s how the networking stack first developed. That terminology is often morphing and inconsistently applied (innocently or otherwise) doesn’t help matters.

The overall building blocks of the private and hybrid cloud stack have now crystallized to a significant degree. The boundaries of these blocks aren’t hard-edged of course; there’s always overlap in the management space given that basic functions tend to come built-in even if they’re superseded at scale or for more complex requirements. But we’re at a point where we can describe the relationship of a cloud platform such as OpenStack to cloud management platforms (CMP)s like CloudForms that shouldn’t be too controversial.

Continue reading at Red Hat Stack