As a rewrite of an existing service to send incremental over-the-air (IOTA) updates to phones and tables, I did architecture a new infrastructure based on AWS. Here I will detail the process and the architecture that I made and speak about application performance.

The service needed to send updates to 3000 boards, can be phones or tables or other devices. Now imagine if all of these devices send requests at the same time (worst case scenario), high load peak will be very heavy to deal with for a traditional architecture. So the first requirement was how to quickly scale, by quickly I mean in a matter of 2-3 seconds, absorb 1000 request/s. Updates where sent twice a week, from our CI (based on Buildbot). In addition, the updates have to be secured, only the entended customers should have access to these IOTA packages.

First approach:

Use an handful of EC2 instance and a load balancer behind to scale.

The problem with this solution, is that scaling is not instant, it takes time for monitoring, and then scaling.

Second approach:

At that time, Amazon Web Services have announced Lambda and API Gateway, so we started thinking about using them, AWS Team kept updating API Gateway with features and enhancement when we were using it.

With the promise of Lambda:

  • Simple setup, we used Node.js, just upload your code, automated Gulp task to package and upload.
  • Quickly scales up and down
  • Integration with all AWS services
  • Can be triggered by API Gateway endpoints

This approach will be API Gateway endpoints, triggering Lambda functions.

We also used S3 to upload the binaries and Cloud Front to distribute them with protected URLs.


I built the hole architecture in less than 3months with Integration into Buildbot to be used from the CI.


The Pros and Cons of each of these services: 

  • Lambda:
    • Pros:
      • Very simple to setup
      • Scales really fast
      • The spawn time is also blazingly fast, I don’t know how AWS did it, but, when you make a request to an end point, it does not take longtime for the lambda to fire (20 ms)
    • Cons:
      • Debug a bit difficult, you have to use AWS Cloud Watch
      • Language support, when they started they had only Java and Node.js (Now they added Python)
      • Lambda as the name suggested should be used for one feature and not like a real server replacement to do multiple things
  • API Gateway:
    • Pros:
      • Scales very good
      • Free SSL
      • Multiple stages or version can be run at the same time
    • Cons:
      • Still early ages for the product, they added Swagger support recently
      • If you deploy one version of your API V2 and you have another one running V1, to get back to your V1 you need to change the hole thing back to V2
      • Working using the AWS Console is very bad, slow and clanky


My overall conclusion is these 2 products are new comers to the fleet of services that AWS have, Lambda didn’t move much since I started using it, But API Gateway changed a lot to add multiple features, despite some limitation, You should be able to work around them and automate most of the tasks using Gulp or Grunt (We used Node.js).

They integrate with all of AWS services really well, they offer the Felexiblity that we didn’t have with an old school servers or even EC2 instances.


Published on

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *


Full Stack Cloudiologist Mind

Back to Home