Reference

CI/CD

TODO CI/CD with Sparta Document the SpartaCodePipeline example. Also see the Medium Post »

Custom Resources

Introduction In some circumstances your service may need to provision or access resources that fall outside the standard workflow. In this case you can use CloudFormation Lambda-backed CustomResources to create or access resources during your CloudFormation stack’s lifecycle. Sparta provides unchecked access to the CloudFormation resource lifecycle via the RequireCustomResource function. This function registers an AWS Lambda Function as an CloudFormation custom resource lifecycle. In this section we’ll walk through a sample user-defined custom resource and discuss how a custom resource’s outputs can be propagated to an application-level Sparta lambda function. »

Discovery Service

Introduction The ability to provision dynamic infrastructure (see also the SES Event Source Example) as part of a Sparta application creates a need to discover those resources at lambda execution time. Sparta exposes this functionality via sparta.Discover. This function returns information about the current stack (eg, name, region, ID) as well as metadata about the immediate dependencies of the calling go lambda function. The following sections walk through provisioning a S3 bucket, declaring an explicit dependency on that resource, and then discovering the resource at lambda execution time. »

Docker

TODO Docker Support Document the SpartaDocker project. »

Dynamic Infrastructure

Introduction In addition to provisioning AWS Lambda functions, Sparta supports the creation of other CloudFormation Resources. This enables a service to move towards immutable infrastructure, where the service and its infrastructure requirements are treated as a logical unit. For instance, consider the case where two developers are working in the same AWS account. Developer 1 is working on analyzing text documents. Their lambda code is triggered in response to uploading sample text documents to S3. »

Hybrid Topologies

Introduction At a broad level, AWS Lambda represents a new level of compute abstraction for services. Developers don’t immediately concern themselves with HA topologies, configuration management, capacity planning, or many of the other areas traditionally handled by operations. These are handled by the vendor supplied execution environment. However, Lambda is a relatively new technology and is not ideally suited to certain types of tasks. For example, given the current Lambda limits, the following task types might better be handled by “legacy” AWS services: »

Local Testing

While developing Sparta lambda functions it may be useful to test them locally without needing to provision each new code change. You can test your lambda functions using standard go test functionality. To create proper event types, consider: AWS Lambda Go types Sparta types Use NewAPIGatewayMockRequest to generate API Gateway style requests. »

Profiling

Introduction One of Lambda’s biggest strengths, its ability to automatically scale across ephemeral containers in response to increased load, also creates one of its biggest problems: observability. The traditional set of tools used to identify performance bottlenecks are no longer valid, as there is no host into which one can SSH and interactively interrogate. Identifying performance bottlenecks is even more significant due to the Lambda pricing model, where idle time often directly translates into increased costs. »

S3 Sites with CORS

Sparta supports provisioning an S3-backed static website as part of provisioning. We’ll walk through provisioning a minimal Bootstrap website that accesses API Gateway lambda functions provisioned by a single service in this example. The source for this is the SpartaHTML example application. Create the Lambda function We’ll start by creating a very simple lambda function: import ( spartaAPIG "github.com/mweagle/Sparta/aws/apigateway" spartaAWSEvents "github.com/mweagle/Sparta/aws/events" ) type helloWorldResponse struct { Message string Request spartaAWSEvents. »