Serverless is ultimately scalable until it is not. You need to do load testing to make sure that your solution scales. The k6 is an amazing tool for that.
One of the main selling points of serverless is that it can scale to almost infinitive. However, building highly scalable systems is still a challenge. Serverless is complex, and it is quite challenging to get the architecture right. It is also very easy to hit service quotes (build in limits) when services stop scaling. They are there for two reasons: for you to not massively overspend in case of a bug or a huge load and that it helps AWS to maintain a level of service availability for all their customers. Some quotas are “hard,” but most important ones are “soft,” meaning you can open a request to AWS to ask for higher limits. You can see the quotes and request a quota increase in the Service Quotas console.
Serverless is ultimately scalable until it is not. You need to do load testing to make sure that your solution scales. The k6 is an amazing tool for that.
If you need to build a highly scalable serverless system, it is not enough to study all quotas and architecture in detail because you will definitely miss something. You need to do load testing. The best kind of tool/service for load testing is k6. The winning feature is it supports writing tests in JavaScript and even TypeScript. If your system is written in one of these languages, it is handy to also use it to write load tests. The benefit of using a real language for load testing, in opposite to just sending a static payload, like in other similar tools, is that you can generate test data on the fly and easily simulate a real user. I find k6 an essential tool for my serverless development, and I use it for all systems that handle any significant load.
You can execute tests locally, or you can use their cloud service. There are many benefits of cloud service. The most important is that you can pick regions where the tests are executed. The service also produces nice graphical reports. But for most cases, when you want to find the scaling limits and when the system will hit AWS service quotas, the local testing is good enough.
Our Project
I will describe how to write a simple test using TypeScript. I am a big advocate for TypeScript, but writing tests for k6 is not that indispensable because tests are usually simple. I still use TypeScript because all of the systems I build are built with TypeScript, and it also allows me to reuse some of the code, like the one to generate sample data, that I can reuse for load, unit, and integration tests.
For writing k6 tests in TypeScript, there is already a well-written sample. We will go much further and expand it with:
- Create a monorepo with an application built with the SST framework. We will execute our test on this application.
- Use esbuild to bundle the code (although webpack is the recommended one by k6).
- Authenticate user using Cognito.
- Use of faker-js to generate some sample data. This part of the code is shared between integration and load test.
- Use the SST Config feature for sharing parameters via the SSM Parameter Store. You can use this approach for regular integration tests and also in-load tests.
You can find the solution here. Before using it, install k6. k6 is not an npm module, it requires a separate install.
Top comments (0)