Category Archives: Microservices

Technology Stack Evolution

Technology paradigms have been making shift through decades. Trends are moving fast in terms of offering agile & pivoting solutions to problems at hand.

From an engineering stand point I have seen following evolutionary trend as waves:

IT Application Engineering → Product Engineering → Platform Engineering

With every wave our approach on how we conceptualize a solution from self-build to best-of-breed has gone through ideological change:

IT Application Engineering

  • Point-to-Point
  • Narrow audience. Build for one works for one

Product Engineering

  • Vertical in terms of features
  • Broader Audience . Build for features serves many
  • Customization may give birth to unmanageable monolith

Platform Engineering

  • Horizontal in terms of features
  • Wider Audience through knob controls on infrastructure seeding
  • Extensible through API design
  • Build on top of it and not within
  • Scales

With the above evolution & need for diversity in addressing different problem statements , one needs to keep following points in mind :

  1. Cookie-cutter approach does not work for diverse business models
  2. “Thought partners” are required to co-develop solutions , listen and adopt design inputs instead of simply being vendors
  3. Need to address data infrastructure, visualization and distributed microservices
  4. Concepts around minimum viable product help understand customers’ journey at a high level and evaluate the technology needs

At such a massive scale, it is always beneficial to develop a set of design principles that can guide your decision-making.

  1. Choose tech solutions made by challengers and visionaries with an extensible, API-first mindset
  2. Avoid legacy companies that might be lagging behind as they try to evolve their monolithic platforms.
  3. Do lot of proof-of-concepts that build hands-on understanding

Platform approach comes with certain amount of decentralization embedded in it for use and extension thus allowing elasticity in solution to serve diverse needs :

decentralization

When we start thinking on above lines it helps us to become creative across two major parameters:

  1. Expanding or Testing into a new market
  2. Expanding or Testing a new product line

Technology should enable this entrepreneurial spirit from start-up to scale across various sub-streams.

I hope this short read provides condensed view of how to evolve your technology stack.

Additional Reference

You can find more details and insights in my catch-up with  Segment.com , that got published on their blog last month on How Our Stack Evolved At Cimpress   . Thanks to Geoffrey Keating from Segment for taking the interview. 

 

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.

mag

Happy reading!