Microservice architecture and startups: a thought excercise

All buzz words aside, microservice architecture or microservices, refer to a style of software architecture where components are built as small and self confined services. These services, when integrated as part of a larger stack, can be arranged to deliver functionalities akin to a traditional monolithic application. This blog post is part of the devops discourse, an exploration and a thought exercise to further examine the best fit of microservice architecture for startups.

Quick micro service summary

Martin Fowler is an authoritative voice on this topic, and he has a series of blog posts outlining the finer details of microservices. Microservice architecture are two peas in a pod with the taxonomy of devops (see https://macyves.wordpress.com/2014/03/08/taxonomy-of-devops-in-startups/), where in addition the former exudes the following characteristics:

  • Componentization via services, service for everything!
  • Organised around business capabilities, cross functional teams
  • Products not projects, full SDLC responsibilities from teams
  • Smart endpoints and dumb pipes, common integration protocols
  • Decentralised governance, common components/libraries
  • Decentralised data management, data redundancy and distribution
  • Infrastructure automation, scalable platforms
  • Design for failure, resilience and high QoS
  • Evolutionary design, continuous integration

Mass adoption?

These aforementioned characteristics are in fact not exclusive to microservice architectures. They can be found in monoliths too. For example, I believe you can have smart endpoints and dumb pipes even when running a large clusters of heavy weight J2EE containers (J2EE is arguably the epitome monolithic platform). You can certainly build decentralised reusable components, which can be put together to form new WAR/EAR packages that can be deployed on an elastic cloud infrastructures. The point here is that enterprises and monoliths are not the mark of the beast. Much like microservices and devops are not the messiah. In fact Fowler stamps his cautious optimism by saying

…you shouldn’t start with a microservice architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.

So for a start up?

Assuming that resources are scarce and VC funding aplenty, the following are some of the common grounds that could help in the endevour of moving monolithic architecture to a microservice one.

  • Cross functional teams. Build devops mentality by avoiding silos from the get go. This extends even to mixing individual with varying programming languages background at times.
  • Product overheads (release, packaging, maintenance, testing, etc). Avoid pushing out too many tiny products that can lead to overwhelming overheads and potential technical debt. Naturally do not build competing products.
  • If several product lines exists, then the implication is that technical teams do not spend time contributing to the same code base. Camaraderie may be amiss and teams maybe in loggerheads. Promote better cross-team communication and be aware of unintended silos.
  • Cross functional team requires quite a wide spread of competencies. Invest in your resources and promote accountability and dogfooding.
  • Build monoliths and utilise common integration protocols (HTTP is always a good choice). Commonly adopted protocols tends to be easier to debug.
  • Keep the size of the teams small. Large teams build larger system.


Microservice architecture attempts to programmatically address devops via architectural design and giving it a name that resonate with enterprise developers and architects. I predict that adoption of microservices will not be hampered by its inherent complexity or costs, but by human factors. Further more, currently microservices read like a silver bullet to everything, but underneath the surface there looms a fair amount of overhead and potential technical debts. I believe that a technical organisation needs to reach a certain critical mass and attain a certain level of competency in order to fully adopt microservices and reap the full benefits.

Indeed I do not believe a startup company is fully capable of building microservice architecture from the get go. I would advice for a transition strategy from monolith to microservice for small technical organisations. Naturally, startups can easy build components that can be used as a microservice too. Perhaps thats where microservices shines the most for a startup.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s