Serverless: Initial Learnings (part 2)

Follow on from Part 1. I suggest you read that first!

If you’re not sure what Serverless means, then read my What *is* Serverless Architecture? post before that.

Learning 6: Communities and support are… fragmented

At present, there isn’t much support for the serverless concept. The idea of serverless is understood, but the community hasn’t coalesced around a series of patterns/ideas as yet. There are attempts to do this, but it’s not so straight forward unfortunately.

There are many different ways of doing serverless architecture and at present, none of them are coming out as “on top” of the others. This will change, but will take some time but could well be quite fragmented.

The nature of serverless will also mean that the community will be less about specific architecture and more about concepts than some technologies are now. The lack of structure is both a good and bad thing.

You need solid, core skills to be able to take on serverless. I would suggest that it isn’t something you do as a newbie.

Learning 7: Serverless requires better architects and coders (imho)

This might seem odd to say it, but the lack of support means that you cannot do this as a “stackoverflowgrammer” (stack overflow programmer). A lot of other languages have a significant amount of answers to simple questions on sites like stack overflow. You can get away with coding quite well with a modicum of skill if you know how to google for answers.

The problem is that serverless is so new (well… not that new, but new enough), that the patterns are not yet established and the skillset is undefined.

That means that most of the answers on a tech Q and A site are going to be targeted at servers and similar.

Unless you realise that, you’re going to find situations where you are helpless. Literally, nobody will have the answer (yet) to your complex question.

And if you are unable to find the answer yourself, or have access to a very good community you are going to struggle.

I’ve asked questions on various tech community sites about node.js or similar only to be told an answer that requires access to the server in some way. This isn’t very helpful, and it is very frustrating, but also, shows how much programmers rely on the server and what it provides.

It definitely improves you as a programmer. Significantly.

But it’s hard to do in isolation.

Learning 8: There is almost infinite flexibility but don’t “over architect”

The ability for you to “add on” is fantastic. At present if you need to switch out a third party API or refactor some code, there are knock on issues.

A lot of the positive notes around event and function driven serverless architecture is that you can change just one thing at a time.

So if you have a serverless system and something “goes wrong” you have the flexibility to choose almost any solution you want to fix it, because you are unrestricted in your choice of solution.

But then you have almost any solution you want to fix it.

Blessing and a curse.

Learn to recognise the limits of your resources and code/architect accordingly. Ability to architect a good solution is going to be where the winners come out of serverless.

I can definitely see situations where over architecting is far far harder to resolve/fix with serverless than it is in current frameworks. We shall see though.

Learning 9: Focus is on singular functions and events

One of the biggest things I’ve found as a positive, is that I am so often only focussed on one thing at a time.

Just one.

At a time.

When you code within a framework, you are constantly thinking about how things fit into the framework and how code affects the server. Usually this is unconscious, but it is definitely there.

Serverless allows you to give almost 100% focus when coding on the actual problem.

It allows you to separate out from every other issue to resolve this singular one.

It is much easier to code this way in my view. Also, if you add in pair programming or other techniques I can imagine a significant increase in productivity.

We all have different skills/speeds of development and we all have different approaches to solving problems. If you give a bunch of singular problems to a team, I can imagine a scenario where you can develop and architect a scalable system at significant speed.

This will almost certainly benefit enterprise more than it will startups, but my experience is that startups can work with small teams and develop high scale, but the benefits to enterprise could be enormous.

Learning 10: I’m still learning

I can’t imagine that Serverless is going to stay like this for much longer. I can feel that the community is ready to go somewhere with this, and the direction will be more of a “philosophy” than it will be an architecture.

We’re sort of there, but we need it articulated so that it can be adapted to different scenarios.

Who knows?

Comments/thoughts welcome.