The Problem

In our scenario, one of our applications needed an export-data-to-excel feature. Probably many of us faced a similar demand in the past. The idea was to get a batch of data, transform it, and dump it into an Excel spreadsheet.

The obvious solution is to implement this service as a timed one into your application. This method worked well with a small amount of data. However, once the dataset was large enough, the application crashed. Someone tried to export too much data at once, which resulted in a memory issue, which brought down the application.

What is the solution then?

Could we separate the service from the rest of the application? Where would you host such an app? Do you expand your current environment with another service? Do you set up a separate environment? Should it be serverless? Which technology should you use?

What if you decide to go serverless?

If you decide to go serverless with a service, the most crucial consideration will be the cost. AWS provides a popular hosting base, and costs are calculated by resource usage mostly.

It fundamentally means the lower your CPU/RAM usage and the execution time is, the less you pay for the same service. Choosing the right technology is critical to optimize your Lambda execution times. Of course, you can go the traditional way and opt for Java, Python, or Node. There is, however, another alternative.

Is GoLang an option?

GoLang advertises itself as a language built for the cloud. Does this claim stand? We wanted to learn what the actual resource usage would look like for this specific excel export use case we had.

The Use Case

We received a bunch of data in JSON format and had to dump that in an Excel spreadsheet. Our previous solution was in Java, and once the input data exceeded a given threshold, the application crashed.

Our investigations concluded that it was a memory issue. If we had thrown a bunch of RAM into the configuration or optimized the solution, we could have most likely avoided the application crash.

We did not want to do that, so we considered moving toward a serverless solution.

The testing methodology

We generated an approximately 70Mb-large JSON file as an input (It is more than the maximum amount of data our service would ever receive) and wrote two sample pieces of code with roughly the same logic.

• Parse the input into a native JSON object
• Loop through the data
• Create an Excel file and a sheet
• Write the rows
• Write the file to disk

We wanted to make the playing ground somewhat even, so both services were Dockerized, and we measured the resource usage with docker stats.

Results

As we see on the graphs, on average, the memory and CPU usage of GoLang was half of Java's.

Of course, the pattern of one programming language might not be the best for another. Sometimes language-native solutions work better for certain scenarios.

If your goal is to reduce your AWS Fargate or Lambda costs, we advise you to look at GoLang.