"In the tech industry there are only a couple of things that can make engineers try something new. Either it's because we can do something faster or because we can do something cheaper,"
"When only one of those two benefits presents itself, we often resort to long trade-off conversations because we not only have to factor in the immediate gains but also the invisible costs of implementation, support, tooling ecosystem, edge cases, and so on."
"From a performance engineer's view, this is a problem," Atlassian's post states. "When issues appear at specific parts of our code, at least you know where to investigate next. But when problems span multiple endpoints and areas of your code, pinpointing a fix is like finding a needle in a haystack."
Atlassian evaluated AWS Graviton processors after Graviton 2 because the chips promised both better performance and lower cost. Early tests failed to confirm AWS's claims and investigations into migrating Jira to Graviton 2 and 3 showed no clear superiority. Performance anomalies affected multiple endpoints, making root-cause diagnosis difficult and consuming scarce engineering resources. Site reliability engineers could not reach consensus and paused the effort. After further work to address performance variability, implementation costs, and tooling gaps, Atlassian reversed course and now runs thousands of server instances for Jira and Confluence on Graviton processors.
Read at Theregister
Unable to calculate read time
Collection
[
|
...
]