How We Used Mock APIs to Save $$$ on Our Cloud Bill

Discover how you can use mock APIs to save money when developing in the cloud 💰☁️

Aah, the cloud. Finally we do not have to go down to the server hall and mount a new rack each time we need to scale up. Simply let your favorite cloud provider automatically spin up a new instance for you, lean back, and focus on cranking out new features for the next big electric scooter app you are building.

As you are coding along, the month ends. You get an email. It’s your cloud bill. It’s huge.

When working on cloud projects, one of the most neglected cost drivers is your development environment. In this article we will describe how we managed to cut the costs in half for our development environment by leveraging mock APIs instead of real services.

Architecture

We were working on an application with a lot of external integrations for push notifications, email, queue management, payments etc. These were all called when running integration tests and using the application in general.

Each of these external integrations cost per each API request made to them, as accustomed in the cloud. This essentially a good thing, we do not have to sign up to expensive plans, we just pay for what we use and no more. It also provides you with an opportunity to minimize the usage of these services to keep costs down.

Creating Our Own Tool

To lower the usage of the external services, we needed something to replace them. They still needed to respond when developing or testing our application, otherwise it would crash or the tests would fail. We started looking at different solutions for simulating or mocking the APIs of our external dependencies.

There are multiple tools out there, but we did not find one that fit our use case 100%. Our requirements were:

• We wanted to manage our mocks as code so that we could version control them easily and deploy them continuously
• We wanted to be able to run our mocks locally
• We wanted to be able to host our mocks and call them remotely

That is why we decided to build our own tool for mocking APIs. This tool enabled us to easily define the mock APIs in a YAML-file, run them locally or deploy them for remote usage.

Cutting the Dependencies

Using our newly built tool, we could start creating mocked versions of the external services. For example, one of our services was an API for sending emails. This was a very simple API with a single endpoint replying 200 OK when an email was successfully sent. Using our tool, we were able to define a mocked version like this:

name: email-api
port: 3001
endpoints:
  - path: /
    method: post
    responses:
      - statusCode: 200
        body: |
          {
            "message": "success"
          }
        headers:
          - name: content-type
            value: application/json

This could be run locally, or we could hook the tool up to read the file from our GitHub repository and update the remote version of the mock.

Little by little, we were able to create mock versions of nearly all of our external dependencies.

Results

After implementing mock versions of the external dependencies, we pointed all of our development configurations to use them instead of the real ones. This meant once a developer started developing a feature, the default services to use would be mocked. At the time, our team was quite large and development work meant a lot of requests to the external dependencies, which in turn meant more costs. Of course, if the developers relied on the result of an external dependency (such as an email arriving) it was still possible to use the real service.

This strategy nearly cut the cost of our development environments in half. We also experienced a small increase in productivity due to not having to rely on the external dependencies being up and functional while developing, the lightweight mock would always be running locally if you needed it.

Further Reading

If you think this approach to mocking external dependencies is something that could be used in your development workflow, there are many more use cases for mock APIs. Inially, we built the tool mentioned in this article for internal use but now we have launched it to the public as a free beta. It can be used for mocking microservices, testing and simply mocking JSON responses.