Projects
Indexity (project)
Indexity (opens in a new tab) is a cloud-native Enterprise Master Patient Index (EMPI) and Master Data Management (MDM) platform designed to enhance data accuracy and interoperability in healthcare systems. It offers rapid data ingestion, sub-second search capabilities within a fully managed, zero-operations environment. This enables organizations to deploy quickly, iterate freely, and maintain up-to-date systems without the operational overhead associated with legacy MDM and EMPI solutions. The platform comprises modular components including Index (a matching and linking engine) and Registry (a persistent, authoritative store). Key features include matching algorithms, stewardship workflows, and comprehensive audit and provenance capabilities.
I spearheaded the deployment of Indexity data-planes on AWS (opens in a new tab), along with other development tasks. This involved designing and implementing cloud infrastructure solutions on AWS, ensuring scalability and reliability of the data platform. I handled all the design work as well as critical security and operational aspects such as Threat Modeling and Disaster Recovery Planning. After the divestment of McCrae Tech (opens in a new tab) from Orion Health (opens in a new tab), I was tasked with leading the Site Reliability Engineering (SRE) and deployment aspects of Indexity data-planes, ensuring high availability, scalability, and reliability of the platform.
Highlights
- Directed the successful deployment of Indexity data-planes using AWS infrastructure; conducted thorough disaster recovery planning, which reduced potential downtime risks from unforeseen incidents by at least 40%.
- Orchestrated the migration of Indexity's SRE frameworks and infrastructure from Orion Health into McCrae Tech, achieving a smooth transition without affecting end users.
- Automated the customer request handling, incident handling, and on-call rotations for the Indexity data-planes, with comprehensive monitoring and alerting, reducing the response times for many incidents.
- Championed an end-to-end deployment strategy for Indexity within a deployment framework on GitLab (opens in a new tab)and AWS, resulting in a faster rollout time that decreased development cycles by one day per development cycle.
- Orchestrated comprehensive threat modeling and privacy assessments, leading to stronger safeguards, resulting in no major vulnerabilities detected by penetration tests initiated by customers.
- Enhanced the precision of phone number searches by implementing Apache Lucene (opens in a new tab)-based indexing techniques, improving the patient searches across two customers.
Choreo (project)
Choreo (opens in a new tab) is a Digital Platform as a Service which abstracts away the complexity of cloud-native development and operations infrastructure so that the users can create new APIs, integrations and services in hours or days instead of weeks or months. Choreo has many features which make this possible such as AI-assisted development, automated deployments in a secure and highly available environment, API Management, etc. Observability is one of the main areas in this puzzle which make the operations easier for the users.
Choreo has many features without differentiating too much across languages. However, it provides more capabilities for Ballerina (opens in a new tab) which was originally built within WSO2 (opens in a new tab). From development to deployment and production, there are many features which add value to the users if the users are using Ballerina. I worked on the Choreo project since it was initially started and was part of the initial team who worked on the foundation of it. During my employment at WSO2, the Choreo project was focusing a lot on implementing and improving the features around Ballerina provided in Choreo. I worked mainly on the Observability aspects of Choreo built around Ballerina designing and architecting the core of Choreo Observability and many features around it.
Choreo provided many capabilities for making the development to deployment and management of cloud-native applications easy. One of these was the Low Code editor provided for Ballerina. To make things easier for development, Choreo provides an online VS Code (opens in a new tab) editor with the Low Code editor and everything configured to develop the applications faster. I designed the scheduling of the online VS Code editor in Choreo, which involved scheduling the resources and configuring the routing to allow users to access the editor in a secure manner. Security, isolation of resources and the startup time were some of the most important aspects of the resource scheduling.
Highlights
- Worked on the Observability aspects of the initial PoC of Choreo and completed it within 3 months leading 2 more engineers.
- Led the Observability team and designed many of the Observability features of Choreo around Ballerina.
- Designed and architected the core data ingestion, storage and analytics architecture of Choreo Observability.
- Guided several interns and new joinees within the Observability team to settle into the company and the team, fostering an environment which allowed them to learn and grow.
- Handled many high-profile war-rooms created to handle various production issues related to Observability as well as in some other areas.
- Designed the resource scheduling of the online VS Code editor and implemented some of the core functionality of it.
- Improved the startup time of the Choreo online VS Code editor by analyzing the time taken for different parts of the resource scheduling.
- Designed the isolation and security aspects of the editor, ensuring that the users have the best User Experience without affecting other users.
Ballerina (project)
Ballerina (opens in a new tab) is a programming language built within WSO2 targeting making the development of cloud-native applications easier. One of the main features of Ballerina was the built-in automated Observability. The automated Observability relies on instructions added by the compiler at the BIR (Ballerina Intermediate Representation) level of the compilation. The instructions are added to the incoming and outgoing functions of Ballerina. This is made easy by the keywords and annotations in Ballerina which mark them explicitly with constructs such as services, resources and remote functions.
Highlights
- Owned Ballerina Observability and designed many of the improvements around compiler level instrumentation.
- Rewrote the Ballerina Observability compiler level instrumentation (moving from a Java bytecode generation level instrumentation to a Ballerina Intermediate Representation modification level instrumentation in the compilation flow) to allow collecting more contextual information, while keeping the performance impact minimal.
- Initiated the migration of Ballerina distributed tracing, from OpenTracing (opens in a new tab) to OpenTelemetry (opens in a new tab).
Cellery (project)
Cellery (opens in a new tab) is an implementation of the Cell-based Architecture which aims to improve productivity of the development of complex microservices, across multiple teams. Cellery introduces microservice composites along with controls to reduce complexity and tools to improve productivity, ensuring that the best practices are met. I was part of the initial team who developed the initial implementation of Cellery and mainly worked on the Observability aspects of the framework. Cellery was built on top of Kubernetes (opens in a new tab) and Istio (opens in a new tab). The Observability features were also built using them and presented to the users with context about the Cells that they create.
Cellery also included a central repository (Cellery Hub) to which the users could push their Cells. This allowed users to reuse Cells and properly wire-up dependencies to manage their deployments efficiently. I worked on the implementation of some parts of Cellery Hub including the Docker (opens in a new tab) Registry-based storage, authentication and authorization of the frontend and the CLI used for pushing and pulling cells.
Another important part of Cellery was the dependency management which ensured that the deployments are done properly without failures. I worked on the dependency resolution and visualization to improve the experience around deployments.
Highlights
- Implemented the Cellery Observability core implementation including dashboards using metrics, distributed tracing by extracting information from the Istio mesh sidecars.
- Guided several junior engineers and interns.
- Presented Cellery Observability in several community calls and wrote Medium (opens in a new tab) articles in the Cellery Medium publication (opens in a new tab).
- Implemented a PoC for the storage of Cells in a Docker Registry-based Cell registry and implemented the core of the storage and authentication.
- Implemented cellery CLI command for logging into Cellery Hub using a browser window-based OAuth flow using code grant flow.
- Implemented transitive dependency resolution, deployment order resolution and parallel deployment of cells (while preserving dependency order) with a single CLI command.
- Implemented D3.js (opens in a new tab)-based cell viewer CLI command which allows users to view a cell and all of its dependencies (this was later adopted into the VS Code plugin as well).
Siddhi (project)
Siddhi (opens in a new tab) is a fully open source, cloud-native, scalable, streaming, and complex event processing system capable of building event-driven applications for use cases such as real-time analytics, data integration, notification management, and adaptive decision-making. Siddhi was developed within WSO2 and maintained for a long time along with other solutions to provide analytics for other WSO2 products as well.
Siddhi has an extensions model which adds many capabilities to the streaming engine. While working as a Software Engineering intern, I worked on the initial implementation of Siddhi extensions within the extrema namespace, which included extensions for finding the maximum and minimum values in various ways in continuous event streams.
Highlights
- Implemented a Notebook prototype for analytics and visualizations using the WSO2 Data Analytics Server.
- Implemented six extensions for Siddhi, Stream Processing Engine.
Google Summer of Code - Siddhi Docs Auto-Generation (project)
During my last year at the University, in my spare time, I worked as a Google Summer of Code - Siddhi Docs Auto-Generation (opens in a new tab) intern. I worked for WSO2 (opens in a new tab) during this period and developed a Maven (opens in a new tab) plugin for automatically generating documentation for the Siddhi (opens in a new tab) extensions. The information for the documentation was scraped from data annotated into the extensions using a Maven plugin and the collected data was converted into HTML pages using MkDocs (opens in a new tab). This was used by Siddhi for generating their documentation till it was decommissioned several years later.
Highlights
- Designed and implemented a Maven (opens in a new tab) plugin for automatically generating documentation for Siddhi extensions using annotated data written in the Java code.