Monday, April 28, 2014

Links for 04-28-2014

Thursday, April 24, 2014

Links for 04-24-2014

Tuesday, April 22, 2014

Links for 04-22-2014

Monday, April 21, 2014

What I did on my Summit vacation

As many of my readers probably know, last week was Red Hat Summit in San Francisco. The big #10, the largest crowd ever, and the first time outside of Boston since it was a much smaller event. This was (I think) my sixth Summit—four since joining Red Hat and two prior and my only regret is that there weren’t two or three of me in attendance. Between my own sessions, an afternoon spent with industry analysts, and various other meetings, I only made one breakout plus about half the keynotes. And, while I had a chance to chat with a variety of fellow Red Hatters, I didn’t get to spend sufficient time with nearly enough.

Check out the main Summit link for lots of material from both the keynotes and many of the breakouts. Lots of good work there by the video and other content teams. Thanks to their efforts, I can share some of the specific sessions I was involved with throughout Summit.

After signing some books on Tuesday, I had the pleasure of hosting Michael Coté of 451 Research who talked about why mobile, DevOps, and cloud trends matter. I’ve known Coté from back when he was an analyst with RedMonk and he recently came back to the analyst side after a stint at Dell. I did a full write-up on his talk, but some of the most interesting tidbits for me came out of recent 451 research on “mainstream” DevOps—i.e. organizations that don’t look like the usual DevOps exemplars like Netflix or Etsy. According to Coté:

These mainstream DevOps companies are mostly using testing, performance monitoring and log management, release management, and configuration management tooling. You’re still not seeing a lot of the new “utopic” startup toolchains that are most associated with DevOps. And only about 16 percent are using automation tools compared to using “older ways” of doing builds such as customer-written build tools and golden images. (Among those using automation, continuous integration tools such as Jenkins and Bamboo are the most common but there’s a lot of DIY tools out there too.)

The bottom line? “There’s strong business demand, work to be done as far as the eye can see, and lots of maturing ahead of us.”

I found this a useful sanity check about the state of DevOps outside of a relative handful of especially forward-looking technology forms.

For my next session, I did a “fireside chat” with David Linthicum of Cloud Technology Partners on best practices for PaaS, OpenStack, and cloud adoption. I’ve had the opportunity to participate with David on a series of GigaOm webinars over the past year. We wanted to try a format for Summit that recreated the interactivity and spontaneity of the webinars rather than taking up the full slot with a presentation. The audience certainly seemed to like it based on the number of questions and topics that they threw out.

Linthicum doesn’t mince words. One of his best practices is:

Go hire someone with a brain. “You need someone who can make the appropriate calls so that you’re marching in the right direction,” said Linthicum.

Most cloud-based systems are lacking architecture, and what’s more, solutions architects can get too narrowly focused on their own areas. “Typically, people aren’t going to have a range of skills that lets them be agnostic architects to make the right decision from all available choices,” Linthicum said. Hence, the need for open minds and sharp brains.

If any of this whets your appetitive, check out the embedded video and/or the blog post.

Finally, I co-presented with my colleague Jane Circle about using Red Hat products in public clouds. I focused on some of the general considerations associated with running workloads on public clouds such as how the applications scales, selecting public cloud instance types, and dealing with data governance. Jane then went into the specifics of consuming Red Hat products from both a business and technical perspective on Red Hat Certified Cloud Providers. These were our overall takeaways:

  • Develop an appropriate application architecture
  • Ensure data is portable: test, test, test!
  • Understand the legal and regulatory compliance requirements of your applicationsIsolate workloads as needed in a public cloud
  • Choose a cloud provider that is trusted and certified
  • Do the ROI to determine the right consumption model
  • Ensure consistent update for your images to maintain application certifications
  • Enable hybrid cloud management, policy, and governance

If you didn’t make it to Summit this time, there’s always next year! Thanks to everyone who came and especially to anyone who attended one of my sessions.

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