Serverless Automation: Services as Code (SaC)

Wayne Scarano
3 min readNov 13, 2017

--

The first generation of cloud computing (Cloud 1.0) abstracted the physical elements of a data center (i.e., building, guards, racks, servers, networks, security). You, the customer, can provision and manage servers within your own virtual private cloud (VPC). While operating in a physical data center, owned by the cloud provider, you could claim you’re “datacenterless”. (An awkward term but you may have guessed where I’m going.)

The next generation of cloud computing (Cloud 2.0) abstracts the provisioning and management of servers, and is widely known as “serverless”. Serverless abstracts Infrastructure as a Service (IaaS), pushing responsibility and risk of server management to the cloud provider.

Serverless defined:

An on-demand scalable compute service,
running a small stateless function,
triggered by an event,
billed only for resources used,
operating on abstracted and managed servers.

Serverless === Managed Function as a Service (FaaS)

Function as a Service (FaaS), a compute service, is similar to serverless; however, it could require some infrastructure management. For example, IBM offers OpenWhisk, a FaaS, which can run serverless via the IBM Cloud, managed by IBM, or non-serverless in your data center (on-premises) and managed by your team. Serverless is about managed services not managing infrastructure.

Infrastructure as Code (IaC) allows you to automate the provisioning and management of infrastructure in your data center and/or in the cloud. IaC typically involves provisioning and managing Infrastructure as a Service (IaaS).

Serverless architecture, on the other hand, is the design of a solution comprised of cloud services, with at least one being FaaS. Cloud services are managed by the cloud provider, eliminating the need for you to create and manage infrastructure. While IaC is used to configure IaaS (i.e., VPC, subnets, server instances) it can also configure non-IaaS related services. For example, IaC can configure all services required for a serverless application, from FaaS to storage services to API gateways to streaming services and beyond. Therefore, Infrastructure as Code (IaC) is a misnomer if we’re defining, configuring, and accessing services not infrastructure.

Managing a serverless solution is the management of services where and when needed, essentially Services on Demand (SoD). Consequently, code for managing services is better described as Services as Code (SaC).

Services as Code (SaC): The automation of Services on Demand (SoD).

SaC automates the configuration of cloud services. AWS introduced their SaC called the Service Application Model (SAM), an extension to their IaC (CloudFormation) which provides easier methods for defining service resources (e.g., FaaS, DynamoDB table). Furthermore, IaC/SaC can launch FaaS and manage data, such as initializing database tables, moving files to storage, etc. For example, AWS CloudFormation templates have the ability to launch Lambda functions via Custom Resources.

A Services on Demand (SoD) architecture configures services and manipulates data. SaC providers are beginning to blur the lines between what constitutes application code and services code. Would we permit SaC to modify application data? Would we permit an application to invoke SaC to define and configure services when needed? Code which manages cloud services and data is a new frontier in terms of risk management*, responsibility, and DevSecOps.

*SaC is code with the ability to cause significant negative impact to an organization, either unintentionally or by a malicious actor. Therefore, it should be properly managed and secured.

Looking Ahead: Serverless Event Management and InterCloud

Events are the fuel which causes action in a serverless solution by launching FaaS container instances. FaaS can be invoked by a service event (e.g., AWS S3 Bucket object) or it can poll a service for invocation by an event (e.g., AWS Kinesis stream record). While we can configure event-based services with SaC, serverless architects may want to configure and manage a serverless event environment (e.g., event gateway) for InterCloud applications. As more organizations and government entities utilize the cloud, many will have multi-cloud deployments or need to access services and data from another cloud, especially at the enterprise level.

Conclusion

Serverless architects will design holistic Services on Demand (SoD) solutions using Services as Code (SaC) to configure secured managed services for code, events, and data.

--

--