Defining Hadoop with a straight face


Unlike datalake, I don’t think of Hadoop as a buzzword at all. It is a real thing – a real project you can touch and feel. Also, I love elephants (The one in the picture is an eighty year old Guruvayoor Padmanabhan, owned by a famous temple in Kerala)  – which might explain why I have a particular soft spot for Hadoop 🙂 . Hadoop is perhaps not yet ready to be an elephant this size, but it is not such a little baby elephant as shown in the marketing pictures either.

20130727-195627.jpg

By now, it is stable enough even for an obsolete programmer like me to play with it minimum fuss. In my day job, I don’t program any more (sadly – but probably a good thing for my team, and perhaps for the rest of humanity). But there is hardly a week that passes me without a need for explaining hadoop to someone. Even when I was between jobs and enjoying a nice vacation, I was pulled into “help me understand hadoop” discussions.

The primary problem for me personally is that the folks I usually have to explain hadoop to are not always conversant with open source. I get to talk mostly to people who are smart enterprise technologists, but who have very little idea of open source per se. Vast majority of them equate open source to free software. And it is not as if open source is a good all encompassing way to explain hadoop (hello MapR). And if I somehow manage to get these folks to understand open source and a few licensing models, I lose them again on the idea of what a distribution is and what is different between the distros. I think its mostly a mental block that there are commercial vendors who make money of software that is supposedly free – and they all do it in different ways. Can’t blame them – I had those questions too for a long time.

Once you get past open source, then there is a question of what constitutes Hadoop.

No one in my circles apparently cares about Hadoop common , so I no longer utter a word about that. And the few times I have mentioned it, mostly to friends who come from coding backgrounds – I have to deal with “why would anyone use java for building this?” 🙂 . Hence no “common” – nothing but grief from that conversation.

Then I talk about HDFS and MapReduce . Enter more rat holes – why does the world need yet another file system – why not use GPFS? I have heard of Spark – so when do we use MapReduce and why not just use Spark all the time? If I get a breather, I also get to mention YARN and Arun’s explanation of datacentre operating system, and that there is a MapReduce2. People get why YARN is a good idea almost instantaneously. Everyone appreciates the vision of pluggability – but invariably someone will ask about its compatibility with stuff that came before YARN .

This is usually where I start with the idea of different kind of nodes, mechanics of replication, why 3 is a default value, and why the whole thing is built for commodity servers daisy chained together. You would think this is the easy part – but it is not. We are dealing with people who have spent their entire careers working on high end servers that have all kinds of resiliency. It is a really hard thing for them to visualize the world hadoop is built for. Usual starting questions include “if I just repurpose all my high end servers, can I just avoid replicating thrice?” or “I already have tooling that takes care of HA and DR in all my data centers. Surely there are APIs that I can use to connect my existing tools to this hadoop thing ?”. This is a game of how many times you get to say “it depends” in any one conversation without taking a breath.

Just when I am ready to wind down the conversation – impatient listener will ask “can you fill me in on hive, HBase etc”. Sure why not – so I explain how there are a bunch of other projects that play alongside hadoop. “Are they all java?” – well, they are not ALL java, but ideally you should not have to worry given they all have interfaces you can use relatively easy. I can see relief !

HBase seems to be a trigger for starting on the NoSQL part of this Odyssey. This is particularly so because my friends know I spent some time working at MongoDB. Sadly – as in REALLY sadly – 90% of my conversations include a part of convincing people that MongoDB is not hadoop. And at a minimum at that point I have to touch on Cassandra to explain there are more NoSQL options out there. Invariably this opens up the question of “does MongoDB work with Hadoop” – thankfully it does and I explain the connector. It also usually leads to my friends from ops background sigh aloud “can’t we just use a general purpose database that does all these things” ? . I no longer fight them on this topic – mostly for lack of energy.

“So you have explained how data sits in hadoop, but you have not explained how I can put it in there or how I get these awesome insights from that data”. Ah I forgot all about that. So I go on to explain even more projects ( at some point it is overwhelming to remember all the names and the right spellings ) – and also manage to get in a plug that a lot of closed source tools can access hadoop. This is usually the point at which my ops friends give up on me and say “good Lord,  it is complicated to manage all this” and my dev friends get all excited that there are so many cool new toys to play with.

Usually the final question is on security. On the bright side, Ranger and Sentry are both easy names to remember. On the not too bright side – I don’t want ( or even know fully well enough) to explain why two major distros have two different approaches. And this usually leads to other examples like impala to show that not all distros share the same implementation philosophy. I should use something other than impala in future as my example – since that goes into “how many possible ways can you do SQL on hadoop?”. My usual temptation is to say “more ways than enough for you to get a costco size jar of aspirin” 🙂

I have not counted, but there are certainly more than 30 projects that can somehow be called a part of hadoop. I have personally played with less than half of them. And every day more projects are starting and it is getting hard to keep up. No wonder why my friends/customers/random people all get stressed out trying to understand hadoop and how to make use of it. And yet – everyone is excited about their hadoop journey, despite all its twists and turns. Marketers like my friend Ingrid who recently joined HortonWorks as CMO should have a fun time articulating a message that makes it much simpler to understand.

Alright, so who wants to ask me about Hadoop next ?

Before you take a dip in a data lake


We all love our jargon and buzzwords, don’t we ? Off late, I get pulled into a lot of discussions on “data lakes”. People are either huge fans of the the data lake approach, or they are super negative. And that is what makes these discussions a lot of fun.

I did a google search on what exactly is a data lake and got this as the number one hit. A data lake is a storage repository that holds a vast amount of raw data in its native format until it is needed. If we stick to this definition (which I like), it also makes it easy to understand the tradeoffs of this approach.

The major benefit of this approach is that you reduce upfront costs associated transformation. Instead of ETL (extract-transform-load), we just extract and load, and leave transform for some other time. On the bright side with a data lake we can cross our hearts and honestly say “no more silos of data” and “one repository to rule them all” . This has its advantages – better deals on HW and SW costs and potential some breathing space to stagger analytics projects to make use of this data.

The whole reason for dumping all data into data lake is to analyze it at some point. For analysis, we need to know the meaning of the data that we are trying to crunch. When we try to do analysis at some point in time – we in all probability cannot make sense of what the data is anymore. Even in the tightly controlled world of datawarehouses, we spend a lot of time in rework when a new data source is introduced . We run to the people who manage the source systems and try to establish rules and governance and so on so that there is less error in steady state and data can be meaningfully combined.

So while data lakes are definitely serving a good purpose – there is an aspect of dealing with the “kicking the can down the road” that often comes with it. A data lake that is meant to prevent data silos, could just end up enabling silos at scale when there is no governance around it. This is the part of the message that marketing peeps usually don’t say out loud. Perhaps the reason they don’t say it is because once governance is established, data lakes might look very similar to the now uncool data warehouses – maybe not physically, but certainly logically.

Data lakes are quite useful as long as the expectations are correctly set. I would not shy away from it. Just keep the expectations real on the trade offs. I was joking with someone that all the fans of data lakes should be made to work in a data curation project for some time on a mandatory basis. That will give them a much more balanced perspective !

This is my second attempt at writing this blog. My (much longer) last trial yesterday night had to be deleted 🙂

Customer references and strategic relationships 


I had an interesting discussion with two friends on Twitter yesterday – Frank Scavo who is a well respected analyst and has advised a lot of customers on buying enterprise software and services , and Ben Haines who used to be the CIO of Box and who is now a VP at Yahoo . The topic was about customer references . I thought I will jot down my (strictly personal) views on this matter.

There is nothing more valuable for a vendor than having a customer who is willing to act as a reference to other customers and prospects.  Nothing puts a prospect at ease about a vendor like another customer who can vouch for the vendor. Customer references are also invaluable in securing favorable analyst reports for the vendor. 

References are very important for the customer too. Vendors will typically paint as bright and rosy a picture as possible to make the customer buy . It is by asking around other customers that a prospect typically gets a full picture . In most cases they just directly ask the vendor for the reference . As a seller and then as a sales leader in my career , I have been asked a zillion times to arrange such reference calls . I am greatly indebted to the customers who have provided such references.

There is a strange irony from this point forward in the story . Many customers who absolutely insist on reference calls are themselves not comfortable to be a reference for the vendors whose products and services they have successfully implemented . The most common excuse I have heard is the generic “it’s against company policy”. These same customers also often lament that their vendors have a very transactional relationship with them and doesn’t take the relationship to strategic levels . 

I am all for hard negotiations upfront . Haggle on price , payment terms , indemnity , dress code or whatever it is that both sides need to agree . But I always request my customers one thing – let’s agree on success criteria and a way to measure it . And let’s put it in the contract that if the success criteria are met – then please be ready to be a reference for a few prospects . As both Frank and Ben correctly pointed out – This is also the first clause in the contract that some CIOs and procurement folks ask me to remove . Their typical response is “we are happy to be a reference , but don’t want it in the contract”. Strangely enough I have not had a single business buyer EVER push back on me on this clause . Not one ! 

I trust my customers . If I don’t trust them , I won’t do business with them . And I earn their trust . So I am almost always sure that a customer who promises to be a reference will typically not decline at the end . But on the other hand I have been in this line of work long enough to know that people change jobs and roles . I also know that if I put it in contract , then any legal issues etc will surface upfront and get resolved one way or other . In many cases the person I am dealing with might not have the right authority to be a reference . In short – it gives me a chance to mitigate “not in policy” risk upfront . It also saves a lot of embarrassment for the customer Employees who find out after the project is over that they can’t keep their word to me . 

What does a strategic relationship mean between vendors and customers ? We both help each other to further our businesses beyond the transaction we have contracted for . As an example , I have many a times helped customers by providing them access to experts in other domains or markets that they need help with . And many customers have helped me win business elsewhere by being a solid references. If all we care about is price and budget and scope – then that is all we will get at the end . That is a fine way of doing business in some cases – but then the expectation should be appropriately set on both sides that there is no strategic nature to this relationship . 

So what is my success rate at getting referrals ? I would say maybe 30 to 40 percent at best . But I am hopeful that I can double the rate at some point . Life in enterprise software is not worth living for transactional relationships – at least for me .