We recently had the pleasure to work on a consulting project for a stealth real-time monitoring/analytics healthcare start-up working with a well-known academic institution. Their CTO challenged our technical team at Zaiku to help replace their existing architecture with something more sophisticated as they move beyond their monolith MVP. The new architecture must essentially enable them the following;
1. To scale more easily and deal with the huge stream of data generated by big number of concurrent users (e.g. patients, doctors, ambulance personnel and hospital admins) via multiple devices (e.g. smartphones, wearables, tablets and desktops).
2. Provide a better and consistent user experience as much as possible regardless of the system load.
3. Adopt Agile software development and continuous integration/deployment (CI/CD) over Amazon Web Services.
After a series of technical/business analysis with their CEO and other stakeholders we proposed reactive microservices architecture. As any architectural adoption decision there is really no silver bullet solution to the challenges ahead as their company grows. However we believe our proposal is firmly aligned to their long term business strategy and innovation roadmap.
What are Reactive Microservices?
Microservices architecture is without doubts amongst the hottest hypes and buzzwords in software industry right now and a proof of this is the presence of microservices in the so — called Gartner Hype Cycle!
Leaving the hype aside, from a high level technical point of view microservices architecture is nothing more than a special case of distributed system architecture. The basic idea is to essentially write software into a collection of small, isolated services, where each service own their data store, can independently be deployed and scaled as needed independently from other services. It gives software developers the freedom to use whatever technologies that make more sense for a particular service i.e. Service A can for example use MongoDB and framework X written in Java while Service B can use something completely different like MySQL and framework Y written in Ruby on Rails. This in theory (not always in practice!) means it is so much easier for a team of developers to make and deploy changes to production across multiple servers with minimal disruption to users, unlike the old school approach where a system can stay hours in maintenance mode while developers are deploying new changes or bug fixes.
Reactive applications are basically microservices applications that obey the Reactive Manifesto i.e. they are responsive, resilient, elastic, and message driven, the combination of which allow these type of applications to scale smoothly without much hassle to developers.
Should early stage startups adopt such an advanced architecture?
There is no right or wrong answer to this question. But traditionally the most successful and disruptive start-ups (e.g. Netflix and Uber) started with a monolith architecture for a while until their business model is proven and then for scaling needs switched to a more advanced architectural pattern such as microservices. In fact last year Uber shared their transformation journey towards microservices in this blog post.
The example of Uber above can make one to jump to the conclusion that it is better to always start with a monolith architecture before adopting advanced architecture such as microservices. However there are some good technical limitations to why these startups decided to adopt monolith architecture when they first started. Few years ago cloud infrastructure providers such as AWS were not mature and advanced enough to provide an environment to deploy distributed architecture e.g. limitation with machines running single core, high latency, expensive disks, very expensive RAM etc.
Fast forward today, the infrastructure to support distributed applications are much more matured and accessible to startups e.g. networks are faster, multi core machines are cheaper, RAM is cheap and cloud infrastructure providers such as AWS have increased their global data center footprint to enable companies to adjust their resource load geographically as per customers location. Hence at Zaiku we think it makes all sense for ambitious startups looking to disrupt their industries to adopt advanced distributed architecture as early as possible in order to hit the ground running. We look forward to sharing the progress of the stealth healthcare analytics startup after they publicly launch next year. We thank their management team for giving us the permission to share some high level details with you.
If you are a startup CEO/CTO looking to explore advanced distributed architecture we would love to hear from you. Check out our Github repository for our general purpose open source Java toolkit aimed at helping developers implement a wide range of distributed systems.