DEV Community: Alex Casalboni

Graceful degradation in practice: how FeatureOps builds real resilience

Alex Casalboni — Mon, 19 Jan 2026 13:57:00 +0000

Modern software systems fail in interesting and unpredictable ways. A payment provider slows down, an analytics service times out, a third-party API rate-limits you, or a new frontend component crashes on only half your users’ browsers. None of this is unusual anymore. What matters is whether your product collapses with those failures or bends without breaking.

That ability to “bend” is what resilience engineering calls graceful degradation:

The ability of a system to maintain at least some of its functionality when portions are not working, or when certain features are not available. [source: wikitionary]

Instead of failing catastrophically, your system falls back to a reduced but still functional experience. It keeps users moving, it protects your brand, and it buys your team time to react instead of firefighting in panic.

Graceful degradation isn’t one technique. It’s a mindset supported by a handful of practices and techniques such as circuit breakers, timeouts, bulkheads, retries with backoff, and load shedding. These patterns keep systems stable under stress, and FeatureOps becomes the layer that lets you control or modify those behaviors dynamically at runtime. Instead of relying solely on hard-coded logic, you gain the ability to toggle fallback paths, disable risky integrations, or reduce load instantly when conditions change.

In other words: your resilience plan is only as good as your ability to control behavior at runtime. This is where feature flags, kill switches, and progressive rollouts become the foundation of engineering resilience.

Let’s break down how FeatureOps makes graceful degradation real for both frontend and backend systems.

Why graceful degradation matters for modern engineering teams

Most systems today are distributed by default. A typical application might have a frontend calling several internal APIs, backend services relying on third-party platforms, workers consuming external queues, or browser features behaving differently across devices.

On top of that, many products now run A/B tests or ship experimental UI variants directly in production. Every one of these moving parts introduces opportunities for unpredictable behavior, and any one of them can slow down, fail temporarily, or start returning inconsistent results.

The goal of graceful degradation is simple: when something goes wrong, users keep moving and you stay in control.

The end goal is to absorb those failures without derailing the user experience. Instead of crashing or blocking an entire workflow, your system should fall back to cached or partial data, disable a problematic UI element, route traffic to safer fallback logic, or temporarily skip a slow backend dependency.

Sometimes it means turning off a resource-intensive algorithm during peak load, or isolating an experiment variant that behaves differently than expected. The specifics vary, but the outcome is always the same: users keep moving, and you remain in control.

What makes graceful degradation especially important is that it requires action in the moment, before a deployment is possible. When something goes wrong, you rarely have time for a rebuild or a redeploy. You need levers you can pull instantly to adjust behavior in production.

This is exactly where FeatureOps becomes essential. Feature flags, kill switches, and progressive rollout controls turn resilience from an improvised reaction into a deliberate runtime capability.

Everything fails all the time

Everything fails all the time. [Werner Vogels, CTO @ Amazon]

Fault tolerance tries to prevent failures entirely, while graceful degradation accepts that failures will happen and focuses on controlling their impact.

Most modern distributed systems rely on a mix of both approaches. In practice, FeatureOps leans toward the graceful degradation side by giving teams control levers that keep the product usable even when parts of the system are not.

FeatureOps as the backbone of graceful degradation

FeatureOps is all about turning runtime behavior into something you can adjust like a control panel. It gives engineering teams the ability to shape system behavior dynamically, which is exactly what graceful degradation relies on.

When something breaks, slows down, or starts acting strangely, you need a set of controls that let you respond immediately without touching the deployment pipeline. Feature flags help isolate risky functionality so issues stay contained. Kill switches give you a fast way to disable dependencies or non-critical features when they misbehave. Progressive rollouts let you limit blast radius by shifting only a portion of traffic onto new code paths until you’re confident in their stability. And targeting rules help you protect specific segments of users or environments if a problem surfaces.

Together, these capabilities turn runtime behavior into something engineers can manage intentionally rather than reactively. Instead of scrambling to patch production during an incident, teams can adjust traffic, disable unstable features, or reduce load with a few controlled changes. Graceful degradation stops being an emergency tactic and becomes part of your regular operating model.

Designing the right fallback

Designing graceful degradation often comes down to choosing the right fallback. A fallback might be cached data when an API slows down, a simplified UI when a component becomes unstable, or stubbed responses when a dependency is temporarily unavailable.

Feature flags act as the switch deciding when to activate those fallbacks, which keeps the complexity out of your core logic and allows you to adjust behavior without redeploying.

Frontend graceful degradation with FeatureOps

Frontend failures tend to be very visible. A single broken component can block checkout flows, onboarding screens, or dashboards entirely. But with flags, you can disable or replace individual UI behaviors in seconds.

Let’s walk through examples for popular frameworks.

React example: disabling a failing component

Imagine a performance-heavy chart is causing the page to freeze for some users.

import { useEffect } from "react";
import { useFlag, useUnleashClient } from "@unleash/proxy-client-react";

export default function Dashboard({ user }) {
  const client = useUnleashClient();

  useEffect(() => {
    if (!client) return;

    client.updateContext({
      userId: user.id,
      country: user.country, // e.g. "DE"
      plan: user.plan,       // optional segmentation
    });
  }, [client, user]);

  const showAdvancedChart = useFlag("advanced-chart-enabled");

  return (
    <>
      {showAdvancedChart ? <AdvancedChart /> : <FallbackChart />}
    </>
  );
}

If the chart starts throwing errors in production, you flip the flag off. Users immediately see the fallback component. No redeploy. No panic.

Next.js example: gracefully degrading an API-dependent UI component

Suppose you rely on a third-party analytics API that starts timing out.

import { getClient } from "@unleash/nextjs";

const URL = "https://api.example.com/analytics";

export default async function Page({ params }) {
  const user = await fetchUserFromSession();
  const unleash = await getClient();

  const context = {
    userId: user.id,
    properties: {
      country: user.country, // e.g. "UK"
      accountType: user.accountType,
    },
  };

  const useLive = unleash.isEnabled("live-analytics", context);

  let analyticsData;

  if (useLive) {
    try {
      analyticsData = await fetch(URL).then(r => r.json());
    } catch {
      analyticsData = { cached: true };
    }
  } else {
    analyticsData = { cached: true };
  }

  return ;
}

If the provider has an outage, you disable live-analytics and ship cached or partial UI instantly.

Angular example: disabling expensive UI logic

@Component({
  selector: 'app-map',
  template: `
    <app-basic-map></app-basic-map>
    <app-heatmap *ngIf="heatmapEnabled"></app-heatmap>
  `
})
export class MapComponent {
  heatmapEnabled = false;

  constructor(private unleash: UnleashService, private userService: UserService) {
    const user = this.userService.currentUser();

    const context = {
      userId: user.id,
      properties: {
        country: user.country, // e.g. "UK"
        subscription: user.plan
      }
    };

    this.heatmapEnabled = this.unleash.isEnabled('heatmap-feature', context);
  }
}

The heatmap renders only when stable. If it starts freezing low-memory devices, flip the flag off globally or for targeted browser segments.

Backend graceful degradation with FeatureOps

Backend systems often face stress and cascading failures when upstream dependencies degrade. Kill switches and fallback flags prevent complete meltdowns.

Not all degradation is equal. Sometimes you only need to reduce functionality slightly, like showing cached analytics instead of live data. Other times, you disable a full subsystem while keeping the rest of the product operational. Feature flags make both soft and hard degradation possible, and the strategy you choose depends on how critical the failing component is.

Let’s look at common examples.

Node.js example: kill switching a dependency

const express = require("express");
const { unleash } = require("./unleash");

const app = express();

app.get("/payments", async (req, res) => {
  const user = req.user; // however you attach auth info

  const context = {
    userId: user.id,
    properties: {
      country: user.country, // e.g. "UK"
      customerTier: user.tier
    }
  };

  const isLive = unleash.isEnabled("billing-live", context);

  if (!isLive) {
    return res.json({
      status: "degraded",
      message: "Billing temporarily unavailable for your region"
    });
  }

  const result = await billingService.fetch(user.id);
  res.json(result);
});

If the billing provider slows down, disable “billing-live” and your API stays responsive.

Most backend systems also rely on timeouts, retries, and circuit breakers. These help react to issues automatically, but they don’t give you fine-grained control when things go badly. Feature flag kill switches complement these mechanisms by giving engineers the ability to intervene proactively when automated recovery isn’t enough.

Python example: degrading an AI or ML feature

from unleash_client import UnleashClient

client = UnleashClient(
    url="https://unleash.example.com/api",
    app_name="recommender-service"
)
client.initialize_client()

def recommend_products(user):
    context = {
        "userId": str(user.id),
        "properties": {
            "country": user.country, # e.g. "US"
            "segment": user.segment
        }
    }

    if not client.is_enabled("recommender-live", context):
        return fallback_recommendations(user)

    try:
        return call_ml_model(user)
    except TimeoutError:
        return fallback_recommendations(user)

This helps when ML features become slow or overloaded.

Go example: isolate an unstable microservice

import (
    "net/http"
    unleash "github.com/Unleash/unleash-client-go/v4"
)

func (h *Handler) Search(w http.ResponseWriter, r *http.Request) {
    user := userFromRequest(r)

    ctx := context.Context{
        UserId: user.ID,
        Properties: map[string]string{
            "country": user.Country,    // e.g. "DE"
            "plan":    user.Plan,
        },
    }

    q := r.URL.Query().Get("q")

    if !h.Unleash.IsEnabled("use-search-service", unleash.WithContext(ctx)) {
        result := fallbackSearch(q)
        writeJSON(w, result)
        return
    }

    result, err := callSearchService(r.Context(), q)
    if err != nil {
        result = fallbackSearch(q)
    }

    writeJSON(w, result)
}

Same logic. Grace under pressure.

Rust example: controlling CPU-intensive workflows

use unleash_api_client::{UnleashClient, Context};

fn process_image(client: &UnleashClient, user: &User, image: Image) -> Result<Image, Error> {
    let context = Context {
        user_id: Some(user.id.clone()),
        properties: Some(
            [("country".into(), user.country.clone())]  // e.g. "FR"
                .into_iter()
                .collect()
        ),
        ..Default::default()
    };

    if !client.is_enabled("image-optimizer", Some(context)) {
        return Ok(simple_resize(image));
    }

    let optimized = heavy_optimization(image)?;
    Ok(optimized)
}

If errors spike, progressive rollout lets you pause or revert instantly without deploying a fix.

Java example: controlling risky workflows

import io.getunleash.Unleash;
import io.getunleash.UnleashContext;

public class CheckoutService {
    private final Unleash unleash;

    public CheckoutService(Unleash unleash) {
        this.unleash = unleash;
    }

    public CheckoutResult checkout(Order order, User user) {
        UnleashContext context = UnleashContext.builder()
            .userId(user.getId())
            .addProperty("country", user.getCountry())      // e.g. "NO"
            .addProperty("accountType", user.getAccountType())
            .build();

        boolean enabled = unleash.isEnabled("new-checkout-flow", context);

        if (!enabled) {
            return legacyCheckout(order);
        }

        return newCheckout(order);
    }
}

Perfect for isolating checkout problems without a redeploy.

Graceful degradation vs chaos engineering

Chaos engineering is often described as the practice of deliberately introducing failures to ensure systems can withstand them. It focuses on exposing weaknesses in real-world conditions so you don’t discover them for the first time in production at 3 a.m.

Graceful degradation, on the other hand, is what keeps the system usable when those failures actually occur. It’s the safety net that prevents isolated problems from cascading into full outages.

The two ideas complement each other. Chaos experiments reveal where your system is too brittle, while graceful degradation strategies give you a way to absorb that brittleness without harming users. Many teams pair the two by running controlled failure injections and observing how feature flags, fallbacks, kill switches, and rollout strategies behave under stress.

One powerful pattern here is using feature flags to run chaos experiments safely in production. Whether it’s adding network latency, forcing an external dependency to fail, or simulating high CPU load, you can wrap failure injection behind a flag and enable it only for a specific subset of users, services, or environments. That means you can test real integrations and real traffic without exposing your entire customer base to the experiment.

If a dependent API goes down during a chaos test and you can flip a flag to route traffic to a fallback path, you’ve validated both your resilience design and your operational readiness.

FeatureOps provides the runtime switches that make this pairing practical. You can simulate outages or degraded conditions safely, monitor how your system responds, and recover instantly if the experiment uncovers unexpected behavior.

Instead of chaos engineering being a risky exercise, FeatureOps turns it into a controlled, reversible workflow where every failure has an escape hatch.

Progressive rollouts as part of graceful degradation

Graceful degradation isn’t always about turning features off. Sometimes the best way to keep a system stable is to control how much traffic a new component or behavior receives.

Progressive rollouts make this possible by letting you adjust exposure gradually instead of pushing all users onto a new path at once. This helps you understand how a feature behaves under increasing load, identify performance issues early, and contain failures before they affect everyone.

For example, you can release a new search algorithm to a small percentage of users, observe real performance, and increase traffic only when you’re confident it behaves correctly. If you start to see latency spikes or error rates climbing, you can pause the rollout or dial it back to a safer percentage without undoing deployments or reverting code.

This kind of real-time control becomes especially useful when features behave well in staging but reveal unexpected performance characteristics under production traffic. With a progressive rollout, you can treat capacity limits, integration issues, or dependency failures as adjustable variables.

Instead of all-or-nothing decisions, you move through a spectrum of exposure levels. It’s a graceful way to test stability under real conditions while keeping the user experience protected.

Kill switches: the emergency lever every team needs

A kill switch is one of the simplest tools in FeatureOps, yet it often delivers the biggest impact during real incidents.

At its core, a kill switch is just a feature flag dedicated to disabling a specific part of your system when it starts misbehaving. That might mean turning off a third-party integration that’s returning errors, skipping a non-critical workflow that’s consuming too many resources, or shutting down an experimental feature that’s affecting only a portion of users.

The moment a dependency slows down or an external service becomes unreliable, you can flip the switch and instantly redirect your application to a safer fallback path.

What makes kill switches so effective is their flexibility. You can disable functionality for all users or limit the change to a specific region, environment, or percentage of traffic if you need a more controlled response. You can even restrict the impact to certain browsers or API consumers when a problem only manifests under specific conditions. Instead of hotfixing production under pressure, you regain stability with a single, deliberate action.

A well-designed kill switch gives engineers a reliable safety mechanism that buys time, protects customers, and keeps the system usable while deeper issues are investigated.

FeatureOps makes graceful degradation repeatable, not improvisational

The real power of FeatureOps is that it turns graceful degradation into a predictable operating model instead of something teams improvise during an outage.

With flags isolating risky behavior, kill switches ready to shut down failing dependencies, and rollout controls that shape how traffic flows through new code, teams gain the ability to manage production conditions intentionally.

Instead of relying on tribal knowledge or frantic Slack threads when something goes wrong, engineers can react with well-understood patterns: shift traffic away from unstable features, disable problematic integrations, or reduce load by rolling back a percentage of users to a safer path.

As teams mature, graceful degradation can also become partially automated. With impact metrics like error rates, latency, or saturation thresholds, Unleash can pause rollouts or trigger fallbacks automatically. This reduces the time between problem and response even further, especially during off-hours or high-load periods.

This structured approach means resilience isn’t something added later or reserved for crisis moments. It becomes part of day-to-day development.

This is how engineering teams protect uptime without slowing innovation.

And because Unleash is open source and self-hostable, you can embed these patterns deeply into your architecture.

Deep dive: finding the optimal resources allocation for your Lambda functions

Alex Casalboni — Thu, 17 Sep 2020 13:39:25 +0000

Building with a serverless mindset brings many benefits, from high availability to resiliency, pay for value, managed operational excellence, and many more.

You can often achieve cost and performance improvements as well, with respect to more traditional computing platforms.

At the same time, the best practices that allow you to design well-architected serverless applications have been evolving in the last five years. Many techniques have emerged such as avoiding "monolithic" functions, optimizing runtime dependencies, minifying code, filtering out uninteresting events, externalizing orchestration, etc. You can read about many of these practices in the AWS Serverless Application Lens whitepaper (last update: Dec 2019).

In this article, I'd like to dive deep into an optimization technique that I consider particularly useful as it doesn't require any code or architecture refactoring.

I'm referring to optimizing the resource allocation of your Lambda functions.

AWS Lambda resource allocation (power)

You can allocate memory to each individual Lambda function, from 128MB up to 3GB of memory.

Before you stop reading because "who cares about memory utilization?" let me clarify that it's much more appropriate to talk about power rather than memory. Because with more memory also comes more CPU, I/O throughput, etc.

So for the rest of this article, I'm going to call it power. When I say "512MB of power" it will correspond to 512MB of memory for your Lambda function.

So why does it matter?

It matters because more power means that your function might run faster. And with AWS Lambda, faster executions mean cheaper executions too. Since you are charged in 100ms intervals, reducing the execution time often reduces the average execution cost.

For example, let's assume that by doubling the power of your Lambda function from 128MB to 256MB you could reduce the execution time from 310ms to 160ms. This way, you've reduced the billed time from 400ms to 200ms, achieving a 49% performance improvement for the same cost. If you double the power again to 512MB, you could reduce the execution time even further from 160ms to 90ms. So you've halved the billed time again, from 200ms to 100ms, achieving another 44% performance improvement. In total, that's a 71% performance improvement, without changing a single line of code, for the very same cost.

I understand these numbers are quite hard to parse and visualize in your mind, so here's a chart:

The blue line represents our average execution time: 49% lower at 256MB and 71% lower at 512MB. Since Lambda's execution cost is proportional to memory allocation, we'd expect to spend more. But because we are jumping down to 200ms and 100ms respectively, the orange line (cost) is constant.

What if I don't need all that memory?

It doesn't matter how much memory you need. This is the counterintuitive part, especially if you come from a more traditional way of thinking about cost and performance.

Typically, over-provisioning memory means you're wasting resources. But remember, here memory means power 🚀

Our function might need only 50MB of memory to run correctly, and yet we will allocate 512MB so it will run faster for the same money. In other cases, your function might become faster AND cheaper.

Great, but how do I verify this in practice?

I asked myself the very same question in 2017. One day (on March 27th, around 6 PM CEST), I started working on automating this power-tuning process so my team and I could finally take data-driven decisions instead of guessing.

Meet AWS Lambda Power Tuning: github.com/alexcasalboni/aws-lambda-power-tuning 🎉

AWS Lambda Power Tuning is an open-source tool that helps you visualize and fine-tune the power configuration of Lambda functions.

It runs in your AWS account - powered by AWS Step Functions - and it supports multiple optimization strategies and use cases.

The tool will execute a given Lambda function a few times, parse the logs, crunch some numbers, and return the optimal power configuration.

This process is possible in a reasonable time because there is only one dimension to optimize. Today there are 46 different power values to choose from, and the tool allows you to select which values you want to test. In most cases, you can also afford running all the executions in parallel so that the overall execution takes only a few seconds - depending on your function's average duration.

Here's what you need to get started with Lambda Power Tuning:

Deploy the power tuning app via Serverless Application Repository (SAR) - there are other deployment options documented here (for example, the Lumigo CLI or the Lambda Power Tuner UI)
Run the state machine via the web console or API - here's where you provide your function's ARN and a few more options
Wait for the execution results - you'll find the optimal power here
You also get a handy visualization URL - this is how you'll find the sweet spot visually before you fully automate the process

How do I find the sweet spot visually?

Let's have a look at the two examples below.

The red curve is always (avg) execution time, while the blue curve is always (avg) execution cost.

In both cases, I'm checking six common power values: 128MB, 256MB, 512MB, 1GB, etc.

Example 1

In this example, I'm power-tuning a long-running and CPU-intensive function. It runs in 35 seconds at 128MB and in about 3 seconds at 1.5GB. The cost curve is pretty flat and decreases a bit until 1.5GB, then increases at 3GB.

The optimal power value is 1.5GB because it's 11x faster and 14% cheaper with respect to 128MB.

Example 2

The average execution time goes from 2.4 seconds at 128MB to about 300ms at 1GB. At the same time, cost stays precisely the same. So we run 8x faster for the same cost.

Before we proceed with more examples...

Remember: we may not need 1GB or 1.5GB of memory to run the two functions above, but it doesn't matter because in both cases we get much better performance for similar (or even lower) cost.

Also note: if you are a data geek like me, you've probably noticed two more things to remember when interpreting these charts.

The two y-axes (speed and cost) are independent of each other, so the point where the two curves cross each other is not necessarily the optimal value.
Don't assume that untested power values (e.g. 768MB) correspond to the curve's interpolated value - testing additional power values in between might reveal unexpected patterns.

What does the state machine input/output look like?

Here's the minimal input:

{
    "lambdaARN": "your-lambda-function-arn",
    "num": 50
}

But I highly encourage you to check out some of the other input options too (full documentation here):

{
    "lambdaARN": "your-lambda-function-arn",
    "num": 50,
    "parallelInvocation": true,
    "payload": {"your": "payload"},
    "powerValues": [128, 256, 512, 1024, 1536, 3008],
    "strategy": "speed",
    "dryRun": false
}

For special use cases - for example, when you need to power-tune functions with side-effects or varying payloads - you can provide weighted payloads or pre/post-processing functions.

Here's what the output will look like (full documentation here):

{
  "results": {
    "power": "512",
    "cost": 0.0000002083,
    "duration": 2.906,
    "stateMachine": {
      "executionCost": 0.00045,
      "lambdaCost": 0.0005252,
      "visualization": "https://lambda-power-tuning.show/#<encoded_data>"
    }
  }
}

power, cost, and duration represent the optimal power value and its corresponding average cost and execution time.

stateMachine contains details about the state machine execution itself such as the cost related to Step Functions and Lambda. This information is particularly useful if you want to keep track of optimization costs without surprises - although typically, we are talking about $0.001 for the whole execution (excluding additional costs that your function might generate invoking downstream services).

Last but not least, you'll find the visualization URL (under lambda-power-tuning.show), an open-source static website hosted on AWS Amplify Console. If you don't visit that URL, nothing happens. But even when you visit the URL, there is absolutely no data sharing to any external server or service. The <encoded_data> mentioned above only contains the raw numbers needed for clientside visualization, without any additional information about your Account ID, function name, or tuning parameters. You are also free to build your custom visualization website and provide it at deploy-time as a CloudFormation parameter.

Show me more examples, please!

Depending on what your function is doing, you'll find completely different cost/performance patterns. With time, you'll be able to identify at first glance which functions might benefit the most from power-tuning and which aren't likely to benefit much.

I encourage you to build a solid hands-on experience with some of the patterns below, so you'll learn how to categorize your functions intuitively while coding/prototyping. Until you reach that level of experience and considering the low effort and cost required, I'd recommend power-tuning every function and playing a bit with the results.

Cost/Performance patterns

I've prepared a shortlist of 6 patterns you may encounter with your functions.

Let's have a look at some sample Lambda functions and their corresponding power-tuning results. If you want to deploy all of them, you'll find the sample code and SAM template here.

1) The No-Op (trivial data manipulation)

When I say No-op functions, I mean functions that do very little, and they are more common than you might think. It happens pretty often that a Lambda function is invoked by other services to customize their behavior, and all you need is some trivial data manipulation. Maybe a couple of if's or a simple format conversion - no API calls or long-running tasks.

Here's a simple example:

def lambda_handler(event, context):
    print("NOOP")
    response = 'OK'
    if event['something'] == 'KO':
        response = 'KO'
    return {
        'output': response
    }

This kind of function will never exceed 100ms of execution time. Therefore, we expect its average cost to increase linearly with power.

(click on the image to open the interactive visualization)

Even though there is no way to make no-op functions cheaper, sometimes you can make them run 3-5x faster. In this case, it might be worth considering 256MB of power, so it runs in less than 2ms instead of 5ms. If your function is doing something more than a simple if, you might see a more significant drop - for example, from 30ms to 10ms.

Does it make sense to pay a bit more just to run 20ms faster? It depends :)

If your system is composed of 5-10 microservices that need to talk to each other, shaving 20ms off each microservice might allow you to speed up the overall API response by a perceivable amount, resulting in a better UX.

On the other hand, if this function is entirely asynchronous and does not impact your final users' experience, you probably want to make it as cheap as possible (128MB).

2) The CPU-bound (numpy)

This function requires numpy, a very common Python library for scientific computing - which is available as an official Lambda layer.

import numpy as np

# make this execution reproducible
np.random.seed(10)

def lambda_handler(event, context):
    # create a random matrix (1500x1500)
    matrix = np.random.rand(1500, 1500)

    # invert it (this is CPU-intensive!)
    inverted_matrix = np.linalg.inv(matrix)

    print(inverted_matrix)
    return {'OK': 'OK'}

The function creates a random matrix (1500 rows, 1500 columns) and then inverts it.

So we are talking about a very CPU-intensive process that requires almost 10 seconds with only 128MB of power.

The good news is that it will run much faster with more memory. How much faster? Check the chart below.

(click on the image to open the interactive visualization)

Yes, it will run almost 21x faster (2100%) with 3GB of power. And that's for a cost increase of only 23%.

Let me repeat that: we can run this function in 450ms instead of 10 seconds if we're happy about paying 23% more.

If you can't afford a 23% cost increase, you can still run 2x faster for a 1% cost increase (256MB). Or 4x faster for a 5% cost increase (512MB). Or 7x faster for a 9% cost increase (1GB).

Is it worth it? It depends :)

If you need to expose this as a synchronous API, you probably want it to run in less than a second.

If it's just part of some asynchronous ETL or ML training, you might be totally fine with 5 or 10 seconds.

The important bit is that this data will help you find the optimal trade-off for your specific use case and make an informed decision.

Note: the numbers above do not take into consideration cold starts. By default, Lambda Power Tuning ignores cold executions, so all these averages are not biased. This allows you to reason about the largest majority of (warm) executions.

3) The CPU-bound (prime numbers)

Let's consider another long-running function. This function also uses numpy to compute the first 1M prime numbers for 1k times in a row.

import numpy as np

def lambda_handler(event, context):
    # do the same thing 1k times in a row
    for i in range(1000):
        # compute the first 1M prime numbers
        primes = compute_primes_up_to(1000000)
    return {'OK': 'OK'}

def compute_primes_up_to(n):
    # this is the fastest single-threaded algorithm I could find =)
    # from https://stackoverflow.com/questions/2068372/fastest-way-to-list-all-primes-below-n-in-python/3035188#3035188
    sieve = np.ones(int(n/3) + (n%6==2), dtype=np.bool)
    sieve[0] = False
    for i in range(int(int(n**0.5)/3+1)):
        if sieve[i]:
            k=3*i+1|1
            sieve[   int((k*k)/3)      ::2*k] = False
            sieve[int((k*k+4*k-2*k*(i&1))/3)::2*k] = False
    return np.r_[2,3,((3*np.nonzero(sieve)[0]+1)|1)]

The function takes almost 35 seconds to run with only 128MB of power.

But good news again! We can make it run much much faster with more memory. How much faster? Check the chart below.

(click on the image to open the interactive visualization)

Yes, it will run more than 14x faster (1400%) with 1.5GB of power. And that's with a cost DECREASE of 13.9%.

Let me repeat that: we can run this function in 2 seconds instead of 35 seconds, while at the same time we make it cheaper to run.

We could make it even faster (17x faster instead of 14x) with 3GB of power, but unfortunately the algorithm I found on StackOverflow cannot leverage multi-threading well enough (you get two cores above 1.8GB of power), so we'd end up spending 43% more.

This could make sense in some edge cases, but I'd still recommend sticking to 1.5GB.

Unless...

Unless there was an even more optimal power value between 1.5GB and 3GB. We aren't testing all the possible power values. We are trying only 6 of them, just because they are easy to remember.

What happens if we test all the possible values? We know that our best option is 1.5GB for now, but we might find something even better (faster and cheaper) if we increase the granularity around it.

{
    "lambdaARN": "your-lambda-function-arn",
    ....
    "powerValues": "ALL",
    ....
}

Here's what happens if you test all the possible values:

(click on the image to open the interactive visualization)

It turns out the (global) sweet spot is 1.8GB - which allows us to run 16x faster and 12.5% cheaper.

Or we could pick 2112MB - which is 17x faster for the same cost of 128MB (still 20ms slower than 3GB, but for a better avg cost).

Remember: when you see an increasing or decreasing trend (cost or speed), it's likely it will continue for a while also for power values you aren't testing. Generally, I'd suggest increasing your tuning granularity to find globally optimal values.

4) The Network-bound (3rd-party API)

Let's move on and talk about a first network-bound example. This function interacts with an external API, an API that's public and not hosted on AWS: The Star Wars API.

import json
import urllib.request

# this is my (public) third-party API
URL = 'https://swapi.dev/api/people/?format=json'

def lambda_handler(event, context):
    # prepare request
    req = urllib.request.Request(URL)

    # fetch and parse JSON
    with urllib.request.urlopen(req) as response:
        json_response = json.loads(response.read())

    # extract value from JSON response
    count = json_response['count']

    return {
        'count': count,
    }

The function performs a GET request to fetch the number of characters available via the Star Wars API (we could have used the official swapi-python library for a higher-level interface, but that wasn't the point).

As we could have predicted, this external API's performance isn't impacted at all by the power of our Lambda function. Even though additional power means more I/O throughput, we are only fetching 5KB of data, so most of the execution time is spent waiting for the response, not transferring data.

(click on the image to open the interactive visualization)

The red curve above is pretty flat and the blue curve is always increasing, which means we cannot do much to speed up this function or make it cheaper.

We might save 50-100 milliseconds with additional power, but usually that's not enough to reduce the cost or keep it constant.

In this case, we can run a little bit faster with 256MB or 512MB of power - up to 16% faster if we're happy to triple the average execution cost.

Is it worth it? It depends.

If your monthly Lambda bill is something like $20, how do you feel about bumping it to $60 and run a customer-facing function 15-20% faster? I would think about it.

If it's not a customer-facing API, I'd stick to 128MB and make it as cheap as possible. And there might be other factors at play when it comes to third-party APIs. For example, you may need to comply with some sort of rate-limiting; if you're performing batches of API calls in series, a function that runs slower might be a good thing.

5) The Network-bound (3x DynamoDB queries)

This pattern is pretty common. Every time our function uses the AWS SDK to invoke a few AWS services and coordinate some business logic. We are still talking about a network-bound function, but it shows a different pattern. In this case, we are performing three dynamodb:GetItem queries in sequence, but the same pattern holds with other services such as SNS or SQS.

import boto3

dynamodb = boto3.client('dynamodb')

def lambda_handler(event, context):

    # three identical queries in series
    # this is just an example
    # usually you'd have 3 different queries :)
    for i in range(3):
        response = dynamodb.get_item(
            TableName='my-table',
            Key={
                'id': {
                    'S': 'test-id',
                }
            }
        )
        message = response['Item']['message']

    return {
        'message': message,
    }

We are talking about AWS services, quite likely operating in the same AWS region. So our API calls won't leave the data center at all.

Surprisingly, we can make this function run much faster with additional power: this pattern is very similar to the first example we analyzed at the beginning of this article.

(click on the image to open the interactive visualization)

The function runs in about 350ms at 128MB, 160ms at 256MB, and 45ms at 512MB.

In practice, every time we double its power we also halve the billed time, resulting in constant price until 512MB.

After that, we cannot make it cheaper, so 512MB is our sweet spot.

But we could get an additional 40% performance improvement (28ms execution time) at 3GB, if we are ready to pay 6x more. As usual, this tradeoff is up to you and it depends on your business priorities. My suggestion is to adopt a data-driven mindset and evaluate your options case by case.

6) The Network-bound (S3 download - 150MB)

This is not a very common pattern, as downloading large objects from S3 is not a typical requirement. But sometimes you really need to download a large image/video or a machine learning model, either because it wouldn't fit in your deployment package or because you receive a reference to it in the input event for processing.

import os
import boto3

s3 = boto3.client('s3')

# from the Amazon Customer Reviews Dataset
# https://s3.amazonaws.com/amazon-reviews-pds/readme.html
BUCKET = 'amazon-reviews-pds'
KEY = 'tsv/amazon_reviews_us_Watches_v1_00.tsv.gz'
LOCAL_FILE = '/tmp/test.gz'

def lambda_handler(event, context):
    # download 150MB (single thread)
    s3.download_file(BUCKET, KEY, LOCAL_FILE)
    bytes = os.stat(LOCAL_FILE).st_size

    total = bytes / 1024 / 1024
    unit = 'MB'
    if total > 1024:
        total = total / 1024
        unit = 'GB'

    # print "Downloaded 150MB"
    print("Downloaded %s%s" % (round(total, 2), unit))
    return {'OK': 'OK'}

Because we are trying to store a lot of data in memory, we won't test lower memory configurations such as 128MB and 256MB.

At first glance, the cost/performance pattern looks quite similar to our fist network-bound example: additional power doesn't seem to improve performance. Execution time is pretty flat around 5 seconds, therefore cost always increases proportionally to the allocated power (at 3GB it's almost 5x more expensive on average).

(click on the image to open the interactive visualization)

From this chart, it looks like we can't do much to improve cost and performance. If we go for 1GB of power, we'll run 23% faster for a cost increase of 55%.

Can we do better than this?

Good news: this kind of workload will run much faster with a very simple code change:

# download 150MB from S3 with 10 threads
transfer_config = boto3.s3.transfer.TransferConfig(max_concurrency=10)
s3.download_file(BUCKET, KEY, LOCAL_FILE, Config=transfer_config)

With the new code above, we're simply providing a custom TransferConfig object to enable multi-threading.

Now the whole process will complete a lot faster by parallelizing the file download with multiple threads, especially since we get two cores above 1.8GB of power.

Here's the new cost/performance pattern:

(click on the image to open the interactive visualization)

Not only is the pattern very different, but the absolute numbers are much better too. We run in 4.5 seconds at minimum power (which is already 10% faster than what we could do before at maximum power). But then it gets even better: we run another 40% faster at 1GB for a cost increase of 23%.

Surprisingly, we run almost 4x faster (1.1 seconds) at 3GB of power. And that's for the same cost (+5%) with respect to the single-threaded code at 512MB.

Let me rephrase it: adding one line of code allowed us to run 4x faster for the same cost.

And if performance didn't matter in this use case, the same change would allow us to make this function 45% faster AND 47% cheaper with minimum power (512MB).

I believe this is also an interesting example where picking a specific programming language might result in better performance without using additional libraries or dependencies (note: you can achieve the same in Java with the TransferManager utility or in Node.js with the S3 Managed Download module).

Conclusions

We've dived deep into the benefits of power-tuning for AWS Lambda: it helps you optimize your Lambda functions for performance or cost. Sometimes both.

Remember that memory means power and there is no such thing as over-provisioning memory with AWS Lambda. There is always an optimal value that represents the best trade-off between execution time and execution cost.

I've also introduced a mental framework to think in terms of workload categories and cost/performance patterns, so you'll be able to predict what pattern applies to your function while you are coding it. This will help you prioritize which functions might be worth optimizing and power-tuning.

AWS Lambda Power Tuning is open-source and very cheap to run. It will provide the information and visualization you need to take a data-driven decision.

Thanks for reading, and let me know if you find new exciting patterns when power-tuning your functions.

How to live-stream meetups on Twitch without any special equipment 🚀

Alex Casalboni — Mon, 16 Mar 2020 13:32:45 +0000

Translations: [Spanish]

This is a true (fun) story that evolved in the last 10 days. I hope it will be both useful and entertaining for everyone who wants to convert their in-person events into remote meetups on Twitch.

TL;DR: direct link to technical & architectural details :)

I'm a software engineer and AWS developer advocate based in Italy, and in the last few weeks I've been working from home because of COVID-19. I've been co-organizing the serverless meetup in Milan since 2016 with a great team of four co-organizers.

Last week we started experimenting with Twitch as our platform of choice for live-streaming our upcoming meetups and give our virtual attendees a chance to communicate and share doubts & ideas in the live chat. We already knew we should use OBS to handle the stream, personalize scenes, etc. - but didn't have much experience with it, so we ran a few tests.

Test #1 - don't do this at home 💥

Very naively, I tried to live-stream from my own laptop (MacBook) using OBS. Since OBS can't use any optimized encoder for live-streaming on MacOS, I almost killed my laptop after only 8 minutes.

So it was pretty clear that we also needed some kind of "special hardware". We asked around and were recommended to run OBS on a PC (Windows) with better CPU performance and ideally a GPU as well.

Because we wanted to allow multiple concurrent speakers, we understood pretty soon that we needed some sort of video call "bridge" and then we could simply stream that into Twitch. So I quickly set up a room on Amazon Chime.

Test #2 — it worked, but low quality 👍👎

Our co-organizer Simone live-streamed a Chime call from his office desktop PC (Windows) using OBS to capture the video stream from Chime. It worked quite well, both video and audio were streamed successfully as I shared my screen (PowerPoint + local IDE). Though, since we were simply screencasting a Chime call (not a native video feed), the scene was pretty basic and the resulting video quality was too low to clearly see small text & code.

So we were lost for a few hours, but another friend from Italy (thanks Gianluca!) told me that there was another option: since 2018, Skype supports the NDI protocol, which allows you to feed the Skype video/audio streams directly into OBS as a native source and hopefully achieve better quality. This sounded promising so we decided to test it too.

Test #3 — much better, but... 😱

Simone and I created a new Skype room, installed the NDI Plugin for OBS and ran another test from his office PC. It took a while to configure OBS correctly, but ultimately it worked pretty well and thanks to NDI the video quality was much better!

So we went on, confirmed the two speakers, published the event on Meetup.com and LinkedIn, and couldn't wait to finally live-stream our first meetup online.

But then the COVID-19 situation here in Italy escalated even more and overnight we found out that we were stuck at home for at least 3-4 weeks, which meant Simone couldn't reach his office and we were suddenly without a streaming PC 😱

Test #4 — a cloudy idea 💡

This is the part of the story where my personal aversion for hardware and my job title become very useful: WE COULD USE THE CLOUD 💡☁️💡

All we needed was a DaaS (Desktop as a Service) alternative to Simone's PC, so I decided to give Amazon Workspaces a try!

Amazon Workspaces is a DaaS solution offered by AWS since 2014. It allows you to spin up Windows or Linux instances in the cloud and connect via browser or using a desktop client, which is available for MacOS, Windows, and Linux. There are multiple bundles you can choose from depending on your performance requirements. Also, there is no up-front commitment and you can choose either the monthly or hourly billing option. For remote meetups, the hourly option (plus a much smaller monthly fee) is great because 3-4 hours per month should be more than enough for a couple of events.

We knew that our performance requirements were quite high, so we started with a Windows PowerPro bundle — 8 vCPU, 32 GiB Memory for $7.25/month + $1.49/hour. This way, our first online meetup would cost us less than $10 and we were happy with that.

The first test with Amazon Workspaces went better than expected, we managed to quickly install all the software on the cloud instance and launch a test stream in less than 30min. Unfortunately, the lack of GPU and Video Memory in the PowerPro bundle resulted in high frame loss and very high CPU usage, corresponding to lagging audio and video.

We needed a more powerful bundle.

Test #5 — Workspaces Graphics to the rescue 💪

The two most powerful bundles are Graphics and GraphicsPro (full list here):

Graphics comes with 8 vCPU, 15 GiB Memory, 1 GPU, 4 GiB Video Memory - for $22/month + $1.75/hour
GraphicsPro comes with 16 vCPU, 122 GiB Memory, 1 GPU, 8 GiB Video Memory — for $66/month + $11.62/hour

We were quite confident that a Graphics instance would be enough and still allow us to keep the monthly cost below $30 (wrt $80+/month for the GraphicsPro instance). So we decided to give the Graphics instance a try.

We ran the next test on Amazon Workspaces Graphics with the very same configuration and it worked great! No frame loss on Twitch, very good video and audio quality, and fairly low CPU usage on the instance.

At this point we had only 24 hours to run a few additional tests before going live with our first online meetup on Thursday, Mar 12th at 6.30 PM CET.

So we did run a few more tests with multiple speakers sharing both audio and video, as well as their screen with flawless take-over, a few backup scenes on OBS, some background noice reduction filters, and we were ready.

We went live on Twitch without a hassle 🙌

On Mar 12th we hosted two great speakers and welcomed more than 170 unique viewers during the stream of 1 hour and 42 minutes, with a peak of 109 concurrent viewers 🎉 (recording here, in Italian 🇮🇹)

Thanks to the built-in Twitch chat we could also take live questions and host a quick Q&A at the end of the meetup, with the supports of both co-organizers and speakers.

Furthermore, as meetup organizers we loved this setup because our attendees didn't have to install any software or browser extensions. In fact, they didn't even have to sign up on Twitch to watch the stream.

Last but not least, nobody depended on any special hardware which means we can organize as many events as we want, wherever we are in the world — as long as at least one of us can start the broadcast via the Workspaces client and connect to the video call to introduce the speakers.

Technical and architectural details ⚙️

This is the final setup we used, with 2 co-organizers and 2 speakers connected to the bridge, plus one additional co-organizer connected to Workspaces to change scenes under the hood, and a fourth co-organizer helping with the Twitch chat moderation. You don't really need 4 people, but I'd say it really helps if you have at least 2.

Here's a shortlist of technical steps you can follow:

Create an AWS Account
Install the Workspaces client on your local machine
Spin up the Workspaces instance — it will take a few minutes
Install OBS (32 bits), the OBS NDI plugin, and Skype on the Workspaces instance
Enable NDI in the Skype client 👉 Settings - Calling - Advanced - Allow NDI usage (video instructions here)
Configure OBS with scenes including audio & video from NDI source — this also takes a while but it's much easier if you do it during a video call so you can quickly see the audio/video preview in OBS
Create a Twitch account
Fetch the Twitch stream key from your account's settings, and configure it in OBS

We also have a few lessons learned to share, so I recommend reading the tips & tricks section below before starting with your own setup.

Tips & Tricks for OBS & Amazon Workspaces

The story above is a quick summary of the various steps which led us to the final solution. The list below contains some tips so you can achieve the same faster and without much frustration:

You may need to request a service limit increase in your AWS account to be able to spin up 1 Graphics instance on Amazon Workspaces
If you are using a Linux machine locally, you'll need to enable the Workspaces Linux client in your AWS Console (it's just a checkbox)
It looks like the OBS NDI plugin is incompatible with OBS 64bit, so make sure you've installed the 32bit version if nothing works
It's much easier if you have an independent Skype profile running on Workspaces (you can't join a call twice with the same profile)
Remember to mute the Workspaces machine in the bridge and also in OBS
If your speakers don't have a professional microphone, you can enable the OBS noise reduction filter (see instructions here)
If you are the only speaker, running everything on your laptop (Skype + Workspaces + PowerPoint + ...) might slow down the whole thing and eventually crash your laptop (true story!) — that's why we'd recommend at least two people/laptops
The NDI plugin for OBS can use the "current speaker" webcam as audio/video source, so you don't have to prepare one scene per speaker and manually switch every time a new speaker starts talking
You can use a service like restream.io to stream to Twitch, Periscope, and YouTube concurrently
After the first meetup we have also tested in-browser solutions such as LightStream Studio and StreamYard - these tools come with an easier in-browser setup, but we realized they don't really work for us because we want to have more control over the overall scenes/audio/video setup

How to configure OBS 📹

Configuring OBS might be the most challenging step if you've never used it, so I'd recommend spending some time learning it. You can check this official quickstart or this in-depth series of videos.

To speed things up even more, you may want to reuse and adapt our OBS profile and scene collection. You can find both here.

The zip file contains two important artifacts:

a folder named "Serverless Meetup" — this is the OBS profile that you can import ( Profile > Import ) and then select from the same Profile menu
a JSON file named "serverless-meetup-obs-preset.json" — this is the OBS scene collection that you can import ( Scene collection > Import ) and then select from the same Scene collection menu

Final thoughts 🤔

We've been pretty happy with this setup and we have collected a lot of positive feedback from our online attendees. We'll keep using this setup for our next serverless meetups online and maybe try to virtually meet even more often now that we have a cloud-based and easy-to-share setup.

I personally hope this article will help many meetup organizers to keep their groups active and motivated during these challenging times. We don't have to sacrifice our communities only because we can't meet in person.

If you're curious about details I haven't mentioned in this article or if you have other ideas to share please feel free to reach out to me on Twitter or drop a comment below.

Translations: [Spanish]

How to FaaS like a pro: 12 less common ways to invoke your serverless functions on Amazon Web Services [Part 3]

Alex Casalboni — Wed, 30 Oct 2019 20:47:46 +0000

“I really like the peace of mind of building in the cloud” cit. myself [Photo by Kaushik Panchal on Unsplash]

This is the last part of my FaaS like Pro series, where I discuss and showcase some less common ways to invoke your serverless functions with AWS Lambda.

You can find [Part 1] here — covering Amazon Cognito User Pools, AWS Config, Amazon Kinesis Data Firehose, and AWS CloudFormation.

And [Part 2] here — covering AWS IoT Button, Amazon Lex, Amazon CloudWatch Logs, and Amazon Aurora.

In the third part I will describe four more:

AWS CodeDeploy — pre & post deployment hooks
AWS CodePipeline — custom pipeline actions
Amazon Pinpont — custom segments & channels
AWS ALB (Application Load Balancer) — HTTP target

9. AWS CodeDeploy (pre/post-deployment hooks)

CodeDeploy is part of the AWS Code Suite and allows you automate software deployments to Amazon EC2, AWS Fargate, AWS Lambda, and even on-premises environments.

Not only it enables features such as safe deployments for serverless functions, but it also integrates with Lambda to implement custom hooks. This means you can inject custom logic at different steps of a deployment in order to add validation, 3rd-party integrations, integrations tests, etc. Each hook runs only one per deployment and can potentially trigger a rollback.

You can configure different lifecycle event hooks, depending on the compute platform (AWS Lambda, Amazon ECS, Amazon EC2 or on-premises).

AWS Lambda

BeforeAllowTraffic — runs before traffic is shifted to the deployed Lambda function
AfterAllowTraffic — runs after all traffic has been shifted

Amazon ECS & Amazon EC2/on-premises

See the full documentation here.

Amazon ECS and EC2 have a more complex deployment lifecycle, while Lambda follows a simple flow: Start > BeforeAllowTraffic > AllowTraffic > AfterAllowTraffic > End. In this flow, you can inject your custom logic before traffic is shifted to the new version of your Lambda function and after all traffic is shifted.

For example, we could run some integration tests in the BeforeAllowTraffic hook. And we could implement a 3rd-party integration (JIRA, Slack, email, etc.) in the AfterAllowTraffic hook.

Let’s have a look at a sample implementation of a Lambda hook for CodeDeploy:

The code snippet above doesn’t do much, but it shows you the overall hook structure:

It receives a DeploymentId and LifecycleEventHookExecutionId that you’ll use to invoke CodeDeploy’s PutLifecycleEventHookExecutionStatus API
The execution status can be either Succeeded or Failed
You can easily provide an environment variable to the hook function so that it knows which functions we are deploying and what’s its ARN

I’d recommend defining the hook functions in the same CloudFormation (or SAM) template of the function you’re deploying. This way it’s very easy to define fine-grained permissions and environment variables.

For example, let’s define an AWS SAM template with a simple Lambda function and its corresponding Lambda hook:

The template above is defining two functions:

myFunctionToBeDeployed is our target function, the one we’ll be deploying with AWS CodeDeploy
preTrafficHook is our hook, invoked before traffic is shifted to myFunctionToBeDeployed during the deployment

I’ve configured two special properties on myFunctionToBeDeployed called DeploymentPreference and AutoPublishAlias . These properties allows us to specify which deployment type we want (linear, canary, etc.), which hooks will be invoked, and which alias will be used to shifting the traffic in a weighted fashion.

A few relevant details about the pre-traffic hook definition:

I am defining an environment variable named NewVersion which will contain the ARN of the newly deployed function, so that we could invoke it and run a some tests
preTrafficHook needs IAM permissions to invoke the codedeploy:PutLifecycleEventHookExecutionStatus API and I’m providing fine-grained permissions by referencing the deployment group via ${ServerlessDeploymentApplication}
since we want to run some tests on the new version of myFunctionToBeDeployed, our hook will need IAM permissions to invoke thelambda:invokeFunction API, and I’m providing fine-grained permissions by referencing myFunctionToBeDeployed.Version

In a real-world scenario, you may want to set up a proper timeout based on which tests you’re planning to run and how long you expect them to take.

In even more complex scenarios, you may event execute an AWS Step Functions state machine that will run multiple tasks in parallel before reporting the hook execution status back to CodeDeploy.

Last but not least, don’t forget that you can implement a very similar behaviour for non-serverless deployments involving Amazon ECS or EC2. In this case, you’ll have many more hooks available such as BeforeInstall, AfterInstall, ApplicationStop, DownloadBundle, ApplicationStart, ValidateService, etc (full documentation here).

10. AWS CodePipeline (custom action)

CodePipeline is part of the AWS Code Suite and allows you to design and automate release pipelines (CI/CD). It integrates with the other Code Suite services such as CodeCommit, CodeBuild, and CodeDeploy, as well as popular 3rd-party services such as GitHub, CloudBees, Jenkins CI, TeamCity, BlazeMeter, Ghost Inspector, StormRunner Load, Runscope, and XebiaLabs.

In situations when built-in integrations don’t suit your needs, you can let CodePipeline integrate with your own Lambda functions as a pipeline stage. For example, you can use a Lambda function to verify if a website’s been deployed successfully, to create and delete resources on-demand at different stages of the pipeline, to back up resources before deployments, to swag CNAME values during a blue/green deployment, and so on.

Let’s have a look at a sample implementation of a Lambda stage for CodePipeline:

The function will receive three main inputs in the CodePipeline.job input:

id — the JobID required to report success or failure via API
data.actionConfiguration.configuration.UserParameters — the stage dynamic configuration; you can think of this as an environment variable that depends on the pipeline stage, so you could reuse the same function for dev, test, and prod pipelines
context.invokeid — the invocation ID related to this pipeline execution, useful for tracing and debugging in case of failure

In the simple code snippet above I am doing the following:

Verify that the given URL is valid
Fetch the URL via HTTP(S)
Report success via the CodePipeline putJobSuccessResult API if the HTTP status is 200
Report failure via the CodePipeline putJobFailureResult API in case of errors — using different error messages and contextual information

Of course, we could extend and improve the validation step, as well as the URL verification. Receiving a 200 status is a very minimal way to verify that our website was deployed successful. Here we could add automated browser testing and any other custom logic.

It’s also worth remembering that you can implement this logic in any programming language supported by Lambda (or not). Here I’ve used Node.js but the overall structure wouldn’t change much in Python, Go, C#, Ruby, Java, PHP, etc.

Now, let me show you how we can integrate all of this into a CloudFormation template (using AWS SAM as usual):

In the template above I’ve defined three resources:

An AWS::Serverless::Function to implement our custom pipeline stage; note that it will require IAM permissions to invoke the two CodePipeline API’s
An AWS::CodePipeline::Pipeline where we’d normally add all our pipeline stages and actions; plus, I’m adding an action of type Invoke with provider Lambda that will invoke the myPipelineFunction function
An AWS::Lambda::Permission that grants CodePipeline permissions to invoke the Lambda function

One more thing to note: in this template I’m not including the IAM role for CodePipeline for brevity.

You can find more details and step-by-step instructions in the official documentation here.

11. Amazon Pinpoint (custom segments & channels)

Amazon Pinpoint is a managed service that allows you to send multi-channel personalized communications to your own customers.

Pinpoint natively supports many channels including email, SMS (in over 200 countries), voice (audio messages), and push notifications (Apple Push Notification service, Amazon Device Messaging, Firebase Cloud Messaging, and Baidu Cloud Push).

As you’d expect, Pinpoint allows you to define users/endpoints and messaging campaigns to communicate with your customers.

And here’s where it nicely integrates with AWS Lambda for two interesting use cases:

Custom segments — it allows you to dynamically modify the campaign’s segment at delivery-time , which means you can implement a Lambda function to filter out some of the users/endpoints to engage a more narrowly defined subset of users, or even to enrich users’ data with custom attributes (maybe coming from external systems)
Custom channels — it allows you to integrate unsupported channels such as instant messaging services or web notifications, so you can implement a Lambda function that will take care of the message delivery outside of Amazon Pinpoint

Let’s dive into both use cases!

Note: both use cases are still in beta and some implementation details are still subject to change

11.A — How to define Custom Segments

We can connect a Lambda function to our Pinpoint Campaign and dynamically modify, reduce, or enrich our segment’s endpoints.

Our Lambda function will receive a structured event:

The important section of the input event is the set of Endpoints. The expected output of our function is a new set of endpoints with the same structure. This new set might contain fewer endpoints and/or new attributes as well. Also note that our function will receive at most 50 endpoints in a batch fashion. If you segment contains more than 50 endpoints, the function will be involved multiple times.

For example, let’s implement a custom segment that will include only the APNS channel (Apple) and generate a new custom attribute named CreditScore:

The code snippet above is iterating over the given endpoints and dynamically modify the set before returning it back to Amazon Pinpoint for delivery.

For each endpoint, we are excluding it from the set if it’s not APNS (just as an example), then we are generating a new CreditScore attribute only for active endpoints.

Let’s now define the CloudFormation template for our Pinpoint app:

The important section of the template above is the CampaignHook attribute of the AWS::Pinpoint::Campaign resource. We are providing the Lambda function name and configuring it with Mode: FILTER. As we’ll see in the next section of this article, we are going to use Mode: DELIVERY to implement custom channels.

In case we had multiple campaigns that required the same custom segment, we could centralize the CampaignHook definition into an AWS::Pinpoint:ApplicationSettings resource:

This way, all the campaigns in our Pinpoint application will inherit the same Lambda hook.

You can find the full documentation here.

11.B — How to define Custom Channels

We can connect a Lambda function to our Pinpoint Campaign to integrate unsupported channels. For example, Facebook Messenger or even your own website backend to show in-browser notifications.

To define a custom channel we can use the same mechanism described above for custom segments, but using Mode: DELIVERY in our CampaignHook configuration. The biggest difference is that Pinpoint won’t deliver messages itself, as our Lambda hook will take care of that.

Our function will receive batches of 50 endpoints, so if you segment contains more than 50 endpoints the function will be involved multiple times (round(N/50) times to be precise).

We will receive the same input event:

Our Lambda function will need to iterate through all the given Endpoints and deliver messages via API.

Let’s implement the Lambda function that will deliver messages to FB Messenger, in Node.js:

The code snippet above defines a few configuration parameters, that I’d recommend storing on the AWS SSM Parameter Store or AWS Secrets Manager, here hard-coded for brevity.

The Lambda handler is simply iterating over event.Endpoints and generating an async API call for each one. Then we run all the API calls in parallel and wait for their completion using await Promise.all(...).

You could start from this sample implementation for FB Messenger and adapt it for your own custom channel by editing the deliver(message, user) function.

Let’s now define the CloudFormation template for our Pinpoint app:

The overall structure is the same of custom segments. Only two main differences:

We don’t need to define a channel
We are using DELIVERY for the campaign hook mode

You can find the full documentation here.

12. AWS ALB (Application Load Balancer)

AWS ALB is one of the three type of load balancers supported by Elastic Load Balancing on AWS, together with Network Load Balancers and Classic Load Balancers.

ALB operates at the Layer 7 of the OSI model, which means it has the ability to inspect packets and HTTP headers to optimize its job. It was announced in August 2016 and it introduced popular features such as content-based routing, support for container-based workloads, as well as for WebSockets and HTTP/2.

Since Nov 2018, ALB supports AWS Lambda too, which means you can invoke Lambda functions to serve HTTP(S) traffic behind your load balancer.

For example — thanks to the content-based routing feature — you could configure your existing application load balancer to serve all traffic under /my-new-feature with AWS Lambda, while all other paths are still served by Amazon EC2, Amazon ECS, or even on-premises servers.

While this is great to implement new features, it also opens up new interesting ways to evolve your compute architecture over time without necessarily refactoring the whole application. For example, by migrating one path/domain at a time transparently for your web or mobile clients.

If you’ve already used AWS Lambda with Amazon API Gateway, AWS ALB will look quite familiar, with a few minor differences.

Let’s have a look at the request/response structure:

AWS ALB will invoke our Lambda functions synchronously and the event structure looks like the JSON object above, which includes all the request headers, its body, and some additional metadata about the request itself such as HTTP method, query string parameters, etc.

ALB expects our Lambda function to return a JSON object similar to the following:

That’s it! As long as you apply a few minor changes to your Lambda function’s code, it’s quite straightforward to switch from Amazon API Gateway to AWS ALB. Most differences are related to the way you extract information from the input event and the way you compose the output object before it’s converted into a proper HTTP response. I’d personally recommend structuring your code by separating your business logic from the platform-specific input/output details (or the “adaptor”). This way, your business logic won’t change at all and you’ll just need to adapt how its inputs and outputs are provided.

For example, here’s how you could implement a simple Lambda function to work with both API Gateway and ALB:

Now, I wouldn’t recommend this coding exercise unless you have a real-world use case where your function needs to handle both API Gateway and ALB requests. But keep this in mind when you implement your business logic so that switching in the future won’t be such a painful refactor.

For example, here’s how I would implement a simple Lambda function that returns Hello Alex! when I invoke the endpoint with a querystring such as ?name=Alex and returns Hello world! if no name is provided:

In this case, I’d only need to apply very minor changes to build_response if I wanted to integrate the same function with API Gateway.

Now, let’s have a look at how we’d build our CloudFormation template. AWS SAM does not support ALB natively yet, so we’ll need to define a few raw CloudFormation resources:

The Application Load Balancer definition requires a list of EC2 subnets and a VPC. This is a good time to remind you that AWS ALB is not fully serverless, as it requires some infrastructure/networking to be managed and it’s priced by the hour. Also, it’s worth noting that we need to grant ALB permissions to invoke our function with a proper AWS::Lambda::Permission resource.

That said, let me share a few use cases where you may want to use AWS ALB to trigger your Lambda functions:

You need a “hybrid” compute architecture including EC2, ECS, and Lambda under the same hostname — maybe to implement new features for a legacy system or to cost-optimize some infrequently used sub-systems
Your API’s are under constant load and you are more comfortable with a by-the-hour pricing (ALB) than a pay-per-request model (API Gateway) — this might be especially true if you don’t need many of the advanced features of API Gateway such as input validation, velocity templates, DDOS protection, canary deployments, etc.
You need to implement some advanced routing logic — with ALB’s content-based routing rules you can route requests to different Lambda functions based on the request content (hostname, path, HTTP headers, HTTP method, query string, and source IP)
You want to build a global multi-region and highly resilient application powered by AWS Global Accelerator — ALB can be configured as an accelerated endpoint using the AWS global network

Let me know if you could think of a different use case for ALB + Lambda.

You can read more about this topic on the official documentation.

Also, here you can find an ALB app on the Serverless Application Repository.

Conclusions

That’s all for part 3!

I sincerely hope you’ve enjoyed diving deep into AWS CodeDeploy, AWS CodePipeline, Amazon Pinpoint, and AWS Application Load Balancer.

Now you can customize your CI/CD pipelines, implement custom segments or channels for Amazon Pinpoint, and serve HTTP traffic though AWS ALB.

This is the last episode of this series and I’d recommend checking out the first two articles here and here if you haven’t read them yet, where I talked about integrating Lambda with Amazon Cognito User Pools, AWS Config, Amazon Kinesis Data Firehose, AWS CloudFormation, AWS IoT Button, Amazon Lex, Amazon CloudWatch Logs, and Amazon Aurora.

Thank you all for reading and sharing your feedback!

As usual, feel free to share and/or drop a comment below :)

Originally published on HackerNoon on Oct 30, 2019.

How to FaaS like a pro: 12 less common ways to invoke your serverless functions on Amazon Web Services [Part 2]

Alex Casalboni — Mon, 01 Jul 2019 15:16:01 +0000

I was told my articles contain too much code & I had to make it sweeter [Photo by Valerian KOo on Unsplash]

A few weeks ago I’ve shared the first part of this series where I analyzed in depth some less common ways to invoke AWS Lambda such as Cognito User Pools, AWS Config, Amazon Kinesis Data Firehose, and AWS CloudFormation. You can find [Part 1] here!

In the second part I will describe four more:

AWS IoT Button — 1-Click handlers
Amazon Lex — Fulfillment activities
Amazon CloudWatch Logs — Subscriptions
Amazon Aurora — Triggers and external data

5. AWS IoT Button (1-Click)

Since early 2018, you can trigger Lambda functions from simple IoT devices, with one click. We called it AWS IoT 1-Click.

AWS IoT Enterprise Button (link), AT&T LTE-M Button (link), and SORACOM LTE-M Button (link).

All you need is one of the IoT buttons above and a few lines of code in your favorite programming language to implement a Lambda Action.

Of course, these devices encrypt outbound data using TLS and communicate with AWS via API to invoke your functions.

Once you’ve claimed your devices on the AWS Console — or via the mobile app — they will appear on your AWS Console and you can map their click events to a specific action.

There are three possible action types:

Send SMS — it lets configure the phone number and message
Send Email — it lets you configure the email address, subject, and body
Trigger Lambda function — it lets you select a Lambda function in any region

Additionally, you can configure custom attributes (similar to tags) for each deployed device.

Please note that SMS and emails are two very common scenarios that AWS provides as built-in options, but under the hood there will always be a Lambda Function implementing the click logic (in these two cases, using Amazon SNS for delivering the message).

If you need something more sophisticated than SMS or email, you can implement your own logic with AWS Lambda. For example, you may want to invoke a 3rd-party API, send a voice message rendered by Amazon Polly, or simply store a new item on Amazon DynamoDB.

Before we start coding, let’s mention a few important details:

Our Lambda function will receive two types of events: buttonClicked and deviceHealthMonitor
The input event always contains useful information about the device such as its ID, its custom attributes, the remaining lifetime, etc.
For buttonClicked events we receive two additional pieces of information: clickType ( SINGLE , DOUBLE , or LONG ) and reportedTime (an ISO-formatted date). The idea is that we may want to implement different behaviors for single, double, and long clicks. Alternatively, we could simply ignore some click types, or even treat them as a generic click event
As you can imagine, deviceHealthMonitor events are triggered when the health parameters are below a given threshold; they allow you to take appropriate actions when the device expected lifetime is too low

This is what the typical click event will look like:

Let’s now implement a simple Lambda function that will store a new (daily) item into DynamoDB on click, and delete it on double-click.

Because we may want to run the same business logic on other computing platforms — such as EC2 instances, ECS containers, or even Kubernetes — here is a platform-agnostic implementation in Python :

In the code snippet above, I’m defining a new ClickHandler class, which abstract some details for the concrete DailyClickHandle class. Its constructor will receive the buttonClicked event as input. Once we create a new DailyClickHandler object, we can invoke its run() method to perform the correct logic for single, double, or long clicks.

I am creating a new DynamoDB Item on-single-click, using the current date as the primary key and storing the most recent reported time as well. On-double-click I am deleting the same daily item.

Note: I am not keeping track of the number of daily clicks for this simple use case, but that would be a nice improvement and a useful exercise for you — let me know if you manage to implement it and share your results!

Since I’ve encapsulated the main business logic into a stand-alone class/module, my Lambda handler will be pretty minimal, just a simple adapter:

The Lambda handler above will check if the current event is a health-check or an actual click. If it’s an actual click, it will create a new DailyClickHandler object and invoke its run() method.

The next step before we can deploy everything is to define our CloudFormation template (IaC).

We will need to define a new AWS::IoT1Click::Project resource and map its onClickCallback attribute to our Lambda function (full CloudFormation reference here):

Please note that the CloudFormation template above will create a new IoT 1-Click project and its configuration, but you’ll still need to add your IoT devices to the project either manually (on the AWS Console) or via the UpdateProject API.

If you want to take this sample code as a starting point for your own project, maybe you could keep track of hourly or weekly tasks (instead of daily) by storing an hourly/weekly item on DynamoDB. Or you could extend the Lambda function to start a new CodePipeline deployment (haven’t you always wanted a physical “ deploy button ” on your desk?).

Let me know what you’ll build with AWS IoT 1-Click!

6. Amazon Lex (fulfillment activity)

Amazon Lex allows you to build chatbots and conversational interfaces, powered by the same tech as Alexa.

Lex supports both voice and text I/O, and it comes with advanced natural language understanding (NLU) capabilities. These capabilities help you extract and store the right information from the conversation so that you can focus your time on improving the interface itself rather than wasting time and energy on edge cases, input parsing, and error handling.

Once Lex has collected all the information you need from the conversation, you can configure your bot to invoke a Lambda function to fulfil the user’s intentions , which could be something like creating a hotel reservation, rescheduling an appointment, requesting assistance on a given topic, etc.

To understand how we can integrate Lambda with Lex we need to understand a few important concepts:

Intents — the different actions/goals that you bot can perform (for example, “Book a hotel”, “Rent a car”, “Reschedule an appointment”, etc.)
Slots — the individual pieces of information/fields that your bot will collect during the conversation (for example, “Location”, “Arrival Date”, “Car type”, etc.) — Some slots have built-in types such as cities, dates, phone numbers, sports, job roles, etc. And you can also define your own custom slot types
Sample utterances — typical sentences and hints about how a user might convey the intent, potentially by providing slot values all together (for example, “Book a hotel room in {Location}” or “Book a hotel room for {N} nights in {Location}”)
Channels — the messaging platforms where you can integrate Lex with just a few clicks, such as Facebook Messenger, Slack, Kik, and Twilio SMS

There are two main ways to integrate Lamdba with Lex:

Input initialization & validation — it allows you to validate each slot value as soon as it is collected by Lex, and eventually prompt an “invalid value message” to request a different value
Fulfillment activity — it lets you process the collected values and proceed with the actual business logic

Since you often want to re-validate your inputs before proceeding with the fulfillment, many developers like to implement a single Lambda function to take care of both validation and fulfillment. In some specific scenarios — for example if you have optional slots or very heavy validation logic — you may want to implement two independent Lambda functions.

Let’s now assume that we are implementing a BookHotel intent and we want to implement two independent Lambda functions for data validation and fulfillment. Here are the slots we’ll be collecting during the conversation:

Location — the city where we need a hotel
CheckInDate — the date when we’ll check-in at the hotel
Nights — the number of nights we’ll stay at the hotel
RoomType — a custom slot with values such as queen, king, deluxe, etc.

In a real-world use case, we’ll need to make sure that the four collected slots are semantically valid. For example, the Location needs to be a city supported by our booking system; the CheckInDate must be in the future; the number of Nights must be greater than zero (and maybe lower than a maximum allowed number?); RoomType needs to be a valid type supported by our booking system; and so on.

In the code snippet below I am implementing the BookHotel intent in Python. Because I’d like you to focus on the core business logic, I’ve moved most of the “boring” validation logic and utilities to reusable external modules (you can find the three files here).

As you can see in the snippet above, the Lambda handler itself is only a simple wrapper/adapter for the book_hotel business logic. In this case, we are handling both single slots validation and final fulfillment with one function.

The main logic looks like this: load session data (this is given in the input event), validate individual slot, elicit slots if missing/invalid data, delegate the next step to Lex until we reach the final fulfillment. Then, we can finally book the hotel through our backend or 3rd-party API.

The full code snippet is available here, and it is actually a refactor of the lex-book-trip-python Lambda blueprint that you can find in the AWS Console:

Once you’ve deployed this Lambda function, you can use it as your bot’s validation code hook and fulfillment directly in the Lex console, as shown in the next screenshots:

Unfortunately, Amazon Lex is not supported by CloudFormation yet, but here you can find a set of CloudFormation templates that will deploy a Lex bot using custom resources.

7. Amazon CloudWatch Logs (subscriptions)

Whenever you functions print or console.log something, you will find the corresponding logs on CloudWatch Logs. And the same happens for over 30 services that can natively publish logs into CloudWatch, including Amazon Route 53, Amazon VPC, Amazon API Gateway, AWS CloudTrail, etc.

Not to mention all those on-premises servers that publish logs into CloudWatch using the CloudWatch Agent.

But that’s *NOT* the reason why CloudWatch is on this list.

You can also use CloudWatch Logs as an event source for Lambda. In fact, CloudWatch allows you to define filtered subscriptions on log groups and implement your own Lambda function to process those logs.

For example, you may want to process all the (filtered) logs generated by an Amazon EC2 instance and correlate those logs with the corresponding trace from AWS X-Ray. Finally, you could store the processed information on Amazon S3, maybe send an email report, or even open a new issue on GitHub with all the information required for debugging the problem.

Let’s look at the structure of CloudWatch Logs events:

Well, we can’t see much until we base64-decode and unzip the incoming data. The good news is that you can achieve that with built-in libraries for most runtimes, including Node.js and Python.

Once decoded, the CloudWatch Logs payload will look like the following object:

The payload contains some meta-data about the event itself, such as the name of the corresponding logStream, logGroup, and subscriptionFilters.

The actual payload you want to process is the list of logEvents , each one with its id , timestamp , and message. Please note that, depending on the subscription filter you define, you will likely receive only a subset of the logs corresponding to a given process/task/function execution. That’s why you may want to fetch additional information from the same log stream, especially if you are filtering errors or exceptions for debugging them later.

The following code snippets is a sample implementation in Python:

A few notes on the code snippet above:

It’s assuming that you’ve created a decode.py file with the decode function we’ve seen earlier in this article
The code is sleeping for 5 seconds, waiting for all the logs to be collected in the corresponding stream; this way, we can collect a few more lines of logs before and after this match
We could implement a fetch_traces function to fetch X-Ray traces based on some sort of Request Id (which is automatically added for Lambda function execution logs, but you may have a different format in your own custom logs)
Ideally, we would like to avoid time.sleep at all and instead define a proper state machine with AWS Step Function; this way, we wouldn’t pay for the 5-10 seconds of idle execution because Step Functions allows us to define Wait states (up to a whole year) while charging only for state transitions

You can also find a similar implementation in Node.js here.

Ok, now that we have a better understanding of the moving parts and a sample implementation, it’s time to define a CloudFormation template for our logs processing application.

The best part is that we don’t have to define any special CloudFormation resource because AWS SAM will do most of the work for us. All we need to do is defining a CloudWatchLogs event for our processing function.

Without AWS SAM, we’d need to manually create an AWS::Logs::SubscriptionFilter resource, as well as an additional AWS::Lambda::Permission resource to grant CloudWatch permissions to invoke our function. AWS SAM will transform our CloudWatchLogs event into those resources and it allows us to use a much simpler syntax.

You can learn more about the built-in event sources supported by AWS SAM on GitHub!

Also, don’t forget to provide your processing function the correct permissions as well. In the YAML template above, I’m providing fine-grained permissions to invoke only logs:GetLogEvents on one log group. Alternatively, I could have used a managed IAM policy such as CloudWatchLogsReadOnlyAccess.

You can find a full reference architecture for errors processing here, which also includes AWS X-Ray traces.

8. Amazon Aurora (triggers & external data)

Aurora is a cloud-native relational database engineered from the ground up, with a MySQL and PostgreSQL-compatible interface. It comes with up to 15 read-replicas and different flavours based on your application needs, such as Aurora Global Databasefor multi-region apps requiring high resiliency and data replication, or Aurora Serverless for infrequent, intermittent, or unpredictable workloads.

We can integrate Aurora MySQL with Lambda in two different ways:

synchronously — useful to fetch data from other AWS services in our MySQL queries;
asynchronously — useful to perform tasks when something happens, for example via triggers

Asynchronous invocation — Example: external data or API

By invoking Lambda functions synchronously you can retrieve data stored in other services such as S3, Elasticsearch, Redshift, Athena, or even 3rd-party API’s.

For example, we could fetch today’s weather to make some of our queries dynamic.

First of all, we’ll need to give the Aurora cluster access to Lambda by setting the aws_default_lambda_role cluster parameter with a proper IAM role. In case your cluster isn’t publicly accessible, you’ll also need to enable network communication. Then we can grant invoke permissions to the database user:

Now we can finally invoke our Lambda functions using lambda_sync:

The code snippet above is selecting all fields from a weather_mapping table, assuming that we are storing the mapping between some parameter of our system and the current weather in a given location (which could be parametrized). For example, our application could use different images, welcome messages, or even prices based on the current weather.

Please also note that the Lambda function FetchWeather should return an atomic value — in this case a string — since Aurora MySQL doesn’t support JSON parsing.

Disclaimer 1 : lambda_sync and lambda_async are available Aurora MySQL version 1.6 and above. For older versions, you can use the stored procedure mysql.lambda_async.

Disclaimer 2 : the functionality above could be implemented at the application layer as well, and I’m pretty sure you will come up with more creative use cases for synchronous invocations :)

Asynchronous invocation — Example: triggers

By invoking Lambda functions asynchronously you can implement something very similar to Amazon DynamoDB Streams, for those scenarios where you need to react to specific queries or events happening in the database.

For example, you may want to send an email every time a new record is inserted into a DemoContacts table. In this case you could achieve the same by sending the email from your application code. But in some other scenarios you might need to add too much logic to your application code (or even just modify too many files/modules), so it would be simpler to use a database trigger to extend the behaviour of the application.

In practice, you can define a MySQL trigger that will invoke your Lambda function asynchronously.

Now we can define a MySQL trigger:

The code snippet above defines a trigger named TR_contacts_on_insert that collects the inserted values of email and fullname, and then invokes a Lambda function asynchronously. The built-in function lambda_async requires a function ARN and a JSON payload, here built by concatenating strings.

In case you want to reuse the invoke logic above for other similar triggers, you may want to create a reusable stored procedure as well.

Conclusions

That’s all for part 2!

I hope you’ve been inspired to build something new with AWS IoT 1-Click, Amazon Lex, Amazon CloudWatch Logs, and Amazon Aurora.

Now you can serverlessly handle IoT buttons clicks, implement the fullfillment logic of your chatbots, process logs in real-time, and implement MySQL triggers and or fetch data from external services/databases into Aurora.

In the 3rd (and last) part of this series I will discuss the last four less common ways to invoke your Lambda functions, including AWS CodeDeploy, AWS CodePipeline, Amazon Pinpoint, and more! Stay tuned and let me know if you’d like to read about other Lambda integrations.

Thank you for taking the time to read such a long article.

Feel free to share and/or drop a comment below :)

Originally published on HackerNoon on Jul 1, 2019.

How to FaaS like a pro: 12 less common ways to invoke your serverless functions on Amazon Web Services [Part 1]

Alex Casalboni — Tue, 02 Apr 2019 16:15:20 +0000

Yes, this is you at the end of this article, contemplating new possibilities!
[Photo by Joshua Earle on Unsplash]

If you feel like skipping the brief introduction below, you can jump straight to the first four trigger with these shortlinks:

Amazon Cognito User Pools — Users management & custom workflows
AWS Config — Event-driven configuration checks
Amazon Kinesis Data Firehose — Data ingestion & validation
AWS CloudFormation — IaC, Macros & custom transforms

A bit of history first

When AWS Lambda became generally available on April 9th, 2015 it became the first Function-as-a-Service out there, and there were only a few ways you could trigger your functions besides direct invocation: Amazon S3, Amazon Kinesis, and Amazon SNS. Three months later we got Amazon API Gateway support, which opened a whole new wave for the web and REST-compatible clients.

By the end of 2015, you could already trigger functions via Amazon DynamoDB Streams, Kinesis Streams, S3 objects, SNS topics, and CloudWatch Events (scheduled invocations).

Personally, I started experimenting with AWS Lambda around early 2016 for a simple machine learning use case. A few months later I published the very first video about my experience with Lambda, which covered all the available triggers and configurations available at the time; well, the video is still available here, but the AWS Console is pretty different now so I’d recommend you watch it only if you are feeling nostalgic =)

Back to history…

In the following months, AWS Lambda became very popular and many other AWS services started integrating it and allowing you to trigger functions in many new ways. These integrations are fantastic for processing/validating data, as well as for customizing and extending the behavior of these services.

You may be already aware of (or intuitively guess) how AWS Lambda integrates with services such as S3, DynamoDB, Kinesis Data Streams, SES, SQS, IoT Core, Step Functions, and ALB. And there are plenty of articles and getting-started guides out there using these integrations as a good starting point for your serverless journey.

In this article, I’d like to share with you some of the many other less common, less well-known, or even just newer ways to invoke your Lambda functions on AWS. Some of these integrations do not even appear on the official Supported Event Sources documentation page yet and I believe they are worth mentioning and experimenting with.

For each service/integration, I will share useful links, code snippets, and CloudFormation templates & references. Please feel free to add a comment below if you think something’s missing or if you need more resources/details. Even if you don’t know Python or JavaScript, the code will be pretty self-explanatory and with useful comments. Please drop a comment on Gist or at the bottom of this article if you have questions or doubts.

Let’s get started with the first 4 triggers for AWS Lambda.

1. Amazon Cognito User Pools (custom workflows)

Cognito User Pools allow you to add authentication and user management to your applications. With AWS Lambda, you can customize your User Pool Workflows and trigger your functions during Cognito’s operations in order to customize your User Pool behavior.

Here’s the list of available triggers:

Pre Sign-up — triggered just before Cognito signs up a new user (or admin) and allows you to perform custom validation to accept/deny it
Post Confirmation — triggered after a new user (or admin) signs up and allows you to send custom messages or to add custom logic
Pre Authentication — triggered when a user attempts to sign in and allows custom validation to accept/deny it
Post Authentication — triggered after signing in a user and allows you to add custom logic after authentication
Custom Authentication — triggered to define, create, and verify custom challenges when you use the custom authentication flow
Pre Token Generation — triggered before every token generation and allows you to customize identity token claims (for example, new passwords and refresh tokens)
Migrate User — triggered when a user does not exist in the user pool at the time of sign-in with a password or in the forgot-password flow
Custom Message — triggered before sending an email, phone verification message, or a MFA code and allows you to customize the message

All these triggers allow you to implement state-less logic and personalize how Cognito User Pools work using your favorite programming language. Keep in mind that your functions are invoked synchronously and will need to complete within 5 seconds, simply by returning the incoming event object with an additional response attribute.

It might be convenient to handle multiple events from the same Lambda Function as Cognito will always provide an attribute named event.triggerSource to help you implement the right logic for each event.

For example, here’s how you’d implement the Lambda function code for a Custom Message in Node.js:

As you can see, the logic is completely stateless and it’s considered best practice to always check the triggerSource value to make sure you are processing the correct event — and eventually raise an error/warning in case of unhandled sources.

The following code snippet shows how you can define the Lambda function and Cognito User Pool in a CloudFormation template (here I’m using AWS SAM syntax, but you could also use plain CloudFormation):

All you need to do is adding a LambdaConfig property to your User Pool definition and reference a Lambda function.

You can find all the attributes of LambdaConfig on the documentation page.

2. AWS Config (event-driven configuration checks)

AWS Config allows you to keep track of how the configurations of your AWS resources change over time. It’s particularly useful for recording historical values and it also allows you to compare historical configurations with desired configurations. For example, you could use AWS Config to make sure all the EC2 instances launched in your account are t2.micro.

As a developer, the interesting part is that you can implement this kind of compliance checks with AWS Lambda. In other words, you can define a custom rule and associate it with a Lambda function that will be invoked in response to each and every configuration change (or periodically).

Also, your code can decide whether the new configuration is valid or not :)

Of course, you don’t have to listen to every possible configuration change of all your resources. Indeed, you can listen to specific resources based on:

Tags (for example, resources with an environment or project-specific tag)
Resource Type (for example, only AWS::EC2::Instance)
Resource Type + Identifier (for example, a specific EC2 Instance ARN)
All changes

There are many AWS Lambda blueprints that allow you to get started quickly without coding everything yourself (for example, config-rule-change-triggered). But I think it’s important to understand the overall logic and moving parts, so in the next few paragraphs we will dive deep and learn how to write a new Lambda function from scratch.

Practically speaking, your function will receive four very important pieces of information as part of the input event:

invokingEvent represents the configuration change that triggered this Lambda invocation; it contains a field named messageType which tells you if the current payload is related to a periodic scheduled invocation (ScheduledNotification), if it’s a regular configuration change (ConfigurationItemChangeNotification) or if the change content was too large to be included in the Lambda event payload (OversizedConfigurationItemChangeNotification); in the first case, invokingEvent will also contain a field named configurationItem with the current configuration, while in the other cases we will need to fetch the current configuration via the AWS Config History API
ruleParameters is the set of key/value pairs that you optionally define when you create a custom rule; they represent the (un)desired status of your configurations (for example, desiredInstanceType=t2.small) and you can use its values however you want; let’s say this is a smart way to parametrize your Lambda function code and reuse it with multiple rules
resultToken is the token we will use when to notify AWS Config about the config evaluation results (see the three possible outcomes below)
eventLeftScope tells you whether the AWS resource to be evaluated has been removed from the rule’s scope, in which case we will just skip the evaluation

Based on the inputs above, our lambda function will evaluate the configuration compliance and it will be able to invoke the PutEvaluations API with three possible results:

COMPLIANT if the current configuration is OK
NON_COMPLIANT if the current configuration is NOT OK
NOT_APPLICABLE if this configuration change can be ignored

Ok, enough theory :)

Let’s write some code and see AWS Config in action.

For example, let’s implement a custom rule to check that all EC2 instances launched in our account are t2.small using Node.js:

In the code snippet above, I am importing a simple utility module (that you can find here) to make the overall logic more readable.

Most of the magic happens in the JavaScript function named evaluateChangeNotificationCompliance. Its logic is parametrized based on ruleParameters and the value of desiredInstanceType — that we will define in a CloudFormation template below — so that we can reuse the same Lambda function for different rules.

Now, let’s define our AWS Config custom rule and Lambda function in CloudFormation:

Defining a custom rule is fairly intuitive. In the Scope property I am selecting only AWS::EC2::Instance resources and I am passing t2.small as an input parameter of the custom rule. Then, I define the Source property and reference my Lambda function.

You can find the full documentation about AWS Config custom rules here, with good references for scheduled rules, tags filtering, etc.

3. Amazon Kinesis Data Firehose (data validation)

Kinesis Data Firehose allows you to ingest streaming data into standard destinations for analytics purposes such as Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, and Splunk.

You can have multiple data producers that will PutRecords into your delivery stream. Kinesis Firehose will take care of buffering, compressing, encrypting, and optionally even reshaping and optimizing your data for query performance (for example, in Parquet columnar format).

Additionally, you can attach a Lambda function to the delivery stream. This function will be able to validate, manipulate, or enrich incoming records before Kinesis Firehose proceeds.

(Optionally, you might have API Gateway or CloudFront in front of Kinesis Firehose for RESTful data ingestion)

Your Lambda function will receive a batch of records and will need to return the same list of records with an additional result field, whose value can be one of the following:

Ok if the record was successfully processed/validated
Dropped if the record doesn’t need to be stored (Firehose will just skip it)
ProcessingFailed if the record is not valid or something went wrong during its processing/manipulation

Let’s now implement a generic and reusable validation & manipulation logic in Python:

The code snippet above is structured so that you only need to implement your own transform_data logic. There you can add new fields, manipulate existing ones, or decide to skip/drop the current record by raising a DroppedRecordException.

A few implementation details worth mentioning:

Both incoming and outgoing records must be base64-encoded (the snippet above already takes care of it)
I am assuming the incoming records are in JSON format, but you may as well ingest CSV data or even your own custom format; just make sure you (de)serialize records properly, as Kinesis Firehose always expects to work with plain strings
I am adding a trailing \n character after each encoded record so that Kinesis Firehose will serialize one JSON object per line in the delivery destination (this is required for Amazon S3 and Athena to work correctly)

Of course, you can implement your own data manipulation logic in any programming language supported by AWS Lambda and — in some more advanced use cases — you may need to fetch additional data from Amazon DynamoDB or other data sources.

Let’s now define our data ingestion application in CloudFormation.

You can attach a Lambda function to a Kinesis Firehose delivery stream by defining the ProcessingConfiguration attribute.

In addition to that, let’s setup Firehose to deliver the incoming records to Amazon S3 every 60 seconds (or as soon as 10MB are collected ), compressed with GZIP. We’ll also need an ad-hoc IAM Role to define fine-grained permissions for Firehose to invoke our Lambda and write into S3.

Here is the full CloudFormation template for your reference:

The best part of this architecture in my opinion is that it’s 100% serverless and you won’t be charged if no data is being ingested. So it allows you to have multiple 24x7 environments for development and testing at virtually no cost.

You can find the complete CloudFormation documentation here. Plus, you’ll also find an end-to-end pipeline including Amazon API Gateway and Amazon Athena here.

4. AWS CloudFormation (Macros)

We have already seen many CloudFormation templates so far in this article. That’s how you define your applications and resources in a JSON or YAML template. CloudFormation allows you to deploy the same stack to multiple AWS accounts, regions, or environments such as dev and prod.

A few months ago — in September 2018 — AWS announced a new CloudFormation feature called Macros.

CloudFormation comes with built-in transforms such as AWS::Include and AWS::Serverless that simplify template authoring by condensing resource definition expressions and enabling components reusing. These transforms are applied at deployment-time to your CloudFormation templates.

Similarly, a CloudFormation Macro is a custom transform backed by your own Lambda Function.

There are three main steps to create and use a macro:

Create a Lambda function that will process the raw template
Define a resource of type AWS::CloudFormation::Macro (resource reference here), map it to the Lambda function above, and deploy the stack
Use the Macro in a CloudFormation template

Macros are particularly powerful because you can apply them either to the whole CloudFormation template — using the Transform property — or only to a sub-section — using the intrinsic Fn::Transform function, optionally with parameters.

For example, you may define a macro that will expand a simple resource MyCompany::StaticWebsite into a proper set of resources and corresponding defaults, including S3 buckets, CloudFront distributions, IAM roles, CloudWatch alarms, etc.

It’s also useful to remember that you can use macros only in the account in which they were created and that macro names must be unique within a given account. If you enable cross-account access to your processing function, you can define the same macro in multiple accounts for easier reuse.

How to implement a CloudFormation Macro

Let’s now focus on the implementation details of the Lambda function performing the template processing.

When your function is invoked, it’ll receive the following as input:

region is the region in which the macro resides
accountID is the account ID of the account invoking this function
fragment is the portion of the template available for processing (could be the whole template or only a sub-section of it) in JSON format, including siblings
params is available only if you are processing a sub-section of the template and it contains the custom parameters provided by the target stack (not evaluated)
templateParameterValues contains the template parameters of the target stack (already evaluated)
requestId is the ID of the current function invocation (used only to match the response)

Once the processing logic is completed, the Lambda function will need to return the following three attributes:

requestId must match the same request ID provided as input
status should be set to the string "success" (anything else will be treated as a processing failure)
fragment is the processed template, including siblings

It’s interesting to note that in some cases the processedfragment will be the same fragment you receive as input.

I can think of four possible manipulation/processing scenarios:

Your function processes some resources and customizes their properties (without adding or removing other resources)
Your function extends the input fragment by creating new resources
Your function replaces some of the resources — potentially your own custom types — with other real CloudFormation resources (note: this is what AWS SAM does too!)
Your function does not alter the input fragment, but intentionally fails if something is wrong or missing (for example, if encryption is disabled or if granted permissions are too open)

Of course, your macros could be a mix of the four scenarios below.

In my opinion, scenario (4) is particularly powerful because it allows you to implement custom configuration checks before the resources are actually deployed and provisioned , with respect to the AWS Config solution we’ve discussed at the beginning of this article.

Scenario (3) is probably the most commonly used, as it allows you to define your own personalized resources such as MyCompany::StaticWebsite (with S3 buckets, CloudFront distributions, or Amplify Console apps) or MyCompany::DynamoDB::Table (with enabled autoscaling, on-demand capacity, or even a complex shared configuration for primary key and indexes), etc.

Some of the more complex macros make use of a mix of stateless processing and CloudFormation Custom Resources backed by an additional Lambda function.

Here you can find real-world implementation examples of CloudFormation Macros, the corresponding macro templates, and a few sample templates too. I am quite sure you will enjoy the following macros in particular: AWS::S3::Object, Count, StackMetrics, StringFunctions, and more!

How to deploy a CloudFormation Macro

Once you’ve implemented the processing function, you can use it to deploy a new macro.

Here is how you define a new macro resource:

That’s it!

AWS CloudFormation will invoke the processing function every time we reference the macro named MyUniqueMacroName in a CloudFormation template.

How to use a CloudFormation Macro

Using a macro is the most likely scenario for most developers.

It’s quite common that macros are owned and managed by your organization or by another team, and that you’ll just use/reference a macro in your CloudFormation templates.

Here is how you can use the macro defined above and apply it to the whole template:

In case you’d like to apply the same macro only to a sub-section of your template, you can do so by using the Fn::Transform intrinsic function:

Let me know what CloudFormation Macros you’ll build and what challenges they solve for your team!

Conclusions

That’s all for Part 1 :)

I hope you have learned something new about Amazon Cognito, AWS Config, Amazon Kinesis Data Firehose, and Amazon CloudFormation.

You can now customize your Cognito User Pools workflow, validate your configurations in real-time, manipulate and validate data before Kinesis delivers it to the destination, and implement macros to enrich your CloudFormation templates.

In the next two parts of this series, we will learn more about other less common Lambda integrations for services such as AWS IoT 1-Click, Amazon Lex, Amazon CloudWatch Logs, AWS CodeDeploy, and Amazon Aurora.

Thank you for taking the time to read such a long article.

Feel free to share and/or drop a comment below.

Originally published on HackerNoon on Apr 2, 2019.

Welcome to Cloud-Native Development with AWS Cloud9 & AWS CodeStar ⚡

Alex Casalboni — Mon, 15 Jan 2018 08:48:43 +0000

I have been experimenting with AWS Cloud9 since Werner Vogels announced it a few weeks ago at AWS re:Invent 2017 (keynote video here).

This article is the paraphrased version of my talk AWS Cloud9 & CodeStar for Serverless Apps, given at the AWS User Group in Milan on Jan 10th.

I am going to skip the “Serverless Disclaimer” section of my deck.

If you are not familiar with Serverless, please have a look here, or here, or here, or here, or here, or here, or here.

If you are familiar with Serverless and you don’t like it, you may still enjoy this article and the benefits of Cloud9 and CodeStar. Just make sure you mentally replace “FaaS” with “Container”, and “SAM” with “CloudFormation” :)

// Detect dark theme var iframe = document.getElementById('tweet-951172504743268353-902'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=951172504743268353&theme=dark" }

What is AWS Cloud9?

AWS Cloud 9 is a “cloud IDE” for writing, running, and debugging code.

I’d start saying that most IDEs are fantastic tools to boost your productivity and the quality of your code if you can use them and invested a few months/years in learning them properly.

That being said, some IDEs offer more advanced and useful features than others (please don’t take it personally, unless you code in Word or Notepad).

AWS acquired Cloud9 in July 2016, which has now been rebranded as AWS Cloud9. Even though it looked brilliant on Werner’s browser, my first impression during the keynote was something along the lines of “ Why should I pay to write code? ”, immediately followed by “ Does that mean I cannot code when I’m offline? ”. Like most software engineers, I’ve used many IDEs in the last ten years, for free, and I’m used to coding a lot while I’m traveling.

Apparently, I was not alone, and many developers asked the same questions during my presentation. So let me briefly recap my arguments.

Regarding the cost, I believe it’s pretty much negligible for most organizations that already use AWS heavily (less than $2 per month for a t2.micro environment, 8 hours a day, 20 days a month). And without considering AWS Free Tier and automatic cost-saving settings (hibernation after 30min).

The “no coding offline” drawback is much harder to defend, but let me try.

Unless you are going for a hardcore debugging session over a well-established project, can you really code for more than 30min when you are offline? Can you git clone or git pull anything useful? Can you npm install or pip install the modules you need? Can you mock or ignore all the third-party services and APIs your application consumes? Can you avoid googling around your favorite framework’s documentation?

Sure, you could prepare for a 12h flight and download/install everything you need in advance. But how often does that happen? Simply put, I’ve seen the best developers and engineers give up and take a break when the network goes down.

On the other hand, AWS Cloud9 offers you a better alternative for when your machine gives up :) I could throw my dev machine out of the window right now, switch to my colleague’s notebook, login into my AWS Account and keep working on the very same Cloud9 session (which is saved and stored server-side). That means you could as well use a much cheaper machine such as a Chromebook or a tablet (or a phone?). Well, you could be 100% operational using the random machine of an internet cafe, or your grandmother’s computer :)

Of course, there are always exceptions, and I’ll make sure I’m ready to use my local IDE when Cloud9 is not an option. In the meantime, I hope AWS will work on some sort of client-side offline support (and maybe turn Cloud9 into a progressive web app?).

… and why does it matter for developers?

I think AWS Cloud9 solves a bunch of problems for the many organizations currently trying to set up elaborate stacks of tools on every developer’s machine, especially if the team is heterogeneous and/or distributed.

Let’s recap some of its features:

It’s a full-fledged IDE (based on the Ace open-source editor)
It comes with an integrated web terminal. It is a real ssh session directly your browser, without the need of managing and storing ssh keys or IAM credentials on your local machine.
This web terminal can run on a new EC2 instance managed by AWS Cloud9 (EC2 env.), or you can bring your own instance (SSH env.)
EC2 environments offer quite a handy cost-saving functionality , which means you can optionally configure them to hibernate after 30 minutes of inactivity (or more)
EC2 environments are based on this Amazon Machine Image, which includes at least 90% of the dev tooling you need. For example, the AWS CLI, sam-local, git, gcc, c++, Docker, node.js, npm, nvm, CoffeeScript, Python, virtualenv, pip, pylint, boto3, PHP, MySQL, Apache, Ruby, Rails, Go, Java, etc. In case anything is missing, you can always install it :)
AWS Cloud9 comes with the live debugging capabilities you’d expect from a modern IDE (currently only for Node.js, though)
It enables collaborative coding and debugging sessions. You can share a Cloud9 environment with other IAM users and invite them with read-only or read-write permissions.
It comes with built-in support for AWS Lambda. This greatly simplifies the process of creating new Lambda Functions, updating and testing their code locally, deploying new versions, etc.
Plus, AWS SAM is part of the team too. AWS SAM — or Serverless Application Model — is an open specification that allows you to define serverless applications and related resources with a simplified CloudFormation syntax. Cloud9 natively integrates some of the functionalities offered by SAM Local, an open-source CLI tool written in Go by AWS to simplify local development and testing of Serverless applications. For example, you can invoke Functions locally and emulate API Gateway endpoints too.

I took the following screenshot during a live-debugging session of a very simple Lambda Function ( note : I also spent 3 minutes customising theme & layout, according to my taste and needs).

AWS Cloud9 in action during a live-debugging session with Node.js

AWS Cloud9 Limitations and my personal “wishes”

I do have a few wishes for AWS Cloud9, and I’ve shared a few of them on Twitter (tweets below).

Let me discuss a few of them:

The “numeric limitations” are pretty reasonable, in my opinion. You can create up to 20 environments per user (max 10 open concurrently), 100 per account, and you can invite up to 8 members in each environment. These are reasonable numbers since you can’t share environment across AWS accounts (yet?)
Live debugging is terrific, but only available for Node.js. I’m looking forward to built-in support for Python (and all the others, of course).
The same holds for some runtime customizations currently not supported. For example, I couldn’t find a way to change the default linting and code completion behavior for Python (only pylint arguments are supported). Without custom linting, Python3 developers cannot benefit from Python’s type hints capabilities (mypy is required).
As discussed above, there is no support for “offline” development. Working offline may become a critical need in some scenarios/teams, although you can always download the whole environment to your local machine with one click (File > Download Project) and keep working locally.
I think Cloud9 could be much better integrated with the AWS Console , especially with services such as Lambda and API Gateway. For example, there is no easy way to jump to the Lambda Console of a given Function (or API Gateway).
The built-in Lambda integration is excellent, but it’s still not as productive as the native Lambda Console. For example, you can test a Function locally, but you can’t quickly pick the test event from a list of templates. For now, you can workaround this by running sam local generate-event in the terminal.

// Detect dark theme var iframe = document.getElementById('tweet-948514630472790017-51'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=948514630472790017&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-948513525420486656-602'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=948513525420486656&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-950315058604793856-316'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=950315058604793856&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-949685627456573440-848'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=949685627456573440&theme=dark" }

What is AWS CodeStar?

AWS CodeStar (aka Code-* ) is a sort of “catch-all service” for the ever-expanding suite of tools for developers.

It is a free service that lets you manage and link together services such as CodeCommit, CodeBuild, CodePipeline, CodeDeploy, Lambda, EC2, Elastic Beanstalk, CloudFormation, Cloud9, etc.

One of my 2018 new year resolutions is to use more memes in my decks (until someone decides to stop me, for some reason), so here’s how I presented some of the pain points that CodeStar can solve.

Too many projects tend to postpone CI/CD until it’s way too late and their productivity level is too low, just because it sounds hard. But it doesn’t have to be that hard, right?

Nobody likes building and maintaining real-time dashboards. But they are vital from day one, for a manager to assess the status of a project, as well as for a developer to monitor how the system is behaving.

This is what most developers want to do all day. Just write some code and push to master. How can you provide such a simple and frictionless experience without impacting quality and ownership?

Issue tracking can be a very frustrating experience, especially if not well integrated with source control, access control, team management, monitoring, etc.

Data-driven parenthesis : I can statistically confirm that the JIRA meme generated 42% more laughs than all others combined.

… and why does it matter for organizations?

CodeStar may not be the best fit for every project/organization, especially the most experienced and advanced ones, but it definitely provides some very good defaults to get started with. It’s worth noting that CodeStar is 100% free, and you only pay for the resources it will spin up on your behalf.

Let’s recap its features:

CodeStar offers the concept of “ project templates ”. Each template represents a complete stack and includes a sample app, with a given backend, programming language, and framework.
It supports three compute layers: EC2 , Elastic Beanstalk , and Lambda.
It supports six programming languages: C# , Java , Node.js , Python , PHP , and Ruby (plus plain HTML apps).
It supports plenty of frameworks: Express , Spring , Django , Flask , ASP.NET Core , Laravel , etc. Note : AWS Lambda projects only support Express (Node.js) and Spring (Java), plus a few sample projects for Alexa Skills.
Depending on the project template of your choice, CodeStar will spin up a CI/CD pipeline by linking together CodePipeline, CodeBuild, and CodeDeploy.
Every CodeStar project starts with source control ( git ), either on AWS CodeCommit or GitHub. CodeStar will create the git repository for you (via OAuth in case of GitHub) and take care of triggers/hooks for CI/CD.
You can optionally configure your own coding tools to work with CodeStar. Currently, only Cloud9, Eclipse, and VSCode are natively supported (plus the regular AWS CLI). You’ll read more on the Cloud9 integration later in this article.
Even though many projects start as a one-person effort over the weekend, good projects tend to evolve and onboard more people quickly. CodeStar allows you to invite IAM users to your project with one of these roles: Owner (“God Mode”), Contributor (everything but team management), or Viewer (read-only dashboard access). More technical info here.
As mentioned above, issue tracking is probably the most frustrating part of many projects, as it brings context switching, visibility, and misunderstanding issues into the equation. CodeStar allows you to integrate JIRA or GitHub Issues into your project dashboard, which might help in reducing the context switch and centralizing all the information.
CodeStar provides a customisable app dashboard (screenshot below), which includes a project wiki section , a CloudWatch Metrics section, your project’s git history, API endpoints, open issues, Cloud9 environments, etc. You can drag-and-drop sections around as you wish and use this dashboard to check the overall status of your project quickly and effectively.

A typical CI/CD pipeline managed by CodeStar (AWS Lambda project)

A brand-new CodeStar dashboard (AWS Lambda project)

CodeStar’s team management and user roles

AWS CodeStar Limitations and a few “gotchas”

CodeStar can look like magic if you’ve never played with CodePipeline and CodeBuild, but unfortunately it’s not perfect yet. I’ve shared a few “wishes” on Twitter too (tweets below), and here’s a quick recap of what I’ve found.

You can create up to 333 projects per account (it looks like the number came out of some kind of thoughtful calculation, right?), but you can only have 10 projects per user and 100 users per project. As for Cloud9, these seem like reasonable numbers, especially since CodeStar does not support federated users or temporary access credentials, which means you’ll need to create a lot of users if a few developers start collaborating across AWS Accounts.
Although the default user roles seem to cover most use cases, you are stuck with the owner/contributor/viewer permissions as you can’t create custom roles. For example, you may want to have a “project manager” role with view-only and team-management permissions.
Remember that CodeStar permissions are not related to Cloud9 permissions. If you want other owners or contributors to join your Cloud9 environment, you’ll have to invite them explicitly. Which makes sense, but I believe it could be improved/automated.
The most critical limitation I’ve found is that there is no way to customise project templates. As I’ve mentioned already, CodeStar provides pretty good defaults for a lot of things, but you’ll probably need to change a few details here and there. For example, you may want to add a testing step to CodePipeline, add custom permissions to the default IAM role, edit the default build file, change the default API Gateway stage, etc. And once you’ve done that, there is no way to save your edits into a new custom project template so that your team will start from there. Which means you’ll have to apply your customizations to each new project. And you only have two options: 1) applying changes manually, or 2) automatically applying Change Sets to your CloudFormation Stacks (please note that every project will create one or more CloudFormation Stack and that the original templates are not versioned anywhere, so good luck with that!). Plus, see the next bullet point :)
Some of the CodeStar functionalities are based on mysterious and undocumented CloudFormation magic such as theAWS::CodeStar::SyncResources resource and the AWS::CodeStar transform. They both sound pretty powerful, but there is no easy way to know what they are used for (or how we could use them). My current understanding is that AWS::CodeStar::SyncResources will wait for all the other resources to be deployed (i.e. DependsOn) and then make sure everything is okay (e.g. IAM permissions, project id, etc.). AWS::CodeStar seems to simply to inject SyncResources into the processed template so that we don’t have to.

// Detect dark theme var iframe = document.getElementById('tweet-948942798929227781-790'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=948942798929227781&theme=dark" }

What about AWS CodeStar + AWS Cloud9?

Cloud9 and CodeStar are pretty cool services on their own, and I was excited to see how they’ve been integrated. Or, better, how Cloud9 has been integrated into CodeStar.

You can associate AWS Cloud9 Environments to your CodeStar project natively. In case multiple developers are working on the same project, you can create and assign a Cloud9 Environment to each developer (eventually, they’ll collaborate and invite each other, if needed).

Once you open Cloud9, you’ll find your IAM credentials integrated with git (which does require some work) and your CodeCommit repository already cloned for you.

Unfortunately, this magic doesn’t happen if you choose GitHub (for now?).

As a couple of friends and colleagues pointed out, it’s not such a critical or technical complex integration, in the sense that you could have taken care of it yourself (as you’d do on your local machine). But I think it’s a great way to streamline the development experience and reduce the margin for error , especially when you work on multiple projects and multiple accounts.

For example, most developers make great use of AWS profiles when working on their local machine, and some of them also manage to remember which profile can do what, in which account, etc. With CodeStar+Cloud9 you won’t care anymore about profiles or local credentials since every Cloud9 environment is bound to a specific project and account. Also, since CI/CD is enabled by default, most of the time you will just write code, test with sam-local and git push 💛

Of course, you may also have a generic Cloud9 Environment (i.e. not related to a specific project) and use it with multiple profiles to manage unique resources or prototype new stuff.

Let me open a parenthesis: AWS SAM

I decided to conclude my presentation with a brief parenthesis about AWS SAM, which got a few mentions and therefore deserves some context.

** Serverless alert **

Meet SAM!

SAM stands for Serverless Application Model , and it’s an open specification whose goal is to offer a standard way to define serverless applications.

Technically speaking, it’s a CloudFormation Transform named AWS::Serverless that will convert special Serverless resources such as AWS::Serverless::Function into standard CloudFormation syntax.

You can think of Transforms as a way to augment the expressiveness of CloudFormation templates so that you can define complex resources and their relationships in a much more concise way.

If you are familiar with other tools such as the Serverless Framework, you’ll notice that the syntax is quite similar (there is even a plugin to convert your templates to SAM).

In fact, you can deploy SAM templates with AWS SAM Local, a CLI tool for local development written in Go and officially released by AWS.

You can use AWS SAM Local to test your Lambda Functions locally and emulate API Gateway endpoints too. The CLI tool is available by default on every Cloud9 EC2 Environment, and the UI already supports some of its functionalities.

A few SAM examples

A simple serverless Function (additional properties are available for IAM policies, VCP config, DLQ, tracing, etc.)

The same Function defined above, plus CodeDeploy Traffic Shifting (10% every 10min)

The same Function defined above, plus an API Gateway endpoint (nothing else needs to be defined)

A simplified DynamoDB definition (only primary key and throughput)

An API Gateway defined in swagger format (sam-local will package it to S3 before deploying!)

My personal “wishes” for AWS SAM

I have only one wish for AWS SAM: I would love to see more transparency and documentation related to the AWS::Serverless Transform.

Having an open specification and local CLI tool on GitHub is great, but as long as CloudFormation Transforms behave like an undebuggable black box, the community won’t be able to contribute much, in my opinion.

And since I like dreaming, why not allowing custom CloudFormation Transforms too? I am almost ready to bet they are implemented with some kind of Lambda hook, and I can’t even start to imagine how many great things the community might be able to develop and share that way.

// Detect dark theme var iframe = document.getElementById('tweet-951219516134100997-216'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=951219516134100997&theme=dark" }

I hope you learned something new about AWS Cloud9 and CodeStar (please don’t confuse them and create weird hybrids such as “ CloudStar ” as I did a few times). I would recommend building a simple prototype or a sample project on CodeStar asap. You can get started here!

If you got this far, you probably enjoyed the article or feel like sharing your thoughts. Either way, don’t forget to recommend & share, and please do not hesitate to give feedback & share your ideas =)

Database News: 7 Updates from AWS re:Invent 2017

Alex Casalboni — Tue, 19 Dec 2017 08:00:49 +0000

Following AWS re:Invent 2017, we’ve counted more than 40 announcements of new or improved AWS services. Today, we’ll be talking about our picks for the new database and storage services that should be on your radar for 2018.

What’s New in the Database world?

If you’re into Magic Quadrants, here is what Gartner had to say about Operational Database Management Systems just one month before the announcements at AWS re:invent. It’s funny to see how quickly these documents become obsolete! :)

Although the largest majority of new services were related to AI and IoT, AWS also announced several new and exciting ways to manage and interact with existing databases, entirely new managed services, and even new optimized ways to fetch data from more traditional storage services such as S3 and Glacier. The bad news is that four out of seven of the following announcements are still in preview. However, I’d gamble that they’ll be GA within a few months, and ideally before the end of Q1 2018. Let’s dig into the new database announcements.

1) Amazon Aurora Multi-Master (Preview)

Amazon Aurora is a cloud-native DBMS that is simultaneously compatible with well-known open-source databases (only MySQL and PostgreSQL for now), promises the same level of performance as most commercial databases, and is 10 times cheaper.

Amazon Aurora already comes with the ability to scale up to 15 read replicas across different Availability Zones and even multiple regions, default auto-scaling, and seamless recovery from replica failures. You can find out how it’s different from a regular MySQL cluster here, and you can see a series ofinteresting benchmarks here.

In Andy Jassy's re:Invent keynote, he announced the Aurora Multi-Master, which allows Aurora clusters to scale out for both read and write operations by providing multiple master nodes across Availability Zones. This update enables both higher throughput and higher availability for Aurora clusters. Interestingly, Jassy pre-announced that Aurora will go multi-region as well, sometime in 2018.

Although the preview is only compatible with MySQL, I hope it will also be available for PostgreSQL once it becomes generally available.

In the meantime, you can apply for the preview hereand get started with this Amazon Aurora Hands-on Lab on Cloud Academy.

2) Amazon Aurora Serverless (Preview)

Less than 60 seconds after announcing Aurora Multi-Master, Andy Jassy announced Aurora Serverless, which transforms how you think of databases for infrequent, intermittent, or unpredictable workloads.

Since Aurora Serverless can be enabled or disabled any time based on the current load of queries, in practice it is the very first on-demand relational database with a pay-per-second model. In fact, you are charged independently for compute capacity , storage , and I/O. In other words, Aurora Serverless is charged based on the total number of requests ($0.20 per million), the total size of the database ($0.10 per GB per month), and the total query execution time in seconds based on the concurrent Aurora Capacity Units ($0.06 per hour per ACU).

The main point here is that the number of ACUs will drop to zero as soon as you stop running queries. As long as Aurora Serverless is disabled, you are charged only for the database storage. If you are familiar with AWS Lambda, this is not too different from how Lambda Functions are charged (and storage tends to be pretty cheap).Aurora Serverless is still in preview, and only for MySQL, but it is really promising for plenty of serverless use cases. First of all, it aligns with my favorite definition of serverless (i.e. it costs you “nothing” when no one is using it). Secondly, it will solve many problems related to serverless applications and relational databases such as connection pooling, networking, autoscaling, IAM-based credentials, etc. When combined with Aurora Multi-Master and Multi-Region, it will finally enable highly available serverless applications backed by a horizontally scalable relational database.

3) Amazon DynamoDB Global Tables (GA)

DynamoDB quickly became one of the most used NoSQL databases when it was launched back in 2012. It’s not the easiest database to work with when it comes to data design (learn more here), but it definitely solves most of the problems related to scalability, performance, security, extensibility, etc.

AWS announced and released the first tools and building blocks to enable DynamoDB cross-region replication back in 2015 (i.e. cross-region replication Java library and DynamoDB Streams). However, setting everything up manually was still kind of cumbersome, especially when considering more than two or three regions.

The newly announced DynamoDB Global Tables will take care of that complexity for you by enabling multi-master and multi-region automatic replication. This is incredibly powerful, especially if you are designing a single-region serverless application backed by API Gateway, Lambda, and DynamoDB. With just a few clicks, you can easily enable Global Tables, deploy your stack into multiple regions, perform some ACM and Route53 tricks, and finally obtain a multi-region serverless application.

The most interesting part is that you won’t need to rewrite your application code since DynamoDB will take care of IAM Roles, Streams, Functions, etc. Also, you will have access to both local and global table metrics.

On the other hand, only empty tables can become part of a global table , which means you can’t easily go multi-region with your existing DynamoDB tables.

Also, remember that removing a region from your Global Table will not delete the local DynamoDB table, which will be available until you actually delete it, but you won’t be able to re-add it to the Global Table either (unless it’s still empty). Basically, you have to carefully choose the regions of your Global Table before you start writing any data into it. We hope that someone will come up with a clever workaround soon.

4) Amazon DynamoDB On-Demand Backup (GA)

The ability to backup and restore DynamoDB tables used to require ad-hoc tools and workarounds, which often required a long time and impacted production database performance. AWS has finally announced a built-in mechanism to create full backups of DynamoDB tables and point-in-time restore capabilities.

Backups will be incredibly useful for handling both regulatory requirements and application errors. You can create backups on the web console or via API. Although there is no built-in way to automatically create periodic backups, our friends at Serverless Inc. have already developed a Serverless Framework Plugin to automate this task for you.

My favorite part is that on-demand backups will have absolutely no impact on the production database. I also like that they are instant operations thanks to how DynamoDB handles snapshots and changelogs. It’s worth noting that each backup will save your table’s data and your capacity settings and indexes. Also, both backups and restores are charged based on the amount of data ($0.10 per GB per month for backups, $0.15 per GB for restores).

The only bad news is that the point-in-time restore functionality will come later next year, while on-demand backups are available today.

5) Amazon Neptune (Preview)

Amazon Neptune is the only new service on this list. It is a fully managed graph database and you can sign up for the limited preview here.

Neptune is intended for use cases where you need highly connected datasets that do not fit well into a relational model. If you already have a graph database, you’ll be able to migrate it into Neptune because it already comes with Property Graph and W3C's RDF support. This means that you can query it with Gremlin (TinkerPop models) and SPARQL (RDF models).

Technically, Neptune can store billions of nodes and edges, and it guarantees millisecond latency and high availability and throughput thanks to 15 replicas across multiple AZs, VPC security, automated backups into S3, point-in-time restore capabilities, automatic failover, and encryption at rest.

In terms of pricing, Neptune is charged by the hour based on the instance type (db.t2.medium or db.r4.*), the total number of requests ($0.20 per million), the total amount of storage ($0.10 per GB per month), and the data transfer (the transfer to CloudFront is free!).

6) Amazon S3 Select (Preview)

Amazon S3 is the grandfather of every Amazon Service, and it keeps innovating how you think about data storage.

So many use cases adopted S3 as their preferred solution to build a data lake, and in many of those use cases, the ability to fetch the exact amount of data can drastically improve both performance and cost. There is an entire family of services that can automatically write into S3 (e.g. Amazon Kinesis Firehose) or query S3 objects without managing servers (e.g. Amazon Athena). However, most of the time the data you need is spread across multiple S3 objects; the only way to retrieve it is to fetch all of those objects.

S3 Select will optimize data retrieval performance and costs by enabling standard SQL expressions over your S3 objects. With S3 Select, you can write simple queries to extract a subset of the data. For example, you could fetch only specific sub-fields of every object or only fetch objects that satisfy a given condition.

This way, all of the filtering logic is performed directly by S3, and the client will receive a binary-encoded response. The advantage is that less data will need to be transferred, reducing both latency and costs of most applications. For example, Lambda applications that read S3 data will be able to reduce the overall execution time. Similarly, EMR applications will be able to use the corresponding Presto connector to drastically improve queries to S3 without changing the query code at all.

S3 Select is still in limited preview and you can sign up for the preview here. It already supports CSV and JSON files, whether gzipped or not. For now, encrypted objects are not supported, although I’m sure they will be once S3 Select becomes generally available.

My favorite part of S3 Select is that it will be supported natively by other services such as Amazon Athena and Redshift Spectrum. This means that it will automatically make your queries faster and cheaper.

7) Glacier Select (GA)

The same S3 limitations related to query efficiency hold for Amazon Glacier, with the additional constraint of waiting a few minutes (or hours, depending on the retrieval type).

Glacier Select is generally available and provides the same standard SQL interface of S3 Select over Glacier objects, effectively extending your Data Lake to cold storage as well. The best part is that Glacier Select will also be integrated with Amazon Athena and Redshift Spectrum. It sounds great, but I’m not sure how an Athena query will run for three hours waiting for Glacier data.

Glacier Select comes with the very same SQL interface, which allows you to reuse S3 Select queries once the objects have been archived into Glacier. Since Glacier won’t have to retrieve the entire archive, fetching archived data will become cheaper, and you still have the ability to choose the retrieval type (standard, expedited, or bulk).

Depending on the retrieval type, Glacier Select will be charged based on the total number of Select queries, how much data has been scanned, and how much data has been retrieved. Of course, retrieved data will be more expensive than scanned data (between 25% and 150% more expensive, depending on the retrieval type), while requests are charged in the order of $0.01 per request in case of expedited retrieval, $0.00005 per request for standard retrieval, and $0.000025 per request for bulk retrieval (price depends on the region, too).

What’s next?

I’m looking forward to experimenting with these new services and features myself, as I’m still waiting to be waitlisted for the limited preview. I’m quite excited by the possibility to painlessly create a global data layer, either with SQL or NoSQL.

As Amazon Aurora is becoming a sort of super cloud-native database, I’m especially curious about the many new features that will be announced. For example, as of re:Invent, it now supports synchronous invocations of AWS Lambda Functions in your MySQL queries.

In the meantime, I will play with DynamoDB Global Tables and build my first globally available serverless application backed by DynamoDB, Route53, Lambda, and API Gateway.

Of course, my favorite update in this list is Aurora Serverless, and I can’t wait to check it out and finally remove every fixed cost from my architecture (while still using our beloved SQL).

Catch up with more of our re:Invent 2017 recaps for Amazon Rekognition Video, Amazon GuardDuty, and AppSync on the Cloud Academy blog.

We’d love to hear about your favorite AWS re:Invent announcement and what you are going to build with it!

AWS AppSync – GraphQL as a Service

Alex Casalboni — Wed, 29 Nov 2017 10:20:36 +0000

Day two at re:Invent 2017 was incredibly packed, crowded, and exciting. My favorite announcement so far is the new AWS AppSync, as it aligns with one of the most promising (yet somehow controversial) design principles adopted by the serverless community: GraphQL. If you are not familiar with GraphQL, we recently explained how to write GraphQL Apps using AWS Lambda, and hosted a webinar about the Love Story between Serverless and GraphQL. Here’s a quick look at what you need to know about AWS AppSync.

Mobile and Web App Challenges

I attended the first deep dive session on AWS AppSync, which brilliantly summarized the main technical challenges faced by most mobile and web applications:

Authentication & user management
Efficient network usage
Multi-device support
Data synchronization between devices
Offline data access
Real-time data streams
Cloud data conflict detection & resolution
Running server-side code (without managing servers)

Each of these challenges could merit its own article, but I am assuming that everyone has experienced a really bad mobile UX, and at least once from the user perspective (any implicit reference to the AWS re:Invent app is clearly unintentional). Moreover, most of these challenges are a direct consequence of how we’ve been designing RESTful interfaces for web and mobile.

If you are a web or mobile developer, GraphQL can help you solve many of these challenges, especially the ones related to network optimization, thanks to dynamic queries, and real-time data streams, thanks to GraphQL subscriptions.

How is GraphQL better than REST?

GraphQL can alleviate the pain caused by many complex problems that are pretty much unsolvable with REST only. This includes API resource relationships , reduced or customized information in API responses , dynamic query support , advanced ordering and paging , push notifications , etc.

GraphQL is basically a query language for APIs , and it makes it very easy to add an abstraction layer on top of already existing data and APIs. Plus, it's strongly typed and can act as a self-documenting contract between client and server.

Again, if you are not familiar with the concept of GraphQL Queries, Mutations, and Subscriptions, have a read here (it gets more technical from now on!).

AWS AppSync Features & Gotchas

AWS AppSync allows you to focus on building apps instead of managing all the infrastructure needed to run GraphQL (either with or without servers).

AppSync will connect queries to AWS resources, and it provides built-in offline and real-time stream support via client-side libraries , which also come with different strategies for data conflict resolution (even custom Lambda-based implementations!). The service offers enterprise-level security features such as API keys, IAM, and Cognito User Pools support.

As with any GraphQL application, your development workflow would look like the following:

Define your schema (queries, mutations, and subscriptions)
Define resolvers (data sources)
Use client tooling to fetch data via the GraphQL endpoint

AWS AppSync provides built-in support for three data sources:

DynamoDB
ElasticSearch
Lambda (for custom or generated fields)

The AppSync client library is available both for mobile and web clients (iOS, Android, JavaScript, and React Native). Offline support is pretty straightforward, and the client will automatically sync data when a network is available. Since GraphQL is an open standard , you are not forced to use the AppSync client. In fact, any open-source GraphQL client will work. Of course, AppSync endpoints can be used by servers, too.

Mutation Resolvers can be mapped into data sources via mapping templates (Velocity). As with API Gateway templates, they come with a few utilities such as JSON conversion, unique ID generation, etc., and ready-to-use sample templates. Based on the specific data source, templates will allow for complete customization of the backend query (e.g. DynamoDB PutItem, ElasticSearch geolocation queries, etc.).

Since you’ll spend most of the time working with the Schema Editor, I was quite happy to notice that it is quite user-friendly, and it comes with search and auto-complete capabilities.

AWS AppSync and AWS Lambda

You can use AWS Lambda to compute dynamic fields, eventually in a batch fashion. For example, imagine that your schema defines a “paid” field that needs to be fetched from a third-party payment system for each invoice. You would probably define a ComputePaid Function and a ComputePaidBatch Function.

The batch function will be automatically invoked to process the value of multiple records without incurring the N+1 problem. Of course, you could use the same Lambda Function for individual and batch processing.

AWS AppSync Pricing

AppSync will be charged based on the total number of operations and real-time updates. More detailed, real-time updates are charged based on the number of updates and the minutes of connection.

Here are the numbers:

$4 per million Query and Data Modification Operations
$2 per million Real-time Updates
$0.08 per million minutes of connection to the AWS AppSync service

Please note that data transfer is charged at the EC2 data transfer rate and that real-time updates are priced per 5kb payload of data delivered (prorated). While the service is completely free during the preview phase, it will come with a free tier once it is generally available.

Also note that AppSync has no minimum fees or mandatory service usage , compared to other similar offerings such as Graphcool.

Conclusions

I expect that AWS AppSync will be well received by the serverless community, and it will make GraphQL much easier to adopt for many use cases.

It will be a great option for applications that need to drastically optimize data delivery, or to transparently manage many data sources under the hood. Moreover, it will also allow developers to design self-documenting APIs powered by a strong type system and a powerful set of developer tools that will simplify API evolution.

Keep in mind that AWS AppSync is still in preview, but you can start playing with it by signing up here.

I’m looking forward to playing with it myself next week, and I can’t wait to share my first results with the community. If you already use GraphQL in production, let us know what you think of AWS AppSync in the comments below!