Designing cloud-native applications in AWS. Part 1
This is a start of a series where I we will design a serverless applications in AWS that utilize ChatGPT and Telegram. Part 1/N.
In this comprehensive series of posts, we will explore the complete process of designing, developing, and deploying a cloud-native application. We will adopt an iterative approach, starting with a minimal viable product and gradually adding complexity.
Application Idea
Given the current popularity of ChatGPT, I couldn't resist delving into this fascinating topic. As an exemplar of a cloud-native serverless application, our focus will be on developing a Telegram bot capable of generating short stories based on predefined themes, with user-defined characters and locations. Each story will consist of a title, a text body of up to 1000 words, and relevant tags. Additionally, the bot will support multiple languages. To showcase our stories to the world, we will create a simple website.
You can check the bot at https://t.me/AIGPTStoriesBot
The website is available at https://robostoryz.com
And you can check the latest code at Github: https://github.com/MrZoidberg/ai_story (which will continue to evolve)
Requirements
Let's outline the functional and non-functional requirements for our system:
The system should be capable of generating AI-driven short stories of up to 1000 words.
The system should include a pre-defined list of supported story themes.
The system should allow users to specify story characters and locations.
The AI model should generate story titles, text, and associated tags.
The system should be extensible to support multiple languages.
Telegram should serve as the platform for user interaction.
The system should have a read-only website that collects and displays all the stories.
The system architecture should aim to minimize the total cost of ownership (TCO).
The system should be scalable, supporting a user base ranging from dozens to tens of thousands of daily active users (DAU).
This concise list of requirements encompasses our major features while also imposing important constraints on the system.
Design Constraints
Let's define some key design constraints:
CON-1: AWS Cloud should be used (that’s one of the goals of my post series).
CON-2: Back-end services should use the .NET framework (I have some cool post ideas for .NET).
CON-3: The front-end website should use Next.js (I’m not a front-end guy, so this is just a framework that I know a little).
CON-4: Github should be used as a code repository and as CI/CD system.
CON-5: ChatGPT should be used as an AI system.
Now, if you have experience working with the ChatGPT API, you might have noticed a limitation—it can be slow. Unless you're a Plus subscriber, API calls with a response containing 1000 tokens (roughly equivalent to 1000 English words) take around 20-30 seconds, and even longer for non-English requests. Consequently, we cannot simply integrate ChatGPT directly into our Telegram bot. In our system, the story generation request and response must be asynchronous operations.
Now, let's define the use cases, which, in our system, are fairly straightforward.
Cloud-Native Applications
One crucial topic deserving of discussion is the concept of cloud-native applications. This term remains somewhat elusive, lacking a concrete definition. You can find a lot of various definitions and discussions on that topic.
However, I came across a particularly insightful definition:
Cloud Native is structuring teams, culture and technology to utilize automation and architectures to manage complexity and unlock velocity.
Here my goal defines something we can stick over these blog post series. While the business aspects of a cloud-native approach are undeniably important (though not the focus here), we will instead establish common criteria for cloud-native architectures:
Immutable infrastructure.
Loosely coupled, independent software components.
APIs as a means of communication (we will explore why AWS SQS is still considered an API in a future post).
Reliable infrastructure and applications.
Efficient usage of resources.
Isolation of components.
Continuous integration/delivery.
It's worth noting that cloud-native architecture does not solely pertain to running applications in the public cloud (e.g., AWS, Azure, GCP). These business, development, and architectural practices can be implemented with on-premises infrastructure, hybrid-cloud architectures, or in a public cloud environment.
Additionally, it's essential to distinguish cloud-native applications from cloud-ready or cloud-enabled applications, which are legacy-style applications capable of running in the cloud without harnessing their full potential. You can read more on what Amazon thinks on this topic here.
That wraps up today's post. In the next post, we will describe the use cases for our application and define the architecture vision.
Please subscribe to my substack to receive notifications of new blog posts.