or “Why abstractions are not always a good thing”
My first experience of developing proper web applications (not just writing a web page) was using perl scripts to generate static web pages. Yup! I did web development with perl and HTML 2. It wasn’t “fun”. It was non-standard and difficult for other devs to fix or improve.
Over the next few years of web dev, various standardisations and “ways of developing” came into being. These evolved into frameworks. The first time I came across a framework was with fusebox and ColdFusion (I’m sorry for swearing). This meant that we could standardise around something, and people could pick up the ideas more easily. These initial frameworks were good at code/file structure rather than anything else and allowed teams to work together more easily.
Rapid Deployment Tools: Rails and Django
Then along came other languages and frameworks, and suddenly, you could start developing web applications that could run on a VPS on the internet with 256MB of RAM without needing to own/rent space in a data centre.
The frameworks developed over the years into rapid deployment tools like Ruby on Rails, and Django. They were great for a developer as it cut down the time to develop the initial prototype by giving you some boilerplate code that multiple devs could understand and help with on forums and in teams.
You could start a project by typing one line into your CLI.
This changed and simplified the development world.
And that meant that people didn’t need to learn why you do things in a certain way.
It’s why we have things like Stack Overflow now.
In other words, it allowed inexperienced people to do something that previously only experienced people could do.
And this caused a problem.
The developers lost control of the complexity.
The Rails problem
This isn’t necessarily a bad thing. Abstracting out the complexity is not the wrong thing to do. Making one single command where before many lines of code and a specific environment were needed is a useful tool.
But it’s just a tool.
Sometimes you still need to know what that tool did and why.
Or you end up with problems like Rails had.
Ruby on Rails became very popular largely because Twitter using it to build their initial prototype and utilising a nascent AWS EC2 service to run it.
What happened then was people started playing with Rails and they became “Rails programmers” who used ruby.
The language was actually secondary.
Now, this isn’t a problem until something happens in the rails environment. Something like a major version switch.
Because if you have “ruby programmers who do rails” then that kind of switch isn’t as big a deal. People know the language, and port their thinking to the new framework.
But if you have “rails programmers who’ve learned ruby” then you end up with people who don’t understand why some things have changed and therefore get fed up and throw their toys out of the pram.
The problem was that the community had grown up around the tool not the language.
Why this whole post matters to Serverless devs
Serverless is about cloud
It’s about understanding cloud and what it can do and how it can do it better than before.
The people that will get Serverless ideas first are those who have been doing cloud based developments for a long time.
Those are often people who’ve come from a sysadmin background and their only major tool is often ssh and they know what awk and sed are and how to do regexes…
My point is this for Serverless people:
Don’t just learn the tools — learn the basis for the tools
Get stuck into why using a Lambda function is a good idea over an EC2 instance or a docker container.
All these tools (and some of them are very good by the way) are abstractions onto cloud.
We will do ourselves a massive disservice if we don’t explain what the tools do and why they do them.
Because we’ll end up with building “serverless developers” rather than proper cloud native thinkers.
Current tooling for serverless
The reason this is so frustrating for me is that the majority of “Serverless” tooling at present is actually simply an abstraction on the deployment of functions.
To be perfectly honest, deploying the function is the easy bit
And structuring code and files is useful, but it’s not really that useful.
And if those are the only tools that get traction and mindshare, we’re in real trouble as a community because we could just be creating a “Serverless Rails”.
And if we create a “Serverless Rails”, those of us who are cloud natives pushing a wider conversation will get lost in the noise.
And the downside is as soon as there is an issue, the entire concept will be damaged.
The next big thing for Serverless
The big conversation for the next 6 months on Serverless is about tooling, because at present, we have a lot of abstractions that allow for deployments and a lot of abstractions that could cause problems in the future (by only thinking about simple use cases).
What we need is to define the kind of tooling we need (which is much much harder) within the community.
Please don’t build another function deployment tool. We don’t need it!
The tooling we need is around infrastructure, deployment, service management, testing…
The thing is, that a lot of great tooling exists…
…for cloud
Serverless is simply advanced cloud development. Developing the functions is the easy bit.
The hard bit is the infrastructure around it.
And the challenge is to learn the lessons from the Ruby on Rails of this world, and not just abstract to Rails and forget the cloud.
Because if we forget the cloud, we will end up with something of far less value than it could be.
So, for me, this is key:
Cloud first, Serverless second
Thanks
Thanks to Florian Motlik for comments to improve this article. He’s awesome! Check out his posts.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!