How Web Development Has Changed
This is my professional journey of what it's been like to code since 1997. To say the least, web production has really fragmented over time. I'm thankful to have started early on because I feel like it was much simpler to grasp coding patterns and web production lifecycles. If I were to start learning how to build a web app today, I probably would have ended up specializing within a single technology, remained within my silo, and possibly never grasped the "big picture".
The other thing you'll notice is that in 2018, I've chosen to migrate towards an all AWS architecture. I've done this by design and the reason is because I want to continue exploring a world where I don't have to manage a data center, a server, a language upgrade or even a framework. I guess I'm trying to solve the holy grail of web production, "How can I just build an app once, test it, get it to work, and leave it alone without having to spend too much time maintaining it?". Although I don't think it's entirely possible, I suspect severless-computing might unlock some interesting clues.
When I was 17, I built my first website and I remember having to learn how to:
- Build my own personal server. I had a Hewlett-Packard Pentium II 233Mhz with 64Mb of RAM.
- Learn how to install Apache 1.0 and serve web pages through
- Learn how to install Personal Home Page Tools.
- Learn how to use Macromedia Dreamweaver (yes, we all used Dreamweaver in 1997) to create a Php file.
- Use Php to render an HTML page.
When I later graduated college and started my first full-time job. The above steps were the same but with bigger words:
- Work with the systems administrators to manage our data center.
- Install, patch and manage two Apache servers together in what was called "load balancing".
- Install, patch and manage PHP 4.0.
- Install, patch and manage MySQL.
In 2007, my workflow changed slightly to include:
- Work with "sys admin's" to manage our data center. They take care of the load balancing.
- Use MAMP to simplify my local versions of Apache and MySQL.
- Learn how to install Ruby on Rails 2.3. Bye bye PHP!
- Fight with RadRails to get a Ruby app working. Ditch it, then revert back to textmate to write clean code.
- Store your code on private cloud-based SVN services like XP Dev.
- Install NodeJS.
- Install MySQL, Postgres or MongoDB using Homebrew
- Install ExpressJS web framework.
- Cloudflare for load balancing.
- Store your code on cloud-based Git services like Github.
2011 - Ruby Peak Performance
I think 2011 was when the entire Ruby ecosystem reached peak performance because you could spin up and deploy a Ruby app within a few clicks:
Now things are starting to fragment. Yes, I've picked up more languages and framework but the only big change is this idea of using a framework not only for server-side development but also client-side development.
- Spin up an EC2 instance on AWS.
- Install Apache or Nginx
4. MongoDB for non-relational databases.
5. MySQL for relational databases.
6. PostgreSQL for relational databases with built-in feature like geo-location.
5. Ruby on Rails to develop a web app using Ruby.
6. Django to develop a web app using Python.
7. Symfony or Zend to develop a web app using PHP.
- Docker on AWS for server-side app deployment.
- Cloudflare or Elastic Load Balancing for load balancing.
- Sublime Text for coding.
- Git for storing code.
With serverless computing, things really start to change. No more data center, no more Operating Systems, no more Apache, no more languages or framework installs. Now it's all about creating tiny, single functions with targeted responsibilities. This functions can be easily parallelized and you only pay for what you use. The only catch? You inevitably start falling victim of vendor lock-in.
- AWS Lambda (with Kenesis) for server-side development.
- AWS DynamoDB (no SQL) or Amazon RDS for a relational database.
- AWS API Gateway for client-side code to access server-side code.
- AWS Route 53 for DNS management.
- AWS S3 for storage and deployment.
- Elastic Load Balancing for load balancing.
- AWS Cloudfront for distributing large files via CDN.
- AWS CodeCommit for Git-based storage.
- Visual Studio Code or Atom for coding.
A Few More Thoughts on Serverless
Serverless offers a lot of potential but from a management standpoint, there are some clear things worth understanding. For starters, it's worth learning the economics of serverless.
I've been working on an analogy for some time and here's the best I've got. It's not perfect so if anyone has something insightful to share, please do.
Consider this powerdrill.
This powerdrill is a tool and it allows me to build whatever I can dream up. This power drill in many ways represents a web technology such as a web server. For the most part, a powerdrill only does one thing. Similarly, a web sever only does one thing; serve client requests.
Now let's suppose I'm working at home and I want to make my bookshelf earthquake proof. I may need to make a trip to Home Depot and purchase a power drill. The cost to buy is ~$100 regardless if I need to drill 10 screws or 10 million. Bummer. In 1997, I as a developer, struggled with the same dilemma. I would either have to pay $2k up-front for a web server or spend $20/mo to rent a shared server through a service like Mediatemple. In this economic model, I may never reach a point where I amortize the cost of buying or renting a server unless I am receiving 2M/monthly requests.
With serverless computing, the economics have been flipped on its head. I do not have to pay for the data center, servers, data transfer, bandwidth, or time spent to install Node, Java, Python, or even Ruby. Instead, I only have to pay every time I serve a web request. Flipping back to the powerdrill analogy, I only pay every time I pull the trigger to drill a hole or remove a screw. At first glance, this sounds great because I no longer have to think about amortizing any up-front costs. Woo Hoo!
On the other hand, this can be potentially hazardous if I mis-plan a project and later realize that my product must serve 2M requests weekly. All of a sudden, I must also consider the financial impact of a DDoS attack or poorly written web app. None of these scenarios are necessarily debilitating but it is a new way to think about the economic model. It's clearly one that I will likely discover more over time.