/ Cloud

What is Serverless and why do I use it

Serverless application development is a different way to build applications that enables me to focus on the business logic that I am creating and not the underlying infrastructure that it runs on.

Since most of the value for an organisation is in the business logic serverless allows me to be more productive and deliver value faster.

Currently, in the market, there are two types of Serverless platform: Closed Proprietary platforms and Open platforms. The closed systems are the most well known since they have been on the market the longest. AWS Lambda, Azure Functions and Google Cloud Functions all fall into this category. Of the open Platforms, there is a number, but I have personally only used OpenFaaS and fnProject. The other major open player is Apache OpenWhisk although I don't have much experience with it yet.

There is a special place in my heart for fnProject since a lot of the core contributors live and work in Bristol (and I love visiting Bristol, so it's a great excuse).
and also it is the Open Source project that Oracle is using to build their Serverless offering. The team that started the project joined Oracle as an Aquisition in 2017 and have been doing fantastic work flying the flag high for container native development at Oracle, which if you know me, was a significant reason for me leaving Microsoft and Joining Oracle.

All of the platforms I have so far mentioned do similar things although they all do them in subtly different ways. Tomorrow I will be a publishing a blog that goes deeper into the differences, but for now, I will focus on the similarities.

As a developer, I can use one of these platforms and create a function in many languages. In this function, I can write some logic. Once I publish the function it will be available at a URL and I can call it and execute that business logic. Here is an example of a function written in Go.

package main

import (

type Person struct {
    Name string

func main() {
    p := &Person{Name: "World"}
    mapD := map[string]string{"message": fmt.Sprintf("Hello %s", p.Name)}
    mapB, _ := json.Marshal(mapD)

I like using Go as an example because it isn't my first language as a developer. I actually wouldn't know where to start if I were to host some go code as microservice. Which web server should I use with Go? How do expose port 80? How do I add a https certificate? How do I scale this code? These are all questions that I no longer need to think about it. That is someone elses problem. I just write some go, solve some problems and check in my code.

The way we call the function will depend on the program, but it might be a simple cURL get to execute the function. It might also be a webhook (which means calling the URL and passing over a specially crafted JSON file).

The way that a Function is invoked is called a trigger. Many companies building Serverless Platforms will allow you to trigger functions when other things happen in your cloud account. So for example, when an image to added to storage or a row or document is inserted into a database. Under the covers, these systems are sending a webhook to the function when events happen. Therefore it's possible to build functions into any workflow so long as you can create webhooks (or call GET requests) when events occur.

In some serverless platforms, you can Orchestrate and manage large numbers of functions and build them into bigger systems. In fnProject the system is called fnflow later Azure Functions have also added a similar system called Azure Durable Functions (imitation is the sincerest form of flattery).

That is how I explain serverless and why I use serverless. Your situation might be different, serverless isn't for everyone. I think serverless marks a new dawn in cloud computing allowing developers to focus on code and not on the infrastructure. Allowing them to build solutions in one or more languages, choosing the best language for the individual tasks of each project.

Martin Beeby

Martin Beeby

Martin works for Oracle as a Developer Evangelist. He’s been a developer since the late 90s and loves figuring out problems and experimenting with code.

Read More