Archive for the ‘Cloud’ Category

Metadata, APIs, and Feeds

Wednesday, December 23rd, 2009

Just for fun, I’m playing with a few plugins on this blog that are intended to provide metadata and catalog services.  For instance, there is a plugin called ScholarPress COinS which inserts a Context Object in Spans (aka COinS) element into each post.  The COinS element provides metadata about the post, such as the title, author, date, etc, making it easily importable into other tools (such as Zotero) or reference / search platforms.  In order to expose this sort of metadata in a catalog form (i.e. list, resource map, etc) I’ve also installed the COinS-PMH, OAI-ORE, and unAPI (also see Peter Binkley’s blog and unAPI.info) plugins.  I wanted a complete OAI-PMH plugin but couldn’t find one; please let me know if you’re aware of this space and have a suggestion of where I could look.

Given that most of my blog posts aren’t the sort of thing people will care to archive, I recognize that most of these plugins aren’t practically useful–they’re just for me to play and learn.  However, I also installed a PubSubHubBub plugin which, not surprisingely, implements the PubSubHubBub protocol.  Basically, it pings "hubs" when a new post is available, which in-turn pings a list of URLs that have been registered as web-hook callbacks.  The built-in hubs are http://pubsubhubbub.appspot.com/ and SuperFeedr, and I’d like to implement my own hub just to become more familiar.  The interesting example of how this could be interesting is SuperFeedr’s ability to translate feed pings to an XMPP stream (aka Jabber).  I’ve got some interesting ideas about how to use that in some infrastructure management and monitoring tools.

So, if you’re interested in experimenting with any of these technologies please let me know.  I’d be happy to test out new code, either in this blog or independently.

Reflections on MPLS 2009

Monday, December 14th, 2009

It has been well over a month since I attended the MPLS 2009 conference and participated in the panel on Emerging Technologies and Business Architectural Impact, and it is about time (over-due) that I posted my thoughts.

Foremost, I should say Thank You to Monique Morrow for organizing such a great panel and inviting me to participate.  I’ve known Monique as a colleague and friend for a while now, and whenever we have chance to meet she never fails to impress me.  In the context of this panel, I was dumbfounded at the quality and breadth of the other participants that she secured.  Monique moderated the discussion such that the panel’s large size was a benefit rather than liability.  As a panel we managed to cover multiple topics with decent depth, and were each allowed to illustrate our different perspectives.  I’ve been told by several audience members that it was an excellent panel, and from my (admittedly biased) perspective I must agree.

As for the discussion itself, I very much enjoyed participating.  Considering the quality of the other panelists, I am honored to have been included; each of the other panelists are recognizable for their contributions and role in the industry.  Given my respect for the other panelists, I tried to enter the conversation prepared and did not hold back any of my significant thoughts during the discussion… for better or worse.

Some of my comments may have included points that were controversial.  For instance, one theme that ran through the entire discussion was the complex balance of cost vs. capacity vs. features in network devices.  I challenged comments from Vijay Gill (of Google) and Donn Lee (of Facebook) which argued in favor of very-large dumb switches. ("dumb" is my word choice, but I suspect they would agree)  From their perspectives, as engineers for large web properties, they need to scale out single-tenant environments to support Internet-scale traffic loads and a simple L2 or L3 switch would enable their topology.  But, I argued, they were "weird" in their requirements, which are unique to large web properties.  Service providers and enterprise environments need more features in order to deal with the complexity and changing "customer" requirements they face daily.

After the panel I had the opportunity to chat with Vijay and Donn, and they had an interesting view of the cost / capacity / features debate.  Their comments deserve some focus, so look for a future post on this topic.

Another topic was the relevance of standards, which wasn’t particularly controversial but which caused some interesting comments.  My point was that standards are critical to the industry, but in the same way that fundamental research is critical to science and technology (broadly speaking).  We need to put effort into standards because it brings people together and promotes the state of the art.  But we also need to recognize that functioning interoperable implementations are what matter, regardless of the standards conformance, etc.  In other words, standards bodies should work diligently but not take themselves too seriously in the process.

Regardless, I hope to be included in future panels such as this one (at the MPLS conference and/or elsewhere) and I’m glad to have had the opportunity at MPLS 2009.  I would absolutely recommend that you attend future panels by Monique, at MPLS 2010 or otherwise, whether I’m taking part or not. Though, obviously, it would be better with my opinion included. ;)

CloudCamp St Louis – This Week!

Monday, December 7th, 2009

In the handful of weeks since we announced CloudCamp STL more than 100 people have registered to attend.  That is awesome!

Given the short notice and the holiday season, I expected a much smaller number.  But word of the event has spread, in no small part thanks to the marketing of Sam Charrington of Appistry.  He wrote a blog post about the upcoming event recently, and has sent messages to local user groups and industry contacts.  Others have spread the word, too, such as Alex Miller who also wrote a blog post.  Then, today I see that the Riverfront Times (RFT) also has a blog post about the upcoming CloudCamp STL meeting.  I couldn’t be happier with the publicity being generated by this CloudCamp.  It shows that St. Louis has what it takes to be a part of the global cloud community.  And when the meeting takes place, attendees / participants will see that St. Louis is, in fact, home to multiple industry thought leaders.

If you want to attend, please register at http://cloudcamp-stlouis-09.eventbrite.com/.  Registration is not required to attend but it helps us plan the space, food, and supplies.  And, of course, registration is free!

Finally, many thanks to our sponsors which currently include:

And also thanks to our Media Sponsors, which help promote the CloudCamp and spread the word to their communities:

St. Louis Java Users Group
StrangeLoopConference2009
Lambda Lounge

Blade Networking Architecture: Cisco vs. Juniper

Monday, November 30th, 2009

My interest was piqued by news from Juniper Networks that they had licensed JunOS to BLADE Network Technologies.  Not that I’m surprised; I’ve suggested this approach (and some approaches more extreme…) to both Juniper and Cisco in the past.  But it did get me thinking about the differences in network architecture, between the approach of Cisco’s UCS versus the potential JunOS/BLADE approach.

For instance, a UCS system leverages a "fabric extension" module, transparently connecting multiple blades to a Top-of-Rack switch (TOR) such as the Nexus 6120.  When combined with the Nexus 1000V software (and VMware-integrated port profiles) an entire cluster of UCS chassis can be managed as a single resource pool.  Making a few design assumptions, the environment may look something like this:

This design provides a single logical interface to the external network (i.e. data center backbone, WAN, whatever).  However it is a flat network within the environment.  This is great for VM mobility throughout the resource pool, but not so great for scaling the network to many VLANs.

The alternative presented by Juniper provides an interesting comparison because it moves a switching function into the blade-server chassis.  Admittedly this doesn’t have to replace the TOR switch.  But just for argument’s sake, again making a few additional assumptions, the design could look something like this:

Note that I show a chassis with and without hypervisor-local switching.  This is just to illustrate the possibility, which admittedly could also exist in the Cisco UCS environment; this is not because I have some interesting point to make about it. ;)

Regardless, the Juniper/BLADE design may allow for better network scaling depending on the features that are bundled into the chassis switch.  However, in contrast to the UCS design there are more management touch-points.  And to really take advantage of the network scale possibilities, the network architecture itself has to be different — more oriented around layer 3, less of a wide-flat-layer 2.  This could be a problem for VM mobility depending on the overall application needs (mostly due to IP addressing and the need for shared broadcast domains).

The key next-step in either approach, in my opinion, is to deploy new features in the TOR and/or chassis switch.  Specifically, data center networking doesn’t have to be an all or nothing L2 vs L3 debate.  Please look for additional thoughts on this topic in a future post.

Comment on Enterprise Transition to Cloud

Saturday, November 28th, 2009

I just wanted to share a comment that I recently posted to Vijay Gill’s blog, regarding cloud economics:

Enterprises are tricky. They are full of legacy apps that won’t magically transition to PaaS. And their internal IT isn’t very visible to the outside world. In other words, the enterprise cloud transition will take a long time and most people won’t know that it’s happening.

That being said, one should be careful about underestimating cloud service providers focused on the enterprise market. (And the dark horse impact of enterprises on the PaaS landscape.)

Obviously, I left a lot unsaid…  Perhaps I can elaborate in future posts.

Regardless, I’m interested in your feedback — what do you think about the enterprise transition to cloud?