I honestly want to publish my university work in here because… why not? I worked on these projects. That’s SWEAT, BLOOD, and TEARS.
When you spend weeks staring at a black terminal screen, fixing invisible configuration bugs at 2 AM, and getting obscure Linux error messages thrown in your face, you don’t just want to hand it in for a grade and let it gather digital dust in a folder on your desktop. You want to show that you built something real.
Now, don’t worry. I am not going to dump my entire university project report word-for-word right here. Nobody wants to read 30 pages of dense academic citations and formal university jargon.
You might be wondering: why am I writing this post then?
Well, I just want to share my honest thoughts about cloud computing. Not entirely about the entire multi-billion-dollar industry as a whole, but specifically about one of the main projects I completed during my cloud computing subject at university.
The Expectation vs. The Brutal Reality
Finishing this project was a huge reality check for me.
On paper—and in lecture slides—cloud computing sounds incredibly clean, modern, and almost effortless. Professors love to draw neat little diagrams showing a user clicking a button, a virtual machine springing to life in the ether, and a fully functional application serving millions of global users seamlessly. It sounds so organized: set up a WordPress site on both Google Cloud Platform (GCP) and Amazon Web Services (AWS), test out a couple of virtual machines, install a standard LAMP stack (Linux, Apache, MariaDB/MySQL, PHP), and call it a day. Simple, right?
Actually doing it step by step was a completely different story.
When you sit down to do it yourself, you realize that the slides leave out the part where a single missing semicolon in a configuration file crashes your web server, or where a missing file permission stops your database from talking to your web page. But looking back, I learned a lot more from those infuriating little hiccups than I ever did from just passively reading powerpoint decks during lectures.
Here’s my honest take on how it all actually went down.
The AWS vs. GCP Battle: What It Actually Felt Like
Doing the exact same assignment on two competing cloud giants back-to-back gives you a front-row seat to how different their design philosophies really are.
┌──────────────────────────────────────────┐
│ The Multi-Cloud Battle │
└────────────────────┬─────────────────────┘
│
┌──────────────────────────┴──────────────────────────┐
▼ ▼
┌───────────────────────┐ ┌───────────────────────┐
│ Google Cloud Platform │ │ Amazon Web Services │
├───────────────────────┤ ├───────────────────────┤
│ • $300 Free Credits │ │ • Native Local Terminal│
│ • Browser-based SSH │ │ Access via SSH │
│ • Global Network Tags │ │ • Stateful Security │
│ • Lower Base Compute │ │ Group Firewalls │
│ Costing Structure │ │ • `.pem` Key Security │
└───────────────────────┘ └───────────────────────┘
Round 1: Google Cloud Platform (GCP)
When I started with GCP, I’ll admit the layout felt a bit confusing.
The console is massive. Google gives you endless sidebars, dropdowns, and sub-menus for everything from AI pipelines to global networking. Just finding where to launch a simple Compute Engine Virtual Machine took a bit of clicking around.
When it came time to log into the machine, Google’s default connection method is a browser-based SSH window. You click a button in your web browser, and a new window pops up with a command line. To be honest, it felt weirdly roundabout. It felt like I was operating a remote server through a middleman website rather than holding a direct line to the machine.
On top of that, trying to get all the database permissions, web configs, and file directories straight inside GCP took a lot of trial and error. Getting Apache to recognize my WordPress folder instead of serving Google’s default landing page meant diving deep into /etc/apache2/sites-available/, editing files with nano, and constantly reloading services. Navigating through all those options in Google Cloud definitely made me realize just how much manual setup goes into configuring even a “simple” virtual machine.
Round 2: Amazon Web Services (AWS)
Then I moved on to AWS, and honestly, the workflow just clicked much better for me.
Instead of forcing me into a browser-based terminal, AWS forces you to deal with real-world security right away. During the creation of my EC2 instance, AWS handed me a private key file—a .pem file—and basically said: “Keep this safe, because without it, you aren’t getting into your server.”
Being able to open Git Bash directly on my own laptop, lock down my key permissions using Linux security commands:
Bash
cd /mnt/c/users/acb/downloadschmod 400 my-aws-key.pem
…and then SSH straight into the instance using its public IP address (ssh -i my-aws-key.pem ec2-user@54.206.89.240) felt like how real developers actually work. It made me feel like an actual systems engineer running commands on a server sitting in a data center thousands of miles away.
Setting up AWS Security Groups also felt much more intuitive. An AWS Security Group acts like a stateful firewall wrapped directly around your virtual server. Need web traffic? Add an inbound rule for Port 80 (HTTP) and Port 443 (HTTPS). Need command line access? Add Port 22 (SSH). It felt direct, logical, and easy to visualize compared to fighting with GCP’s broader, network-wide firewall settings.
The Financial Plot Twist
That being said, GCP definitely wins on budget and peace of mind.
Google throws $300 worth of free credits at you the moment you sign up as a new user. Having that $300 buffer made me way less anxious about accidentally clicking the wrong machine size or running up a surprise bill while testing things out.
AWS gives you 12 months on their Free Tier, which sounds great on paper. But AWS’s free tier is strictly limited to very small instances (like t2.micro or t3.micro). Every time you configure something in AWS, there’s this tiny, lingering paranoia in the back of your mind: Did I attach an extra disk drive? Did I forget to turn off a load balancer? Am I about to get hit with a random $50 credit card charge at the end of the month?
What I Struggled With (And What Actually Worked)
Building a full LAMP stack manually isn’t just about clicking “Launch.” It means installing every single software component yourself, linking them together, and making sure the operating system permissions don’t block them from talking to each other.
The Hands-On LAMP Stack Architecture
┌───────────────────────────────────┐
│ Ubuntu Linux OS (Compute) │
│ │
│ ┌───────────────────────────┐ │
│ │ Apache Web Server │ │
│ └─────────────┬─────────────┘ │
│ │ │
│ ┌─────────────▼─────────────┐ │
│ │ PHP Script Engine │ │
│ └─────────────┬─────────────┘ │
│ │ │
│ ┌─────────────▼─────────────┐ │
│ │ MariaDB/MySQL Database │ │
│ └─────────────┬─────────────┘ │
│ │ │
│ ┌─────────────▼─────────────┐ │
│ │ WordPress Application │ │
│ └───────────────────────────┘ │
└───────────────────────────────────┘
1. The Nightmare of Commands Line-by-Line
Copy-pasting and typing out commands like sudo apt update, installing Apache, setting up MariaDB, and tweaking wp-config.php files manually was tedious beyond belief.
Bash
# Updating system repositories and upgrading installed packagessudo apt update && sudo apt upgrade -y# Installing the core web server, database, and PHP runtimessudo apt install apache2 mariadb-server mariadb-client php libapache2-mod-php php-mysql -y
When you are manually installing five or six different software packages, one small typo can break your entire chain. At one point, I spent over an hour trying to figure out why WordPress couldn’t connect to my database. It turned out I had made a tiny mistake in my SQL privilege commands while granting permissions to my database user.
In another instance, Apache kept throwing generic 500 Internal Server Error messages because the ownership of the /var/www/wordpress directory was assigned to my personal admin user instead of the web server’s native execution user (www-data).
Fixing those mistakes meant digging through log files, running systemctl status apache2, and testing commands one by one. But as annoying as it was at the time, troubleshooting those Apache and database errors forced me to actually understand what each command was doing instead of just blindly copy-pasting code from tutorials.
2. The Moment It Finally Worked
After hours of command-line wrestling, directory reconfigurations, and security group adjustments, came the final test: opening a web browser, pasting in the external IP address, and pressing Enter.
GCP Public Endpoint: http://34.125.87.46
AWS Public Endpoint: http://54.206.89.240
Hitting those public IPv4 addresses in my browser and seeing the clean, colorful, live WordPress installation wizard page pop up was super satisfying.
┌────────────────────────────────────────────────────────────────────────┐│ WordPress Installation │├────────────────────────────────────────────────────────────────────────┤│ ││ Welcome to the simple WordPress installation process! ││ ││ Site Title: [ My Cloud WordPress Site ] ││ Username: [ admin ] ││ Password: [ ****************** ] ││ Your Email: [ student@torrens.edu.au ] ││ ││ [ Install WordPress ] ││ │└────────────────────────────────────────────────────────────────────────┘
Seeing that screen meant my virtual machine was alive, Apache was listening on Port 80, PHP was processing code, and MariaDB was ready to accept data. It instantly made all the terminal headaches and permission errors completely worth it.
My Main Takeaways
Looking back at the entire experience, three big lessons stood out that completely changed how I view software engineering and cloud infrastructure:
Lesson 1: Preparation is Everything
Spinning up cloud instances without a clear plan wastes time and money. When you jump straight into the console without planning your IP subnets, file paths, or security rules, you end up making messy mistakes that take twice as long to undo. Next time, I’m mapping out my network rules, database credentials, and directory structures on paper before I even touch the launch button.
Lesson 2: Doing This Manually is for Learning, Not Production
Sitting there running 20 different bash commands to set up a basic server taught me the fundamentals, but nobody should ever be doing this manually in a real job.
If a company needs 100 web servers, no engineer is going to SSH into 100 individual machines and type apt install apache2 by hand. Moving forward, I want to learn Infrastructure as Code (IaC) tools like Terraform or write shell scripts so I can deploy an entire configured cloud stack automatically with a single terminal command.
Lesson 3: Single Servers are a Single Point of Failure
Sticking the database, PHP engine, and web server all onto one single virtual machine works fine for a university assignment, but it is super risky for real-world applications. If that single server runs out of memory or crashes, your entire website goes offline, and your database goes down with it.
My next goal is to practice splitting things up—using managed, dedicated cloud database services like AWS RDS or Google Cloud SQL for the database layer, while letting the virtual machine focus entirely on running the web code.
The Final Verdict
At the end of the day, AWS felt more natural and developer-friendly to use, but GCP is way friendlier on the wallet for experimenting and testing out quick ideas.
Getting both platforms up and running, running into real errors, and fixing them myself gave me a massive confidence boost with cloud infrastructure. It proved to me that cloud computing isn’t just a buzzword on a presentation slide—it’s a practical skill that you build line-by-line in the terminal.
That’s all folks! Thanks for reading about my cloud journey.
Leave a Reply