Serverless Simplified

Synopsis

Serverless is a way to think of a system in terms of individual functions.  In this you can create the services, practices, and strategies.  This enables you to build more agile applications to innovate sooner and respond to change faster. With serverless computing, infrastructure management tasks like capacity provisioning and patching are handled by the service provider, so you can focus on only writing code that serves your customers.

Serverless services like AWS Lambda come with automatic scaling, built-in high availability, and a pay-for-value billing model.

Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices or monoliths. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.

Problem

As mentioned, the goal of a Serverless architecture is to innovate and respond to change faster. However, it still takes considerable work to get to that point.  For even a small to moderate size application, the # of individual core functions to perform fundamental operations quickly gets into the 100s then 1000s.  Writing a few is easy enough, but writing that many is time consuming and really not the best use of time.

Solution

Don’t write them, generate them!

Harbormaster was built to handle the mundane work required to build out the core capabilities of any application, including monolithic, microservices, and Serverless architectures.  The platform can generate all the CRUD serverless functions

As with a microservices implementation, it makes sense to captures the subsystems of the larger system as individual models.  This will ensure loose coupling and the freedom to wire things together in a wide variety of ways.

Serverless Function Strategies

Harbormaster offers 3 serverless function delivery strategies.  Choose the one that works best for the subsystem being considered.

Name	Strategy	Description	Suggested Use Case
Methods Per Class	Individual CRUD methods per model entity	This strategy will expose one Lambda function for each generated CRUD function. This includes create/read/update/delete/getall for each entity along with assign/un-assign for single associations and add/remove for multiple associations	Best used in situations where aggregates will be used in front of this API. The aggregates will handle business functionality leveraging these underlying functions.
Uber Method Per Class	A single method handler per model entity	Each entity will have a single entry point to handle the CRUD functionality.	This provides a good alternatively to the Methods Per Class strategy where the number of Lambda functions will equal the number of model entities.
Uber Method	One single entry point for a subsystem	Each subsystem will have expose exactly one Lambda function	Use this strategy to offer the minimum number of functions for a subsystem. This is ideal for centralized security or when the underlying functions change often or will change.