Tag Archives: Microservices

Vertical Decomposition Of Software Systems

This is a very light post on vertical decomposition and by no means is most comprehensive read on this topic! It is meant for engineers and product managers that are looking after or working in such initiative to resurrect their current approach or pick something new from the examples.

Vertical decomposition powered by micro-services is a handy approach while trying to break down applications which appear to be black-boxed and contain objects with too many responsibilities. This complex overlap causes unwanted extension in data structures and creates convoluted schema that albeit powers the application but fails to provide right level of elasticity for absorbing ever changing needs of business.

Vertical decomposition can help you break down the application that encapsulates single business domain such as order , search , customer , product etc. In turn these single business domains should have concrete resource definitions with right level of granularity powered by micro-services to expose their

  • Functions
  • Configuration
  • Events
  • Discoverbility

While looking at vertical decomposition , one needs to spend time and decide which pieces need to be decomposed and how an incremental migration of same would take place.

Some great examples where you will find a particular resource having multiple responsibilities is as follows [ not comprehensive but enough to drive home the point ] :

  • Cross Domain
    • Customer carries definition on discounting that is linked to products
    • Customer specific products are linked to the product model
  • Complex Structure
    • Customer carries definition of tiers with logic and rules attached to it
    • Ordering pattern combines buying and promotions together

Such scenarios clearly help you identify radius of operation and allow you to start breaking down aspects of complexities with primarily two things as drivers:

  • Break things which are simple in nature and help you lay foundation
    • Example : [ assigning loyalty tiers to customers ]
    • Break Loyalty program out from the customer
  • Identify dependencies that reduce reliance on your current monolith [ follow anti-corruption design in case dependency exists ]
    • Example : [ login service ]
  • Carve out independent services that can expose required functionality without going back to monolith
    • Example : [ Separate discount from customer as product discount or separate promotions from buying operations ]

If you are some where above and started to experiment then for sure your delivery teams are comfortable with building micro-services and ready to go. However you may hit roadblock as the deconstruction process is not an easy one. Domains are over-lapped and need to break down that one resource which does it all. One of the key things to achieve that is start imagining distributed systems and finding a “best-of”breed” approach to separate by keeping persons in mind mapped to domains and then to best of breed architecture. This way you would be able to spread the system as  a platform and created separation of concerns which can then start to shape up the action map for the persona and domain.

Achieving this is not a one day’s job and requires us to ramp up on many fronts as an organization. The safety net in doing so should be always kept in mind so that you can ensure to isolate or promote basis the phase outcomes before we proceed. The whole exercise will start with broad funnel approach and then start to narrow down eventually leading to spurt of services that control separate domains and talk to each other in a contractual approach.

µ-services – Enabling Agile Development

I got an opportunity to share my insights in CIOReview Mag. – March 17 edition.

You are either building software… or losing to someone who is – @littleidea

Technology plays a pivotal role today on how we deliver to our business objectives. The choice of technology can determine over a period of time how business will scale and disrupt the market. One of the most modern paradigms of support new technology evolution has been Microservices.

I have tried to provide simple insight through this articles what it means to operate in API economy and opportunities it spells along with challenges.


Happy reading!

Monolith 2 Microservices @ OSI2016

I have been little inactive for past few weeks & somewhat busy doing too many things !

I spent two days in Bengaluru participating as well speaking at Open Source India 2016. It was  a great experience and lovely audience to interact with. I had chosen to speak on microservices and how this is an evolving paradigm in current business context.

Idea of my talk was to drive following point:

You are either building software… or losing to someone who is – @littleidea

Comparison to monolith and the journey to microservices is just a paradigm shift depending on what we are trying to achieve and whether or not we have spine to carry that shift. It is not necessary to make a change if you can follow good programming practices and still remain monolithic in nature. Understanding why one would want to move to microservices and how is very important . Realising & mapping what intrinsic and extrinsic value addition it will do a over a period of time is the necessary business bridge to achieve synergy with current business objectives.

At the end of the day if one has to be great at building software then following things must always be kept in mind:

  • Technology
    • Build technology for ease of business
  • People
    • Hire smart and talented people across various domains
  • Product
    • Provide products as business enablers
  • Data
    • Create visibility of insights for remaining competitive
  •  Go-To-Market
    • Disrupt Go-To-Market strategies

One needs to build technology by hiring domain agnostic talented people who can build products to enable business through data and power disruptive go-to-markets.

You can find my presentation in following location: microservices @ OSI @2016

Happy Reading!

API Economy : Vertical v/s Horizontal

What is a vertical API

In simple terms these are industry specific solutions powered using API stack. So as more and more API get exposed to users , there is also a new trend catching up where API adoption is expanding to provide industry specific solution.

Horizontal versus Vertical API

As companies across the world are adopting platform strategy to create a truly disruptive and sustainable business over a period of time using micro-services , it is also become pertinent to provide features as  service . You could very well imagine vertical API being docked to platform serving a particular industry or feature need of the consumer. The platform in itself though remains agnostic to the vertical.

Another .. example 

You might have seen lot of companies specifically e-com one’s integrate with logistics providers to send packages and then expose ability for customers to track their packages.Each one of these tires their best to make that exposure world class but have to deal with ever increasing provider integration. They are not well equipped to solve data visibility or tracking issue as their core platform need but you find compCaptureanies like Aftership: “Track shipments of 350 couriers” through shipment tracking platform for logistics industry as a Vertical API solution

We at Cimpress are also making strides for providing vertical API solutions for manufacturing sector. Still in beta mode allows fulfillers and merchants to seamlessly connect with each other through full stack Mass Customisation API  . You can get to hear more through following Software Engineering Daily podcast

Whilst large companies release API stack and start-ups or other solution integrator tend to use it to build solutions , it will become very pertinent for companies to understand the industry dynamics and within that the consumer behaviours to offer disruptive vertical solutions or more aptly feature-as-a-service.