So I’ve got a service I’m trying to clean up. It responds to requests by starting a stopped server on Amazon EC2, waiting for it to come online, then configures a 3rd party piece of software on the server through a rest api, and then sets a task to start on that 3rd party piece of software. The service also does some maintenance type stuff and tries to keep track of “orphaned” servers or servers that no longer need to be running and shut them down. It keeps state in a database currently.
Right now it’s kind of working like an informal state machine. The “task” is the unit that is being managed, and the task has all sorts of states that it can be in, but basically most of the states are just steps in the initialization process. The code is pretty messy, and adding features can be somewhat painful. For example I am struggling to find a way to cancel the task while the initialization process is underway without writing in manual checks to see if it is canceled at the beginning of each step.
I thought a state machine would be a good way to clean everything up and standardize the code somewhat, but there seems to be a problem with that solution when I consider it more carefully. In a state machine you are directly controlling the state, and define the transitions between states that should be possible. In this system though I am really using AWS API and this 3rd party software API to tell me what the state of things actually is. Regardless of what my service thinks the state should be, the real source of truth is outside of my control, and I have to transition into whatever state it tells me it is in and work from there. So it kind of seems like I would end up making a state machine just to break basically all of its rules and manually control the state anyway.
Is a state machine a bad fit for this? Is there another pattern that should work better? Or do I just need to slowly work on refactoring things to make them better.