The brave new world of plentiful tooling, and especially open source tooling, has driven home the realization that developers are the new decision-makers, not the man in the high castle that just dictates the technology and stack. A minute before I was about to publish this piece, John Vrionis of Lightspeed Ventures wrote a piece, It’s actually open source software that’s eating the world, that perfectly segues into this one, you should read it if you haven’t yet.
I wrote about similar concepts, in my recent post the Disruption Cycle where I note the trend that by the time the latest and greatest tooling has started to get a foothold in the market, another newer and hotter technology lands. These days, the differences in tooling are becoming mostly minor and superficial, and largely a matter of personal preference, and the focus is no longer on the core functionality and the deeply intelligent backend, but more on the first impression and experience the developer encounters. And as a result, the way developers adopt tooling isn’t that different from the way any new trendy gizmo or fashion is adopted. And today’s companies need to learn a thing or two from none other than the fashion or consumer industry.
Image credit: Venturebeat, It’s actually open source software that’s eating the world
While many companies believe they know how to target developers, and what developers want, the execution and ultimately the numbers in adoption will often times speak to the contrary.
The language we’ve been speaking to developers to date of features and functionality is becoming passe - as it doesn’t speak to the way they actually adopt tooling - it speaks to the way we THINK they adopt tooling. The mobile app adoption rate speaks to the same issue.
An excellent testament to this is in the early days of NoSQL databases where MongoDB and Cassandra were the leading players - both on paper excellent databases, where in terms of features and functionality the scales should have actually been tipped in Cassandra’s favor with better scaling and clustering capabilities...but Mongo took the lead, and has dominated since. Cassandra never really managed to catch up in numbers. If we examine how that happened it was a result of the really simple API Mongo provided to enable developers to just roll up their sleeves and get to work. The Cassandra interface and API was a lot more clunky and complex...despite the more robust feature set.
And it’s almost a snowball effect, because once the buzz and the hype begins to build around a new tool or technology, everyone wants to play with the new and awesome toy. So many times, the way a tool reaches the developer is based on its popularity, trendiness, word of mouth and a developer’s personal preference, not necessarily based on what’s under the hood.
Give Me Liberty...Wait, What do I Want?
The funny thing is that I’m not certain that if you asked the average developer they would know how to articulate that a better API is what they want - they likely would say it’s the feature set. This classic Ted Talk from 2004 by Malcolm Gladwell, writer of Blink and The Tipping Point, remains timeless, and still hits home. The most important take away is this:
[Offering diverse choices of spaghetti sauce - ~NS]...fundamentally changed the way the food industry thinks about making you happy. Assumption number one in the food industry used to be that the way to find out what people want to eat, what will make people happy, is to ask them.And for years and years...would have focus groups, and they would say, "What do you want in a spaghetti sauce?” And for all those years -- 20, 30 years -- through all those focus group sessions, no one ever said they wanted extra-chunky. Even though at least a third of them, deep in their hearts, actually did.
When I was a kid I only had Levis or Lee jeans to choose from and pretty much one style. Likewise, when I was a fledgling developer the same held true for my tooling and stack. The Oracles and IBMs were pretty much ubiquitous. Enterprises who built their whole market strategy around lock-in, where they would even provide “shelfware” in their six-figure contracts, that for them even served as their “contingency plan” for when additional tools were needed. There was no choice and diversity - and so there was little need to cater to developer’s needs, as it wasn’t a business factor. But the tables have turned.
While we like to believe that all developers are basically the same and driven by the same motives - just let me code, the truth is, that this means very different things to the different kinds of developers. Depending on the type of development front end, back end, big data and the beloved buzzwords fullstack & DevOps - each has a different framework and stack they like to work with - and many times, these don’t communicate well.
What’s more, developers too are also equally influenced by peers and trendiness, and the sexiness of the user experience and API, and sometimes even the prettiness of the GUI when it comes to adopting the latest tooling (remember a world before Docker?!). However, from a developer’s perspective the API is the key interaction point, and is largely the UI equivalent of an average user for judging the user experience of a new tool. This new world order dictates that if before the focus in product releases has been on core functionality and UIs, at the expense of the API’s usability - a major transgression by many software companies, that today the API is likely the most important element that will be the measure of your product’s adoption.
I Want it Now
So, the new challenge has evolved into how to get as many frameworks and tools to the developers, without a black box experience. In the past the thinking was that a developer wants a hassle-less experience, so this brought about the trend of very limited and opinionated frameworks that the former generation of PaaS suffered from. But this didn’t hold water, since while developers want to be spared the hassle, they need some semblance of control even more, and the option at the very least to tweak the framework when they want, and you can see a huge trend of abandonment of PaaS frameworks for more flexible options - often times leveraging a number of tools for this purpose.
So AWS took the exact opposite approach, continuously rolling out new services as they become popular, and deserve to be looked up to in this respect. They have managed to continually be ahead of the curve, or at least very slightly behind the curve with an unrivaled and rapid time to market to cater to the diverse whims of developers these days.
And the numbers speak for themselves the very far second Microsoft Azure, that took a more holistic and platform-like approach has been lagging behind in adoption, suffering from a slow rollout of new services. So while AWS can be perceived as the “Woolworth’s” of cloud marketplaces cluttered with a disorganized hodgepodge of services for every need, the more organized specialty shop that is Microsoft Azure that took the time to holistically think about how to integrate each service to the platform as a whole, has suffered in adoption as a result.
This clearly indicates that the speed of innovation is directly related to the speed of adoption. The standard has now become how fast can you launch new services into your cloud as they become popular, as the benchmark for what is going to win the developers’ mindshare.
And while the AWS model is impressive and agile and comprehensive...it’s not very future proof nor scalable or sustainable to develop all these services and frameworks in-house.
One Size Fits All
Which means that the approach to making this possible would need to be one that is so generic that it can fit the diversity and variety of frameworks that exist today, enabling you to mix and match and do whatever you want. A one size fits all sort of model.
So the idea would be to make it possible to be able to quickly take the latest fashionable framework - deploy it with a completely agnostic platform that can abstract it entirely and take it to any underlying infrastructure. Without knowing what that platform is or even will be in say August 2037.
And this is where that buzzword orchestration comes in.
It provides exactly that kind of generic automation and management for a large variety of frameworks and applications, which is why it’s not surprising that we’re seeing the rise in orchestration popularity over the past few years.
There are multiple kinds of orchestrations, here’s a partial roundup of the most popular orchestration tools, which are different in their goals and approach. There are those that are infrastructure-centric i.e. automate things on top of their specific infrastructure, to container-centric, or pure-play orchestration frameworks which are more of an integration platform that glue together the the infrastructure of choice with your DevOps toolchain.
Choosing the right tool for the job
Clearly the scope of the problem is fairly large, and there isn’t any one solution that can actually automate the deployment process of all the different kinds of workloads, on every kind of infrastructure. To really achieve this we would need to stack a few orchestration tools together.
So with such complex stacks and the diversity of infrastructure and workloads - that all need to be managed with different tooling....where new and innovative tooling is continually being developed (is your head spinning yet?!)...there has to be a way to unify everything, without even knowing what that everything is.
Choice + Speed + Simplicity = Adoption
So the software industry has quite a bit to learn from the fashion industry or any highly-competitive consumer-based industry that has an abundance of choice where the differences between products and are almost negligible, yet clear patterns of choice are still identifiable. These choices are based less and less upon rationale and more on intuition and even peers’ word of mouth.
In order to stay relevant in this world of diversity of software options, we all need to learn how to play in this new game. It’s no longer about the deep features and functionality it’s about diversity and choice. It’s about how quickly we can introduce these new toys into our window, all while keeping it simple.
This means:
- More tooling and services vs. complex and holistic platforms
- Sexy APIs, even more so than GUIs - as the API has become the “front end” for developers.
Generally speaking catering to the developer’s UX and simplifying how they work with your framework.
Because at the end of the day we all want our companies and teams to be considered technologically fashionable - based on what the moment dictates. Whether it's because we need to be an attractive enough business to appeal to developers looking to integrate our technologies, or even the need to be able to recruit excellent developers...who only really want to work with the latest and greatest tooling.
Of course, this is easier said than done, and in the real world actually takes a lot of experimentation and iterations, because even that is a constantly moving and changing target. So your speed of innovation will ultimately decide what remains a timeless fashion or a passing trend.
About the Author
Nati Shalom, Founder and CTO at GigaSpaces, is a thought leader in Cloud Computing and Big Data Technologies. Shalom was recently recognized as a Top Cloud Computing Blogger for CIOs by The CIO Magazine and his blog is listed as an excellent blog by YCombinator, as well as the HP Helion MVP Award for his contributions to the OpenStack community. Shalom is the founder and also one of leaders of OpenStack Israel group, and is a frequent presenter at industry conferences.