I had today an interesting discussion with my colleague Javad, who is helping us on Docker & K8s topics. He is interested to build a showcase for Operaton running in AWS. We talked with another colleague who is responsible for the itemis products which run on AWS and where we have gained much expertise with operating products in the cloud.
Javad will start setting up the necessary infrastructure and deploy Operaton with (likely) Postgres on an AWS based K8s cluster. In a first instance, we will just make Operaton accessible in the web. Later we might connect it with an Identity Provider via OpenID Connect.
In a first step this should enable users to try out Operaton even simpler. Maybe later we could offer users to manage their own services, if there is need for that.
It might take a while until we are ready. Then we will give an update on it.
Sounds great! Curious to hear what deployment architecture you’re thinking of for the engine. Will you be running the engine as a separate component, with services or task implementations communicating via REST or messaging? That corresponds closely to Operaton’s standalone server or shared engine modes, as described in their architecture overview: Operaton Architecture.
Or are you considering embedding the engine directly into each service, where each one handles a specific process fragment it also implements? That would turn the overall process into a distributed, chained execution model. where each service owns part of the process and works more like an orchestrated choreographic setup.
Alternatively, maybe it’ll be more of a monolith or modulith approach, where the engine and all service logic live together in a single deployable unit.
I tend to avoid the discussion about what qualifies as a microservices architecture and what doesn’t - intentionally - because it usually leads us away from the actual topic and into endless debates about terminology… 
Would be interesting to know which path you’re taking and why.
We are currently thinking more in the direction of a standalone server with connectors. This would enable to deploy and maintain a single Operaton service in the direction of SaaS.
In a first step we would just make it available, having Operaton as a demo service.
Next, we could combine it with an IDP and allow users to create their own accounts and deploy processes, also not much more than a demo level.
Next, we could establish a Free tier allowing users to reliably use the service.
And then, if there is enough demand, extend it to a SaaS product.
This is all just an idea, and we go now into further discussions.