custom-header

From Monolithic to Micro Service Architecture 1/4

From Monolithic to Micro Service Architecture 1/4

Intro

Over the time you come across numerous articles about using the right software stack and choosing the best architecture approach. I will use this series to share my opinion on the latter one and hope that it contains some valuable information for the audience.

This series is split into three posts, having this one as the starter mainly covering the ‘Monolithic Architecture’.

Have fun and leave me a comment !!!

Background

I have coded my first lines of HTML back in 1995 with the inception of Netscape 2.0. After realising that Perl was not yet on track for the WEB (or me too dumb to deep dive into its pointers, references etc.  ), I took a deep dive into PHP 2.0 and developed my first webpage in 1996. The first contact with an ‘e-commerce’ platform was back in 1999 @ Pixelpark where I was hunting down bugs and extended functionality on one of Germany’s  perl based electronics platform named ‘Conrad’.

Since then I have been a CTO for five startups and have been freelancing for companies around  Europe. My familiy decided to relocate to Singapore in 2013 and since then I work over here as a CTO.

My main take away

My general advice here sounds so very simple but is so astonishingly hard to follow:

You cannot assess what you have not measured !!!

The Monolithic Architecture

monolithMost of the dev’s around  might already came in contact with a Monolithic Architecture. Usually PoC’s and early startups using it and its advantages. The first three internet companies I worked for built their platforms around that principle, first one on Perl, second on Java/Tomcat and last but not least Java/Weblogic. Even though the latter one already provided the means to build and deploy a SOA application, we did not make use of it back then. 

These would be my unique characteristics for a Monolithic Architecture:

  1. One shared codebase all developers work on
  2. One build & deployment for the whole application
  3. Scaling out is achieved by distributing the whole application to many containers/servers
  4. Usually a single storage solution is used
  5. High feature throughput with small team and less functional complexity

 My learnings

I consider it a very viable architecture solution especially for the early company phase. The monolithic approach facilitates an average sized and skilled team to move fast and efficient. Especially in an early company stage, where the business and product owners change their strategy more often than you are able to grab a coke from the fridge, you will not find a better architecture. Short lead times and deployment cycles due to minimised internal dependencies are definitely a big help for the company … however not always for the dev’s. I have used this principle together with:

  • The Spring Framework
  • Grails
  • Playframework
  • Zend
  • Yii

Early warning system

risksAhead

The challenge with this architecture is, that as soon as shit hit the fan, you are more or less doomed to work around the clock to shift your platform to the next level. I have been in that situation and there was no easy way out.  There are a number of precautions I take that are specific for this setup and help me minimise the risk of a potential disaster:

 

 

  1. Performance Tests
    1. Frequently running performance tests are a personal reinsurance. Due to the nature of the Monolithic Architecture, tests should always cover the top use-cases and really focus on maximum throughput. Only that will provide some clarity on the expected performance of your application.
  2. Check external jobs
    1. People tend to outsource jobs like reconciliation of data, fanout of notifications and even any kind of reporting into cron scheduled actions. This might be convenient but easily becomes toxic when traffic picks up and this job processing interfers with your regular request processing especially on the storage layer.
  3. Team Scale
    1. You cannot grow the team with this setup infinitely. There is a feature throughput threshold you gonna hit sooner or later. What you need are metrics about the performance of your team and the individuals.

It usually takes some time before the platform runs into performance issues or the team throughput no longer scales linear with the people you hire or the technical requirements getting too complex to house it together with rest of the code.  This ‘Early Warning System’ might help you to find the right point in time to prepare for the big step.

Take away

takeAway

  1. Monolithic Architecture facilitates short development life cycles with short lead times while the overall platform complexity is low and the team size is small
  2. Closely monitor team evolution vs feature throughput, platform performance and functional complexity of the application to avoid any surprises
  3. Keep your business owners informed about possible shortcomings of the setup

 

 

Next blog will covers ‘Semi Monolithic Architecture‘.

Thanks for your time.

 

Author: Thorsten Maus

Grown up in Berlin, Germany
Starting coding with 12 years on a Z80 processor
First contact with the internet in 1994 in Dublin

Living in Singapore

CTO Jobs:
helloPay (current)
Lazada (Special Projects)
Zalora
eDarling
iLove

Leave a Reply

Your email address will not be published. Required fields are marked *

Shares