Publications

In the previous article Boosting Jira Cloud app development with Apache Ignite we explained the benefits of using Apache Ignite in a combination with Spring Boot for building scalable and distributed backends for Jira add-ons. The important aspect of the backend design left without much attention was the machine learning infrastructure. In this post I’ll explain why we started with a combination of Scikit-learn and Celery and ended up with a combination of Apache Ignite, Ray Serve, Scikit-learn and PyTorch.

The microservice paradigm continues to gain popularity among developers of scalable and fault-tolerant systems. While usually being deployed in the cloud, the building blocks of such systems need to be deployed, developed and debugged locally on developer’s workstations. The heavy use of containers and container orchestration frameworks such as Kubernetes, OpenShift to name a few drives the need to approximate the properties of cloud infrastructure when making the local deployments on software developers workstations. Such an approach requires solving the whole set of problems: having to use the reduced datasets, scaled down configurations, simplified network topologies, having to replace certain building blocks that are parts of the cloud provider infrastructure (such as load balancers e.g.) with open source alternatives (Nginx + HAProxy e.g.) to name a few. To work around this problems we have created a simple command line Python-based network isolation tool that automatically configures iptables and Linux Kernel to achieve the desired level of isolation. The tool is designed for Arch Linux and Manjaro Linux as we heavily use the latter at Alliedium for software development (explaining the choice of Manjaro Linux is a topic for a separate article).

In this paper we show how Apache Ignite distributed database combined with Spring Boot framework can be used to build services with outlined properties, including our own service Alliedium AIssistant Cloud app built as Jira Cloud app that leverages machine learning (ML) to make Jira issue processing easier. This choice of technologies has proven to be a practically viable solution that runs equally well on both AWS EKS as our production environment and our local Kubernetes cluster deployed via Kubespray used as our development environment.