June 2017 – Toronto AWS User Meetup

Serverless Backends w/AWS Lambda & API Gateway

Frank and Jay from Anomaly Innovations talked about their experiences with serverless APIs running on AWS Lambda. Check their site Serverless Stack for detailed tutorial on setting up AWS Lambda functions.

  • check out the serverless framework to make using AWS Lambda easier
  • look out for ServerlessCD project from the presenters
  • keeping infrastructure deployments with Cloud Formation separate from code deployments with AWS Lamda, or your deployments will get slooow and you will not be able to run/fix things as quickly.

I wanted to compare this to Firebase Cloud Functions

  • function signatures are very similar
  • Firebase has a nice CLI tool for deploying code to Google’s servers. AWS users will use 3rd party open source tools for this
  • AWS offers a wider variety of environments for running code (Node, Java, javascript, .NET) than Firebase (javascript only)
  • like Firebase Cloud Functions, using AWS Lambda will force you into using a more microservicey architecture

AWS Layered Approach to Security

Nick Boccone from Engage talked about general application security stuff and made me feel OK to be be paranoid about everything.

4 tenets of security

  1. trust nothing and no one
  2. nothing is secure until you turn it off
  3. security is a tradeoff with usability
  4. embrace your paranoia

6 layers of security

  1. descope, limit, block
    • store less data so there is less to steal
    • do less work on a server or service so there is less surface area to attack
    • block access by default and use whitelists
  2. Know your touch points, the boundaries of your application/product
    • where does your application interact with other applications from other organizations?
    • where does your application interact with infrastructure from other applications?
    • where does you application interact with people vulnerable to social engineering
  3. didn’t write it down
    • something else about touchpoints?
  4. make access difficult
    • trade-off between usability and security e.g. 2 factor auth
  5. didn’t write it down
    • wish I wrote it down
  6. Keep up-to-date
    • keep software patched
    • policies need to be reviewed and updated when there is new information
    • training (you team and customers need to know about)
    • security landscape (OWASP, National vulnerability db, AWS security cheat sheet?)

Words I had to look up

Federated

Maybe it was this? Federated Architecture. A group of distinct services or databases working together

DMZ

demilitarized zone – exposing part of a network to the public (e.g. DNS, FTP, email sending/receiving), and hiding the rest behind a firewall (e.g. file storage, computing)

Also from chatting with people

https://www.meetup.com/Toronto-AWS-Users-United/events/238953929/

Toronto AWS Users United: Building Unbreakable Software

We met at The Score‘s office, and Nate Smith talked about ways to structure AWS-hosted applications for availability and consistency.

Here are some points that stood out:

  • Your software will probably outlive the VM it lives in. Be ready to deploy to another server on short notice, or have redundant servers ready

  • Build systems that get stronger when they break, like human muscle. Read Antifragile

  • EC2 can have network outages between nodes. Do not trust the network more than you trust an instance

  • One bad outage example – on April 2 2011, parts of the AWS EBS service were down for 80 hours (despite this, Amazon is still better at sysadminning than you)

  • When thinking about CAP theorem and a network of database servers, assume the network will go down. That means the P (partition tolerance) is chosen as 1 of your 2 options, and you are choosing between C and A. Shopping Cart software usually picks Availability as the other option. How to deal with the resulting inConsistency is a business issue

  • Check out Jepsen, tests of different databases to see they react to network partitions.

  • Oversimplified CAP summary:

    • Got 1 MySQL server? You have CP, because your data is consistent (it’s all in 1 place), but not available (1 server goes down = no availability)
    • Got 1 read/write server and replicas to read from? You have AP because your data is available (some read replicas can down and you’ll be OK), but data isn’t consistent across all servers (due to replication lag, network partitions, or other issues)

The crowd at the Toronto AWS Users United meetup

Building Unbreakable Software on Amazon Web Services

Wednesday, Sep 10, 2014, 6:00 PM

theScore
500 King Street West, 4th Floor Toronto, ON

60 Members Went

We’re all set to get together again and chat all things AWS.This time we will have Nate Smith from Shopify share his experience and thoughts on designing unbreakable systems on AWS.You’ve turned off the last server in the rack. Your software is running blissfully on a dozen – maybe hundreds – of EC2 instances. Everything’s humming along and then…

Check out this Meetup →