Cloud

How Not to Build an Application in the Cloud: Common Mistakes to Avoid

How Not To Build an Application in the Cloud

Cloud computing has revolutionized the ability of small and medium-sized businesses (SMBs) to create custom applications that meet their unique needs. With platforms like AWS, the barriers to entry for custom development have never been lower. However, as accessible as cloud technology is, missteps in implementation can lead to costly and inefficient solutions.

The Key Players

  • The SMB Owner: our protagonist envisioned a simple, custom application tailored to their business needs. They aimed to develop it at a lower cost than a commercial off-the-shelf subscription-based solution.
  • The Development Team: an outsourced application development entity skilled in creating business logic, building databases, and designing functional frontends with authentication.
  • The Managed Service Provider (MSP): responsible for the SMB Owner’s IT infrastructure, the MSP managed the AWS account where the application was hosted. They may have also recommended the development team.

The Application Overview

The SMB Owner, MSP, and Dev Team collaborated to define a basic inventory and order management application. Its architecture comprised three logical tiers:

  1. Web Frontend: the user interface.
  2. Business Logic Tier: processes user requests.
  3. Database Tier: stores application data.

The application was hosted on a Microsoft Server EC2 instance on AWS, aligning with the developers’ expertise.

The Implementation and Its Flaws

The Dev Team chose to implement all three tiers — web frontend, business logic, and database — on a single EC2 instance. This setup incurred a monthly cost exceeding $250 and had numerous flaws:

  1. Encapsulation of All Tiers: all components were hosted in one EC2 instance, creating a single point of failure.
  2. Lack of Scalability: horizontal scaling was impossible, limiting performance optimization.
  3. Single Availability Zone (AZ): the application’s availability was dependent on a single AWS AZ.
  4. Public Internet Exposure: all tiers, including sensitive database components, were accessible directly from the public internet.
  5. Dynamic Public IP Address: the application’s GoDaddy-hosted URL pointed to an IP address that could change whenever the EC2 instance was restarted.
  6. No Automated Backups: the lack of snapshots meant that a failure could result in data loss and a complete restart of development.

Why These Implementation Issues Matter

  1. Performance Limitations: without horizontal scaling, the application risked overload during simultaneous user access. The only workaround was vertical scaling, which increased costs significantly.
  2. Availability Risks: hosting in a single AZ made the application vulnerable to downtime if the AZ experienced issues.
  3. Security Concerns: direct exposure to the public internet increased the risk of cyberattacks. Isolating tiers in private subnets could have mitigated this.
  4. Configuration Challenges: the dynamic IP address required manual updates to maintain URL functionality.
  5. Data Loss Risks: without automated snapshots, recovering from an instance failure was nearly impossible.

A Better Solution: Decoupling and Best Practices

A more robust architecture would involve decoupling the application tiers:

  1. Web Frontend: host in its own EC2 instance or in an AWS S3 bucket for cost efficiency.
  2. Business Logic: deploy in a separate EC2 instance within a private subnet.
  3. Database: use a dedicated EC2 instance or AWS RDS service for better performance and automated backups.

Key Improvements:

  • Autoscaling Groups: separate EC2 instances for each tier could be placed in autoscaling groups to dynamically manage demand.
  • Multi-AZ Deployment: distribute resources across multiple AZs to ensure high availability.
  • Enhanced Security: use private subnets for the logic and database tiers, and apply security group rules to minimize the attack surface.
  • Elastic IP Addressing: associate an Elastic IP with the EC2 instance to ensure URL consistency.
  • Automated Backups: configure regular snapshots to prevent data loss and simplify recovery.

The Backstory and Lessons Learned

This story is based on a real-world consultation. The client was transitioning to a new application and needed to keep the current one running during the migration. Gart Solutions‘ role was to optimize costs and ensure stability for this interim period. We implemented an EC2 snapshot, created an Elastic IP for the instance, and updated the GoDaddy URL mapping.

However, the engagement left us reflecting on how the solution could have been architected differently from the start.

Conclusion

This case illustrates the pitfalls of poor cloud architecture and highlights how thoughtful design can yield cost-effective, scalable, and resilient applications. While the cloud provides many tools and approaches, careful planning and adherence to best practices are essential for success.

What are your thoughts on this story? Share your experiences or insights into building better cloud applications.

FAQ

1. Why is it important to decouple application tiers?

Decoupling application tiers improves scalability, security, and resilience. Each tier — frontend, logic, and database — can be managed, scaled, and secured independently, ensuring better performance and reducing the risk of a single point of failure.

2. What are the risks of hosting all tiers on a single EC2 instance?

Hosting all tiers on a single EC2 instance creates several risks: - Single Point of Failure: If the instance fails, the entire application goes offline. - Scalability Issues: It prevents horizontal scaling, leading to performance bottlenecks. - Security Vulnerabilities: Exposing all components to the public internet increases the risk of attacks. - Data Loss Risks: Without backups or redundancy, data may be irretrievably lost in the event of failure.

3. What’s the benefit of deploying resources across multiple Availability Zones (AZs)?

Using multiple AZs ensures high availability. If one AZ experiences downtime, the application can continue operating from another, minimizing disruptions and enhancing reliability.

4. How does autoscaling improve performance?

Autoscaling dynamically adjusts the number of running instances based on demand. This ensures sufficient resources during peak times and reduces costs during periods of low activity.

5. Why is an Elastic IP address better than a dynamic public IP?

An Elastic IP address remains consistent even when an EC2 instance is stopped and restarted. This ensures uninterrupted application access and avoids manual updates to URLs.

6. What role does AWS RDS play in database management?

AWS RDS provides managed database services with built-in features like automated backups, failover support, and scaling. It simplifies database management while improving reliability and performance.

8. Is it more expensive to use decoupled architecture on AWS?

Initially, decoupled architecture may appear costlier due to the need for multiple resources. However, the long-term benefits of scalability, reliability, and security outweigh these upfront costs. Proper configuration and autoscaling can also optimize expenses.

9. What are the biggest mistakes to avoid when designing an AWS-hosted application?

Some common mistakes include: - Hosting all tiers on a single EC2 instance. - Failing to implement backups or disaster recovery. - Neglecting security best practices, such as using private subnets. - Overlooking the need for scalability and high availability.

10. What steps can I take to optimize costs for a temporary AWS application?

- Schedule the EC2 instance to start and stop during specific hours. - Use snapshots to back up data and configurations. - Implement an Elastic IP for consistent access during the application lifecycle.
arrow arrow

Thank you
for contacting us!

Please, check your email

arrow arrow

Thank you

You've been subscribed

We use cookies to enhance your browsing experience. By clicking "Accept," you consent to the use of cookies. To learn more, read our Privacy Policy