Serverless Beyond the Buzzword: What Can Serverless Architecture Do for You?

By Thomas Smart

This book describes how Serverless and cloud-native systems work, their benefits and roles in automating and optimising organisations, and the challenges to be considered. Anyone interested in Serverless architecture will benefit from this book regardless of their level of technical understanding.

'Serverless - Beyond the buzzword' explains many related terms such as microservices, cloud-native, architecture, several relevant AWS services and how it all works together to produce cost-effective, scalable solutions in the cloud.

For the less-technical decisionmaker, an essential part of the book is that it helps you understand how Serverless might affect finance, security, people and compliance. It touches on important decisions, such as selecting and working with external or internal specialists and teams, finding them, evaluating, training, and the flexibility and dynamics within digital projects.

Deployment automation and DevOps also feature heavily in this book, and towards the end of the book, you can find some real use cases and examples of Serverless architecture to get you started.

It's worth noting that this book is not a development guide; it gives you a comprehensive understanding of what Serverless is so you can make informed decisions for your organisation and projects.

• Language: English
• Publisher: Partridge Publishing Singapore
• Release date: Nov 12, 2020
• ISBN: 9781543761665

Thomas Smart

Thomas Smart has been actively involved with digital projects since 2002. His experience crosses many sectors and types and sizes of business – all of which give him a wealth of experience and knowledge to draw upon as part of his consulting services. His passion for Serverless comes from his focus on innovation, rapid prototyping and designing solutions that are as cost-effective as possible. Serverless, as you will see in this book, is very suitable for all these goals.

Book preview

Copyright © 2020 by Thomas Smart.

All rights reserved. No part of this book may be used or reproduced by any means, graphic, electronic, or mechanical, including photocopying, recording, taping or by any information storage retrieval system without the written permission of the author except in the case of brief quotations embodied in critical articles and reviews.

Because of the dynamic nature of the Internet, any web addresses or links contained in this book may have changed since publication and may no longer be valid. The views expressed in this work are solely those of the author and do not necessarily reflect the views of the publisher, and the publisher hereby disclaims any responsibility for them.

www.partridgepublishing.com/singapore

Contents

About the author

Acknowledgements

Prologue

Who is this book for?

Technical levels used in this book

What will you learn?

Amazon Web Services (AWS)

Chapter 1: Serverless basics

What is Serverless architecture?

Microservices

Serverless example

History of Serverless

Types of projects

Key challenges

Key benefits

Chapter 2: Finances

Cost to develop Serverless

Cost of maintenance and operations

Estimating operational cloud costs

Tracking operational cloud costs

Chapter 3: Security

Shared responsibility

Serverless security

Principle of Least Privilege

Cloud security controls

Security for microservices

Security for cloud users

Encryption

Privacy and GDPR

Security monitoring with ElectricEye

Chapter 4: People

Serverless roles

Serverless roles: Solution Architect

Serverless Roles: Cloud Security Engineer

Serverless Roles: Deployment Automation Engineer

Serverless roles: Full Stack Developer

Serverless roles: Database Engineer

Serverless training

Working with Serverless vendors

Vetting Serverless capabilities

Chapter 5: DevOps

What is DevOps?

Infrastructure as Code

AWS Cloud Development Kit (CDK)

CDK technical implementation

AWS Amplify

Chapter 6: Architecture & Development

AWS Lambda and CloudWatch Logs

AWS API Gateway and Gateway Sockets

AWS Serverless databases

AWS Aurora Serverless

AWS security services

Other Serverless services

Design patterns

Lambda Microservice Types

Decoupled microservices

Containers

Well-Architected Framework

Serverless tips

Chapter 7: Case Studies

Introduction

Proactive logging

Serverless data lake

Video analysis

Dynamic live streaming

SEO-friendly website and CMS

Virtual host

True Serverless containers

Epilogue

References

About the author

about_author%20(make%20b-w).jpg

Thomas Smart has been actively involved with digital projects since 2002. His experience crosses many sectors and types and sizes of business – all of which give him a wealth of experience and knowledge to draw upon as part of his consulting services.

His passion for Serverless comes from his focus on innovation, rapid prototyping and designing solutions that are as cost-effective as possible. Serverless, as you will see in this book, is very suitable for all these goals.

Acknowledgements

A big thank you to my wife, Meiting, whose tolerance and patience with me knows almost no bounds; and to my boys, Blaze & Dash, whom every day inspire me to share my knowledge with the next generation.

Many thanks to my editor Mary Whitehouse, who helped make the book a lot more readable; and Won Jenn Lee, who implemented some of the case studies in Chapter Seven and wrote the ‘lessons learned’ section, included in the same chapter.

And last but not least, many thanks to Wayne and Sherri for reading the manuscript and providing valuable feedback before the final copy went to the publisher.

Prologue

Technology is best when it brings people together.

Matt Mullenweg, social media entrepreneur.

45913.png Who is this book for?

This book is for anyone interested in Serverless, regardless of their technical level. I share strategic insights for entrepreneurs and executives, planning and team insights for project managers, and technical insights for architects and team leads. The intent is to provide a deep understanding of Serverless Architecture and how it could impact your business and your projects.

This book is not a Serverless development guide. Because of the sheer number of programming languages and the rapid pace of change in this area, the Internet is your best source of information on developing Serverless.

If any of the following scenarios sound familiar, then this is the right book for you:

• You are an executive or manager, and your technical people have been talking about Serverless for some time. You are interested but want to make sure it’s the right strategic choice for your business or project.

• You are a project manager or team lead tasked with digital transformation and are looking for a technology strategy that will give you an unfair advantage.

• You are an entrepreneur or innovation manager looking for a way to rapidly prototype ideas using a cost-effective approach.

• You are a software architect or developer who wants to find out more about the broader implications of Serverless. For example, to gain a deeper understanding or to pitch it to your stakeholders.

45935.png Technical levels used in this book

As you may have noticed, each section header has a little icon which indicates the technical level of that section.

45938.png 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.

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.

45941.png Amazon Web Services (AWS)

Most of my experience is on Amazon Web Services, so the cloud services and examples that I mention in this book are often for their platform. That being said, the high-level concepts described can be applied to all major cloud providers using their relevant services.

Amazon is the largest e-retailer in the world, as well as the largest cloud provider. As the cloud services generate more revenue, some people liken it to an IT firm with a gift shop. Joking aside, Amazon’s hands-on experience through the e-retail business is one of the reasons that its cloud services are such a success. They have been tried and tested in Amazon’s real production environments with massive volumes of users and data. 2019 figures reveal that, when a service needs to be hosted online, there is a 34% chance that it will be hosted on Amazon’s cloud.

The history of Serverless (discussed in Chapter One) provides some insights into how AWS started the Serverless evolution. They have been my preferred cloud partner for several years in part due to their strength in Serverless.

In 2019, in recognition of my Serverless activities, they invited me to join their exclusive AWS Partner Ambassador programme as one of the few independent consultants, where I continue to be active in promoting, training and talking about Serverless.

Chapter 1

Serverless basics

The Web as I envisaged it, we have not seen it yet. The future is still so much bigger than the past.

Tim Berners-Lee, Inventor of the World Wide Web.

45956.png 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.

‘True Serverless’, ‘full Serverless’ or ‘pure Serverless’ are terms you might hear that indicate an additional set of requirements is expected. For a service to be considered ‘true Serverless’, the following should apply:

1. A significant portion of the service is managed by the cloud provider – including operating system, most software and generic dependencies. We also expect to see that redundancy, scalability and, to some degree, security is managed and automated.

2. You pay only for actual usage, e.g. the number of requests, the amount of storage or the duration for which a service is actually used. If you have to pay for idle or unused time, it would not be considered truly Serverless. Some services bill for idle time but, due to their nature or your use case, they can be turned off automatically when not needed and turned back on again automatically when required. This approach helps to minimise being billed for idle time.

3. Using custom code or configurations to ensure a service meets the truly Serverless criteria is acceptable. But if these changes compromise the security of the solution in any way, or make it unstable, the service could not be considered truly Serverless.

Some cloud services use the term ‘Serverless’ in their name or description but do not satisfy all of these criteria. With cloud services, the nature of the service and its typical use case, combined with if and how idle time is billed, is especially relevant.

Let’s look at some examples to give that some context. If you have a website or web app which you want to make available online, you have three options:

1. Put the website on a server (or service) for which you pay a fee-per-time. This is not Serverless because you are paying for idle/unused time. In a given month you would pay the same if you had zero visitors or 1000. Due to the nature of servers and, especially, the time needed to start a server, it is not realistically possible to automatically disable and enable servers in response to visitors.

This is how traditional server hosting and relational database services work.

2. Put the website on a managed service that bills you for the size of your website and per request (each time someone visits your website). This can be considered Serverless. In the zero or 1000 visitors comparison, you would be billed the same amount for the website size because that doesn’t change, but you would only pay for requests if there were actually visitors.

This is how some managed services work, such as cloud storage and certain types of databases.

3. Similar to option one, but the website will be disabled when there are no visitors, and will automatically enable with no noticeable delay when a visitor arrives. This can be considered Serverless because you are only paying for the online time when a visitor is using it.

This is how microservices work and how the AWS Fargate container service can be configured to work with some help from microservices.

The term Cloud-Native is commonly used to describe applications that are developed specifically for the cloud. This can refer to server-based applications designed to take advantage of cloud capabilities such as autoscaling or to fully Serverless applications. As the cloud continues to evolve, the term is becoming more associated with the latter, but it is not quite interchangeable yet. I use the term Serverless in this book to avoid any confusion.

It is equally important to know what Serverless architecture is not. It is not going to replace every other architecture available, nor is it suitable for every project. As with any tool, it is vital to pick the right one for the job and not to force it on something it is not suited for. The same goes for the managed services you use within a solution. Microservices are great for many things, but they have their limits. Sometimes a container or a server is just a better solution for a given problem. The important point here is that we should not pick a technology based solely on the team’s experience or because it’s ‘trending’. We should assess a given project’s short and long-term requirements and pick the most suitable technology to achieve them.

46055.png Microservices

Microservices frequently come up when Serverless is discussed, and they are a typical design pattern for Serverless. However, not all Serverless solutions use microservices, nor does a solution have to be Serverless to use microservices.

Traditionally, software architecture was monolithic, meaning that the application was written as a single collection of code that contained all of its functions. While well-written monolithic applications are often layered to provide some separation between data, function and design, the different layers and the functions within a given layer are heavily dependent on each other.

Microservices are the opposite of that. They can be thought of as independent mini-applications that handle a specific feature or set of closely related features. Multiple microservices will work together to deliver all of the required features for an entire solution. While microservices can work together, each microservice can fulfil its purpose without depending on other microservices or relying on any shared code.

In a Serverless application, microservices make up the intelligence of a solution. They can do calculations, apply algorithms and machine learning models, convert data between different formats and much more. Microservices are also commonly used as the ‘glue’ between managed services. For example, extracting audio from video in one service (Transcode), converting it to text in a second service (Transcribe), then having the text analysed in a third service (Comprehend).

Consider the following comparisons between monolithic and microservice architecture.

Independence

• Monolithic architectures require a significant amount of regression testing after each change. Testers do end-to-end testing to make sure that a change in one part of the solution has not broken something in a different part of the solution that may be dependent on it.

• Each microservice has a specific and narrow scope, and what data goes in and what result comes out is clearly defined. Even if changes within the code are made, if you can avoid having to change the format of what goes in and what comes out, then the changes will not impact any next step in the workflow. Alternatively, it’s simple to create a new version of a microservice running in parallel with the first version to avoid disrupting any workflows. As microservices are billed based on requests, this would not increase cost the same way it would if you had to run multiple versions of a server-based solution.

Reusability

• A monolithic application might have a function to create thumbnails of images. This same function would be repeated in every other application needing this feature so a change, for example, to upgrade the quality of the thumbnails over time would need to be applied in multiple applications.

• If we use a thumbnail microservice, then this would be a stand-alone mini-application for creating thumbnails. Several other applications within the organisation can easily use the same microservice. This microservice is given image data and returns thumbnail data, so it does not need to deeply integrate into each solution to be able to perform its task.

Security

• A monolithic application might have a function that is storing sensitive transactional information in a database. Because it’s a single code base and this function needs access to that database, that means that ALL of the code, and indeed the entire server, has access to that same database.

• In a Serverless solution, there would be a microservice for transactions. This is the only microservice that has access to the transactions database (which is exclusively for storing transactions). Other parts of a solution must go via this microservice to interact with transaction data, and all such requests can be easily monitored, authorised and audited in this one location.

Separation of front-end and back-end

• Well-developed monolithic applications can achieve this too, but it wasn’t a common approach to take. Monolithic applications following a ‘Model View Controller’ (MVC) approach would have separation of layers, but the layers would all still be within the same