With React, I Don’t Need to Be a Ninja Rock Star Unicorn

San Diego Comic-Con 2011 - Lego Ninja, The Conmunity - Pop Culture Geek from Los Angeles, CA, USA

Followers of my blog may remember my microservice period. There was a time I could not shut up about them. Now, several blogs and not a peep. Am I over microservices? Not by a long stretch.

For us, microservices are gravity now. I remember an interview with Billy Corgan of The Smashing Pumpkins where, when pressed about his choice of guitar strings, he answered: “I use them”. That’s how I feel about microservices – now that we live and breathe them every day, they are not exciting, they are air. The only people who get exited about air are SCUBA divers, I suppose, particularly if they are running low.

ReactJS, on the other hand, is interesting to us because we are still figuring it out. For years we were trying to have our cake and eat it too – merge the benefits of server and client side rendering. I guess my answer to ‘vanilla or chocolate ice cream’ is ‘yes please’, and with React, I can have my chocolate sundae for breakfast, lunch and dinner.

The problem with ninja rock star unicorns

The magical creature from the title is of course the sought after 10x developer. He/she knows all the modern frameworks, sometimes reads about the not so modern ones just for laughs, and thrives where others are banging their heads against their desks repeatedly.

Rock star developers not only do not shy away from frameworks with high barrier of entry such as Angular, they often write there own, even more sophisticated and intricate. Nothing wrong with that, except that you cannot hire a full team of them, and even if you could, I doubt team dynamics would be particularly great. The reality of today’s developer job market is that you will likely staff a team with great, competent and potentially passionate developers. I say potentially because in many cases their passion will depend on you as a leader and your ability to instill it.

The React connection

This is where React comes into play. Careful readers of this blog may remember my aversion to JavaScript frameworks in general. For modestly interactive sites, you can go a long way with just Node.js, Express, a templating library such as Dust.js and a sprinkle of jQuery for a good measure. However, a highly dynamic app driven by REST APIs is too much of a challenge for jQuery or vanilla JS alone. I am not saying it cannot be done, but by the same token, while you can cut your grass with box cutters, it is massively less efficient than a lawn mower. At the end of the day, you need the right tools for the right job, and that means some kind of a JavaScript library or a framework.

What kept me away from Angular for the longest time was the opinionated nature of it, and the extent to which it seeks to define your entire world. Angular is a cult – you cannot be in it part time.

“Angular is a cult – you cannot be only a part time member.”

Not an Angular cult member

I have already written about why I got attracted to React from a technical point of view. There are great things you can do with isomorphic apps when you combine great React libraries. But these are all technical reasons. The main reason I am attracted to React is its philosophy.

We are all idiots at times

Angular used to pride itself as a ‘super-heroic JavaScript framework’. Last time I checked, they removed it from the home page (although it still appears in Google searches – ironic, I know). I presume they meant that the framework itself gives you super-hero powers, not that you need to be a super-hero developer in order to use it, but sometimes I felt that way.

I am singling out Angular somewhat unfairly – most MVC JavaScript framework approach the problem by giving you tools to carefully wire up elements on the page with events, react to watched variables, surgically change styles, properties, collections and so on. Sounds great in the beginning, until you scale to a real-world application, and things become really complex.

This complexity may not be a big deal while you are in the thick of it, coding like a beast. You may be a great developer. The problem is that the moment you turn your head away from that code, you start the ‘idiot’ clock – until that time when you no longer remember how everything fits together.

Now, if you are looking at your own code and cannot figure out how it works, what are the chances another team member will? I long ago proclaimed that dumb code is good and smart code is bad. Not bad code, just straightforward, easy to understand, ‘no software patent here’ code. Your future self will be grateful, future maintainers doubly so.

React allows us to write boring code

Let me summarize the key React philosophy in one sentence:

“Something changed in my application’s state. Better re-render it.”

React in a nutshell

I cannot emphasize enough the importance of this approach. It does not say “watch 50 variables and do surgically change DOM elements and properties when something happens in one component, then cascade those surgical changes to other components also watching those components”. Behind this, of course, is React’s ingenious approach of using a virtual DOM and only updating the real DOM with the actual changes between the two. You can read about it on React’s web page.

After many years of ‘surgical’ JavaScript DOM manipulations, there is something completely counter-intuitive about ‘just re-render’ approach. It feels like it should not work. It feels wasteful to keep creating all those JavaScript objects, until you realize that they are really cheap, and that the true cost are actual DOM manipulations.

In fact, you can use this approach with any JavaScript rendering engine – Mustache, Handlebars, Dust. The only problem is – if you try the ‘something changed, re-render the component’ approach there, templates will re-render into inner HTML, and that is wasteful. It is also potentially disruptive if users are interacting with form elements you just recycled under their feet. React, on the other hand, will not do it – it will carefully update the DOM elements and properties around the form controls.

Increase velocity without increasing bug rate

The key design goal of React was to help real world projects running code in production. Developers of modern cloud applications are under constant pressure from product management to increase velocity. The same product management of course expects you to maintain quality of your apps, which is very hard. It is not hard to imagine that shortening the cycles will increase the bug rate, unless the code we write is simplified. Writing ‘surgical’, intricate code in less time is asking for trouble, but React is easy to understand. There is uniformity in its approach, a repeatability that is reassuring and easy for people who didn’t write the code originally to understand when they pick it up.

Developers take great pride in their work, and sometimes they get carried away by thinking that code is their deliverable. They are wrong. What you are delivering are user experiences, and code is just means to an end. In the future, we will just explain what we want to some more powerful Siri or Cortana and our app will come to existence. Until then, we should use whatever allows us to deliver it with high velocity but without bugs that would normally come with it.

For my team, React is just the ticket. As is often in life, YMMV.

© Dejan Glozic, 2015

The Art of Who Does What

Jacob Duck, Dividing the Spoils, 1635, Wikimedia Commons
Jacob Duck, Dividing the Spoils, 1635, Wikimedia Commons

Job posting: If you like my blog and would like to work on the stuff I write about, come and join my Toronto team.

Novelist Erich Maria Remarque claimed in one of his novels that civilization is a thin veneer, covering the primal urges of savages ready to grab each others’ throats at a moment’s notice. You can attest to that at times of temporary breakdowns such as power outages, elevator malfunctions, or heated sports events. In the relatively rational and orderly corridors of corporate life, nothing brings the primitive reptilian brain to the forefront like the activity of divvying up the work.

There are perfectly rational explanations for why this happens. Work is a big part of our identity. It is now spilling out into our personal brand as well – your LinkedIn and Twitter profiles say what you do for living. You will go great lengths and exert a lot of effort in order to move that needle from ‘Something’ to ‘Architect Something’ to ‘Senior Architect Something’. You want these changes to reflect on your LinkedIn profile as an upward progression, a well managed and deliberate career narrative.

Titles aside, most people want to do meaningful work, and want to grow their career by kicking ass, not by marking the time. A precondition for this is to be assigned a great and meaningful task that you can crush, being amazing as you are.

Divvy up

In corporations large and small, there comes a time where in one part of the room, you have a few nervous people, and in another, a pile of stuff to be done. Call it a work pie – it has to be cut and divided among them. Now remember the ‘civilization as a thin veneer’ and you can imagine the emotional undercurrents of such a situation.

Divvying up the work is tightly connected to hiring, and those two activities may act like the chicken and the egg in many situations. The amount of work is also very important. If this is the only pie to divide, tensions will be much higher than if the pies keep coming – people who didn’t get their piece will be much more relaxed if a new one will arrive in 5 minutes.

In my professional life, I have observed several situations I will try to enumerate here.

Grow with work

What is more fitting to start with than, well, a startup. When you have two starry-eyed founders and a lofty vision (according to HBO’s Silicon Valley, which must include a desire to ‘make the world a better place’), there is this infinite pie that never gets smaller no matter how much you cut it. Founders work day and night and ‘who does what’ discussion is very short and efficient. Nothing will matter if work is not done before the VC money runs out, so getting it done is primary consideration.

According to the guys of 37signals, most startups are careful with hiring and really only hire when they reach practical limits.

The right time to hire is when there’s more work than you can handle for a sustained period of time.

Jason Fried & David Heinemeier Hansson, ‘Rework’

In this mode, dividing the work is a low ceremony affair – everybody wears many hats, and there is a sense of ‘we are all in this together’. This is a good phase.

Lions eat first

When companies are growing quickly and they are having a lot of impact, careers take care of themselves. And when companies aren’t growing quickly or their missions don’t matter as much, that’s when stagnation and politics come in.

Google’s Erich Schmidt to Sheryl Sandberg

When Facebook’s Sheryl Sandberg got this advice from Google CEO Erich Schmidt, it highlighted the moment when the pendulum swings and there is more people than work. In most real world organizations, the amount of things to do grows and shrinks faster than the teams do. After all, you cannot be hiring and firing people all the time – it is expensive and bad for morale.

In those situations, politics goes into full swing, and managers closer to the executives in control of the pie get the choicest pieces, leaving the scraps for the less connected and less savvy. This was and still is a reality in many big corporations to one degree or another, but things are changing there as well. New organizational trends already brought us flatter structures. Matrixed organizations with feature teams are more often the norm, with models like the one used by Spotify being all the rage recently.

There are varying reasons why certain teams tend to run away with key pieces of the mission. They can have a track record of delivery, which is fair. They can also have a critical mass required to take on an important mission. They can also be tapped to own the technical area (say, compilers) and have the expertise. But sometimes there is the inertia that crosses over into politics. A team that traditionally owned an area may be a bad choice to take that technology to the cloud because of the skills mismatch. In many of these discussions, the results will not seem fair to the outside observer not in on the subtle political undercurrents of the situation.

Second wind

A comical side-effect of the ‘lions eat first’ model is that eventually lions get stuffed silly and cannot take another bite. In my time, I was often far from the main power centres, so I developed the art of the second wind to perfection. Here how it is plaid:

  1. The first pie arrives to the table
  2. Lions eat first, stuff themselves until they cannot breathe
  3. After a while, an unexpected pie arrives. Lions watch it with sad eyes, unable to do anything.
  4. You jump in and run away with the whole new pie.

As I said before, this all depends on the availability of the new pie. But even in the olden days it was possible. The first division of ‘who does what’ is normally based on the very imprecise ideas of what the new project is all about. After a while, reality sets in, holes are identified, new requirements emerge, and this is where you can jump in and get that work.

Or you can invent a whole new pie. You can actively look for gaps in the vision, notice the opportunity, prototype something and demo it to the executives. When there is not enough pie on the table, create more by innovating.

Note that this model is becoming more of a norm lately. Everything is speeding up, cycles are getting shorter, feature teams (or should I say ‘squads’) are formed and dissolved at a faster rate. This is good news, because there is nothing like office politics to sap enthusiasm and energy from bright and starry-eyed new hires. I am happy we are slowly moving away from politics-ledden job partition, if only out of necessity brought on by the tectonic shifts in the industry.

Getting ahead of the HR curve

Alas, where there are people, there will always be some amount of politics. The corporation does not even have to be that big to get into the bizarre game of req tickets:

Reqs vanish randomly, often without notice, without reason, and at the least convenient time.

Rands in Repose

First of all, if you have hiring tickets, congratulations – it means you are on a project that is growing (assuming these are not backfills). You may even be in the coveted ‘startup in a large organization’ situation, where you are trying to grow a 1.0 project and are staffing like crazy.

This is an often comical situation because you are trying to be two things at the same time. You are trying to move fast, build a team and be nimble, while at the same time dealing with a corporate machine that is not designed for that. You are growing against a fluid plans and visions that change daily (or should I say ‘pivot’). And you never know when the executives championing the new startup culture will succumb to bean counters’ nagging and rein in the mad hiring sprout.

You could say that true startups grow with concrete work, and that this is not a very startup-like behaviour, and you would be right. However, there is logic to it:

  1. You are growing a team with a general skill set, kind of like a local competency centre, or to use the Spotify parlour, a ‘chapter’. You can form guilds as needed, but your chapter will be more stable and build an enviable track record that will attract new work in the future.
  2. You are building a centre of gravity that will assist you in the upcoming ‘who does what’ discussions. You want to be the path of least resistance for tasks that look related and up your team’s skill alley.
  3. And of course, a req ticket unused is a req ticket lost.

Be the baker

Based on everything I said so far, it appears that in order to change the conversation, it is better to ensure that pies are coming than to entangle in the ugly politics of wrestling over a scarce resource. Build a team of great skilled developers, preferably able to do full-stack development and do many things with aplomb, and then unleash the innovation that creates new pies out of thin air. It is better to be the one creating the new work than fighting over it.

Now if you excuse me, all this talk about pie made me hungry. Mmmm, pie.

© Dejan Glozic, 2015

Oy With the Gamification Already!

Lady Katrana Prestor ~ Human Onyxia, World of Warcraft, 2014, Stephan Shubert via Wikimedia Commons
Lady Katrana Prestor ~ Human Onyxia, World of Warcraft, 2014, Stephan Shubert via Wikimedia Commons

“Hi, everybody. My name is Dejan and, … well…, I don’t play games (gasp). There, I’ve said it. This feels so liberating, I am a bit lightheaded. I think I’m going to sit down now.”

I cheated a bit in my pretend-address to the local Non-Gamers Anonymous chapter. I did play Microsoft Flight Simulator obsessively for years, but that is more of a gateway drug to real flight lessons than a multi-person shooter. Most people who tried it lost interest when they realized they cannot fire at other planes, promptly crashed their Boeing 737 and moved on to fight trolls and solders in a futuristic dystopia.

All these gaming-intolerant impulses kicked into high gear when I read the Spotify engineering model white paper. In case you missed it, Spotify is creating a stir with their new way of work organization. In a nutshell, they organize people into co-located feature teams called squads that have all they need to deliver a feature relatively independently. Several squads are organized into tribes that tend to be limited to about 100 people to prevent social connections breakdown.

Since squads are self-reliant, it is easy to envision a situation where the same problem is solved multiple times by squads that don’t communicate. To avoid this massive waste, like-minded squad members organize into chapters that share the same general knowledge (Web UI, iOS/Android, Design, Test) and a line manager. This provides organizational glue and prevents duplication. Finally, chapters are connected into guilds in a looser way, ensuring sharing of ideas and best practices.

The gamers are coming!

One of the first concerns that people have voiced was ‘how is this different from matrixed organizations’. I find guilty pleasure in observing these kinds of questions because they remind me of another debate closer to home, this one on how micro-services are nothing more than SOA.

But listen – oy with the gamification already! I explained the basic premise to my 18 year old son (an avid gamer) and even he was rolling his eyes (calling the lingo ‘juvenile’). The World of Nerddom is spilling into the rest of the reality with a vengeance that sometimes verges on bullying (yes, I get the irony). Case in point: a presenter at a recent NodeSummit suffered ironic remarks by the MC for daring to bring a Windows laptop to the stage, and not the all-beloved Mac (and I am typing this on a sweet new MacBook Pro; I just don’t like bullies, male or female). And now there is a growing chance another outgrowth of that world will become your everyday working reality.

Spotify is a young, rapidly growing company, and the main source of music for my teenage daughter. I am sure that game-playing millenials that I can see in the company photos feel very comfortable with guilds, tribes and squads. Their model is irresistible in that it addresses so many paint points that feed Dilbert cartoons. Their two-part video is smart, wonderfully animated and easy to follow, and many of the messages will ring true and soothe your pain if you spent any amount of time in an old enterprise work process.

What I find problematic is when those same enterprises latch on it and try to apply it in their own (very different) context. One of the reasons they would do it is the assumption that a successful implementation in a fast moving company gives it a seal of approval. Some of it is sheer survival instinct – everybody needs to move fast these days, and if your traditional org chart is slowing you down, you need to change if you want to be around in five years. Finally, and to be fair to large enterprises, it is really hard to find a true command-and-control organization these days – some variation of Scrum or Kanban is a norm virtually everywhere. Spotify provides a simplifying refinement that attempts to address the observed shortcomings.

It is not a religion

I see two problems with adopting Spotify model as-is:

  • It is a moving target. White paper authors themselves pointed out that it is entirely possible that by the time you implemented the squad/tribe/chapter/guild model, Spotify will have moved on to the next refinement of it. A kitschy version: you can’t capture the wind or the waterfall – you end up with dead air and stale water, respectively (rim shot).
  • It uses gamer-friendly terms. It assumes that everybody in the industry is a gamer and is instantly familiar and reacts positively to the images these names evoke. I cannot help but giggle imagining a bank IT shop where executives arrive and declare: “all right people, all of you on this floor are now the Stonehoof tribe. Stay tuned for the org chart to find out which squad and chapter you belong to. Guild masters are currently working on their corresponding chapter lists”. It is not even a generational thing – believe it or not, there are young people who have better things to do than kill hours working on their WoW reputation (and virtual gold). And yes, there are middle-aged clan leaders. Sadly.

Test out carefully

There are many worthy ideas in the Spotify engineering model. Some of them are a refinement of the matrixed models from the past. Most can be used without all the gaming jargon that goes with them. Discussions I had so far point at exactly that – savvy organizations will filter out the startup exuberance and latch on the more lasting nuggets. All of them should be treated as an experiment in the event they end up working only for Spotify (or in the event Spotify has already outgrown them).

And finally, the goal is to enable teams (squads?) to be agile and deliver results with the speed of the cloud. If that does not pan out, you just spent a lot of money re-arranging chairs on the Titanic. And called yourselves silly names that should be left behind once you reached your twenties.

Pardon the grumpiness. Hey, I may end up liking it after I live it for a while. Now if you excuse me, I have to go work on my LARP uniform. War is in the air.

© Dejan Glozic, 2015

For Once, Being Reactive is Good

5 Gum - React
5 Gum – React

Apple said Monday that it sold more than 300,000 iPads on the first day of its launch, ushering a new era of people buying things in order to find out what they are.


SNL Weekend Update, season 35, episode 18

All my life, I thought ‘reaction’ was a bad word. Ever since the French Revolution, being ‘reactionary’ could get you into a lot of trouble. More recently (and less detrimental to your health and limb count), being in ‘reactionary’ mode is considered merely an anti-pattern. We were all in situations in life where we felt like we were merely reacting to changes foisted upon us, like tall grass helplessly flailing on a windy day. We all want to be the wind, not the grass.

As you could read only everywhere, including my own blog post, Agile movement has been declared dead (although ‘agility’ is still fine and dandy, thank you). Being communal people and in need of an idea to gather around, and not liking the traditional organized religions’ early hours, we looked for a more suitable replacement.

Not that others were not trying, and even before Agile’s passing. For example, Adam Wiggins of Heroku extraction has channeled his inner L. Ron Hubbard by establishing his Church of 12 Factors (kudos for pulling it off without one reference to space ships). It it is chock-full of Cloud-y goodness and is actually quote good and useful. I think Adam is now beating himself up for not waiting a bit and slapping ‘micro-services’ all over the manifest, because that is totally what ’12 factors’ are about.

According to Adam, 12-factor apps:

  • Use declarative formats for setup automation, to minimize time and cost for new developers joining the project;
  • Have a clean contract with the underlying operating system, offering maximum portability between execution environments;
  • Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration;
  • Minimize divergence between development and production, enabling continuous deployment for maximum agility;
  • And can scale up without significant changes to tooling, architecture, or development practices.

So what went wrong? It is still a worthwhile document, and I keep revisiting it often, but it lacks the galvanizing force that true movements have. Maybe there are just too many factors (even actual religions knew to stop at 10), or maybe because it sounds too much like inspirational lifestyle articles such as 12 Lifestyle Factors That Make You Feel Depressed.

Then the Agile thing happened, and it was time to get cracking. It was not a long wait – behold The Reactive Manifesto.

Now, I make it sound like it all happened in a neat chronological order (something my buddy Adrian Rossouw would organize in a Wayfinder timeline), but it did not. The first version of the manifesto was published by Jonas Boner and friends and described on the Typesafe blog in July 2013. It was uploaded to GitHub and the community was invited to help tweak the document. The current version (1.1) dates September 2013 and is signed by thousands of believers (I meant ‘supporters’). In Jonas’ own words, the motivation for putting the manifesto forward was:

The primary motivation for this manifesto is to come up with a name for these new type of applications (similar to NOSQL, Big Data, SOA and REST) and to define a common vocabulary for describing them — both in terms of business values and technical concepts. Names matter and hopefully this will help bring the communities together and make it easier for users and vendors to talk about things and understand each other.


Up to now the usual way to describe this type of application has been to use a mix of technical and business buzzwords; asynchronous, non-blocking, real-time, highly-available, loosely coupled, scalable, fault-tolerant, concurrent, reactive, event-driven, push instead of pull, distributed, low latency, high throughput, etc. This does not help communication, quite the contrary, it greatly hinders it.

The four traits

In its core, The Reactive Manifesto puts forward four reactive traits a modern distributed system should possess (notice the small number of key tenets – that’s how it’s done). Let’s see how these qualities intersect with the modern micro-service based systems I was writing about in the last few months:

  1. Reactive to events – a modern micro-service based distributed system is asynchronous by nature, with each service sitting dormant until an event wakes it up. Lest it turns out we are talking REST only, a loosely coupled system using some kind of message broker is a better fit because it offers further decoupling. Publishing into a pub/sub topic does not require any knowledge of the possible consumers of the message in a way that A->B REST calls do. And of course, while the authors of the manifest seem to be coming from the Scala background (with Play framework also playing a part), it is easy to notice that Node.js is an even better fit. Its asynchronous nature ‘all the way down’ ensures non-blocking way of reacting to events.
  2. Reactive to load – a corollary of the micro-service based system is the freedom to scale out each service independently of the rest of the system. The ability to instrument the nodes and cluster hot spots while living the less popular services as-is is of great help in the cloud environments. Cloud resources are finite and cost money. Knowing which nodes to cluster (and more importantly, where that would be overkill) is essential to arriving at a system that is reactive to load while still keeping the monthly bill reasonable.
  3. Reactive to failure – when there are many moving parts, failure is inevitable. Successful ‘born on the net’ companies with complex distributed systems not only guard against failure, they openly embrace it (who hasn’t heard about the Netflix’s Chaos Monkey).
  4. Reactive to users – this part is a bit confusing. You would think that the four reactive traits are like ‘four pillars of heaven’ or ‘the four elements’ (minus Mila Jovovic). As it turns out, the previous three reactive properties are preconditions to the system being reactive to users – by providing real time, engaging, performant user experiences. Being reactive to events, load and failure will simply increase your chances to be reactive to users in a way that will keep them from leaving in frustration.

Reactive reactions

When you research a topic, and the second Google search hit after the actual topic is “Reactive Manifesto bulls**t”, you cannot resist clicking on the link. In it, Paul Chiusano argues that Reactive Manifest is not only not right, it’s not even wrong. It looks like the ultimate insult is being banished into the binary system limbo, where you are neither right nor wrong, you are, well, nothing (it’s like Louis CK joke that because he owes $50, he needs to raise $50 just to be broke).

Of course, there are positive reactions and people who don’t really care – the usual spectrum.

Here is what I think: I am actually positive about the intent of Reactive Manifesto. First off, it redefines ‘reactive’ as something positive. Of course it didn’t invent anything new, but that is not the first time in history somebody came and put a name on something we were already doing but didn’t know it. Remember JJG and Ajax? He didn’t invent it – he just put a name on a technique that is the bedrock of any modern client side application. How about ‘micro-services’? Many people fail to see how they are different from SOA or just plain ‘services’ or ‘distributed systems’ – a lot of haters in that camp too.

But here is what my first reaction was: coming from a former communist country, my first association was with a guy whose beard is every hipster’s dream – Karl Marx. When he and his buddy Engels came forward with the Communist Manifesto, they didn’t invent alienation, oppression and capitalism’s seedy underbelly. They just articulated them succinctly and gave something to millions of disgruntled workers around the world to rally around. It didn’t turn out all that well in hindsight, but notice what I am getting at here – manifestos don’t invent new things, they put a names on concepts, helping the adherents galvanize around them and form movements.

So to those who say ‘The Reactive Manifesto’ didn’t invent anything new, you are right: that was not the intention. Go read your history or  Google ‘manifesto’.

The ‘What, Why, How’ trifecta

I would like to circle back to ’12 factors’ and ‘micro-services’ and claim that we now have a fairly complete set of answers to big questions we may ask while we build modern distributed systems:

  1. What are we building? A micro-service based distributed system.
  2. Why are we building it? Because we want it to be reactive to events, load, failure and users.
  3. How are we building it? Using the techniques and recommendations outlined in the 12-factors.

There you go – no need to choose one over the other – a simple ‘1 + 4 + 12’ formula that will bring you happiness and make you rich.

As for me, I am taking a leaf from the SNL book – I am going to the first Toronto Reactive Meetup. In fact, I am raising SNL by not only participating but actually speaking at it – a new era of people presenting on topics to find out what they are.

If you are in Toronto on June 24, join us – in addition to reading my musings, you can see me deliver them in full HD.

© Dejan Glozic, 2014

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

Lean Startup Inc.

Y2K was a banner year for behavioral scientists. In the years leading up to the Internet bubble bust, most investors reported on their profiles that their risk tolerance was ‘high’. At that time, they assumed that the risk meant that they can get an even higher return on their speculative investments than they have hoped for in their greedy minds. Then came Y2K and the realization that ‘risk’ is a double-edged sword, and both sides are very, very sharp. Many investors got so burnt that for more than a decade they reacted to the stock market the way Bela Lugosi reacted to garlic (now Bauhaus told me in my youth that Bela Lugosi’s dead, but there will never be another Dracula for me but Bela).

The Lean Startup movement I already mentioned in one of my previous posts is meant first and foremost for actual startups. It applies perfectly to a couple of founders, a few first employees rapidly burning through Angel Investors’ money, walking around with starry eyes, dreams of becoming ‘the next Facebook’ and drawing a short list of islands they will buy once that happens. It is a mad race for getting to the business end of the ‘hockey stick’ chart – the part where revenue takes off to actually finance the business (or, in the case of Snapchat, becomes greater than zero). The challenge is to reach this point before venture capital runs out and the repo men cometh.

An expansive aspect of the methodology is that it can be applied to any new effort amid extreme uncertainty, even in huge multinationals or governments. Any corporate team attempting to start a version 1.0 of a product or a service is effectively a startup. Instead of VCs, there are executive sponsors, and instead of actual money, there is headcount – number of people working on the project until business declares that time’s up.

I am a big fan of Michael Lopp and his alter ego Rands. I followed his blog for years, an even bought his book Being Geek. In the chapter called ‘A Deliberate Career’, he cited a ‘third option’, apart from a startup and an established company:

There’s a constant threat in a start-up, and that’s the threat of failure. You can ignore it when you’re busily working three weekends straight, but it’s always there: “We could fail.” The larger company’s success has hidden this threat under a guise of predictability, domesticity, and sheer momentum.
Still, you can find the same [start-up] attributes in a large company in a specific group that has been tasked with the new and sexy.

It appears that working on an exciting new project in an established company is a win-win situation – all the fun of a startup but no risk. But there is a bug here. Fear is a powerful motivator. Remove it, and everything slows down, because if the cheque clears like clockwork, what’s the hurry?

In my recent post on client side frameworks, I kept mentioning Angular.js. On the surface, it seems to fit the description of the ‘best of both worlds’ project – Open Source exposure backed by security of Google. Then you have to remember that Google uses spaghetti approach to their services – throw a plateful towards the wall, and see which one will stick. So Angular.js is great, unless your team works on Closure or GWT or Dart, and you know that at any point in time the axe can fall and people will be leaving flowers for it in the graveyard of Google Services. That’s enough fear for me, thank you.

A friend from my youth went to spend some time in Greece. He didn’t have a lot of money and the beautiful island of Santorini was not exactly cheap, so he had to do all kinds of jobs to support himself. He told me and my wife something that stuck:

Not knowing where your next meal will come from does wonders to focus your mind.

Since lack of fear means lack of alertness, sense of urgency and get-go, teams working on new projects in large companies often lose sight of the possibility that the project may not result in an actual product. Your mind is playing tricks with you, similar to the DotCom investors who had ‘high risk tolerance’. Large companies don’t fail, you say. And you are right – not in the way startups do. With no buffer and no sheer mass to amortize the blow, any kind of snag can knock you down if you are a startup. Still, in a big company you can fail to see your vision through to completion, and see the joy of customers actually finding your product useful. You may still have your job, but unless you are in it just for the paycheque and your true passion lies elsewhere, that’s got to hurt a bit. And if your heart is not in it, what exactly are you doing all day? Checking Facebook? Laughing at Doge pictures?

A much healthier approach for you if you want to continue to be on the bleeding edge is to accept that all startups can fail, even those in big companies (in their own soft way). The fact that in the latter case the salary keeps landing in your bank account already puts you at an advantage over most of Silicon Valley. Accept both sides of risk, not just the good one, accept that ‘extreme uncertainty’ is a serious business (unlike extreme ironing), and act accordingly.

Oh, and read The Lean Startup book carefully. You will find plenty of examples of tactical failures along the way – failures to accurately predict customer base, feature set, the essence of the product value add, customer interest. While pivots are a normal part of the startup experience, they can be truly unsettling to a corporate developer used to stability and predictability.

Even in a big corporation, you cannot have it both ways. Either be truly lean, agile and ready for all kinds of curve balls, ready to turn on a dime, or move to a more established project already shipping products or services, where incremental innovation is more important than starting from scratch for the third time. In both real and corporate startups, if you are not afraid, it’s not a real startup.

© Dejan Glozic, 2013

The 12 Amp Limit


Sometimes movies I watch leave a lasting impression for completely unexpected reasons. Case in point – 1995 hit “Apollo 13”. The movie offered plenty of fodder for people who like to play Six Degrees of Kevin Bacon, and offered Tom Hanks in a clean 1970 NASA style haircut. A lot easier to take than the abomination on top of Robert Langdon’s head. Of course, the movie is packed with nail-biting scenes, if you bite your nails even if you know perfectly well that they are going to make it in the end. But that is not why I remember the movie.

Somewhere in the second half, the crew on the ground is trying to devise a plan of onboard system startup that is not going to suck all the juice from the remaining batteries. The battered ship’s power supply can only take up to 12 amps of current before it cries Uncle, and they have a nice analogue instrument with a needle to watch it creep up. Gary Sinise starts clean, carefully adds one by one module and before you know it, 12 amp limit is hit and the metaphorical crew is dead. Ultimately, the solution was found not in the proper startup sequence but in adding another partially shot battery useless on its own, but giving just the needed push when hooked up into the circuit as a booster.

I keep thinking of this scene looking back at software development projects I was on. It all starts new and shiny – real and metaphorical junk cleaned up, new ground broken, everything seems possible, we make crazy progress unencumbered by restrictions and customers. But soon enough, code piles up, requirements keep coming, constraints set in and before you know it, you hit the limit. It could be too many features, too much code, pages taking too long to load, UI too complex, too much customization needed – anything that marks the transition away from innocence into maturity. The problems you need to handle now are not cool, they are adult stuff.

When this limit is hit, different people react differently. Some people are forever chasing the new project high. As soon as it is gone, they start looking for another ‘new’ project in order to recreate the wonderful sense of freedom and freshness, the ‘new project smell’. Others accept the maturity process and ride it all the way. Then there is a group that actually thrives in a mature project environment – they like the structure and the boundaries it provides, engaging in a series of incremental improvements within the constraints of a mature project.

The point I am trying to argue here is that for all the allure of the early days of a project, it is the period after the metaphorical 12 amp limit that separates boys from men. The early days value your ability to dream, to conjure up new, exciting and innovative concepts, new ways of doing things, and things never done before. The next phase is all about execution, about turning that vision into reality, into something that actually delivers on the early promise. Many a startup crashed and burned on the ability to deliver, to scale when faced with the real world problems and customers. The bridge from an early prototype to a real product is the hardest one to cross. All the shortcuts and omissions you made in the rush to the prototype will come to a head and bury you if you are not careful.

For all the head swooning allure of the early days, it is the maturation of a new product that is the most exciting to me, and if you bail as soon as things become too complicated, too hard, not fun any more, you are missing out on the best part. Don Draper from Mad Men was described by a bitter girlfriend as one that ‘only likes the beginnings of things‘. Don’t be the Don Draper of software projects – see the project to the successful maturation and you will be rewarded with a payoff of a job completed, not merely started.

© Dejan Glozic, 2013