What will you learn?
This book will help you understand what colleagues or friends mean when they are talking about ‘Serverless’.
I want to share the facts about and background of Serverless to help you decide for yourself if it is a technology fad or a technology evolution. You’ll be able to determine if it’s relevant to you, your career and your business, and what impact it might have if you were to start using it in your projects.
About a third of this book addresses the question ‘why Serverless?’. This includes some history and discusses how the cloud has evolved to this point.
Another third explores the ‘what’ of Serverless, to give you a deeper understanding of what it is some people are so excited about.
The final third addresses the ‘how’. Where do you go from here, how to find the right people, and how to start implementing Serverless in your projects.
Chapter One introduces Serverless and its challenges and benefits. It will be useful to anyone looking to understand on a high level what Serverless is and its potential relevance to their business.
Chapters Two, Three and Four delve deeper into the strategic impact of Serverless on finance, security and people within an organisation. It answers questions such as:
How are business models, estimates and budgets evolving with Serverless?
How does Serverless impact security and GDPR or similar privacy regulations?
Where do I find and how do I assess the right talent for a Serverless team?
How can we be more agile and fast-paced in our digital projects?
Chapters Five and Six get a bit more technical. We explore DevOps concepts and how Serverless can be automated to optimise businesses. In Chapter Six, we get into some Serverless solution architecture and development concepts. You might want to go straight to these chapters if you are a solution architect or team lead who is already familiar with Serverless as a concept and looking for best practices and example architectures.
Chapter Seven looks at a number of real-world uses for Serverless that I have implemented in actual projects. You will learn some practical design patterns and approaches to common problems.
Glossary
Before you start reading, here are some words you’ll come across in the book, along with definitions, in case you’re not entirely familiar with cloud jargon.
Provider, Cloud Provider, Cloud Service Provider, CSP
An organisation providing a cloud platform, such as Amazon Web Services, Google Cloud and Microsoft Azure.
Service
Another word for a feature, tool or product in the cloud. For example, Amazon S3 is a storage service. Services are typically owned by the Provider and offered through their platform in an entirely self-service or automated way.
Solution
As we commonly see an application as an answer to a given problem, we also call applications ‘solutions’. So this really just means an application, piece of software or similar project. In the context of this book, it will usually be talking about a cloud-based application.
Architecture
This does not refer to buildings in our industry, although, conceptually, it has some similarities. Architecture can refer to the structure of an application. When talking about the application code, we call it the ‘software architecture’. We call the entire application, including all of the cloud services, ‘solution architecture’. An even higher level, including integration with corporate networks, is ‘enterprise architecture’.
Solution Architect
Combining our definitions of ‘solution’ and ‘architecture’ gives you the title for the person responsible for designing the overall structure of a cloud-based application. Similar to the levels in architecture, we also have a Software Architect and an Enterprise Architect.
Instance
This is a word for servers in the cloud. They are not a physical server but a software-defined section of a physical server. In the cloud, physical servers are typically split into multiple sections or virtual servers to improve utilisation. We will explore this in more detail later in the book.
What is Serverless architecture?
Simply put, Serverless architecture is a way to build software that will run on a server fully managed by a cloud provider instead of a server that you manage yourself.
The word ‘Serverless’ is a bit of a misnomer as there actually are servers involved in storing and running your code. It is called Serverless because the developers no longer need to manage, update or maintain the underlying servers, operating systems or software.
Redundancy, load-balancing, networking and, to some extent, security is also largely managed, guaranteed and monitored by the cloud provider and their dedicated 24/7 operations team.
With Serverless, the focus of the development team will be entirely on the cloud configuration - NOT to be underestimated – and writing their code.
Provision
This means to configure and activate a particular cloud service for use in your solution. For example, when we ‘launch a server’ in the cloud, the correct terminology would actually be ‘provisioning an instance’.
Parameters, Variables, Configurations, Settings, Options
These all effectively mean the same thing and can usually be used interchangeably. These are used to make services behave in a way required for the solution. For example, the size of an instance can be configured with the ‘Instance Type’ parameter.
Lambda function vs Lambda microservice
Lambda is an AWS service for hosting microservices but these can also be called Lambda functions. The two terms are usually interchangeable. In this book I use the term Lambda microservice.