How Not to Develop a Cloud Application: A Cautionary Tale

Introduction

As a strong advocate for small and medium businesses (SMBs) building cloud applications, I often emphasize the accessibility of cloud platforms like AWS for creating cost-effective, custom solutions. However, this story serves as a warning about common pitfalls when implementing such applications.

The Key Players

  • SMB Owner: The protagonist, an SMB owner with a straightforward idea for a custom application tailored to their business needs, seeking a cost-effective alternative to subscription-based software.
  • Development Team (Dev Team): A contracted team skilled in coding, database creation, and functional frontend development, but lacking expertise in cloud architecture.
  • Managed Service Provider (MSP): The outsourced IT team managing the SMB’s network and AWS account. They may have recommended the Dev Team to the SMB owner.

The Application Concept

The application was envisioned as a simple inventory and order accounting system built on a three-tier architecture:

  1. Web Frontend
  2. Business Logic Tier
  3. Database Tier

After discussions, the decision was made to host the application on a Microsoft Server EC2 instance in AWS, the platform most familiar to the developers.

The Implementation

Cloud architecture offers multiple implementation strategies depending on trade-offs like cost, scalability, and disaster recovery needs. Unfortunately, the approach taken by the Dev Team was far from ideal.

Delivered Solution

The Dev Team delivered the entire application on a single Microsoft Server EC2 instance with:

  • A single Availability Zone (AZ)
  • A public IP mapped to a GoDaddy-hosted URL
  • A large instance size with high storage volume, costing over $250 monthly

While functional, this setup was riddled with flaws.

Problems with the Implementation

  1. Monolithic Design: All three tiers were combined into a single EC2 instance, limiting scalability and flexibility.
  2. No Horizontal Scalability: The system couldn’t handle increased user demand, relying solely on vertical scaling by upgrading the instance.
  3. Single AZ Deployment: This created a single point of failure, risking downtime if the AZ went offline.
  4. Security Risks: Exposing all tiers directly to the public internet increased the attack surface.
  5. Dynamic IP Address: The GoDaddy URL mapped to a public IP, which could change upon instance restart, breaking access to the application.
  6. Lack of Backups: No automated snapshots meant data and configurations could be irretrievably lost if the instance failed.

Why These Issues Matter

These flaws led to poor scalability, vulnerability to failures, and heightened security risks. Additionally:

  • Without decoupled tiers, implementing autoscaling and high availability was impossible.
  • A dynamic IP for the URL made the system unreliable.
  • Missing automated backups jeopardized data recovery and continuity.

A Better Approach

A well-architected solution would decouple the tiers:

  • Web Frontend: Hosted on its own EC2 instance or in an S3 bucket.
  • Application Logic: Deployed in its own EC2 instance.
  • Database: Hosted in a separate EC2 instance or managed through AWS RDS.

This design would enable:

  • Improved Security: Logic and database tiers isolated in private subnets with security groups.
  • Scalability: Autoscaling groups for web and application logic tiers to handle demand fluctuations.
  • High Availability: Deployment across multiple AZs for better resilience.
  • Reliability: Elastic Load Balancers for user access, and automated backups for data recovery.

Real-World Context

In this real-life scenario, the SMB client was transitioning to a new solution and only needed the existing application for occasional data migration. My role was to reduce costs by scheduling instance start and stop times, creating snapshots, and using an Elastic IP to stabilize the URL mapping.

Conclusion

This case illustrates the importance of thoughtful cloud architecture. Decoupling application components, implementing autoscaling, and securing resources are key to creating cost-effective, scalable, and resilient solutions. While there are many ways to design cloud applications, this example highlights what to avoid. Share your thoughts on additional considerations for cloud architecture!

Connect on: Ig:-@coderjourneys

Support us by buying me a coffee ☕

Do share your valuable opinion, I appreciate your honest feedback!

connect me: coderjourneys.com

If you like this article don’t forget to share

Banner Content

0 Comments

Leave a Comment