Cost-Efficiency and Cloud-Native Applications: An Overview

In the dynamic realm of cloud deployment, the cost-effectiveness of each transaction is a crucial factor. Leveraging cloud services and associated cost metrics effectively can lead to optimal resource utilization. In this article, we’ll delve into the world of cost-driven cloud-native applications, using Amazon Web Services (AWS) as our prime example due to its pioneering status and current leadership in the cloud industry. It’s worth noting that similar services are offered by other providers such as Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud (OCI), IBM Cloud, and more.

In this post, we’ll provide an extensive view of a cost-driven and cloud-native full-stack application. The showcase application, named BlogQ-Editor (BqEditor), serves as a blog editing system, designed to serve as a real world example, workshop template, and featured content on TechEule.com. Developed using Java, Eclipse MicroProfile 6.0, TypeScript, Redux (Redux-Toolkit), Lit, and Bulma.io.

It finds its home in the AWS Cloud through the AWS Cloud Development Kit (CDK), embracing the concept of Infrastructure as Code (IaC). For those interested, the source code is hosted on GitHub at github.com/techeule/techeule-blog-quarkus.

Expect upcoming articles dedicated to delving deeper into the application’s structural intricacies, its source code (both front-end and back-end), deployment specifics using AWS CDK, CI/CD setup, and an exploration of the AWS services harmonized within this application. Keep an eye out for the continuation of the BlogQ series right here.

Application Architecture

BqEditor stands as a state-of-the-art application, sporting a Single Page Application (SPA) in the front-end, coupled with a RESTful Web API in the back-end. All data is conveniently stored in an Amazon DynamoDB table.

Deployment Setup

BlogQ-Editor Deployment Setup
BlogQ-Editor Deployment Setup

Backend

At its core, the backend encompasses a web API dedicated to managing blog posts. This segment is constructed using Java 17, Eclipse MicroProfile 6.0, and Quarkus.io version 3.x. The backend can be seamlessly deployed as an AWS Lambda, made accessible via Amazon API Gateway with a customized and easily memorable domain name. DynamoDB serves as the cornerstone of the application’s data storage. Furthermore, the backend’s Infrastructure as Code (IaC) source code can be found within the repository’s cdk maven submodule. The backend code is organized into three distinct Maven modules: blogq-engine, blogq-app, and blogq-backend.

Why using AWS Lambda for the backend?

Contrary to the notion that serverless functions can’t effectively manage multiple endpoints, BqEditor’s backend handles four distinct web endpoints. With Quarkus providing seamless AWS Lambda support, you can develop your application without any intricate AWS-specific configurations. A couple of Maven dependencies and Quarkus-Maven build integration are all that’s needed for AWS Lambda compatibility.

BqEditor Swagger-UI
BqEditor Swagger-UI

In terms of cost, the backend operation stays within the USD 15 per month range. The AWS Lambda component, in particular, costs approximately USD 5.73, potentially even less with AWS savings plans factored in. The calculation is achieved through AWS’s pricing calculator, enabling proactive cost estimates.

I have made the following assumptions:
  • USD 5.73 for AWS Lambda:
    • Architecture: ARM CPU,
    • RAM: 2 GB,
    • Number of requests: 2,000,000 per month, and
    • Amount of ephemeral storage allocated: 512 MB
  • USD 5.13 for Amazon DynamoDB:
    • Table class: Standard,
    • Average item size (all attributes): 64 KB,
    • Data storage size: 1 GB,
    • 10,000 on-demand writes (90% Standard writes and 10% Transactional writes), and 1,000,000 on-demand reads (100% Strongly consistent reads)
  • USD 3.00 for Amazon API Gateway:
    • HTTP API requests: 3,000,000 per month, and
    • Average size of each request: 400 KB

Realistically, costs might fall below USD 8 per month if the application experiences limited usage. For periods when the application remains dormant and inactive, AWS Lambda charges are non-existent. Additionally, the expenses for Amazon API Gateway and Amazon DynamoDB Table usage remain very low.

If I were to opt for an alternative compute solution from AWS (e.g. ECS, EC2, or EKS, etc), the costs would be substantially higher, even during periods of application inactivity.

Front-End

BqEditor’s user interface resides within the user’s web browser as a Single Page Application (SPA). TypeScript, Lit, and Redux/Redux-Toolkit are the driving forces behind its creation, while styling is achieved through CSS and Bulma.io. The front-end’s source code can be found in the blogq-web-ui folder within the same repository.

Front-End Deployment

Front-end artifacts, essentially static text and media files, find their home in an Amazon S3 bucket. However, there’s a twist. Amazon S3 website hosting doesn’t presently offer HTTPS endpoints. For HTTPS via a custom domain name, Amazon CloudFront (CDN) steps in. CloudFront serves files from Amazon S3 to the internet, complete with a custom domain name and secure HTTPS protocol. Notably, CloudFront provides advanced security measures, allowing access restriction through diverse rules.

One hurdle presented by Amazon CloudFront is caching. Whenever a new front-end version is deployed, file names might remain unchanged. Consequently, the CloudFront distribution is purged post-deployment, ensuring that the subsequent request fetches the updated files from the Amazon S3 bucket.

In terms of cost, the front-end operation stays within the USD 2.94 per month range. The Amazon CloudFront component, in particular, costs approximately USD 2.38. The calculation is achieved through AWS’s pricing calculator, enabling proactive cost estimates.

I have made the following assumptions:
  • USD 2.38 for Amazon CloudFront:
    • (United States) Data transfer out to internet: 1 GB,
    • (United States) Data transfer out to origin: 0 GB per month,
    • (United States) Number of requests (HTTPS): 1,000,000 per month,
    • (Europe) Data transfer out to internet: 1 GB,
    • (Europe) Data transfer out to origin: 0 GB per month, and
    • (Europe) Number of requests (HTTPS): 1,000,000 per month
  • USD 0.56 for Amazon S3:
    • S3 Standard,
    • S3 Standard storage: 1 GB*,
    • PUT, COPY, POST, LIST requests to S3 Standard: 100,000,
    • GET, SELECT, and all other requests from S3 Standard: 100,000,
    • Data returned by S3 Select: 1 GB per month*,
    • Data transfer Inbound: All other regions: 1 GB per month*, and
    • Data transfer Outbound: Amazon CloudFront: 1 GB per month*
*) the smallest unit is GB, and smallest amount is 1.
Deploying the front-end using ECS, EKS, or EC2 along with an AWS ALB (Amazon Application Load Balancer) would result in significantly higher costs, spanning multiple orders of magnitude.

Security

Security stands paramount in BqEditor, achieved through JWT (OpenID Connect/OAuth2) implementation.

Conclusion

In conclusion, this exploration has illuminated the intricacies of cost-efficient cloud-native applications. By navigating the landscape of AWS, we’ve dissected the architecture, deployment nuances, and security aspects of the BlogQ-Editor. The journey continues with in-depth insights into each of these components, providing an opportunity for deeper engagement with cloud-native application development.

As always, while the setup illustrated above isn’t universally applicable, it’s well-suited for scenarios where the backend doesn’t require continuous usage and the request volume remains manageable. It’s advised to explore and compare various compute solutions, leveraging AWS’s pricing calculator. This configuration is particularly effective for business applications operating during working hours or on a set schedule. The integration of AWS services, streamlined deployment processes, and careful cost analysis make this framework an attractive option for businesses seeking to enhance their cloud operations.

So, whether you’re embarking on a similar venture or charting a different cloud-native course, the principles shared here can serve as guiding lights in your pursuit of efficient and cost-effective application deployments. Stay tuned for more comprehensive explorations and insights as we delve deeper into the world of cloud-native architecture and development on TechEule.com.

Expect upcoming articles dedicated to delving deeper into the application’s structural intricacies, its source code (both front-end and back-end), deployment specifics using AWS CDK, CI/CD setup, and an exploration of the AWS services harmonized within this application. Keep an eye out for the continuation of the BlogQ series right here.

Resources: