Operations

  • Magefiles
  • Magefile To support cross platform development and usage, Sparta uses magefiles rather than Makefiles. Most projects can start with the magefile.go sample below. The Magefiles provide a discoverable CLI, but are entirely optional. go run main.go XXXX style invocation remains available as well. Default Sparta magefile.go This magefile.go can be used, unchanged, for most standard Sparta projects. // +build mage // File: magefile.go package main import ( spartaMage "github.com/mweagle/Sparta/magefile" ) // Provision the service func Provision() error { return spartaMage.

  • CloudWatch Alarms
  • The CloudWatchErrorAlarmDecorator associates a CloudWatch alarm and destination with your Lambda function. Sample usage: lambdaFn, _ := sparta.NewAWSLambda("Hello World", helloWorld, sparta.IAMRoleDefinition{}) lambdaFn.Decorators = []sparta.TemplateDecoratorHandler{ spartaDecorators.CloudWatchErrorAlarmDecorator(1, 1, 1, gocf.String("MY_SNS_ARN")), }

  • CloudWatch Dashboard
  • The DashboardDecorator creates a CloudWatch Dashboard that produces a single CloudWatch Dashboard to summarize your stack’s behavior. Sample usage: func workflowHooks(connections *service.Connections, lambdaFunctions []*sparta.LambdaAWSInfo, websiteURL *gocf.StringExpr) *sparta.WorkflowHooks { // Setup the DashboardDecorator lambda hook workflowHooks := &sparta.WorkflowHooks{ ServiceDecorators: []sparta.ServiceDecoratorHookHandler{ spartaDecorators.DashboardDecorator(lambdaFunctions, 60), serviceResourceDecorator(connections, websiteURL), }, } return workflowHooks } A sample dashboard for the SpartaGeekwire project is: Related to this, see the recently announced AWS Lambda Application Dashboard.

  • CodeDeploy Service Update
  • TODO: Document the CodeDeployServiceUpdateDecorator decorator. See also the Deployment Strategy page.

  • CI/CD
  • TODO: Document the SpartaCodePipeline example. Also see the Medium Post

  • Deployment Strategies
  • Document the SpartaSafeDeploy example.

  • Metrics Publisher
  • AWS Lambda is tightly integrated with other AWS services and provides excellent opportunities for improving your service’s observability posture. Sparta includes a CloudWatch Metrics publisher that periodically publishes metrics to CloudWatch. This periodic task publishes environment-level metrics that have been detected by the gopsutil package. Metrics include: CPU Percent used Disk Percent used Host Uptime (milliseconds) Load Load1 (no units) Load5 (no units) Load15 (no units) Network NetBytesSent (bytes) NetBytesRecv (bytes) NetErrin (count) NetErrout (count) You can provide an optional map[string]string set of dimensions to which the metrics should be published.

  • Profiling
  • 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.