Turning a Tiffin Demand Prediction Model into a DevOps and Cloud Project
What started as a simple machine learning model for predicting tiffin demand became an opportunity to explore the complete software delivery lifecycle. I experimented with model evaluation, automated testing, GitHub, Docker, Jenkins, and Kubernetes, while exploring how the application could be extended to AWS. This project helped me understand how an ML model can move from a local notebook toward a reproducible, deployable cloud application.
Turning a Tiffin Demand Prediction Model into a DevOps and Cloud Project
When I first started working on my tiffin demand prediction project, my goal was straightforward: use machine learning to predict whether the demand for tiffins would be high or low.
At that stage, I was mainly thinking about the model.
But after getting the model working, I started asking a different question:
What happens after the model is trained?
That question led me from machine learning into Git, testing, Docker, Jenkins, Kubernetes, and cloud computing.
Starting With a Real-World Problem
Food preparation involves uncertainty.
For a tiffin service, preparing too many meals can result in unnecessary waste, while preparing too few can lead to shortages.
I wanted to explore whether historical information could be used to make demand prediction more systematic.
My dataset contains 700 records with information related to factors such as:
- Day of the week
- Student count
- Examination status
- Rain conditions
- Temperature
- Discount percentage
- Demand label
I treated the problem as a classification task.
Experimenting With Machine Learning
Instead of immediately selecting one algorithm, I compared several approaches.
I experimented with:
- Decision Tree
- Logistic Regression
- Random Forest
- Support Vector Machine
- K-Nearest Neighbors
- Gaussian Naive Bayes
Each model produced different results.
On my test split, the Support Vector Machine achieved approximately 97.86% accuracy, which was the highest among the models I tested.
This was one of the first lessons I took from the project:
Model selection should be based on experimentation and evaluation rather than assumptions.
But this was only the beginning.
The Notebook Wasn't Enough
A Jupyter Notebook is excellent for experimentation.
I could load the dataset, train different models, compare results, and inspect predictions.
But a notebook alone doesn't provide everything needed for a maintainable application.
I wanted the project to have a proper structure.
So I separated the responsibilities into different components:
1
2
3
4
5
6
7
8
9
10
11
12
13
Data
↓
Training
↓
Saved Model
↓
Prediction
↓
Testing
↓
Container
↓
Deployment
This simple change helped me think about the project as software rather than just an ML experiment.
Bringing Git Into the Workflow
Version control became an important part of the project.
Using Git and GitHub allowed me to track changes, experiment with branches, merge changes, and maintain a history of the project.
This became especially useful when I started modifying different parts of the application.
Instead of thinking:
"I changed something and hope it still works."
I could think:
"I changed something, committed it, tested it, and can track exactly what changed."
That shift made the development process much more organized.
Adding Automated Testing
The next step was testing.
I created a basic automated test for the prediction functionality.
Running:
1
python -m pytest
successfully executed the test suite.
This was a relatively small addition, but it changed the way I approached development.
A model can work perfectly today and stop working after a change tomorrow.
Automated tests provide a simple way to catch those problems early.
Packaging the Project With Docker
The next challenge was the environment.
Machine learning projects depend heavily on Python libraries.
A project that works on one computer may behave differently on another because of differences in:
- Python versions
- Library versions
- Operating systems
- Installed dependencies
Docker helped solve part of this problem by allowing me to package the application and its dependencies into a container.
The basic workflow became:
1
2
3
4
5
6
7
8
9
Python Application
↓
Dockerfile
↓
Docker Image
↓
Container
↓
Prediction
I successfully built a Docker image for the project and ran the prediction application inside the container.
During this process, I encountered a scikit-learn version compatibility warning related to the saved model.
Instead of simply ignoring it, I investigated the difference between the local and container environments.
That experience taught me an important lesson:
Reproducibility matters just as much as model accuracy.
Introducing CI/CD
Once the application could be tested and containerized, automation became the next logical step.
I started working with Jenkins to understand how continuous integration and continuous delivery could fit into the project.
The workflow I designed was:
1
2
3
4
5
6
7
8
9
10
11
GitHub
↓
Jenkins
↓
Run Tests
↓
Build Docker Image
↓
Deploy
↓
Kubernetes
The idea is simple: when code changes, the system should be able to automatically verify and prepare the application rather than requiring every step to be performed manually.
Learning Kubernetes
Docker taught me how to package the application.
Kubernetes introduced me to managing containerized applications.
I explored Kubernetes deployments and services to understand concepts such as:
- Pods
- Replicas
- Services
- Resource management
- Scaling
- Deployment configuration
Conceptually, the application could move from:
1
One Container
to:
1
2
3
4
5
6
7
8
9
Kubernetes
|
---------------------
| | |
Pod 1 Pod 2 Pod 3
| | |
-----------|---------
|
Application
This helped me understand why Kubernetes is useful when applications need more structured deployment and scaling.
Connecting the Project to AWS
The next step is taking this architecture toward AWS.
What interests me about AWS is that cloud deployment is not simply about putting an application on a remote machine.
A real cloud application also needs to consider:
- Compute
- Storage
- Networking
- Security
- Monitoring
- Scalability
- Deployment automation
The project gives me a practical application through which I can explore these concepts rather than learning them only theoretically.
What This Project Taught Me
The biggest change in my thinking was moving from:
"I built an ML model."
to:
"I am building a system around an ML model."
That difference is significant.
The model is responsible for making predictions, but the surrounding engineering determines how easily that model can be tested, packaged, deployed, updated, and maintained.
My learning path became:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Machine Learning
↓
Python
↓
Git & GitHub
↓
Testing
↓
Docker
↓
Jenkins / CI-CD
↓
Kubernetes
↓
AWS / Cloud
Using AI During Development
I also used AI tools during development.
Rather than treating AI as a tool that simply writes the entire project, I used it to help understand errors, explore unfamiliar commands, debug configuration issues, and generate possible implementation approaches.
The important part was validating the suggestions myself.
My workflow often looked like:
1
2
3
4
5
6
7
8
9
10
11
Problem
↓
Explore with AI
↓
Implement
↓
Run
↓
Debug
↓
Test
This made AI useful as a development companion while keeping testing and verification part of the process.
Future Improvements
There is still a lot I want to improve.
Some of the next steps include:
- Deploying the application on AWS
- Creating a web interface
- Exposing the model through an API
- Adding cloud-based storage
- Automating model retraining
- Adding monitoring and logging
- Implementing automated deployments
- Tracking historical predictions
- Exploring better forecasting techniques
The eventual goal is to turn the current project into a practical demand-management application rather than just a prediction script.
Conclusion
This project started with a simple question:
Can machine learning help predict tiffin demand?
It eventually led to much bigger questions about how software is built and delivered.
I learned that achieving good model accuracy is only one part of the process.
A useful ML application also needs testing, version control, reproducible environments, containerization, automation, deployment, and monitoring.
For me, the most valuable part of this project has been experiencing that progression firsthand:
From notebook → model → application → container → CI/CD → Kubernetes → cloud.
That is the journey I want to continue exploring with AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article