Zoomdata Blog Microservices Architecture: A Brief History At Zoomdata

Several years and what seems like hundreds of releases ago, Zoomdata was a monolithic application and had similarly antiquated models for high-availability (HA) that limited options for scaling: Vertical: make the box and JVM bigger Horizontal: Replicate Zoomdata instances on separate hardware behind a server-side load-balancer Since then, the journey to a microservices architecture (MSA) that started with the Smart Data Connectors in Zoomdata 2.3 has expanded to include all Zoomdata componentry. However, for all the flexibility that MSA brought to the application, we still had work to do modernizing HA and scaling capabilities. We’ve dedicated ourselves to that work, and are making great progress. Our Elegant Approach to High Availability To think about HA and load balancing in a modern MSA for your own SaaS application is one thing. To build out a reliable and scalable application platform that customers take and derive their own SaaS and PaaS offerings with is something else entirely. To that end, we decided that rather than build out what may be a whole host of different configuration options and componentry, why not make things simple for ourselves and our customers? Component microservices are deployed across clustered hardware so each microservice should be HA capable to ensure availability during hardware failures or component interruptions. No intermediary load balancers, no side-car technology. The only thing you will need to deploy a highly available Zoomdata is Zoomdata. Simple. Zoomdata’s Rapid Release version 4.4 finds us roughly halfway through our HA journey with full capabilities expected in the next Long Term Supported release. Development has focused on meeting this need through the following requirements in Zoomdata’s microservices. Each service must: Be deployable as a distributed pool of microservices (2:n) Offer meaningful health checks Be fault-tolerant Automatically failover Be stateless (or attempt to gracefully shutdown where state is used) The key to all this has been implementation of client-side load-balancing for each of the microservices. Client microservices can now interact with a pool of microservices up the application stack as if the pool were a single service. Since pool size can be scaled from 1:n and back down without interrupting the client microservice’s requests, we can now achieve a more efficient means of scaling and distributing Zoomdata as an application. BOOM. What’s Next: Looking Forward to Simple Scalability We are busy rounding out the rough edges, determining what folks should do vs. could do with the technology and that means getting to a reference architecture, determining sizing guidelines, and testing, testing, testing.