I started building websites and apps in 1997, and since then, I've seen web production fragment into hundreds of bits and pieces. If I were learning how to build a web app today, I'd likely specialize within a single framework (such as React, Vue, Angular), remain siloed, and run the risk of never grasping the big picture.

Big picture thinking is where engineers can make the most impact. It's the opportunity to see an existing product, service, or concept, break it down into simple building blocks, reconstruct it to achieve an inspired outcome, and still make it better, cheaper and faster. Big picture thinking is where all technical engineers should perch themselves. It's the only way to remain free from the tyranny of silos.

In 2018, I started migrating my work towards cloud-based architectures, and serverless computing drove me there. I love assembling new teams that do not require data center maintenance. It's solving the holy grail of app development, "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, serverless is driving us there better than any other solution.

Looking back in time, here is all the stuff a web developer was required to manage.

1997

  1. Build my server. I had a Hewlett-Packard Pentium II 233Mhz with 64Mb of RAM.
  2. Learn how to install Apache 1.0 and serve web pages through /var/www.
  3. Learn how to install Personal Home Page Tools.
  4. Learn how to use Macromedia Dreamweaver (yes, we all used Dreamweaver in 1997) to write PHP.
  5. Use IE5.5 to view the HTML.

2004

  1. Work with the systems administrators to manage a data center.
  2. Install, patch, and manage two Apache servers together in what was called "load balancing."
  3. Install, patch, and manage PHP 4.0.
  4. Install, patch, and manage MySQL.
  5. Use BBEdit to write clean PHP and Javascript code.
  6. Create microsites using PHP, Javascript, and Actionscript.

2007

  1. Work with System Administrators to manage the data center, including load balancing.
  2. Use MAMP to simplify the installation of Apache and MySQL.
  3. Learn how to install Ruby on Rails 2.3. Bye, bye, PHP!
  4. Labor through RadRails to get a Ruby app working. Ditch it, then revert to textmate to write clean code.
  5. Store your code on private SVN services like XP Dev.

2011 - Javascript Renaissance

  1. Install NodeJS.
  2. Install MySQL, Postgres or MongoDB using Homebrew
  3. Install ExpressJS web framework.
  4. Deploy your app on nodejitsu
  5. Cloudflare for caching and load.
  6. Store your code on Git-based services like Github.

2011 - Ruby Peak Performance

  1. Spin up AWS Elastic Beanstalk or Heroku for Ruby
  2. That's it!
  3. Store your code on Github or Bitbucket

2016

Now things are starting to fragment.

  1. Spin up an EC2 instance on AWS.
  2. Install Apache or Nginx
  3. Use
    4. MongoDB for non-relational databases.
    5. MySQL for relational databases.
    6. PostgreSQL for relational databases with built-in feature like geo-location.
  4. Use
    4. NodeJS with ExpressJS to develop a web app using Javascript.
    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.
  5. Use
    7. AngularJS to render client-side Javascript.
    9. React to render client-side Javascript done differently.
  6. Docker on AWS for server-side app deployment.
  7. Cloudflare or Elastic Load Balancing for load balancing.
  8. Sublime Text for coding.
  9. Git for storing code.

2018

With serverless computing, things 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. These functions can be parallelized, and you only pay for what you use. The only catch? You inevitably start falling victim to vendor lock-in.

  1. AWS Lambda (with Kenesis) for server-side development.
  2. AWS DynamoDB (no SQL) or Amazon RDS for a relational database.
  3. AWS API Gateway for client-side code to access server-side code.
  4. AWS Route 53 for DNS management.
  5. AWS S3 for storage and deployment.
  6. Elastic Load Balancer for load balancing.
  7. AWS Cloudfront for distributing large files via CDN.
  8. AWS CodeCommit for Git-based storage.
  9. Visual Studio Code or Atom for coding.

A Few More Thoughts on Serverless

Serverless offers infinite potential, but from a management standpoint, there are some things worth understanding beforehand. For starters, let's talk about the economics of serverless.

Here's my best analogy to date.

Consider this power drill.

download

This power drill 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 power drill only does one thing. Similarly, a web server 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 ten screws or 10 million. Sad. 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, economics is 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. Switching back to the power drill analogy, I only spend every time I use the 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 misplan 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 a 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 one that I will likely discuss in a future post.