Micro-Services – Fad, FUD, Fo, Fum

The Triumph of Death, Pieter Bruegel, 1562
The Triumph of Death, Pieter Bruegel, 1562

But band leader Johnny Rotten didn’t sell out in the way that you’re thinking. He didn’t start as a rebellious kid and tone it down so he could cash in. No, Rotten did the exact opposite — his punk rebelliousness was selling out.

[…] And he definitely wasn’t interested in defining an entire movement.

From 5 artistic geniuses who only became great after selling out

We all intrinsically know that internet cycle is shortening, but what is happening these days with micro-services is bordering on ridiculous. But let’s start from another cycle that is now circling the mortal coil on an ever shorter leash – the Agile movement. Let’s hear it from @pragdave (one of the founding fathers) himself:

Ignoring the typo in the tweet (Dave Thomas obviously meant ‘word’, not ‘work’), this is a familiar story that starts with enthusiasm and fervor of a few ‘founding fathers’ (you can see them artistically blurred in comfortable pants). But before you know it (and in this case ‘before you know it’ takes a span of 13 years), the idea is distorted, commercialized, turned into professional certifications, turned into a rigid religion, and essentially morphed into an abomination barely recognizable to the said founding fathers. The Agile Manifesto defined good practices ‘in the left column’ to combat bad practices ‘in the right column’, yet Dave founds the reality steadily creating ‘agile’ practices that are hard to distinguish from the very things the original movement was raising against.

He who is bitten by a snake fears a lizard.

East African proverb

If you read so far, you are still waiting to see the connection to micro-services. There seems to be a micro-service bubble in formation, inflated by a steady stream of articles in the last couple of months. I have written recently about it, but it bears repeating.

The term itself entered my consciousness during the NodeDay 2014, thanks to great presentations of Ian Livingstone and Richard Roger (both the slides and videos are now available). It followed by an epic 7-episode miniseries by Martin Fowler, only to be challenged to a post-off with an alternative article).

Not to be outdone, Adrian Rossouw published the first article in a series (what is it with micro-services that makes people think they write copy for HBO?), and he brought the parabola of monkeys into the mix. He also expressed concerns that micro-services may not be the best solution in some contexts (client side – duh, I don’t even know how to make browsers run multiple processes even if I wanted to; but also REST APIs, which I completely disagree – in fact, they map perfectly into a system API, where each micro-service can handle a group of API endpoints, nicely routed to by a proxy such as NGINX).

Finally, Russ Miles collapsed 13 years of Agile journey into a Janus-like post that declares a tongue-in-cheek Micro-Services Manifesto. In addition to the real-fake manifesto with signatures (something Nicholas Cage could search for in his next movie), he proposed an official mascot for the movement – Chlamidia bacteria (not a virus, Russ, and you don’t want to contract it):

Chlamidia bacteria
Chlamidia bacteria – a microbial mascot for micro-services

The moral of this timeline? It definitely took us way less than 13 years to get from excited to jaded – about three months, I think. We should all back off a bit and see why the micro-services came to being before declaring another ‘Triumph of Death’.

On Premise Systems – Driver Analogy

Before the cloud, most of the enterprise software was meant to be installed on premise i.e. on customers’ computers, managed by their own administrators. A good analogy here is creating a car for consumers. While a modern car has hundreds of systems and moving parts, this complexity needs to be abstracted out for the average driver. Drivers just want to enter the car, turn on the key and drive away (North American drivers don’t even want to be bothered to shift gears, to the horror and loathing of their European brethren).

By this analogy, monolithic on premise software is good – it is easy to install, start and stop (I said ‘easy’, not ‘fast’). When a new version arrives, it is stopped, updated and started again in a previously announced ‘maintenance window’. The car analogy holds – nobody replaces catalytic converter while hurling down the highway at 120km/h (this is Canada, eh – we hurl down the highway in the metric system). This operation requires service ‘downtime’.

Cloud Systems – Passenger Analogy

With cloud systems, complexity is not a problem because somebody else is driving. Therefore, it does not matter if you cannot do it as long as your driver knows how to operate the velocitator and deceleratrix. What you do expect is that the driver is always available – you expect no downtime, even for service and repairs. That means that the driver needs to plan for maintenance while you are in a meeting or sleeping or otherwise not needing the car. He may need to involve his twin brother to drive you in an identical car while the other one is in service. You don’t care – as far as you are concerned, the system is ‘always on’.

What does this means for our cloud system? It means that monolithic application is actually hurting our ‘always on’ goal. It is a bear to cluster, scale, and keep on all the time because it take so long to build, deploy, start and stop. In addition, you need to stop everything to tweak a single word in a single page.

Enter micro-services, or whatever practitioners called them before we gave them that name. Cutting the monolith into smaller chunks is just good common sense. It adds complexity and more moving parts, but with redundant systems and controlled network latency, the overhead is worth it. Moreover, in a passenger analogy the added complexity is ‘invisible’ because it is the driver’s problem, not yours. It remains the implementation detail of a hosted system.

With micro-services, we can surgically update a feature without affecting the rest of the system. We can beef up (cluster) a feature because it is popular without the need to needlessly cluster all other features that do not receive as much traffic. We can rewrite a service without committing to rewrite the entire monolith (which rarely happens). And thanks to DevOps and all the automation, we can deploy hundred times a day, and then monitor all the services in real time, through various monitoring and analytics software.

Before we called it ‘micro-services’, Amazon called it services built by two pizza teams. We also had SOA, although they were more about reusable services put into catalogs then breaking down a hosted the system into manageable chunks without grand aspirations of reusability.

The thing is – I don’t care how we call it. I don’t even care if we come up with a set of rules to live by (in fact, some may hurt – what if I cannot fit a micro-service into 100 lines of code; did I fail, will I be kicked out of the fraternity). There is a need for decomposing a large hosted system into smaller bits that are easier to manage, cluster and independently evolve. We probably should not call it after a nasty STD or monkeys as suggested, but in the end, the need will survive the movement and the inevitable corruption and sell out.

If you are writing a cloud-based app these days, and through trial and error discovered that you are better off breaking it down into several independent services with a strong contract, communicating through some kind of a pub/sub messaging system, you just backed into micro-services without even knowing.

In the end, while ‘Agile’ was declared dead by a founding father, ‘Agility’ lives on and is as needed as ever. Here is hoping that if we manage to kill the the micro-service movement somehow (and in a much shorter time), the need for composable hosted systems where parts independently evolve will live on.

That’s the kind of afterlife I can believe in. That and the one by Arcade Fire.

 © Dejan Glozic, 2014

Node.js and Enterprise – Why Not?

nodejs-enterprise

My daughter is 14. Like her father, she loves and plays music. As with all the restless teens, sitting through multiple hours of Grammys 2014 was a non-starter. Therefore, she installed me as her push notification service. My role was to sit on the sofa (iPad in hand – I am not crazy to just watch TV for hours either), and alert her when the acts she was interested in arrived. Her alerts: Lorde, Lindsey Buckingham, Trent Reznor.

In her room she created a ‘shrine’ on the drawer chest, consisting of the CD jewel cases of Mellon Collie and the Infinite Sadness by Smashing Pumpkins, The Greatest Hits by Fleetwood Mac, all Vampire Weekend CDs, Pure Heroine by Lorde and The Bell Jar by Sylvia Plath (the book, not the CD). Couple of years ago she exited the Beatles phase, where nothing mattered if it was not about John and Paul.

Meanwhile, my 17 year old son likes to play multiplayer shooters while listening to Mozart’s Requiem. On other days he makes methodical passes through the entire Depeche Mode back catalog. Besides Game Of Thrones, his bedtime reading consists of chronicles of some of the most obscure periods in Persian, Egyptian and Chinese history few have heard of.

Time means nothing to my kids, only quality does. For my children, Mozart, Stevie Nicks, David Gahan, Ezra Koenig and Lorde all exist simultaneously in a vast random-access buffet.

Which brings me to the topic of the blog post. A young colleague from the vicinity of my old country commented about my blog thusly:

Are there multiple ways of looking at Node.js? Is there a ‘startup-y’ way of looking at it, and an ‘enterprise-y’ way? Is the former more cool, is the latter the more boring, adult, ‘taking all the fun out of it’ way? More importantly, should enterprises only use older, proven technology, while startups and individuals play with the new and shiny?

It is no secret that I work for IBM, the biggest and oldest of all the IT enterprises out there (it is 103 years old!). Should I even be allowed to write about, play with, and (God forbid) push for Node.js in IBM, let alone make it the center piece of the new micro-service architecture for JazzHub?

Let’s see how my kids would approach it: because they are young and unaware of stereotypes, they would totally use Node.js for the front end, because they have little patience for tedium and Node.js would allow them to iterate through the interface ideas much faster. If they had some high performance/CPU task to accomplish, they would not hesitate to write it in Java, or even  better, C or C++. Or maybe they would look at Go. They would add i18n support so that they can show what they built to their relatives in the old country that are not very good in English. They would add security because some bored hackers would pounce on their site as soon as it became live (my daughter’s Club Penguin account was repeatedly hacked when she was 9). They would do all these things because they are common sense, they are important, they matter and you cannot be ‘done’ until you have them.

The moment you have customers and feel responsibility for them, you are doing ‘enterprise-y’ stuff. NPM just became a company (they raised 2.6m in seed funding less then two months ago), and you know what one of the first orders of business were? Ordering external security audit. That sounds very ‘enterprise’ to me. Uber business model may sound weird to you* but they are a serious business (serious enough to create a pushback from lobbyists in each new market they expand to), and they were running Node.js in their dispatching system since 2011. The same for AirBNB, although they jumped into Node in 2013.

I am using these two companies as an example because they are relatively new and don’t fit the stereotype of a classic ‘enterprise’. And yet, look at their web sites carefully – both sport a dropdown to choose the language. I can paraphrase a classic joke ‘you know you are a redneck…’ as ‘you know you write enterprise-class software when you need to deal with i18n’. Of course, If you are an enterprise that wants to sell to the US government, it’s not a stretch goal – you must meet regulation 508 to even be in the running. There is an equivalent set of requirements for the European Commission. But you don’t have to be beaten with a government stick to add i18n and accessibility to your business’ web application – it just makes sense because you can reach more people that way. And it is not limited to Node.js – go through the examples of the wildly popular Bootstrap toolkit and search for the word ‘aria’ – you will see 43 hits because all the components have wai-aria accessibility support.

Uber (left) and Airbnb (right) language picker.
Uber (left) and Airbnb (right) language picker.

We are now entering the most exciting phase of Node.js’ young life – Node.js in the enterprise. The signs are everywhere, from testimonials of companies reinventing their systems using Node.js during Node Summit 2013 and NodeDay 2014, to the surge in articles and discussion on enterprise micro-service architecture (Martin Fowler creating a Downton Abbey event by releasing the article on micro-services in mini-episodes, only to be challenged to a post-off with an alternative article – man, this is going to be fun!).

I have seen a marked change in tone in the recent weeks around Node.js and enterprise. In the past, the discussions were heated as if there was a smidgen of insecurity in the pro Node.js camp, so the general discourse was ‘is Node.js ready for the enterprise?’ with a verdict left hanging in the balance. The tone has shifted now, coming from rapid maturation of the Node.js community bolstered by some significant success stories. The discussion is not any more if Node.js is ready for the enterprise – it IS in the enterprise, and that segment provides the most significant growth now. In a sense, the discourse now is ‘why are we even having this discussion?’ coming from mild annoyance of raising a topic that has been settled in many minds already, and with a resounding ‘Yes’. People are now busy having fun with Node.js at scale, for example:

Sometimes, a historic perspective helps, so here is one. In 1995, Sun made Java and JVM public as an alternative to C++ for desktop applications. It was interpreted, it was slow, it was buggy but it was new, exciting, promised ‘write once, run anywhere’ without recompilation, and the community was growing rapidly. In 1996, I was asked to try to write a prototype of a framework that would allow an IBM middleware development tool with a significant GUI to run on AIX, OS/2 and Windows NT without maintaining three separate code bases. I wrote it in Java and called it JFace. This framework eventually ended up in a much larger body of code (albeit totally rewritten) in what was later known as the Eclipse Platform.

A three-pane window showing three alternative representations of the same model circa 1998.
A three-pane JFace window showing three alternative representations of the same model, circa 1998.

The point of this story is that I was asked to solve a problem using Java when Java was only 2 years old, and the huge Eclipse platform effort was based on Java when it was 4 years old. At that time, Java was buggier and slower than Node.js is today (performance inflation-adjusted). In fact, Java was consistently slower than the incumbents, whereas Node.js shows performance improvements when used as designed (for systems with a significant I/O activity). I am sure people had their doubts about Java in its time, but that didn’t stop them from forging ahead and fixing whatever had to be fixed to dispel those doubts.

In a sense, some people in the enterprise sound like parents who had a wild youth, then forgot all about it and turned into old fuddy-duddies. As you see from my example above, we were fearless before, we can be fearless again. In five years, something new will come along, and we will have this discussion again.

So to wrap up, it is very unlikely that any Node.js discussion today will not be ‘enterprise-y’ – we have great HWPS (Hello World Per Second) numbers and now need to solve real problems that involve i18n, security, scale, independent evolution of micro-services by large teams, inter-service messaging, clustering, continuous integration and deployment with zero downtime etc. Let’s approach it the way my kids approach music – open minded, without prejudice, without preconceived notions, on merits only.

Node.js is but a tool in the tool box, use it as intended and it will repay handsomely. Feeling reinvigorated, loving your job again, being excited to get your hands dirty and code is tossed into the package for free as a reword for your open mind.

*Correction – the original article had an erroneous claim that Uber cars have silly pink moustaches on their grills. In fact, they belong to their competition Lyft. Thanks to @bdickason for spotting the error.

© Dejan Glozic, 2014

Sitting on the Node.js Fence

Sat_on_the_Fence_-_JM_Staniforth

I am a long standing fan of Garrison Keillor and his Prairie Home Companion. I fondly remember a Saturday in which he delivered his widely popular News From Lake Wobegon, and that contained the following conundrum: “Is ambivalence a bad thing? Well, yes and no”. It also accurately explains my feeling towards Node.js and the exploding Node community.

As I am writing this, I can hear the great late Joe Strummer singing Should I Stay or Should I Go in my head (“If I stay it will be trouble, if I go it will be double”). It is really hard to ignore the passion that Node.js has garnered from its enthusiastic supporters, and if the list of people you are following on Twitter is full of JavaScript lovers, Node.js becomes Kim Kardashian of your Twitter feed (as in, every third tweet is about it).

In case you were somehow preoccupied by, say, living life to the fullest to notice or care about Node.js, it is a server-side framework written in JavaScript sitting on a bedrock of C++, compiled and executed by Google’s Chrome V8 engine. A huge cottage industry sprung around it, and whatever you may need for your Web development, chances are there is a module that does it somewhere on GitHub. Two years ago, in a widely re-tweeted event, Node.js overtook Ruby on Rails as the most watched GitHub repository.

Recently, in a marked trend of maturation from exploration and small side projects, some serious companies started deploying Node into production. I heard everything about how this US Thanksgiving most traffic to Walmart.com was from mobile devices, handled by Node.js servers.

Then I heard from Nick Hart how PayPal switched from JEE to Node.js. A few months ago I stumbled upon an article about Node.js taking over the enterprise (like it or not, to quote the author). I am sure there are more heartwarming stories traded at a recent #NodeSummit. Still, not to be carried away, apart from mobile traffic, Node.js only serves a tiny panel for the Walmart.com web site, so more of a ‘foot in the door’ than a total rewrite for the desktop. Even earlier, LinkedIn engineering team blogged about their use of Node.js for LinkedIn Mobile.

It is very hard to cut through the noise and get to the core of this surge in popularity. When you dig deeper, you find multiple reasons, not all of them technical. That’s why discussions about Node.js sometimes sound to me like the Abott and Costello’s ‘Who’s on First’ routine. You may be discussing technology while other participants may be discussing hiring perks, or skill profile of their employees, or context switching. So lets count the ways why Node.js is popular and note how only one of them is actually technical:

  1. Node.js is written from the ground up to be asynchronous. It is optimized to handle problems where there is a lot of waiting for I/O. Processing tasks not waiting for I/O while others are queued up can increase throughput without adding processing and memory overhead of the traditional ‘one blocking thread per request’ model (or even worse, ‘one process per request’). The sweet spot is when all you need to do is lightly process the result of I/O and pass it along. If you need to spend more time to do some procedural number-crunching, you need to spawn a ‘worker’ child process, at which point you are re-implementing threading.
  2. Node.js is using JavaScript, allowing front-end developers already familiar with it to extend their reach into the server. Most new companies (i.e. not the Enterprise) have a skill pool skewed towards JavaScript developers (compared to the Enterprise world where Java, C/C++, C# etc. and similar are in the majority).
  3. New developers love Node.js and JavaScript and are drawn to it like moths to a candelabra, so having Node.js projects is a significant attraction when competing for resources in a developer-starved new IT economy.

Notice how only the first point is actually engineering-related. This is so prevalent that it can fit into a tweet, like so:

Then there is the issue of storage. There have been many libraries made available for Node.js to connect to SQL databases, but that would be like showing up at an Arcade Fire concert in a suit. Oh, wait, that actually happened:

Never mind then. Back to Node.js: why not going all the way and use something like MongoDB, storing JSON documents and using JavaScript for DB queries? So now not only do front end developers not need to chase down server-side Java guys to change the served HTML or JSON output, they don’t have to chase DBAs to change the DB models. My point is that once you add Node.js, it is highly likely you will revamp your entire stack and architecture, and that is a huge undertaking even without deadlines to spice up your life with a wallop of stress (making you park in a wrong parking spot in your building’s garage, as I did recently).

Now let’s try to apply all this to a talented team in a big corporation:

  1. The team is well versed in both Java (on the server) and JavaScript (on the client), and have no need to chase down Java developers to ‘add a link between pages’ as in the PayPal’s case. The team also knows how to write decent SQL queries and handle the model side of things.
  2. The team uses IDEs chock-full of useful tools, debuggers, incremental builders and other tooling that make for a great workflow, particularly when the going gets tough.
  3. The team needs to deliver something new on a tight schedule and is concerned about adding to the uncertainty of ‘what to build’ by also figuring out ‘how to build it’.
  4. There is a fear that things that the team has grown to expect as gravity (debugging, logging etc.) is still missing or immature.
  5. While there is a big deal made about ‘context switching’, the team does it naturally – they go from Java to JavaScript without missing a beat.
  6. There is a whole slew of complicated licensing reasons why some Open Source libraries cannot be used (a problem startups rarely face).

Mind you, this is a team of very bright developers that eat JavaScript for breakfast and feel very comfortable around jQuery, Require.js, Bootstrap etc. When we overlay the reasons to use Node.js now, the only one that still remains is handling huge number of requests without paying the RAM/CPU tax of blocking I/O, one thread per request.

As if things were not murky enough, Servlets 3.1 spec supported by JEE 7.0 now comes with asynchronous processing of requests (using NIO) and also protocol upgrade (from HTTP/S to WebSockets). These two things together mean that the team above has the option of using non-blocking I/O from the comfort of their Java environment. They also mean that they can write non-blocking I/O code that pushes data to the client using WebSockets. Both things are currently the key technical reasons to jump ship from Java to Node. I am sure Oracle added both things feeling the heat from the Node.js, but now that they are here, they may be just enough reason to not make the transition yet, considering the cost and overhead.

Update: after posting the article, I remembered that Twitter has used Netty for a while now to get the benefit of asynchronous I/O coupled by performance of JVM. Nevertheless, the preceding paragraph is for JEE developers who can now easily start playing with async I/O without changing stacks. Move along, nothing to see here.

Then there is also the ‘Facebook effect’. Social scientists have noticed the emergence of a new kind of depression caused by feeling bad about your life compared to carefully curated projections of other people’s lives on Facebook. I am yet to see a posting like “my life sucks and I did nothing interesting today” or “I think my life is passing me by” (I subsequently learned that Sam Roberts did say that in Brother Down, but he is just pretending to be depressed, so he does not count). Is it possible that I am only hearing about Node.js success stories, while failed Node.js projects are quietly shelved never to be spoken of again?

Well, not everybody is suffering in silence. We all heard about the famous Walmart memory leak that is now thankfully plugged. Or, since I already mentioned MongoDB, how about going knee-deep into BSON to recover your data after your MongoDB had a hardware failure. Or a brouhaha about the MongoDB 100GB scalability warning? Or a sane article by Felix Geisendörfer on when to use, and more importantly, when NOT to use Node.js (as Node.js core alumnus, he should know better than many). These are all stories of the front wave of adopters and the inevitable rough edges that will be filed down over time. The question is simply – should we be the one to do that or somebody can do the filing for us?

In case I sound like I am justifying reasons why we are not using Node.js yet, the situation is quite the opposite. I completely love the all-JavaScript stack and play with it constantly in my pet projects. In a hilarious twist, I am acting like a teenage Justin Bieber fan and the (younger) team lead of the aforementioned team needs to bring me down with a cold dose of reality. I don’t blame him – I like the Node.js-based stack in principle, while he would have to burn the midnight oil making it work at the enterprise scale, and debugging hard problems that are inevitable with anything non-trivial. Leaving aside my bad case of FOMO (Fear Of Missing Out), he will only be persuaded with a problem where Node.js is clearly superior, not just another way of doing the same thing.

Ultimately, it boils down to whether you are trying to solve a unique problem or just play with a new and shiny technology. There is a class of problems that Node.js is perfectly suitable for. Then there are problems where it is not a good match. Leaving your HR and skills reasons aside, the proof is in the pudding (or as a colleague of mine would say, ‘the devil is in the pudding’). There has to be a unique problem where the existing stack is struggling, and where Node.js is clearly superior, to tip the scales.

While I personally think that Node.js is a big part of an exciting future, I have no choice but to agree with Zef Hemel that it is wise to pick your battles. I have to agree with Zef that if we were to rebuild something for the third time and know exactly what we are building, Node.js would be a great way to make that project fun. However, since we are in the ‘white space’ territory, choosing tried and true (albeit somewhat boring) building blocks and focusing the uncertainty on what we want to build is a good tradeoff.

And that’s where we are now – with me sitting on the proverbial fence, on a constant lookout for that special and unique problem that will finally open the Node.js floodgates for us. When that happens, you will be the first to know.

© Dejan Glozic, 2013