Photo by Andre Benz on Unsplash

Serverless Taxi’s: What the heck is Serverless?

What is Serverless as an analogy with descriptions and visuals.

our fictitious Taxi company: Serverless Taxis

Introduction 🚕

Having worked with Serverless since the inception of Lambda back in 2014, I have regularly created articles, spoke at events, and ran sessions around complex Serverless concepts and general thought leadership.

It recently dawned on me, “what about the people that have not accompanied me on that journey across various organisations, and are starting in Serverless from day 1?”

“It recently dawned on me, what about the people that have not accompanied me on that journey across various organisations, and are starting in Serverless from day 1?”

This article explains Serverless as a concept and its core facets, as a story of a fictitious company (‘Serverless Taxis’), with visuals and descriptions for the analogy to make Serverless easier to understand.

Serverless Taxi’s: What the heck is Serverless? 🚕

Lets set the scene about our fictitious taxi company ‘Serverless Taxis

our fictitious Taxi company: Serverless Taxis

Serverless Taxis’ is a new taxi company which is going up against the industry leader, ‘ServerFUL Taxis’. Let’s see why they disrupted the Taxi industry using Serverless concepts!

Why does Serverless work well? 💡

Let’s cover below why Serverless works so well, and let’s equate this back to our taxi company example, and the comparison in the IT World.

Please note this is trying to give some real World comparison for learning only, and of course I am not an expert in taxi company’s or how they work!

We hire the cars rather than the overheads of manufacturing and building cars ourselves

Serverless Taxis scenario
Their competitors ‘ServerFUL Taxis’ are manufacturing their own taxis (cars), paying for and managing their own warehouses, manufacturing plants, staff etc — whereas ‘Serverless Taxis’ have gone down the route of hiring the cars from another company— meaning increased speed, less operational costs, and increased agility.

There is an agreement that the MOT, servicing, maintenance costs etc of the vehicles are managed by the third party company they are hiring from.

Comparison to the IT World
Historically for non-serverless companies, the onus on managing servers (whether that be physical or EC2), has been on the customer; which can include managing execution environments, patching, network infrastructure, server software, server patching etc — and for non-cloud companies can also include physical data centres, networking and maintaining physical servers (including backup generators etc).

In the AWS Serverless World, the shared responsibility between the customer and AWS means that we as customers are freed of this additional burden, and can focus specifically on the application code and any dependencies (for example NPM modules), the resource configuration, and the identity and access management. This allows us to move at speed, shipping features to our customers quicker.

“This shared responsibility model can help relieve your operational burden, as AWS operates, manages, and controls the components from the host operating system and virtualisation layer, down to the physical security of the facilities in which the service operates”

For AWS Lambda, AWS manages the underlying infrastructure and foundation services, the operating system, and the application platform.

Shared Responsibility Model
We have a fleet of cars to utilise when demand scales up, vs having to manufacture or procure our own ready for that potential scale

Serverless Taxis scenario
When the taxi company has a peak of customer requests in one go (say a large event is happening like a soccer match), they can very quickly hire more cars from the third party almost instantly, compared to their competitors who either need to manufacture more cars; or a large lead time on purchasing them. Either way, this is a long and costly process for them, with many people involved in the process.

Comparison to the IT world
In the Serverless World, AWS services automatically scale out elastically under load almost instantly i.e. meaning more requests can be satisfied and scaling out almost indefinitely. Compared to physical servers, companies historically needed to over provision servers to accommodate any future growth or spikes. Either that, or manage and maintain the underlying physical clusters which scaled out container based solutions.

When we don’t have customer demand we can hand back our hire cars, vs being stuck with cars not being utilised (gathering dust)

Serverless Taxis scenario
Once the large event had finished (as above), and customer demand had gone; ‘Serverless Taxis’ are able to hand their hire cars back almost instantly, compared to their competitors who now have a large fleet of cars sitting dormant collecting dust. Not good!

Comparison to the IT world
In a Serverless World this is known as scaling in (and can for the most part scale to zero), meaning that your services will scale up when required, and then scale back down when not being used anymore (to the point that there are no services running when no customers require them). This happens very quickly even under high load, reducing the companies overall costs, whilst servicing customers when needed.

When required at a drop of a hat we can acquire more powerful cars, compared to being stuck with the cars we have

Serverless Taxis scenario
Some of the customers had requirements for more powerful cars for their taxis, and required them at very short notice. For ‘Serverless Taxis’ this was no issue, as they had an agreement with their hire company that they could change the cars for more powerful ones at extremely short notice (higher performance cars almost instantly).

Their competitors however were stuck with their existing cars they had just purchased or manufactured, and couldn’t facilitate customers needs (the less powerful cars were no use to them!).

Comparison to the IT world
In the Serverless World we are able to change the configuration of the services very quickly and easily through IaC (Infrastructure as code.. more later); allowing us to very quickly increase performance to meet our customer requirements.

When our customers don’t require such powerful cars anymore, we can easily give them less powerful cars instead which are more economic (rather than being stuck with expensive powerful cars)

Serverless Taxis scenario
When the customers of ‘Serverless Taxis’ didn’t require the more performant cars anymore (taxis); they were able to quickly swap out the powerful cars for less performant ones; reducing the operational costs significantly. Their competitors however had manufactured or purchased powerful cars to meet previous demand, and were now stuck with them. Ouch!

Comparison to the IT world
In the Serverless World we are able to scale down very quickly and easily through infrastructure as code. This allows us to reduce the performance of the services when required, further reducing cost.

We deliver quicker for our customers as we have increased agility and speed to meet their requirements

Serverless Taxis scenario
Serverless Taxis’ now became much more agile and quicker to market compared to their competitors, due to the fact that they could scale out, scale in, scale up, and scale down, at a drop of hat, with no maintenance or operational overheads; all of which was to meet their customers needs, whilst also reducing the overall TCO for their service.

Comparison to the IT world
In the Serverless World we gain huge speed and agility to meet our customer needs through the flexibility we have around managed AWS services; as well as the reduced costs around managing and maintaining servers.

We have reduced costs as we are hiring not building and maintaining

Serverless Taxis scenario
Serverless Taxis’ have greatly reduced costs compared to their competitors as they don’t have the overheads of manufacturing, staff, warehousing, cars, maintenance, cars sitting not utilised etc

Comparison to the IT world
In the IT World this is much the same, where in Serverless we have greatly reduced costs when it comes to maintaining our services and the operational overheads of more serverFUL services.

This is shown in the diagram below:

Example diagram showing the shift from ServerFUL to Serverless, and the impact on speed, agility and cost
We only pay for the cars whilst we are using them, as thats the agreement with the car hire company

Serverless Taxis scenario
Due to the contracts in place with the hiring company, ‘Serverless Taxis’ only incurred costs when their customers actually used the taxis (cars). Serverless Taxis competitors however had cars sitting idle when customers were not even using them, and essentially were paying for the costs associated with their cars even when they were not being utilised (including staffing and storage etc).

Comparison to the IT world
One of the main advantages of Serverless technologies is the fact that you only incur costs when the services are being utilised (pay for use). Why would you want to pay for and maintain services when no customers are online using them? This is very much what happens currently in the serverFUL World, where you are paying for services 24/7.

We have cars globally so if one breaks down we can reroute others, making them highly available

Serverless Taxis scenario
When ‘Serverless Taxis’ became Global, they found that they quickly needed to service their customer needs regardless of where they were based globally; and in the event of a car breakdown, they could quickly replace in seconds and support their customers. Serverless Taxis competitors however had low availability of cars globally; and if a car broke down they were unable to send out another one until it was procured or manufactured.

Comparison to the IT world
In the Serverless World, high availability means that if one geographical area goes down, we can quickly switch to another; meaning that our customers are unaffected, and our services are online 24/7. In more traditional architectures we find that if a data centre goes down (for example a power cut), then the customer is affected.

Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize costs. — AWS

We have no costly and time consuming maintenance on our fleet of cars

Serverless Taxis scenario
Serverless Taxis had a major one up on their competitors, which was that they didn’t need to MOT, service or maintain their cars (taxis). ServerFUL taxis however had a large fleet of cars that they not only owned, but needed to maintain, MOT, store, service etc — including the costs of staff and materials.

Comparison to the IT world
In the Serverless World this goes back to the shared responsibility model, and the fact that we have no servers to patch, maintain etc. These services include (but not limited too) AppSync, API Gateway, DynamoDB, EventBridge etc

We have Taxis next to all of our customers geographically, rather than customers waiting for Taxis to travel

Serverless Taxis scenario
‘Serverless Taxis’ have an agreement that they have cars available globally, meaning that cars are always distributed close to their customers. Rather than waiting a long time for a taxi, or no taxis being available in their area; customers always have taxis available very quickly in their vicinity.

Comparison to the IT world
In the Serverless World most services are highly available and close to end users, meaning that customers have lower latency and higher availability. This essentially means customers wait less for use of end services (reduced latency).

We are more sustainable for the World with more on demand rather than running servers 24/7

Serverless Taxis scenario
Serverless Taxis are more sustainable compared to their competitors as they are only using cars when needed on demand through hiring and reusing them, and ensuring that all cars are electric rather than petrol, as opposed to the less sustainable companies which are manufacturing, operating and maintaining their own.

Comparison to the IT world
Serverless architecture removes the need for you to run and maintain physical servers, because it is abstracted by AWS services. Because the cost of serverless architectures generally correlates with the level of usage, your workload’s cost efficiency will improve.

At AWS, we are committed to running our business in the most environmentally friendly way possible. We also work to enable our customers to use the benefits of the cloud to better monitor and optimize their IT infrastructure. As reported in The Carbon Reduction Opportunity of Moving to Amazon Web Services, our infrastructure is 3.6 times more energy efficient than the median US enterprise data center, and moving to AWS can lower your workload’s carbon footprint by 88% for the same task.” — AWS

What is IaC (Infrastructure as Code)?

The Serverless World is very much married to IaC (Infrastructure as Code), which allows us to template what our architecture looks like, and use this as a blueprint to bring up new services at a drop of a hat (as well as removing them very easily and quickly too!).

An example of IaC would be the AWS CDK where we can easily describe our infrastructure through code (for example TypeScript), and then deploy it very easily in a repeatable manner. Let’s see that in action in the next section.

Getting started with our first Serverless app!

To have a go at your first simple Serverless App using the AWS CDK you can follow along with wit the following tutorial:


I hope you found that useful as a way to understand what Serverless is as a paradigm.

Go and subscribe to my Enterprise Serverless Newsletter here for more of the same content:

Wrapping up 👋

Please go and subscribe on my YouTube channel for similar content!

I would love to connect with you also on any of the following:

If you enjoyed the posts please follow my profile Lee James Gilmore for further posts/series, and don’t forget to connect and say Hi 👋

Please also use the ‘clap’ feature at the bottom of the post if you enjoyed it! (You can clap more than once!!)

About me

Hi, I’m Lee, an AWS Community Builder, Blogger, AWS certified cloud architect and Global Serverless Architect based in the UK; currently working for City Electrical Factors & City Electric Supply, having worked primarily in full-stack JavaScript on AWS for the past 6 years.

I consider myself a serverless advocate with a love of all things AWS, innovation, software architecture and technology.

*** The information provided are my own personal views and I accept no responsibility on the use of the information. ***

You may also be interested in the following:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lee James Gilmore

Principal Serverless Engineer | Enterprise Cloud Architect | Serverless Advocate | Mentor | Blogger | AWS x 7 Certified 🚀