I currently have a monolith application, which has a thread running per customer. Each time a new customer registers, you start up a new thread; each time they send in information (make an order, change details,etc.) The message is routed to the correct thread; and each time they unregister the thread shuts itself down.
I have a routing thread that does the thread and message management.
It seems, with my limited knowledge of microservices, that this is a prime candidate for converting to a microservices architecture - I have a set of independent processes (customer threads) running.
As I start looking into it, I was thinking of creating one service that is the equivalent of the "customer thread" - customer microservice instance.
How would you go about spinning up a new customer microservice instance each time a new customer comes along? You could have some kind of manager microservice, but given that the idea is to distribute the customer microservice instances "in the cloud" (i.e. we shouldn't care about where they are?) This doesn't quite seem to fit with what I've read about microservices and how they work. Or have I misunderstood something? What would be the best approach for distributing this system?
One approach I have considered is having the manager microservice contact a "process starter" service round-robin. the process starter service would have an instance running on each physical server (or in each container), which then starts local customer microservice instances - but from what I was reading you shouldn't really share a container with multiple microservices?
This may become too opinion-based for Stack Overflow - but I'll give it a go.
The most common definition of a microservice architecture I'm aware of is "a group of small, focused services operating in a bounded context, which are composed to deliver end-to-end functionality to business processes." Your "thread per customer" approach is almost exactly the opposite of this - the thread appears to know everything about the customer, what they do and how they do it. The thread is the monolith.
In a microservice architecture, you would have services for specific contexts in the business domain, for instance CustomerProfile, Orders, Invoices, CustomerService etc.
In this model, you could still have a "thread per customer", but instead of baking the knowledge of how to place an order into the thread itself, the thread invokes a microservice (probably over HTTP). The thread is responsible for state management and orchestrating the microservices to achieve the end-to-end business functionality.
Each microservice would be as independent as possible; it's common for each microservice to have its own container(s) and deployment architecture.
Again, mostly opinion-base - if you decide to stay with "thread per customer", I would not want to spin up a new service for every customer - this would be very wasteful. I imagine most of your threads are asleep for the vast majority of their life; giving them their own service instance (and container to run in) would not make a lot of sense.
However, the answer to "how can I start a service instance" is handled typically by load balancing (the load balancer knows which instances are available, and routes requests based on whatever availability heuristic you choose). You can auto-scale on most cloud providers, or you can use tools like Kubernetes to manage the provisioning of containers and servers.