Ride with an Elephant

Meet our character PP, initials of Poor Programmer. Following is one of his many stories. Some are quite adventurous, while some are very dull. You like it or not, he remains a poor programmer.

Interlude

Overwhelmed, PP is hitting his keyboard very hard for last couple of minutes. He has been instinctively trying to make things work without a single breakthrough for an hour or two. He is so much frustrated now.

"Heck?"

"This is getting trickier like hell." - he mumbled with the burning eyes.

Intro

It was an usual dull Sunday noon like as always. PP just came home from the market. He opened his laptop and saw an interesting article becoming viral on web.

"Microservices. Umm…"

"Wow, that sounds terribly great!"

He was very happy when he read that and other few articles regarding microservices. It was a fancy, and trendy term those days.

But why was he so happy about it?

Prelude

In his past, as a web programmer, PP worked on tens of small-sized to giant web applications, and delivered most with less hassle. But he better knew pain of working on 'em.

In his early days, he never got a chance to start with a greenfield project. All those he worked on were quite old, aging from a few months to years or two. Mentors and seniors were so much in love with Rails. Convention over configuration was a quite preferred paradigm among 'em. With a few lines of code and a few toggles in the configuration, so many things happen magically. Well, that was great, and he loved it so much. Those were his happy days.

As time passed, he realized on his own, as well as heard complaints from managers and clients. Slow page load time, huge downtime during deployments, overhead and less flexibility while adding new features in conjunction with existing codebase, etc. Everything sound absurd. His monolithic elephant-looking apps were now becoming slow in every aspect. He tried to address and fix some of these issues by distributing load with a few obvious solutions viz. using messaging queues, hosting database on different servers with master-slave replication strategy, load-balancing requests, etc.

PP wasn't remain a programmer. One day, he became conscious of the fact that he was just doing configurations and wiring stuff by day, i.e. doing just ops work. He experienced an unemotional feeling when this thought occurred to him. He started looking for a more scalable, flexible, and community-driven solution to his problems.

Postlude

PP now have a microservice-based architecture in place. Everything works like a charm. Major learning during design was figuring out type of requests, viz. those which needs response right away, and those which need not. He has written a number of distributed micro-services (in Ruby, Node, Go, Clojure, Shell, etc.) which can be awakened to process simple HTTP requests, while some to do background (batch/bulk/intensive) processing. JSON, Protocol Bufferes are the coolest ways he has found to transmit information to-and-fro between microservices. Some microservices simply proxies the request to others intelligently. Microservices which do background processing are mostly relied on messaging queues and distributed stream processors, while some just work using UNIX pipes with nohup, either redirecting output to a black hole or persisting state into an in-memory data store. He has wired all of these microservices with a single or two entry points for public APIs (which are consumed by proprietary or authorized clients). Just to make a note of web frontend side architecture - it is powered by Webpack with a real power as discussed somewhere.

Everything looks good so far.

But wait…

Did I say that this whole architecture is designed for a greenfield project?

Umm…

PP read an article one day -- Microservice Trade-Offs.

"This is new and early stage project, man! Totally…"

"Lots of modifications in code by minute, somebody help me!"

With day to day iterations in business flow of a completely new product, things are becoming more worse while making a simple change. No part of this new architecture design stays stable by the end of the day. His microservice-based architecture is not helping him as well as his team, to iterate quickly with a simple functionality or throw-away feature in such an early stage of product.

PP thinks that his choice to choose microservice-based architecture for a project starting from scratch is quite wrong. Monolith (until it becomes an elephant) could have been more helpful in such a situation.

He's now thinking to throw away all his micro-services and just start with a simple monolithic app for now.

He has learned something, but he cannot be sure about it.

Time is passing.