Fabio Manganiello on Nostr: A problem often neglected when it comes to choosing #cloud infrastructure over ...
A problem often neglected when it comes to choosing #cloud infrastructure over self-hosted is the often inevitable loss of test coverage.
I'm currently working on a project involving deep graphs, and the management has been toying with the idea of migrating the data model from a vanilla MySQL to a graph db like #Neptune over #AWS.
The data model and storage layer are usually the most crucial parts in any piece of software, and that's where you want your integration tests coverage to catch all the possible corner cases.
But where do you even start to write CI tests for a service that is cloud-only?
It's quite straightforward with MySQL. You just spawn a MySQL container with #TestContainers from your code, and you've basically got an exact replica of the storage infrastructure that you'll be using wherever your software runs.
But what about a service like Neptune?
If you're lucky and you're using a popular cloud service, then #LocalStack may probably provide you with a reliably similar replica of that service that you can run locally, and instruct your tests to spawn before running.
But more niche services, or services like Neptune that take a heavy toll on memory, aren't usually provided by LocalStack.
So what do you do? Create a test AWS account to be used only by your integration tests? And face the nightmare of how to properly secure it in a context where anybody with the source code can run stuff on your cloud infrastructure without authentication?
And how about the costs, since every request is diligently billed, even if it comes from your own integration tests? As your team size scales up and the number of pull requests, CI pipelines and local test runs increases what do you do?
Any modern piece of software infrastructure must also provide developers with the ability to have a local replica that they can reliably use to test things out. Products like LocalStack shouldn't be an afterthought developed by 3rd-party companies or volunteers. We can argue if we prefer a cloud-first or local-first infrastructure, sure. But a cloud-only infrastructure is a guarantee of poorer test coverage, poorer developer experience, or both.
@programming.a.gup.pe
I'm currently working on a project involving deep graphs, and the management has been toying with the idea of migrating the data model from a vanilla MySQL to a graph db like #Neptune over #AWS.
The data model and storage layer are usually the most crucial parts in any piece of software, and that's where you want your integration tests coverage to catch all the possible corner cases.
But where do you even start to write CI tests for a service that is cloud-only?
It's quite straightforward with MySQL. You just spawn a MySQL container with #TestContainers from your code, and you've basically got an exact replica of the storage infrastructure that you'll be using wherever your software runs.
But what about a service like Neptune?
If you're lucky and you're using a popular cloud service, then #LocalStack may probably provide you with a reliably similar replica of that service that you can run locally, and instruct your tests to spawn before running.
But more niche services, or services like Neptune that take a heavy toll on memory, aren't usually provided by LocalStack.
So what do you do? Create a test AWS account to be used only by your integration tests? And face the nightmare of how to properly secure it in a context where anybody with the source code can run stuff on your cloud infrastructure without authentication?
And how about the costs, since every request is diligently billed, even if it comes from your own integration tests? As your team size scales up and the number of pull requests, CI pipelines and local test runs increases what do you do?
Any modern piece of software infrastructure must also provide developers with the ability to have a local replica that they can reliably use to test things out. Products like LocalStack shouldn't be an afterthought developed by 3rd-party companies or volunteers. We can argue if we prefer a cloud-first or local-first infrastructure, sure. But a cloud-only infrastructure is a guarantee of poorer test coverage, poorer developer experience, or both.
@programming.a.gup.pe