Understanding AWS Server Deployment Properly!
I'll explain it to you more simply and more firmly.
This isn't just a simple AWS ECS & Docker tutorial!
You'll experience the inconveniences of deploying traditional VMs firsthand. This will help you understand the why and learn ECS & Docker properly . 😎
Why does AWS adoption feel so unfamiliar? 😥
Have you ever felt overwhelmed trying to use the AWS cloud? There are so many ways to deploy servers within AWS. And most importantly, each configuration is different. You simply want to deploy your code robustly, cheaply, securely, and quickly. But there are so many unfamiliar settings.
- VPC?! What's a Subnet anyway?
- Availabiliy Zone?
- What about security groups... inbound? Shouldn't this just allow all IPs?
- Wouldn't it be safe to put environment variables here?
- What the heck is IAM?! Why not just grant AdminAccess?
- What else is a load balancer? Setting up listener rules and target groups...
Haven't you ever asked yourself this question after barely distributing it?
- How do you automate deployment? CI/CD? What is CI and what is CD?
- They say you can auto scale using the cloud, but how do you do that?
- What exactly is the difference between a virtual machine and a container?
- Why use containers? And what is Container Orchestration?
- Kubernetes vs Elastic Container Service (AWS ECS), I don't know what's the difference.
- I understand Docker, but what is Docker-compose? Do I need to know this too?
- Why not just use an "easy" cloud like Fly.io, Vercel, or Heroku? Sure, it might be a bit more expensive, but wouldn't it save me a lot of time?
I think most of you have either given up on adopting AWS because you wanted to focus on service development, or you've just haphazardly set things up to make it work.
The problem is that if done wrong, you could be exposed to costly and critical security vulnerabilities . And despite the ease of building highly available servers, you might not be able to take advantage of these cloud benefits.
Highly available servers are crucial, especially as your service grows. Even if a natural disaster completely shuts down your data center, you can still maintain service!
I hope that through this lecture, many people will be able to properly understand AWS and use it easily.
Originally, I planned to create a course solely covering Docker and AWS ECS. However, I felt that it might be too overwhelming and difficult to understand why these technologies were developed. Therefore, to facilitate understanding, I divided the course into two parts .
The first part covered "A robust deployment method using traditional virtual servers."
I've tried to explain this as simply as possible, using Lightsail instead of EC2. This process covers important concepts related to server deployment.
- Horizontal Scaling vs. Vertical Scaling
- Stateless vs. Statefull
- High Availability & Availability Zones
- Private Network & Firewall
- Load balancer & HTTPS
- SSH tunneling
- Deployment Automation: Pull Request-based CI/CD for Teams & CI/CD for Solo Developers
- Handling the Test & Build Process for CI
- Managing environment variables safely
Next, we'll revisit the shortcomings of virtual servers and explore how container technology can improve these issues . In the final part, we'll delve into the fundamentals of Docker containers and focus on AWS Elastic Container Service (ECS), a leading container orchestration technology.
Below are some of the materials used in the lecture :)
Q&A 🙋🏻♂️
Q. Should I learn ECS instead of Kubernetes?
I've been using Kubernetes for about five years. I introduced it to my company directly when I implemented MSA. Even then, I was debating between K8S and ECS. The open source aspect was appealing, so I chose Kubernetes at the time.
After much deliberation, I decided to use ECS for my new company. While ECS isn't open source, I found it easier to use. And then I realized that the vendor-lock issue was actually much smaller than I'd anticipated. Regardless of whether you use Kubernetes or ECS, you're using the same Docker containers. All code is written in the same Docker environment. On AWS, ECS was attractive because it was slightly cheaper and had slightly easier DX. Furthermore, both Kubernetes and ECS are container orchestration technologies. In other words, if you excel at one, switching to the other is surprisingly easy.
Q. What do you think about serverless systems like AWS Lambda?
It's certainly a good technology, and I use it in my image upload tutorial . However, I don't think it's suitable for general servers unless there are special circumstances. While it may seem very cheap, it quickly becomes significantly more expensive as traffic increases. It's also highly susceptible to vendor lock-in, making it relatively difficult to migrate to a general server later.
First of all, because Lambda is a short-lived server, it's difficult to create a WebSocket server. Therefore, Vercel, which uses AWS Lambda, states in its documentation that it doesn't support WebSockets and recommends using an external service. There may also be additional issues to consider, such as managing a database connection pool.
Q. Do I need to know Node.js?
No! In this course, we'll initially build a simple backend (Express app) using Node.js. However, this is purely for the purpose of providing code for deployment. It's also intended to add dummy test code and build processes for building a CI pipeline. All the Node.js code generated here is provided, so you can skip this section.
Q. Do you also learn about deploying stateful services, such as databases or message queues like Kafka, and managing servers?
Stateful services like databases and message queues are more complex and require more management than you might think. This course focuses on deploying your own developed services (backend, ETL pipeline, SSR server), rather than complex external services like databases.
While the material covered here is certainly relevant for deploying complex services like databases, if you're looking to deploy your own databases, you'll need to study more. For stateful services like databases and queues (Kafka), managed services are recommended! Most managed services are supported by AWS itself, while others are managed clouds offered by individual service providers.
For example, for Kafka, there's Confluent or AWS MSK, and for MongoDB, there's Atlas or AWS DocumentDB. These managed services exist for each service in the first place because server management for these services is more complex than you might think! Therefore, even if you're taking this course, I highly recommend using managed services for these stateful services!
