Username:

Password:

Fargot Password? / Help

Blog

Announcing the Demo Pod Winners!

Back in November, we announced that Alcatel-Lucent was becoming the community underwriter and partner sponsor for Gluecon. The primary effect of this was that we were opening up a Demo Pavilion, where every company inside of it would be there based solely on merit, and not on the ability to pay.

We opened up the application process, took in a ton of applications, asked our cadre of distinguished judges to place their votes, and now I'm incredibly excited to announce the fifteen companies that have been chosen for Gluecon's 2011 Alcatel-Lucent Demo Pod Pavilion:

BigDoor

ReportGrid

StreamStep

Wanderfly

Proxomo Software

LocVox

Singly

Eclipse Foundation

Standing Cloud

Flomio

Jexy

Axiomatics

WhoSentIt

Statsmix

Tendril

It's an amazing group of companies, all of whom will be showing their wares at Gluecon. In addition, all Gluecon attendees will be voting (via an app courtesy of Twilio) for the best demo pod at Gluecon, and the winner will be taking to the keynote stage on day 2 of the event.

I couldn't be more excited about getting these companies involved. And we should all give a huge "thank you" to Alcatel-Lucent for sponsoring such a truly great thing for the developer community.

Lastly, early bird pricing for Gluecon expires next Monday, April 18th -- so be sure to get your discounted registration today!

On Online Identity

Last night, my tweetstream lit up with comments about a piece that Ev Williams (of Twitter) wrote entitled, "Five Easy Pieces of Online Identity." I threw a few off-the-cuff comments out there and went to bed. Morning brings clarity, and the desire to comment a bit more.

First, a little context:

I've "known" Ev since the early days of Blogger (early as in him and Meg Hourihan running it, and me emailing Ev and saying, "Ev, blogger's f&cked, can you reboot it?"). In fact, Chris Locke and I ran personalization.com entirely on Blogger (i'm still arguing that this was the very first example of a business site run entirely on a blogging platform -- circa 2000).

Shortly thereafter, I got seriously involved in identity. I co-founded Digital ID World (identity management conference; sold to IDG), and was employee #1 at Ping Identity (which is now a bona fide world wide leader in enterprise identity stuff; full disclosure - I'm a shareholder). When I got into identity, I was the young guy that had to listen to all of the old directory guys tell war stories. When I "left" identity (it's like the mafia, you never leave), I was the old guy watching the young kids have the "same old arguments" that we'd been having for 7 years. Somewhere along the way, I provided feedback to Kim Cameron as he was writing "the laws of identity" -- which I consider to be *the* seminal identity document of the last 10 years.

Lastly, I obviously have huge respect for Ev, his work, etc. We're not "buddies" like we hang out having beers (or he'd even recognize me on the street), but more often than not, he answers when I shoot him an email, and I'd like to think he remembers me from back in the early blogger days -- so all of this is just constructive criticism, as it were.

With that as context, my thoughts on Ev's post:

Ev divides identity into 5 "easy pieces" - but I think he's got some confusion in the pieces (ie, there are actually more than 5), so let me walk through them individually.

1. Authentication. Ev begins with "authentication" and says it answers the question "do you have permission?" Every security guy I know just paused. That question is an "authorization" question, not an authentication question. Traditionally, security guys divide "AuthN" (shorthand for "authentication") and "AuthZ" (shorthand for "authorization") very strictly. Authentication answers one thing and one thing alone: are you who you claim to be? Once that question has been answered, THEN you move to authorization -- which is (properly) "what do you have permission to do/access/alter/etc?"

Note that AuthN and AuthZ can be split functions, as is the case with OAuth (I'm so woefully in over my head here that if I make technical errors you have to promise to be gentle). OAuth can provide AuthZ for an app to access some info (you give it permission), but it does not perform AuthN (it doesn't authenticate that you correctly are who you say you are). Example: I login to Twitter, I then give an app permission to access my twitter stuff via OAuth. I have given it authorization, but it (the app) has no way of knowing if i hacked the account to gain access in the first place - hence, AuthZ without AuthN.

Bottom-line: Ev *means* AuthZ, even though he labels it AuthN. I think. (I'll let him say differently.)

2. Representation: Ev starts off explaining "representation" by "who are you?" -- which makes every security guy think he means AuthN. But he doesn't. Hence, the question that he's answering is badly phrased. It's not "are you who you say you are?" (AuthN), but "who do you represent your self to be to the outside world (in terms of accomplishments, work history, etc)?" In this context, representation is actually the unverified flip-side of reputation.

Bottom-line: by the time Ev hits #2, he's actually got 3 pieces in his head -- AuthN (are you who you claim to be?), AuthZ (do you have permission?) and Representation (how do you present your self to the outside world?).

Since reputation is the flip side of representation, I'm skipping 3 (communication) and 4 (personalization) on Ev's list to deal (for now) with 5 (reputation).

5. Reputation: Ev's observations about reputation are spot on. Reputation is "how you are regarded" -- essentially, the flip side of representation. Reputation can be "verified" (credit scores) or "unverified" (an opinion) -- where "verification" does NOT equate to being true (there are incorrect credit scores all of the time). Most importantly, once we "externalize" and codify reputation in such way so that the person can see and access it, it's no longer reputation. Which is to say that at least HALF of reputation is what people say about you when you're not there to hear it.

3 and 4: Communication and Personalization: I actually think these are the same category, as "how do I reach you" is a personal preference. Call it the broad category of personalization -- which is giving the individual some amount of control over the relational dance that occurs between them and the outside service provider (or world at large).

That surfaces what I think is the *crucial* thing to consider when considering identity. And it's a tough philosophical nut to grasp.

Western civilization predisposes the majority of us ("us" being folks reading this blog) to think of "identity" as a discrete thing ("me") that was either determined via nature ("i'm born this way"), nurture ("my environment made me this way") or a combination of both. No matter what your view on nature or nurture, though, your western predisposition sees identity as a fairly discrete object ("me").

In practice, I'd argue that your "identity" is a constantly evolving set of relational interactions. Every time I use a debit or credit card to make a purchase, it is a complex interaction between me, the issuer of the card, and a service provider. That *interaction* (their actions as well as mine) feeds into a sense of "my" identity. But that information and interaction is in no way "owned" by me. At best, I'm legally able to exert some level of "control" over the exhaust (implications) caused by the interaction. But that's it. The relational nature of the interaction makes it nearly impossible for "me" (discrete entity) to "own" my "identity."

In that light, I'd break Ev's easy pieces down into things that are discretely associated with me and those that aren't. Note that "discrete" does not mean "lack of interaction" with other party. My philosophical stance (which is too nutty to detail here) is that there is no instance of identity where you're not interacting with something/someone/etc. (Feel free to drive yourselves crazy arguing about that without me.)

Discrete Pieces of Identity: Authentication (who are you?), Authorization (do you have permission?), Representation (how you present yourself to the world), and Reputation (how the world regards you).

Interactional Pieces of Identity: Communication, Personalization, Geo-location and any other instance where an "interaction" between you and a service provider occurs. Within that interaction, you may wish to express preferences.

The bottom-bottom-line: Ev's right. Online Identity is *still* one of the messiest problems out there, and people have been working on this for (no joke) decades (plural) now. Check out VRM, the IIW, Kantara, the Liberty Alliance, SAML, or any number of identity-related topics to see just how deep this rat-hole goes. Hats off to Ev for re-starting the discussion at large. I'll be watching to see if his next sure to be a monster startup tries to deal with the identity problem head-on. ;-)

(ps: come to gluecon for more on OAuth, SAML, etc.)

Building a Standards-Based Private Storage Cloud

On the afternoon of May 24th (the day before Gluecon "starts"), we're having three pre-conference workshops. These workshops are limited in size (40 people per workshop; registered attendees only), four hours long, and meant to be in-depth "build-fests." Which is to say, you walk in with not having, and you walk out having.

One of the workshops is brought to us via SNIA (the Storage Networking Industry Association), which has built a standards-based "cloud data management interface." Here's Mark Carlson on "Building your own standards-based private storage cloud":

This session will take you deeper into cloud storage than you likely have ever been. First we will explore the standard cloud storage interface called CDMI (Cloud Data Management Interface), including some of the rationale and design tradeoffs in its creation.

Learn about how to use the RESTful interface to move data into and out of a storage cloud using a common interface. Learn how CDMI enables data portability between clouds. Dig deep into features such as Data System Metadata (how you order services from the cloud), cloud-side operations, queues, query and more.

Then stick around as we load an open source Java implementation of CDMI onto your laptop to create your own private cloud. Explore the workings of the JAX-RS standard used in this implementation and the storage code working behind the scenes. Advanced users can even implement their own cloud storage features and expose them through the standard interface.

Be sure to take advantage of Early Bird pricing and register today!

An API for the "Real World"

Next up in the posting of session descriptions, Rick Bullotta with "An API for the 'Real World'":

There has been a great deal of activity and discussion of late regarding the potential of the "Internet of Things" or "Web of Things" in transforming our daily lives. The reality is that there is a mind-blowing amount of value and innovation that can be unlocked by bridging meatspace (people), cyberspace (systems/information), and atomspace (the physical world). A lot of work has been done to address the first two, and the third has typically been a monstrous challenge.

The application domains within the web of things are broad and diverse - ranging from smart cities, buildings, utilities, factories, retail, homes, transportation, and countless others. Additionally, there is recognition that not all of these "Things", for a variety of reasons ranging from security to physical limitations, will be connected to the internet. We also will discuss how value is not simply extracted within each of these networks (homes, cities, factories, electricity), but also at the nexus of each - the "network of networks". Examples will be discussed including industrial facilities, the smart grid, and crowdsourcing via "human sensors".

Rick will present an API for "Things" that allows data, events, and services from the "real world" to be composed, visualized, and mashed up with just about anything else. Included in this concept is set of APIs for discoverability and metadata/metamodel information as well as configuration and runtime services. We will also describe challenges in designing APIs to capture the massive data exhaust from the activity streams of "Things" into a searchable and accessible semantic data store. We will also discuss some of the opportunities and challenges in applying the current generation of web technologies to this domain, including limitations with HTTP, JSON/XML, and the Internet itself.

ElephantDB at Gluecon

I'm continuing to post Gluecon session descriptions (check out the agenda). Here's Nathan Marz:

Exporting data from Hadoop with ElephantDB

ElephantDB is a database that makes it easy to export data out of Hadoop to serve in your applications. Both the exporting and serving of a dataset is done in a completely distributed way. ElephantDB emphasizes ease of use and stability -- it just works. Unlike alternatives like HBase, ElephantDB is easy to configure, requires almost no maintenance, and is easy to deploy. BackType uses ElephantDB to serve hundreds of gigabytes of views off of a 30TB dataset.

Since ElephantDB can only be written to in batch, and doesn't support random writes, it is extremely simple. This leads to ElephantDB being rock-solid in production, since there's almost no moving parts.

In this session, you'll learn how to use ElephantDB and how to deploy/operate it. You'll learn how the exporting process works and how to configure an ElephantDB cluster to serve that data. Additionally, you'll learn how to use ElephantDB's automated deploys to provision and launch an ElephantDB cluster with just the click of a button. We'll see how to do incremental updates to an ElephantDB domain, and we'll see how to use ElephantDB as an indexed key/value file format on top of Hadoop.

Get Your Butt to Gluecon

In ten years of running conferences, I've been responsible (or, at least, partly responsible) for curating a LOT of agendas. And when you've done it for a while, and you know what your "audience" is like (I use "audience" lightly, because gluecon attendees are hardly an "audience"), then you get an internal gauge of what will hit the mark and what will miss it.

In that context, let me say this with as little hyperbole as possible: Gluecon 2011 may be the best agenda that I've ever put together (and that's not me patting myself on the back; it's all due to the presenters). Have I done other agendas with "bigger name" keynoters? Sure. But that's not what makes an agenda.

As I look at these sessions come together, the sheer weight, the meat, the substance of the breakout sessions is *stunning*. Whether you're an enterprise developer or a startup developer or an indie developer, you're going to be stretched. You're going to find things you didn't expect. You're going to walk out with your hair on fire. Okay, that was hyperbole. In any case, get your butt registered for Gluecon.

Here's today's session description -- brought to you by Francois Lascelles of Layer 7 Technologies:

Enterprise access control patterns for REST and Web API

The current trend of moving enterprise applications to SaaS-style public cloud solutions and deploying services off-premise in general is raising a number of concerns regarding security and governance in the Enterprise. The need for integration between your IT assets does not disappear once they leave your premise. In fact, this integration must now accommodate the fact that service oriented transactions cross multiple domains, over public networks. In addition to this, the Enterprise is increasingly under pressure to provide APIs to third parties such as partners, consumers, etc. The need for API management is security is now at the forefront of the Enterprise’s IT responsibilities.

Proper access control mechanisms must not only serve the protection of the information and services they are acting on behalf of but must also ensure that they accommodate the varying capabilities of the clients that they target. Although standards are slow to emerge when it comes to authentication and integrity for RESTful web services and APIs, there are already a number of related patterns emerging.

This presentation illustrates the applicability of API keys, OAuth, SAML, OpenID, and a number of proprietary mechanisms such as HMAC signatures for consuming and exposing Web APIs and RESTful web services.

Gluecon Session Descriptions

Over the next few weeks, I'll be posting (on a near daily basis) session descriptions for Gluecon. You'll also see the next three weeks lead up to a final version of the agenda itself. These two things point to one, unavoidable fact: Gluecon is coming, and you should make sure that you're making plans to be there.

On April 18th, early bird pricing expires, and right now, airlines all over the country are offering cheap flights into Denver. As a bonus, Southwest is even offering flights with both wi-fi AND sunroofs on the planes. ;-)

As a beginning, I'll turn to James Urquhart's session, "Cloud and the Future of Networked Systems":

Today's public and private cloud environments are changing the way software developers and IT administrators create, deploy and manage distributed applications. As the sophistication of software systems inevitably increases, the network will play an increasing role in how we architect and operate those systems. Find out how the future of dynamic and intelligent network infrastructure will impact the security, performance, reliability and flexibility of cloud computing environments, and support a range of network payloads from simple data access to interactive video, the “Internet of Things”, and computing as a utility.

Core concepts covered in this session include:

  • Cloud as an operations model
  • Cloud and networking today
  • Use cases for dynamic, intelligent networks
  • Network automation and the network container
  • Dynamic provisioning of network capabilities and services
  • Standards and Open Source driving the new cloud network

Join us!

Metaphors Matter

Metaphors matter. The fact that someone somewhere choose to model our ubiquitous electronic messaging system after "mail" (i.e., "e-mail") matters. If they had chosen to model it after a group therapy session (e-therapy?), we'd be living in a much different world. The metaphor of "mailing a letter" makes email easy to understand (for everyone), and it also sets some early, unwritten limitations.

You can also see that metaphors matter in the early history of Twitter. Twitter went outside of a known communications metaphor - and they've suffered for it (in terms of people not easily grasping it - "what's a tweet?"). At the same time, it might also be the most important choice they ever made (in that it doesn't set early, unwritten limitations on Twitter).

Bottom-line: Metaphors matter.

Here's the rub: you don't always *know* that you're choosing a metaphor to base something on.

Take conferences. In a "conference," the metaphor is a classroom. We're supposed to sit passively in our seats, take notes, absorb knowledge and walk out "educated." Some conferences even give educational credits toward industry certifications. Is the classroom bad? Of course not. Is it a bad metaphor to base a conference on? No, but it does have its limitations. And you can hear that all of the time when you hear folks complain about "format," or session length, or even speakers. Often what they're really feeling is that they're bumping up against the metaphorical limitations of the classroom -- and wishing their experience more matched a *different* metaphor.

The next time you walk into a conference setting, you'll see it. People milling around being nice to each other ("nice" as in "we're expected to have a certain amount of decorum; this is an educational setting"). Music playing very quietly (if at all), and always the kind of music that people are expected to not like or dislike - just don't be offended. There are even conferences that *purposefully* limit wifi in the conference sessions because they "want people to pay attention."

I don't choose education as a metaphor. I think of conferences as experiential vehicles. I know that the sessions, while important, are really about fostering an experience -- one that happens in between sessions, or in the hallway as often as not. I want people to feel energized, upset, disturbed, physically exhausted, motivated, ready to go *do* something when they leave our conferences.

So what's my metaphor? A rock concert. I want loud music, people interacting with the stage, lighting and production, some level of *theatricality* to the whole event.

At this point, you're thinking: "Eric, I've been to other conferences that have music leading up to a rock star presenter, with lots of stage lighting." Yep, I know you have. But it's not the big things that make it work -- it's the original *choice* (or non-choice). Did the organizer choose a rock concert metaphor? Or were they told, "hey make sure the stage is really cool" - and still (often subconsciously) choose the classroom metaphor.

I think you see my point. Metaphors matter. And they matter in the details (not just the lighting).

In the meantime, check out the agenda (which we're updating weekly), and come join us at Gluecon.

It's All About the Developers

I had a company yesterday tell me that they weren't going to exhibit at Gluecon because Gluecon is "developer-focused," and they want to talk to the C-level decision maker types. Now, it doesn't really bother me if someone doesn't want to exhibit at Gluecon (hell, I've *advised* several companies not to), but, for some reason, their statement made me pause.

Specifically, it made me question a choice I made. From the moment the very first Gluecon ended, I knew it would be a developer show. To be clear, we had "C-level" types at the first Glue. We also had developers. One thing was clear: the developers were driving EVERYTHING (including the decision making process) in the cloud.

It's standard enterprise software lore: the CIO makes the decision on some "enterprise-wide" initiative and the big contract is yours. One problem: it's not happening (nor is it going to happen) that way in the Cloud. Reason: APIs and developers.

As we've been saying for several years now, the movement to the cloud is a two-step: 1) turn infrastructure into a "utility," so that the enterprise can 2) easily expose that infrastructure for things like app development, mobile, big data analytics, etc. To be sure, there's money to be made in both 1 and 2 -- but the BIG move (on a time-scale) isn't the move to utility infrastructure. That's inevitable (that's why we position Gluecon as "post-cloud" -- we assume #1). The big move is to expose things to the developers in such a way that improves their efficiency (in development, deployment and maintenance) across several platforms. And one of the huge chunks of that is the API.

That thought process led me to the choice. Focusing on the C-level is to focus on the wrong target. It's the stable target, the "easy" target -- hell, it's the target that your board wants you to focus on. It's also the wrong target. If you want to "win" the cloud, you win the developer (unless you're purely infrastructure -- and even then, you win the admin, not the c-level).

Bottom-line: it is ALL about the developer.

So, when Alcatel-Lucent came to me and said, "hey, we think the cloud is all about APIs and developer. And we wanna help you support them." Well, you can imagine the smile that came across my face. ;-)

If you're a developer, I hope you'll join us. If you're not a developer (and you're a c-level type), you should send your developers (we're the place that's going to provide the most value). See you at Gluecon!

Pressing Your Bets

Contrast these two points of view:

"Dude, as soon as I get up a little, I take my profits and walk away."

versus

"Roulette is a game for greedy people. I'm either tripling my money or going home with zero."

I heard both statements while I was in Vegas over the past few days. The first one was two college kids on spring break that were trying to preserve capital (or in their parlance, "have enough money to get hammered tonight"). The second was made during a marathon five hour roulette session by an indonesian entrepreneur who was regularly raking in 10-15k per win, and walked away from the table up $30,000 bucks *after* paying off his 10,000 dollar casino marker.

And that got me thinking about entrepreneurship, investing, risk -- and specifically "pressing your bets."

Anyone can go to Vegas on a budget, set your capital constraints for each day (i.e. how much money you're going to lose daily), and have a grand ole time just grinding it out at the craps tables. But not just anyone can be grinding it out at a table game (be it craps, roulette, black jack or even poker), and know *when* and *how* to press your bets. In fact, good VCs, entrepreneurs and startup guys and gals of all stripes spend a lifetime figuring out the when and how of pressing your bets. Because here's the thing: if you don't press it at some point, then you're the college kids managing your capital for drinking money, and not the guy walking away from the roulette table up 40k in 5 hours.

(side note: If you're not familiar with the term "press your bets" - it refers to when you win a bet and instead of collecting your winnings, you tell the dealer to "press" it -- i.e. to put your winnings back on the table in some fashion. If you never press your bets and place bigger bets, than the casino's house advantage will *always* win over time.)

The art of it, then, is A) *when* to press your bets and B) how to press your bets.

In the startup game, I'm still learning this. And I think any VC or entrepreneur that's being honest will tell you that learning when to press and how (whether that's a product risk, capital risk, human resources risk, etc) to press are life-long learning processes. With that in mind, a few simple rules for pressing your bets:

1. You need a win to be able to press: You can't just get into a game and press your bets. By definition you have to have won *something* (no matter how small). Similarly, you don't enter the startup game and bet the company on the first roll of the dice. You've got to get some win -- release the product, land a first customer, something.

2. You press when you get "on a roll": Statisticians will tell you that there's really no mathematical basis for thinking you ever get "on a roll" at a table (excepting blackjack). Gamblers will tell you otherwise. And when a roll hits, you'll know it. Suddenly, it feels like the wind is at your back, and you can do no wrong. The hard part about rolls is recognizing that they've started before they're over, while not mistaking a non-roll for being a roll too early. How do you do that? Practice. And when you're on a roll, press. Press hard.

3. When you do press, press without fear: You've got a win under your belt, it looks like you're on a roll, and you've decided to press it. Fine - do so without even the smallest bit of fear. Like a guard dog, the gods of risk management can smell it on you when you're scared. Be the guy at the roulette table -- when you press, you decide that you're going home up big, or with zero.

4. If the "roll" isn't coming, don't get anxious; walk away: Sometimes, the roll never comes. Sometimes, you pick up your chips, down a little bit, and you walk away. Failure's okay. You paid to learn. And that's worth something.

5. Lastly, if you do get on a roll, and you're pressing and winning - tip your dealer: This holds true in startups and Vegas. You didn't get here without help. Be kind to those that gave you a hand when you were just buying into the game.

At the end of the day, all gamblers rely on pressing their bets -- and learning that skill is really what defines someone who knows what they're doing versus someone who doesn't. That's the nature of the game. The only way to change that is to be the house. ;-)