Building for long, learning for long
Each project is a journey filled with unique challenges and opportunities. The past three years of shepherding a software project from zero to production have been nothing short of transformative, both personally and professionally.
You learn the most when you’re in the thick of it.
The above screenshot is taken from a Healthcare solution running in a hospital environment for almost 2 years now. We process roughly a million events per month, including all the external integrations and internal events.
Uptime is not a direct measurement of a successful software, but it definitely helps you measure that most of your decisions worked as expected.
Some of you might recognize terms like HL7, Nursecall, and Room Status (RTLS) as those are Healthcare domain keywords. I didn’t know them when we started building this application. This application is expected to run On-Prem and not in the Cloud. I am more comfortable with Cloud technologies because they provide better flexibility, control, and automation.
The team wanted to validate the idea first, we had a shoestring budget to build and manage this entire application. Most of our technology choices worked well and remained consistent from the early days to now. But with time, we offloaded a few things that we felt were not adding any value instead adding overhead.
(Simple) Tech Stack
The overall use case was not simple data processing. It was centered around collecting Health records and other events from the Hospital environment and creating patient-specific dashboards that will be available inside patient rooms, nurse and care team-specific dashboards that are accessible through the Web App, and an overall system dashboard.
- ReactJS for everything UI side
- Metronics and React for the Admin UI
- React Native app with native integration to load UI as well as interact with various device-level operations, primarily for Android.
- Kuzzle Backend — Kuzzle allowed us to maintain a static connection so that all the Android devices are connected to our backend services all the time. We send real-time data updates to refresh the UI.
- NodeJS Backend Services — NodeJS was our obvious choice as we build a lot of applications with NodeJS, both Container-based and Serverless-based. We built a bunch of custom services that interact with each other for data processing.
- Percona MongoDB Server — We selected the Percona server as it has the option to encrypt the data at rest.
- ELK — Elastic and Kibana were primarily used to keep all the System Logs and prepare the dashboard.
- Traefik — We chose Traefik as our Ingress and Load Balancer over Nginx for a few internal reasons and it worked out well.
- Docker Containers — Docker is the BEST technology for modern software development and delivery. We went with containers from Day 0 and that was the best decision, considering we are Off Cloud, packaging and delivery are very important parts of the overall process. We have a consistent development and release cycle. The containers are easy to move to different environments. And our rollout process became effortless. We were able to supply software updates on physical portable drives as well ;)
- Helm Charts and Docker Compose — From our AWS DevOps experience, we usually go with a more process and script-driven approach instead of managing something manually. Both Helm and Compose work great in their context. Our build process can generate an output that is compatible with the Kubernetes Cluster and Single Machine Docker environment.
- Amazon Web Services — We utilised various AWS Services like CodeCommit, CodePipeline CodeBuild for release purposes. We also utilized a fair bit of Serverless services for a few use cases like AppSync, API Gateway, Pinpoint, S3, Cognit, DynamoDB, CloudWatch Logs/Metrics/Dashboard, etc.
Effort Paradox
It takes a lot of effort to make something look effortless.
At times, it’s very easy to recognize the framework/service/tool based on its core features, but putting all of them together and building a solution is something unique for each software.
We had prior experience building Cloud Native applications using Docker and Serverless technologies. But this one was way different.
We also faced countless problems in our production journey. Besides the obvious software-related issues, there was a set of environmental issues ranging from Physical network instability, No Internet in some environments, Rollout of software updates with Docker containers in portable drives, and many many more.
We still use AWS services including AWS Lambda, API Gateway, DynamoDB, Code* Services for Developer Tools, etc. But over time, based on our new found learnings, we made the solution suitable for both Online and Offline environments.
Moving Forward
This is just half of the picture. Our React Native application is another complex piece of the entire solution. Luckily my long-time experience with Hybrid Mobile Technologies added good value (10 years and my name is still in the All Time Contributors list).
My journey so far with this project has reinforced the importance of embracing change, honing our skills, and approaching each day as an opportunity to grow.
As we move forward, remember that building for the long term is not just about the software we create but also the knowledge and experiences we accumulate along the way.
P.S. — Not sharing the name of the startup as we are still young in our journey and things may change over the period of time.
