So this is more of an AWS simulator than a digital twin.
Digital twin to me means an additional synchronized representation of a system that I can use to interact with the underlying plant.
I think this sort of thing is still useful. I'd never attempt to build something like this without modern AI tools. This is arguably a good use case assuming you are checking your work against AWS actual.
To me it means a system that I can model things on with enough fidelity I find the results predictive if I go do it for real. Not a control panel, an alternate reality.
Actual twins don't occupy the same space time on the same 4D trajectory.
For the sake of the metaphor, both should respond the same way to the same inputs. You can, for instance, run two medical lab tests using two twins in parallel and get interchangeable results.
That said, I imagine when this twin is sufficiently faithful, one could first issue state convergence commands until the digital twin mirrored the real, and then overlay an orchestrator to do things perhaps you're thinking of such as: if digital deploys of config changes work, then the same change is applied to the real.
This looks pretty cool! However I feel that if the README starts with "Drop-in replacement for X", it should also start with "Why use this over X".
I do like the idea of saving prompts for projects like these (Which is also where the above question is answered: "Creating an MIT-licensed wrapper around Moto that has 100% feature parity with Localstack." [0] Which (i assume) is motivated by the recent changes to Localstack's distribution model [1])
This is awesome for local development of AWS service based software, allowing developers to develop without having to enable AWS access, or handle them stepping on each other's toes with S3 bucket names, or Dynamo table names, IAM roles etc.
So this is more of an AWS simulator than a digital twin.
Digital twin to me means an additional synchronized representation of a system that I can use to interact with the underlying plant.
I think this sort of thing is still useful. I'd never attempt to build something like this without modern AI tools. This is arguably a good use case assuming you are checking your work against AWS actual.
To me it means a system that I can model things on with enough fidelity I find the results predictive if I go do it for real. Not a control panel, an alternate reality.
Actual twins don't occupy the same space time on the same 4D trajectory.
For the sake of the metaphor, both should respond the same way to the same inputs. You can, for instance, run two medical lab tests using two twins in parallel and get interchangeable results.
That said, I imagine when this twin is sufficiently faithful, one could first issue state convergence commands until the digital twin mirrored the real, and then overlay an orchestrator to do things perhaps you're thinking of such as: if digital deploys of config changes work, then the same change is applied to the real.
This looks pretty cool! However I feel that if the README starts with "Drop-in replacement for X", it should also start with "Why use this over X".
I do like the idea of saving prompts for projects like these (Which is also where the above question is answered: "Creating an MIT-licensed wrapper around Moto that has 100% feature parity with Localstack." [0] Which (i assume) is motivated by the recent changes to Localstack's distribution model [1])
[0] https://github.com/robotocore/robotocore/blob/main/prompts/2...
[1] https://blog.localstack.cloud/the-road-ahead-for-localstack/
This is awesome for local development of AWS service based software, allowing developers to develop without having to enable AWS access, or handle them stepping on each other's toes with S3 bucket names, or Dynamo table names, IAM roles etc.
Looked at LocalStack today, but management said 'no' because $$$$. :(
So this is awesomely timed.
"build me an aws clone. make no mistakes"
If you want an AWS clone, wouldn't you want it to have all of AWS's mistakes?
[dead]
[flagged]
[flagged]