Pattern: Microservice Architecture


  • There is a team of developers working on the application
  • New team members must quickly become productive
  • The application must be easy to understand and modify
  • You want to practice continuous deployment of the application
  • You must run multiple copies of the application on multiple machines in order to satisfy scalability and availability requirements
  • You want to take advantage of emerging technologies (frameworks, programming languages, etc)


Define an architecture that structures the application as a set of loosely coupled, collaborating services. This approach corresponds to the Y-axis of the Scale Cube. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc.

Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP. Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services. Data consistency between services is maintained using an event-driven architecture


Fictitious e-commerce application

Let’s imagine that you are building an e-commerce application that takes orders from customers, verifies inventory and available credit, and ships them. The application consists of several components including the StoreFrontUI, which implements the user interface, along with some backend services for checking credit, maintaining inventory and shipping orders. The application consists of a set of services.




Ultimate Realization of Truth

“One thing: you have to walk, and create the way by your walking; you will not find a ready-made path. It is not so cheap, to reach to the ultimate realization of truth. You will have to create the path by walking yourself; the path is not ready-made, lying there and waiting for you. It is just like the sky: the birds fly, but they don’t leave any footprints. You cannot follow them; there are no footprints left behind.”

Software engineers should also act as Tech Support

Important for the product based organization, Software engineers should also act as Tech Support at least twice a month.

  • Fights “Development in a vacuum” syndrome. It’s valuable to gain exposure to how users use the app. Until I finally saw this as a young developer, I didn’t realize what a crappy UI developer I was. All I cared about was coding and not design, analysis or the user’s perspective.
  • Delivery product to the target audience in a better way. They can simply the UX issues for the customer which cause more customer satisfaction.
  • Software engineers can also realize the pain of Support Staff and simplify his life after delivering a better product.
  • Developers that are not as good as they think they are can be humbled (although there’s no guarantee you’ll get this benefit; some devs are truly oblivious, selfish, and stubborn).
  • Developers will gain domain knowledge. This is critical if your developers are to eventually become better at identifying and filling in the gaps the business analysis phase (assuming there is any) misses.
  • Good support is a marketing point. If you do it well, clients will come to appreciate it. And a well-rounded developer with communication skills and domain knowledge is capable of doing this well. However, I would still prefer that applications be of high enough quality that they don’t need support. Superior quality is its own form of customer support (and also a marketing point).


परख – एक कथा

एक मन्दिर में एक संन्यासी रहा करते थे। मंदिर के ठीक सामने ही एक वैश्या का मकान था। वैश्या के यहाँ रात−दिन लोग आते−जाते रहते थे। यह देखकर संन्यासी मन ही मन कुड़−कुड़ाया करता। उस संन्यासी ने यह हिसाब लगाने के लिए कि उसके यहाँ कितने लोग आते हैं एक−एक पत्थर गिनकर रखने शुरू कर दिये। एक दिन वह अपने को नहीं रोक सका और उस वैश्या को बुला भेजा। उसके आते ही फटकारते हुए कहा— ‟तुझे शर्म नहीं आती पापिन, दिन रात पाप करती रहती है। मरने पर तेरी क्या गति होगी?”

संन्यासी की बात सुनकर वेश्या को बड़ा दुःख हुआ। वह मन ही मन पश्चाताप करती भगवान से प्रार्थना करती अपने पाप कर्मों के लिए क्षमा याचना करती। बेचारी कुछ जानती नहीं थी। बेबस उसे पेट के लिए वेश्यावृत्ति करनी पड़ती किन्तु दिन रात पश्चाताप और ईश्वर से क्षमा याचना करती रहती। हमेशा की तरह, संन्यासी ने, जब कोई आता एक पत्थर उठाकर रख देता। इस प्रकार पत्थरों का बड़ा भारी ढेर लग गया तो संन्यासी ने एक दिन फिर उस वेश्या को बुलाया और कहा

“पापिन? देख तेरे पापों का ढेर? यमराज के यहाँ तेरी क्या गति होगी, अब तो पाप छोड़।”

पत्थरों का ढेर देखकर अब तो वेश्या काँप गई और भगवान से क्षमा माँगते हुए रोने लगी। अपनी मुक्ति के लिए उसने वह पाप कर्म छोड़ दिया। कुछ जानती नहीं थी न किसी तरह से कमा सकती थी। कुछ दिनों में भूखी रहते हुए कष्ट झेलते हुए वह मर गई।

क्या पता था, उस संन्यासी का भी समय आ चुका था, वह भी चल बसा।

सच के दरबार में जब पेशी हुई, तो संन्यासी को सज़ा सुनाने वालों की तरफ़ रखा गया और वेश्या को माफ़ करने वालों की तरफ़ । तब संन्यासी ने बिगड़कर कहा “तुम कैसे भूलते हो। जानते नहीं हो, मैंने कितनी तपस्या की है त्याग किया है”

सत्य बोले “हम सबकी असल जानते है। असल तो यह है वह वेश्या पापिन नहीं है पापी तुम हो। उसने तो अपने पाप का बोध होते ही पश्चाताप करके सच्चे हृदय से भगवान से क्षमा याचना करके अपने पाप धो डाले। अब वह मुक्ति की अधिकारिणी है और तुमने सारा जीवन दूसरे के पापों का हिसाब लगाने की पाप वृत्ति में, पाप भावना में जप तप छोड़ छाड़ दिए और पापों का अर्जन किया।

भगवान के यहाँ मनुष्य की भावना के अनुसार न्याय होता है। बाहरी बाने या दूसरों को उपदेश देने से नहीं। परनिन्दा, छिद्रान्वेषण, दूसरे के पापों को देखना उनका हिसाब करना, दोष दृष्टि रखना अपने मन को मलीन बनाना ही तो है।

संतों ने कहा है –

परख करोगे तो परख होगी। 

क्षमा करोगे तो क्षमा मिलेगी, हम अपने आपको भी क्षमा कर पायेंगे।

हम अपनी भावनाऐं पाप, घृणा और निन्दा में डुबाये रखने की अपेक्षा सद्विचारों में ही क्यों न लगावें? क्यों न अपनी चेतना को परमात्मा के चरणों ने लगायें।

या जग में कोई सुख न देखो

श्री हज़ूर स्वामी जी महाराज भी फरमाते है –

या जग में कोई सुख न देखो | गहो गुरु के बचननियाँ ||
दुःख के जाल फँसे सब मुरख | तू क्यों उन संग फंसननियाँ ||

स्वामी जी महाराज के भाव, जो मुझे समझ आता है – हमें लगता है कि इस दुनिया में लोग सुखी है लेकिन असलियत यह है कोई भी जग में सुखी है नहीं, सारे ही दुःख के जाल में फँसे जा रहे है, इसलिए आप समझते है हम क्यों उनके साथ फँसते जा रहे है, हमें तो हमें गुरु के वचनों पर चलना है।

सब घट मेरा साइयाँ

कबीर साहिब ने फ़रमाते है –

सब घट मेरा साइयाँ, सूनी सेज न कोय ||
बलिहारी वा घट्ट की, जा घट परघट होय||

भावार्थ – हर घट यानी शरीर के भीतर, मेरा ही परमात्मा (साइयाँ) निवास करता है।  कोई भी उससे (रब से) खाली नहीं है| जिसका मतलब यह है, परमात्मा का घर, कहीं बहार नहीं है, वह घर हम सब के अन्दर ही निवास करता है|

लेकिन उस घट यानी शरीर यानी जीव की बलिहार है, जिसके घट में वह (रब) प्रगट होता है।


Why Git-Tag is important for Release

Tag and Branches

What’s the difference between tags and branches? The workspace is (almost always) associated with a branch, called master by default. When it is, a commit will automatically update the master reference to point to that new commit; in other words, branches are mutable references.

What is Git Tag?

A tag, on the other hand, is created to point to a specific commit and thereafter does not change, even if the branch moves on. In other words, tags are immutable references.

Git has two flavours of tags;

  • annotated and
  • non-annotated.

When using them, there is little difference between the two; both will allow you to refer to a specific commit in a repository. An annotated tag creates an additional tag object in the Git repository, which allows you to store information associated with the tag itself. This may include release notes, the meta-information about the release, and optionally a signature to verify the authenticity of the commit to which it points.


Why use Git tag?

Git tags are like milestones, markers or a specific point in the repo’s history marked as significant. Tags are usually used to mark stable releases or achievement of very important milestones.

Tags can help the users of the repo to easily navigate to the important parts of the code history like release points. For example, on Github, you can easily grab archive of “tags” in the current repo.


Commands dealing with Tags

List tags:
git tag

Search in tags:
git tag -l v1.*

That will display tags starting with “v1.” – use regex and your common sense to do complex queries. This can help you narrow down your query in case you have plenty of tags in the repo.

View a tag:
git show v1.4

Note: The command doesn’t have “tag” in it. 🙂

Adding tags:
git tag -a v1.0.0 -m ‘version 1’

The “-a” denotes an annotated tag – means it’s stored as a full object in the git database where as a non annotated tag is just a pointer to a specific commit. Just drop the “-a” to create normal tags. The “-m” option is of course obvious, it allows you to add a message to the annotated tag.

Adding Tags later:
git tag -a v1.2 9fceb02

This will add the “v1.2” tag to the commit marked by “9fceb02”. “git log” will help you get the checksum of the commit.

Pushing Tags to remote branch:
git push –tags

PS: Git tags are not pushed automatically with generic “git push” command. You must push the tags separately.

Deleting a tag:
git tag -d v1.0.0

That will delete the tag v1.0.0.

These are the very common uses of Git tags. Look at the git manual for more complex stuff you can do with taggin

Brainstorming Process

Brainstorming is a group or individual creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its member(s). The term was popularized by Alex Faickney Osborn in the 1953 book Applied Imagination. Osborn claimed that brainstorming was more effective than individuals working alone in generating ideas, although more recent research has questioned this conclusion. Today, the term is used as a catch all for all group ideation sessions.

In another words, Brainstorming with a group of people is a powerful technique. Brainstorming creates new ideas, solves problems, motivates and develops teams. Brainstorming motivates because it involves members of a team in bigger management issues, and it gets a team working together. However, brainstorming is not simply a random activity. Brainstorming needs to be structured and it follows brainstorming rules. The brainstorming process is described below, for which you will need a flip-chart or alternative. This is crucial as Brainstorming needs to involve the team, which means that everyone must be able to see what’s happening. Brainstorming places a significant burden on the facilitator to manage the process, people’s involvement and sensitivities, and then to manage the follow up actions. Use Brainstorming well and you will see excellent results in improving the organization, performance, and developing the team.

Brainstorming Process

  1.     Define and agree the objective.
  2.     Brainstorm ideas and suggestions having agreed a time limit.
  3.     Categorise/condense/combine/refine.
  4.     Assess/analyse effects or results.
  5.     Prioritise options/rank list as appropriate.
  6.     Agree action and timescale.
  7.     Control and monitor follow-up.

1. Lay out the problem you want to solve.
This may be easier said than done.  Keeney describes a doctoral student who is at sea while trying to come up with a dissertation topic and advisor.  The student grasps for ideas with only the vaguest idea of a goal, stated as negatives rather than positives. “I don’t think I could do it,” “it is not interesting to me,” “it seems too hard,” and “it would be too time consuming.” Then finally someone suggests an idea that doesn’t have any of those negatives. The doctoral student grabs the topic. But Keeney says this is a poor way to make a major decision. Instead the student should keep pushing until they come up with at least five more alternatives, and then, considering all those, “identify your objectives for your dissertation, evaluate the alternatives and select the best.” It will be well worth the effort.

2. Identify the objectives of a possible solution.
This is what Keeney did for the German energy company and what he’s done for several government agencies, including the Department of Homeland Security and the energy department. It’s not easy and it takes time but if you can approach your goals critically and hone in on what you want to achieve, your brainstorming session will be much more effective.

Keeney offers a great example of this process. David Kelley, the founder of renowned design firm IDEO, wanted to design a product that would enable cyclists to transport and drink coffee while they were riding.  A couple of ways to describe what he wanted to design: “spill-proof coffee cup lids,” or “bicycle cup holders.”  But a much better description is the following objective: “helping bike commuters to drink coffee without spilling it or burning their tongues.”  Keeney likes this statement because it clearly lays out IDEO’s objectives, to help  bike commuters 1) drink coffee, 2) avoid spills, 3) not burn their tongues. He even contributes a few objectives of his own: avoid distractions while biking, don’t contribute to accidents, keep the coffee hot and minimize costs. Going into that much detail before  brainstorming about ways to design the cup holder makes IDEO much more likely to succeed.

3. Try to generate solutions individually.
Before heading into a group brainstorming session, organizations should insist that staffers first try to come up with their own solutions. One problem with group brainstorming is that when we hear someone else’s solution to a problem, we tend to see it as what Keeney calls an “anchor.” In other words, we get stuck on that objective and potential solution to the exclusion of other goals. For instance, when Keeney was consulting with a cell phone maker years ago, the company had numerous objectives. It wanted to produce a lightweight phone that also had GPS capabilities (Keeney did this consulting gig some time ago, but he insists the example remains illustrative). When company executives got together to brainstorm ideas about how to build a better phone, one person brought up the issue of weight. Suddenly everyone became fixated on that idea and forgot about their other objectives. Coming into a meeting with potential solutions reduces the risk that participants will get bogged down on one objective.

4. Once you have gotten clear on your problems, your objectives and your personal solutions to the problems, work as a group.

Though he acknowledges that it’s a challenge not to “anchor” on one solution in a brainstorming session, Keeney believes that if participants have done their homework, clarifying the problem, identifying objectives, and individually trying to come up with solutions, a brainstorming session can be extremely productive.

At the end of the paper, he describes a 2008 workshop he held to try to come up with ways to improve evacuations in large buildings in case of a terrorist attack, based on a recommendation from the National Institute of Standards and Technology. Keeney brainstormed for two-and-a-half days with 30 people with expertise in everything from firefighting and building codes to handicapped people and human behavior. The result, after going through Keeney’s four-step process: a list of 300 new alternative ways to speed evacuation. Then the participants evaluated the many ideas, which included using cell phone alarms to guide people to exits and building linked sky bridges on every fifth floor. The hope, of course, is that these solutions will never be tested. But Keeney’s brainstorming method helped the group find effective suggestions..

Improving the Daily Scrum

Few important points

  1. Time Start at: 10.00 AM (Not 10.02 AM); Scrum meetings wait for no one.
  2. Three Key Questions:
    1. “What did you do since the last meeting?”
    2. “What are you going to do until the next meeting?”
    3. “What impedes you from being more productive?”
  3. Concentrate on the second and third question, not on the first one.
  4. Standup means stand up, no sitting, really. except medical conditions.
  5. Stand in front of the visual progress artifact.
  6. Everybody should be present except medical conditions.
  7. No typing.  
  8. Daily standup is for synchronizing between the team members, not between Scrum Master and the team. If team members start behaving as they are reporting to Scrum Master, he can start literally looking at another person or even walk away a little. Such small tricks are often able to confirm that daily Scrum is for the team members and not for the Scrum Master


Load Balancer

Load balancers are used to increase capacity (concurrent users) and reliability of applications. They improve the overall performance of applications by decreasing the burden on servers associated with managing and maintaining application and network sessions, as well as by performing application-specific tasks.

Basically, a load balancer is a device that acts as a reverse proxy and distributes network or application traffic across a number of servers.

Load balancers are generally grouped into two categories:

1. Layer 4 and

2. Layer 7.

Layer 4 load balancers act upon data found in network and transport layer protocols (IP, TCP, FTP, UDP).

Layer 7 load balancers distribute requests based upon data found in application layer protocols such as HTTP.

Requests are received by both types of load balancers and they are distributed to a particular server based on a configured algorithm. Some industry standard algorithms are:

  • Round robin
  • Weighted round robin
  • Least connections
  • Least response time

Layer 7 load balancers can further distribute requests based on application specific data such as HTTP headers, cookies, or data within the application message itself, such as the value of a specific parameter.

Load balancers ensure reliability and availability by monitoring the “health” of applications and only sending requests to servers and applications that can respond in a timely manner.


Open Source Tools

Ultra Monkey

Ultra Monkey is a project to create load balanced and highly available network services. For example a cluster of web servers that appear as a single web server to end-users. The service may be for end-users across the world connected via the internet, or for enterprise users connected via an intranet.

More Details:

Red Hat Cluster Suite

It is a high availability cluster software implementation from Linux leader Red Hat. It provide two type services:

  1. Application / Service Failover – Create n-node server clusters for failover of key applications and services
  2. IP Load Balancing – Load balance incoming IP network requests across a farm of servers

More Details:-

Linux Virtual Server (LVS)

LVS is ultimate open source Linux load sharing and balancing software. You can easily build a high-performance and highly available server for Linux using this software.

More Details:-

The High Availability Linux Project

Linux-HA provides sophisticated high-availability (failover) capabilities on a wide range of platforms, supporting several tens of thousands of mission critical sites.

More Details: