It's now been over 14 years since AWS launched the Simple Storage Service (S3), Simple Queue Service (SQS) and Elastic Compute Cloud (EC2). These three services ushered in the modern era of cloud as a set of utility services that developers can build on top of.
Since then, we've seen attempts to redefine cloud in terms of Platform as a Service (PaaS) starting with Heroku and Google App Engine (GAE) in 2008. PaaS has been through several iterations, but Kubernetes is currently the most popular tool for building PaaS-like services. It has garnered a huge amount of developer mindshare, vendor support, open-source contributions and attention.
We've also seen the serverless revolution kicked off with AWS Lambda in 2014. Serverless has been massively popular with a subset of developers, and also has lots of community support, educational resources, and so-on.
But while working at AWS and as part of the EC2 team, I realized that lots of the design choices and APIs in the cloud are driven by what is feasible to build. Sure, AWS tries to "work backwards" from the customer, but many AWS APIs seem like they are working forwards from design or physical constraints. Why do Lambda functions need to mess with networking and IP addresses? Why is AWS billing so complicated? Why does AWS need 200+ services? Why is DNS so hard?
If the current set of cloud services is not the end of the road, then what comes next? Will containers, or EC2 be like the humble array or class, and be taught to new developers for decades to come? Or, will they be like the FORTRAN programming language, mostly consigned to the dustbin of history? Or, will they be like the C programming language, used for low-level tasks, but not by the majority of developers?
Will so-called NoCode or low-code solutions be the future? Will it be platforms like Glitch targeted at specific languages or communities?
I'm curious what people think.
Top comments (2)
I fully believe that developers will always choose higher levels of abstraction because they have increasingly harder problems to solve. So leave the undifferentiated work to something else, hopefully it's an automated service that you can leverage and pay for. That's all serverless really offers, a service that you can rely on to be part of your infrastructure.
Having been exposed to Serverless over the last few months, it seems that the things they make easy are things that really shouldn't be happening too often anyway, eg changing hosting vendors. I'm thinking I should integrate more tightly with AWS's Lambda definitions so I can step through the function with my IDE's debugger − a benefit I lose from this abstraction; that I would actually use every week.
The other appeal of Serverless seems to be that their syntax is "simpler" or whatever, but as an abstraction layer, it inherently makes itself prone to being incorrect or feature-incomplete. I noticed for instance that I couldn't apply tags in some particular scenario (the only time I wanted them), so the claim of simplification doesn't really hold up.
I can see the motivation for Serverless − as you mention, AWS can be complicated and their error messages often amount to lying or gaslighting, eg saying something doesn't exist, when actually you're just not allowed to see it. On the flipside, I can get a forbidden message if I get the URL wrong for API Gateway ¯\(ツ)/¯.
I'm optimistic about the future of the AWS architecture insights tool, as it focuses on the biggest issue for cloud infrastructure − people don't understand what to do.