Request to build a Dockerfile which should cater for providing a Flask based solution which would be able to call functions out of the main functionality. The Docker container should be based upon OL7-SLIM. Flask could form the basis for all REST based API calls and we could use a design first strategie by leveraging a Swagger definition file.
This would enable us to:
build the solution as a microservice which we can call (feed) tickets into the classifier for NLP actions, tagging, analysis and receive the feedback as a JSON object. A connector to a ticket system for getting new tickets and updating tickets could be developed in the same container however, more ideal we would have a container based service that will call this "main intelligence" service.
Additionally this will make the solution more easy to scale by spinning up more containers to support the analysis of incoming tickets. In a model that the ticket system connector is based in another container based solution you could scale up and down the number of containers for analysis based upon the nummer of analysis requests originating from the "connector containers"
Request to build a Dockerfile which should cater for providing a Flask based solution which would be able to call functions out of the main functionality. The Docker container should be based upon OL7-SLIM. Flask could form the basis for all REST based API calls and we could use a design first strategie by leveraging a Swagger definition file.
This would enable us to:
build the solution as a microservice which we can call (feed) tickets into the classifier for NLP actions, tagging, analysis and receive the feedback as a JSON object. A connector to a ticket system for getting new tickets and updating tickets could be developed in the same container however, more ideal we would have a container based service that will call this "main intelligence" service.
Additionally this will make the solution more easy to scale by spinning up more containers to support the analysis of incoming tickets. In a model that the ticket system connector is based in another container based solution you could scale up and down the number of containers for analysis based upon the nummer of analysis requests originating from the "connector containers"