Managed Versus Fully Managed Services – Introduction to Serverless on AWS
Managed Versus Fully Managed Services
Before exploring the characteristics of serverless in detail, it is essential to understand what is meant by the terms managed services and fully managed services. As a devel‐ oper, you often consume APIs from different vendors to fulfill business tasks and abide by the API contracts. You do not get access to the implementation or the operation of the service, because the service provider manages them. In this case, you are consuming a managed service.
The distinction between managed and fully managed services is often blurred. Cer‐ tain managed services require you to create and maintain the necessary infrastructure before consuming them. For example, Amazon Relational Database Service (RDS) is a managed service for RDBMSs such as MySQL, SQL Server, Oracle, and so on. However, its standard setup requires you to create a virtual network boundary, known as a virtual private cloud (VPC), with security groups, instance types, clusters, etc., before consuming the service. In contrast, DynamoDB is a NoSQL database service that you can set up and consume almost instantly. This is one way of distinguishing a managed service from a fully managed one. Fully managed services are sometimes referred to as serverless services.
Now that you have some background on the origins and evolution of the cloud and understand the simplicity of fully managed services, it’s time to take a closer look at serverless and see the amazing potential it has for you.
The Characteristics of Serverless Technology
Serverless is a technological concept that utilizes fully managed cloud services to carry out undifferentiated heavy lifting by abstracting away the infrastructure intrica‐ cies and server maintenance tasks.
John Chapin and Mike Roberts, the authors of Programming AWS Lambda (O’Reilly), distill this in simple terms:
Enterprises building and supporting serverless applications are not looking after that hardware or those processes associated with the applications. They are outsourcing this responsibility to someone else, i.e., cloud service providers such as AWS.
As Roberts notes in his article “Serverless Architectures”, the first uses of the term serverless seem to have occurred around 2012, sometimes in the context of service providers taking on the responsibility of managing servers, data stores, and other infrastructure resources (which in turn allowed developers to shift their focus toward tasks and process flows), and sometimes in the context of continuous integration and source control systems being hosted as a service rather than on a company’s on-premises servers. The term began to gain popularity following the launch of AWS Lambda in 2014 and Amazon API Gateway in 2015, with a focus on incorporating external services into the products built by development teams. Its use picked up steam as companies started to use serverless services to build new business capabili‐ ties, and it’s been trending ever since.
During the early days, especially after the release of AWS Lambda (the FaaS offering from AWS), many people used the terms ser‐ verless and FaaS interchangeably, as if both represented the same concept. Today, FaaS is regarded as one of the many service types that form part of the serverless ecosystem.
Definitions of serverless often reflect the primary characteristics of a serverless application. Along with the definitions, these characteristics have been refined and redefined as serverless has evolved and gained wider industry adoption. Let’s take a look at some of the most important ones.