Serverless Architecture: Is It Actually Possible?
Editor’s Note: A quick read on why our Accommodation team migrated their server infrastructure that handles their operational services dashboard, whose one of the services is to provide properties & business management for their external partners, from being self-managed to third-party-managed and the impact such a move has on the overall usage cost for the team.
How It All Began
Traveloka is one of the leading online travel companies in Southeast Asia, providing a wide range of travel needs in one platform. One of our products, Accommodation, has its own operational services dashboard named TERA (Traveloka Extranet Reservation Access) that provides a platform for external parties such as hotel managers and owners to manage their properties and businesses.
In the middle of this year, we recognized the ever-increasing engineering expenses for running TERA alone was quite costly, and one of the big chunks came from the price of the Amazon EC2 servers. EC2 is amazing. But, we believe that for some services, there should be a more optimized and cost-efficient solution to operate our platform namely the use of EC2 should have been charged based on the number of requests instead of flat pricing. Also, knowing that TERA’s front-end requests per month have been very high that it currently exceeds other internal dashboards in Traveloka, sometimes, we had to over-provision by having other servers to cater to the peak traffic, which then added more expenses to the overall infrastructure cost. With these two facts, our Accommodation Engineering team decided to conduct an experiment using the latest tech trend of serverless architecture, starting in one of our Accommodation internal tools called TERIUS (TERA Internal User Dashboard), which used to be attached inside the TERA website, but it was later detached to be on its own.
Anyway, when we say “serverless”, it does not necessarily mean we don’t need a single server at all. Technically, the servers exist and we still use them for our main TERA website except that we don’t have to manage the servers anymore and instead, we let AWS (Amazon Web Services) takes over the server management for us. There are two goals of using this technique; the first is to reduce our infrastructure and maintenance cost by using the server only on-demand (charges upon usage) such as when a request is being called in contrast to using EC2, where charges are continuously rendered regardless of the absence of usage. By doing so, we hope to reduce our infrastructure and maintenance cost, as well as having the managed servers be able to scale up (or down) in real-time in the event of sudden bursts of traffic without having to add more physical servers on our own.
How We Did It
As you can see in the diagram above, there are two AWS EC2 servers being used to support our TERA platform. Since our goal is to be totally serverless for TERIUS, we’re migrating to a new architecture depicted in the diagram below.
To fully adopt the serverless architecture, we need the help of AWS CloudFront, Lambda@Edge, and S3. If you are not yet familiar, CloudFront is Amazon’s Content Delivery Network (CDN) service that delivers data, apps, and APIs through a globally distributed network of proxy servers that cache contents and is tightly integrated with AWS. Lambda@Edge, on the other hand, is a feature of CloudFront that lets us run code closer to the geographical location of users of the application and thus helps to reduce latency and increase performance. Finally, S3 is Amazon’s object storage service through a web service interface that is widely used for websites, mobile apps, backup, restore, and archive operations. As you can see in the diagram above, CloudFront is being used in the center of the process. First, it checks the cached front-end contents on TERIUS. If the system detects a newer version (a cache miss), the Lambda@Edge will request the latest version from our S3. The S3, in return, will have to respond to CloudFront with the updated version. CloudFront then renews the cache with the last updates. So if anyone makes a request afterward, TERIUS won’t give the users outdated contents.
The diagram above also depicts CloudFront’s ability to write an access log for every request to our TERIUS. The log files are usually sent to our AWS S3 bucket within an hour of the events that appear in the log.
The Benefits and The Downsides of Serverless Architecture
One of the advantages of serverless architecture is that it costs less compared to renting a dedicated server. In our case, we managed to trim down our spending by more than 90% compared to our existing cost with the EC2 server. Another advantage is that we don’t have to maintain our server since AWS is doing it for us. As a result, the latency to load front-end content is also greatly reduced.
Despite having those advantages, using a serverless architecture also has its own drawbacks. First, since there is no server-side rendering, there will be a lack of Search Engine Optimization (SEO) support. However, given that TERIUS by itself is an internal tool, even if it does not have SEO support, this tool can still function properly. Another drawback that we have thought about is that all API calls are initiated from the user’s browser and not from the EC2 server, meaning that there will be authorization and authentication payload along with the call, causing a higher API call latency.
What We Will Do Next
TERIUS is only a small part of TERA and though this experiment has been proven to be impactful enough in providing not only faster access and reduction of the company’s expenses, we also have a short-term goal to implement this serverless architecture approach to other tools as well. If you are up to tackling real-life engineering problems in Traveloka just like the experience I have just shared, take a good look at Traveloka’s careers page! A great opportunity is up for the taking. 👀
