My professional journey of what it's been like to code since 1997.
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.
Build my 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 /var/www.
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.
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.
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.
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.