As part of the core engineering team tasked to rebuild Userpilot’s infrastructure and applications, I was involved in the initial design, architecture, and implementation phases of moving Userpilot’s analytical API into Elixir, backed by ClickhouseDB for analytical data persistence, and deployed to Kubernetes (managed by AWS EKS).I’ve implemented infrastructure as code (using Terraform) to manage the entirety of Userpilot’s next generation infrastructure and deployments, introducing… Show more As part of the core engineering team tasked to rebuild Userpilot’s infrastructure and applications, I was involved in the initial design, architecture, and implementation phases of moving Userpilot’s analytical API into Elixir, backed by ClickhouseDB for analytical data persistence, and deployed to Kubernetes (managed by AWS EKS).I’ve implemented infrastructure as code (using Terraform) to manage the entirety of Userpilot’s next generation infrastructure and deployments, introducing CI/CD processes (using GitHub Actions) to all new projects there. The new infrastructure, aside from being highly available, allowed for automatic system autoscaling to accommodate for load variance dynamically without manual intervention.During the development of the next generation analytical API, I took part in designing the new analytical data schemas design, built on ClickhouseDB, utilizing it’s various features to tune our queries in order to be as performant as possible.After going live with the next generation analytical API, I lead the migration process of customer’s analytical data from Userpilot’s legacy analytical API into the next generation one, before sunsetting our legacy analytical APIs completely.Moreover, after encountering a few scaling issues that were related to a couple of memory leaks we were facing in our implementation, I’ve took part in debugging those leaks which turned out to be caused by how the BEAM internally handles memory allocation, particularly when it comes to binaries. After a little less than a month of debugging, I’ve fixed several binary leaks we had.From there, I turned my attention to how the BEAM allocates memory, and after experimenting and retuning with multiple BEAM VM options, the new API’s memory utilization went from around 30% memory utilization at best to 60% utilization on app start, and around 93% memory utilization after running under production load, all with no changes to our actual code base. Show less

Helped in containerizing Cypress based, E2E project, followed by building a CI pipeline around it based on GitLab Pipelines, the pipelines held scheduled smoke and regression tests, as well as manually triggered test cases.Helped in the maintenance of multiple CI/CD pipelines both on GitLab Pipelines as well as Bamboo and Octopus Deploy.In my last months, I’ve helped in bootstrapping, designing, and architecting an E2E testing project for our mobile app based on Appium and using… Show more Helped in containerizing Cypress based, E2E project, followed by building a CI pipeline around it based on GitLab Pipelines, the pipelines held scheduled smoke and regression tests, as well as manually triggered test cases.Helped in the maintenance of multiple CI/CD pipelines both on GitLab Pipelines as well as Bamboo and Octopus Deploy.In my last months, I’ve helped in bootstrapping, designing, and architecting an E2E testing project for our mobile app based on Appium and using Kotlin and JUnit5. Show less

In my 3 years role as the sole DevOps Engineer at Yamsafer, I have worked on automating all the release processes for our backend and frontend applications using Chef Infra on AWS OpsWorks Stacks. As well as increasing the resilience of our services by clustering our core database, and adding load based instances that can take up our load should it stress our systems.I’ve then moved towards adding CI/CD pipelines for them containing E2E tests, in that process I have helped in the design… Show more In my 3 years role as the sole DevOps Engineer at Yamsafer, I have worked on automating all the release processes for our backend and frontend applications using Chef Infra on AWS OpsWorks Stacks. As well as increasing the resilience of our services by clustering our core database, and adding load based instances that can take up our load should it stress our systems.I’ve then moved towards adding CI/CD pipelines for them containing E2E tests, in that process I have helped in the design and maintenance of our in house built E2E testing framework re|flow. I’ve also worked on CI/CD pipelines for our native iOS and Android applications, as well as a React Native mobile application using Fastlane.Also, I’ve worked on containerizing our batch commands, which are scheduled as CRONs, and automating their management and release using Chef Infra, also on AWS OpsWorks Stacks.Returning to our core backend and frontend CI/CD pipeline, I’ve automated staging environment generation and release based on GitHub pull requests using Kubernetes and Docker.I was also responsible for managing the deployment and maintenance of Kong as the main API gateway for our services, especially with our move towards more service oriented architecture, as well as Elasticsearch (along with Kibana, Logstash, and Filebeat) for logs and analytical data ingestion.One of my final contributions at Yamsafer, was creating and maintaining a monorepo for our microservices (built on AWS Lambda) and code sharing for our backend team, based on Lerna for dependency management and Apex for release management. Which was, towards the end of in my time there, the main project (repository) used for developing all of our newer features and APIs. Show less