3 ms·
If I was to adopt these ARM instances in production, for my services running on the JVM, I suppose I need to ensure things can actually build, integration test
by tracer4201 7y ago
If I was to adopt these ARM instances in production, for my services running on the JVM, I suppose I need to ensure things can actually build, integration test it all together, load test it, and review performance metrics.
Then I also need to ensure that all the tooling I use (for example - agents running on the box, other processes decoupled from my service, etc) are all working as expected without functional or performance regressions.
I’m actually not sure what else needs to be looked at... but this is all new work without new value if I look at it on its own. Hard to justify to my CIO.
I don’t know what the pricing model is but I wouldn’t even think of adopting this unless there’s a significant price benefit, allowing me to run on much cheaper hardware.
Even then, it only makes sense to me if you have hundreds or thousands or tens of thousands of hosts provisioned where that price delta really adds up to savings.
This is all conjecture - I’ve never done a migration like this.
- jedberg 7y agoPresumably you wouldn’t migrate to these unless you had a good reason. But it might make sense to build new applications on ARM.
- inlined 7y agoThen don’t you worry that there’s only one real ARM offering and you’d be locked in lest you do the same kind of analyses for porting back to x86/x64?
- PaulHoule 7y agoSome software will run on ARM with very little work. (If you care about performance it might be a little more work!) Some will involve one hell of a fight with your compiler, libraries, build tools, etc. AMZN itself is a good early adopter for a new architecture since they have so many services such as S3, SQS, where they have huge fleets of machines running a single set of programs, so the payback time for the port should be low.