Outlining my initial thoughts on a cloud-based pipeline implementation, as seen in the Deployment to the Cloud article.
As can be seen in General Flow and Minimum Viable Product, the core of the application involves the user uploading an image/video in a website/web app, after which it is analysed by OpenFace and the developed analysis service to determine its realism.
There are multiple ways to implement such a prototype, dependant on the time allotted and the stated requirements. In order to illustrate this, 3 options will be presented.
Simple prototype
This is the simplest form of prototype to implement: a simple web app, analysis service and (optionally) a way to store the generated data. If this is not used, a downloadable report can be created, leaving the choice to store it up to the user.
Overview of a simple prototype.
Complex prototype (scalable microservices)
The complex prototype trades simplicity for inherent scalability. Attaching a queue to the system allows for multiple instances of the analysis server to pick up jobs. This would be considerably more work, but fits better in the theme of modularity and scalability.
One of the more attractive options so far is integrating everything in a Django project. This will make it easy to allow services to communicate while still being relatively loosely coupled (through the use of Django applications). Alongside this, Django has a built-in ORM allowing easy use of a database in the MVP. Python is also one of the best options for the analysis side of the project, meaning most of the pipeline would be using a single language.
Due to its structure, implementing the application using Django would change the architecture somewhat. Each project is split into applications, meaning that even though it is a singular back-end it is split into various (seperately) reusable services. This fulfills the need for modularity while keeping the developmental benefits of a cohesive project.
Overview of a prototype using Django with high cohesion and low coupling.
Hosting
The created services will, of course, need to be deployed in order to be used. Fontys has various facilities allowing deployment to a self-hosted server, Azure or AWS. The specific service is not important: each service has a similar portfolio. AWS is the industry standard, though Azure is not far off. Azure also has the benefit of being used in past projects, meaning it will be easier to set up. Once there is a clear picture of what technologies will be used and what they require, a proposal can be made and the required resources can be freed up. Aside from the deployment itself, there could be various other services that could aid the pipeline.
Conclusion
To create the MVP as fast as possible, the better option for now is the prototype using Django. If deemed valuable, this can be expanded upon later. The goal is to have the basic flow up and running as soon as possible, and the tools provided by Django are the best for this.
