Serverless: It’s much much more than FaaS

aka Data, Logic and Infrastructure — how do they fit together?

I’ve been spending my time since leaving AWS thinking about some of the challenges around Serverless. I’ve also been considering the ideas encompassed by the DevOps movement and how they fit (or don’t) into the narrative of the serverless world. There are some really interesting moves in this space and some exciting startups around monitoring and observability too.

When you come down to it, a solution that is aiming to be deployed in the cloud has a number of core elements:

• A Presentation layer or client layer (if it’s a service of some kind)
• A logic layer (the code)
• A data storage layer (databases, object stores, search capabilities, queues etc)

This is generally the realm of the Development team within an organisation. When it comes to deployment, there is an additional element:

• Infrastructure definition

The rise of DevOps has largely been due to the automation and integration of skills in both areas of Development and Operations (a very simplistic view I know — there are whole books written on this) so that this “handover” issue between the two was as smooth as possible (or simply didn’t exist) and that whoever built the solution owned a problem it if something went wrong.

However, serverless raises different issues for the process of development and automation of deployment and management of issues. In my experience serverless solutions have encompassed object storage, HTTP gateways, on demand functions (FaaS), data storage (of various sorts), queues and many other services.

Why is it important to identify serverless solutions in this way?

Serverless solutions are inherently about logic AND data AND infrastructure.

Putting this another way, it doesn’t make sense to me for a development team to build a serverless solution, and then “throw it over the wall to the operations team” to deploy. The DevOps movement is there to tell us that this is a bad idea anyway and builds should be automated, tested, monitored etc anyway.

Now I’m not saying that there shouldn’t be some sort of process for management of production infrastructure or audit and checking whether a solution is appropriate or fits within a compliance framework, but simply that it isn’t that simple.

It is relatively easy to build a series of functions that connect to defined data sources, and then find out that when you deploy it, that there are issues of scaling. One of the biggest problems I’ve seen over and over again is that people use relational databases and expect them to be able to scale as well as a FaaS platform e.g. building a function in AWS Lambda, using an ORM within that function, and using an RDS database as the store.

Put another way: I think it’s possible that you can build a non-serverless solution using FaaS. Just using functions doesn’t make something automatically serverless.

The issue is that while DevOps tells us that automation is important, serverless solutions have given us a dimension that is not often considered, and that is that serverless infrastructure is part of the solution, not simply what the solutions runs on.

Why am I saying all this?

When architecting a serverless solution it is actually very difficult to separate out the operational concerns from the development concerns.

You have to know more about the environment into which you are placing your serverless solution.

Note: that’s not to say that you didn’t have to know anything for a microservices or monolithic deployment. You simply had to know much less about the environment when developing for e.g. an EC2 based infrastructure.

For a serverless system you simply have to understand how each element could scale to know where potential bottlenecks could be (e.g. relational databases and functions are a good example of potential bottlenecks although it is possible to develop serverless solutions that work with those technologies).

You also have to know how data flows through your application and how fast. This is often an infrastructure question for a serverless application rather than a code problem (e.g. how fast does data travel through this queue?), and can be critical to how an application functions for the user.

To put it another way:

How you define your logic and your data matters, and you need to be able to define your infrastructure alongside both to deliver the solution.

As opposed to deploying into a container based or instance based model, where a developer can choose to deploy (and therefore has to manage) other resource e.g. databases, open source servers, security updates to containers etc.

“It doesn’t matter to the developer where it runs”… or does it?

I’ve heard it said many times that it “doesn’t matter” to the developer where their code is run in a serverless application.

I completely disagree.

This view is a very narrow view of serverless and completely misses the above point. It absolutely should matter to a developer where their code is run and goes alongside the issue of knowledge of the environment that there code is being placed into. In fact, if they are being told that it doesn’t matter, then they have a big issue in being able to deliver their solution to the user.

Which brings me back to the logic/data/infrastructure point.

How do logic and data and infrastructure fit together?

In the serverless world, they cannot easily be separated. At least, logic and data and infrastructure are more highly integrated than in the microservices or monolith world.

It has been pointed out that this could be seen as a “shortcoming” of serverless. I don’t see it that way. I see it this way:

Serverless allows the developer to reduce the amount of code that needs to be created to produce a solution without necessarily reducing the amount of other services needed (e.g. database, storage etc).

In other words, if you were producing the solution in another form (monolith or microservices or another way), you would need more code and you would need a similar level of “other” services alongside it though.

And when you need to write fewer lines of code to deliver a solution, what tends to happen is that you build things more quickly.

Building things more quickly is a good thing when you’re a CTO.

Best practices

This closer integration causes some issues, including what constitutes a “server” in this scenario or what the right amount of testing to do is and what you should test.

It is possible to develop FaaS solutions treating each function like a server, e.g. using a switch statement and therefore having multiple routes in one function, however this isn’t what I would call a best practice. Best practice would be for each function to do one thing. It allows for your function to scale based upon usage and logic, and for you to easily identify issues and you could also work out the financial benefit of each function as well.

Taking this best practice, you find that you end up in a serverless system with a system being a set of events and queues (which act as breakers in the system), with transient data stores, and flows of data through your system.

Which means that in a serverless application your infrastructure is part of your system.

Your system is not just your servers — in fact, it never was.

So let’s take a bit of a hint from the hardware world.

The best analogy is to think of a serverless solution more like a microcontroller. A microcontroller needs a microprocessor, I/O circuits, clocks, RAM, programs and other elements as well. It’s not just the programming, but a combination of all of those that turns it into a useful tool. The infrastructure is the combination of the elements into a coherent piece. A developer might use components, but the manufacturer needs the circuit board design.

Taking it back to serverless, imagine a developer saying that they’ve programmed some code that works great, but now someone else has to build the board to make that programming run in production? Of course the developer needs to understand and develop the architecture they are building for with all the inherent limitations that come with it. Otherwise, they could build something that just won’t work.

And the thing is that the serverless services are there to take away the complexity of managing your system. They are the off the shelf components (the standard processors etc) that make the job of development more straight forward and take away the headache of having to make the decision.

When I talk about serverless, the people who seem to inherently understand it are actually people who were working in hardware in the 1970s and 1980s. I think it might be something to do with the above.

Where does this leave the Developer and the Operations teams?

For serverless, the roles will shift.

Developers will have to define infrastructure as well as logic and data storage. They have to become more like Operations people. Maybe this is more Cloud Native.

Operations will have to accept this, and provide both support and engage with the development teams so as to be able to provide manageable guidelines for the teams (around compliance for example).

Security and Compliance teams will have to come up with workable solutions to allow teams to build serverless solutions, or risk being left behind by organisations that move on this more quickly. I can see CTOs wanting to build more solutions more quickly, and requiring security teams to come up with a way of managing this.

DevOps actually points the way in many ways, towards automation and monitoring and delivery. Serverless is taking on some of the ideas and pushing some of the boundaries of the existing tools. We’re not there yet though.

This isn’t an impossible problem to solve. Serverless does however need a different way of working and thinking than we have become used to up until recently.

The best practice will show that over time.

Serverless is more than just FaaS… much much more

Serverless is not just functions deployed to cloud or containers. That is simply FaaS.

Serverless encompasses new ideas and methodologies and will bring some ideas that we haven’t even encountered yet. We’re only just seeing the beginnings of what serverless will be.

Just like when cloud came along, we needed a Ruby on Rails plus a Twitter to make it clear what could be done, we are still waiting for that for the serverless world, and I don’t think we have that…

… yet.

But so we’re absolutely clear…

Serverless is much more than just FaaS. It always will be.