Is Serverless the New Visual Basic?
Monday, May 15, 2017 at 9:35AM 
With Serverless hiring less experienced developers can work out better than hiring experienced cloud developers. That's an interesting point I haven't heard before and it was made by Paul Johnston, CTO of movivo, in The ServerlessCast #6 - Event-Driven Design Thinking.
The thought process goes something like this...
An experienced cloud developer will probably think procedurally, in terms of transactional systems, frameworks, and big fat containers that do lots of work.
That's not how a Serverless developer needs to think. A Serverless developer needs to think in terms of small functions that do one thing linked together by events; and they need to grok asynchronous and distributed thinking.
So the idea is you don't need typical developer skills. Paul finds people with sysadmin skills have the right stuff. Someone with a sysadmin background is more likely than a framework developer to understand the distributed thinking that goes with building an entire system of events.
Paul also makes the point that once a system has built experienced developers will get bored because Serverless systems don't require the same amount of maintenance.
For example, they had good success hiring a person with two years of vo-tech on-the-job training because they didn't have the baggage of working with frameworks and servers and all of those kind of things. That baggage gets in the way.
So hire younger, hungrier developers who don't have that experience behind them.
Obviously "younger, hungrier" and "less experienced" also means cheaper, not that there's anything wrong with that. Developers are hard to find.
We've seen this kind of thing before. Using Visual Basic lots of systems were built that did real and important work for companies by relatively inexperienced people because VB made it so easy to write a Windows program. It was really difficult and time-consuming to write a Windows program, like it's really difficult and time-consuming to write a cloud program today. Like VB, Serverless radically reduces the expertise needed to write a cloud program.
Though they got the job done, most of those VB programs were technical debt bombs. Over time as more and more functionality was bolted on they became hard to understand, hard to change, hard to test, and were poorly designed. Your classic Big Ball of Mud.
A lot of the problem was VB made it easy to include business logic in event handlers, so there was no layering, the GUI was the orchestrator. This made VB programs hard to test. Serverless also has this problem. Inexperienced programmers also used a lot of global variables in VB programs so there wasn't a clean separation of concerns. Coupling was high and cohesion was low. Serverless also has this problem, though obviously there are no global variables in the code, the database effectively becomes a store for global variables that can be accessed from any Serverless function.
It will be interesting to see if Serverless can avoid VB's fate.
Reader Comments (10)
One reason I like the Serverless idea (although we haven't gone there yet) is that a big part of the overhead of traditional server-side development is in building and maintaining the scaffolding that basically let you right stateless functions. If you get it right (transactions, failover, etc) nobody notices, but get it wrong and your system is DOA. With Lambda (or similar), that overhead reduces to zero.
What I haven't yet found is a good set of tools that let you easily have, say, a single GitHub project with a bunch of defined endpoints in it and automatically deploy and lifecycle that set through for you, similar to (for lightweight example) a set of JWS endpoints on Heroku. Then again, its been a few months since I've looked.
"Paul also makes the point that once a system has built experienced developers will get bored because Serverless systems don't require the same amount of maintenance."
Um... because what experienced developer doesn't love maintenance :)
Yep, that thought passed through my mind too :-)
Richard: see https://github.com/Miserlou/Zappa for a tool as you've described. It's easy to set up with a CI solution for continuous deployment. AWS also rolled out CodeStar for an end-to-end solution for Lambda but I haven't tried it yet.
Checkout this repo for Severless deployment combining AWS Lambda, API Gateway, and DynamoDB. It's CI friendly, and runetime agnostic
To answer the question at the start of the blog:
No
I think you're making a bit of a leap. Serverless takes *more* expertise in cloud than the majority of developers have. Most developers are actually working quite a long way away from the "metal" of the services.
All this means that to train a developer in Serverless techniques who has to unlearn those framework based skills is actually harder than finding a young and talented coder without that baggage and train them in cloud.
Training people in serverless (aka Super Advanced Cloud) is hard for everybody.
Training people in serverless whilst unlearning skills learned over 10-15 years is much harder.
Your comparison to VB is a little far fetched. Sorry!
Your analogy is bad and you should feel bad
Abstractions all the way down! The cloud and serverless are easy to grok, ones implementation of those (aws, azure, google) may take some more connecting of the dots. But, I do expect the older programmers to grok these patterns and domains much quicker than any younger folk, and, through experience, be able to leverage them most efficiently. Efficiency is synonymous here with milisecond runtimes saving or making a business tons of $$$$.
Pay peanuts and you get monkeys, always, same was true when VB came out and same is true now and companies will continue to make the same mistakes while the new leaders and disruptors will not.
First, every language can be exploited and so is the VB. I have seen many well layered programs build using VB running under sandboxed registry avoiding DLL hell.
I believe there is nothing one size fits all. Serverless computing has its own space and should be carefully evaluated and should not be any worry.
Well, I believe the main thing here is the value provided by any tool.
I will not go into the debate of "unlearning and learning a new thing".
Let's call the relatively less experienced developer our hero.
Firstly, an experienced developer has gone through all those fat frameworks and knows what's happening behind the scenes so it would be really easy for him to maintain or troubleshoot while our hero would have some difficulty being the younger and hungrier species he is.
Secondly, an experienced developer knows what value will be provided by using serverless while our hero will know less about the same.
Last, but not the least, an experienced developer, can easily understand and migrate the existing codebase (which needs maintenance for a looong time, believe me).
Also, the analogy is really bad.
VB was a thing of the past and had many performance issues, serverless (spring cloud functions) is a robust, resilient and lightweight methodology of implementing microservices which are really easy to test and scale.