Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Serverless Architectures

Serverless Architectures

It can be argued that the future of cloud computing is going to be serverless (and containerless) and cloud providers will be responsible for providing the runtime environment and all the building blocks needed for creating large scale, distributed systems. Rafal Gancarz presents how such a future could look like based on currently available AWS stack (Lambda, API Gateway, DynamoDB, S3, Kinesis, CloudWatch and more).

Rafal Gancarz

July 05, 2016
Tweet

More Decks by Rafal Gancarz

Other Decks in Technology

Transcript

  1. 2 Agenda • What is serverless? • Why serverless? •

    The state of serverless • Anatomy of the serverless system • Business logic (Lambda) • APIs (API Gateway) • Persistence (DynamoDB, S3, etc.) • Messaging (SNS, Kinesis, etc.) • Other services • How to design a serverless system? • How to secure a serverless system? • How to operate a serverless system? • Infrastructure Provisioning • Continuous Integration / Delivery • Monitoring / Logging / Auditing • The future is serverless • Q&A
  2. 3 What is serverless? • An emerging approach towards building

    cloud-native architectures • Forget (almost) everything you know about the traditional system architecture! • No servers or containers • No OS processes • No runtime (JVM, etc.) • Use only cloud provider services including managed runtime for running application code • The “true” Platform as a Service (?)
  3. • Natural evolution of the cloud computing • virtual machine

    -> container -> function • Built-in fault tolerance • Effortless and limitless(?) scalability • Runtime as a service • Pay for what you use • Reduced operational overhead • No OS to upgrade or patch • No process to manage • No runtime environment to tune or troubleshoot • Embrace the cloud! • Get your service to the market quickly and with minimal investment Why serverless? 5
  4. • AWS the most complete platform • AWS Lambda officially

    launched in April 2015 • several enhanced released subsequently • provides a rich set of cloud services that Lambda functions integrate with • GCP launched Google Cloud Functions in February 2016 (still in alpha) • Microsoft launched Azure Functions in April 2016 (still in preview) 7 The state of serverless
  5. • Runtime as a service • supports Java, NodeJS and

    Python natively • other runtimes can be executed in a sub-process • Event-based execution model • push - events received by AWS Lambda • pull - events consumed by AWS Lambda • Integrated security model (IAM) • Cost based on number of invocations and execution time and allocated memory (in GB-seconds) • 1 million invocations and 400k GB/s free per month on free tier! • $0.20 per 1 million requests and ~$6.65 for 400k GB/s thereafter AWS Lambda 8
  6. • API Gateway • management • security • caching •

    auditing • AWS Lambda can be used as a backend (integration type) • Cost based on number of requests and data transfer • 1 million requests per month for free • $3.50 per 1 million requests and $0.09/ GB (for the first 10 TB, then cheaper) AWS API Gateway 9
  7. • Managed NoSQL database • document & key-value data model

    • consistence performance • highly scalable • fine-grained access control • Can use AWS Lambda as triggers (DynamoDB Streams) • Cost based on provisioned capacity and data storage • 25 GB of storage and 25 units of read capacity each month for free (~200k requests per month) • $0.25 per GB/month and $0.0065 per hour for 10 units of write capacity (36k writes/hour) or 50 units of read capacity (180k reads/hour) AWS DynamoDB 10
  8. • File storage • durable, available and scalable • fine-grained

    access control • Can use AWS Lambda functions to process bucket contents when modified • Cost based on data storage, API calls and data transfer (see online for more details) • 5 GB of storage and 15 GB of data transfer out to Internet each month for free • $0.03 per TB/month and $0.09 per GB data transfer out to Internet AWS S3 11
  9. • Publish-subscribe service • scalable • delivers push notifications to

    mobile devices • delivers to SQS, Lambda, emails, SMS, HTTP • Can be used as an event bus between Lambda functions or whenever pub-sub semantics are required • Cost based on notifications published, delivered and data transfer • 1m publishes, 1m mobile push notifications, 1k emails, 100k HTTP notifications and 1 GB of data transfer out each month for free • $0.50 per 1m publishes, $0.60 per 1m HTTP notifications and $0.09 per GB data transfer out to Internet • SQS queue and Lambda deliveries are free AWS SNS 12
  10. • Real-time data streaming • parallel processing with multiple consumers

    • scalable and reliable • Apache Kafka “in the cloud” • Can be used as an high-throughput event bus between Lambda functions • Cost based on number of shards (partitions) and messages sent • no free tier • $0.015 per shard/hour, $0.014 per 1m PUT payload units (25KB) + extended retention charges • data transfer is free AWS Kinesis 13
  11. • SQS - point-to-point messaging • SES - email integration

    • ElasticSearch - full-text search • Redshift - data warehouse • Cognito - mobile identity and data sync • IoT - device communications • CloudWatch - metrics, logs, events • CloudTrail - auditing • and anything that can run in the VPC Other AWS services 14
  12. • simple use cases are easy • Lambda function that

    processes images uploaded to S3 bucket • SPA (from S3) + API + Lambda function + DynamoDB table • Slack bot • the fun begins when trying to create a complex enterprise-grade system • 10s/100s of Lambda functions • buckets, tables, topics, queues, streams … 16 Architecture
  13. Things to avoid/prevent • monolith in the cloud • big

    ball of mud • tight coupling Use system architecture best practices • modularisation (bounded contexts) • cohesion and encapsulation • clear interfaces • flexible message formats • async messaging 17 Architecture
  14. • Similar objectives • Distributed systems • Functional decomposition •

    Agile development • Different paths or means • Microservices = lightweight SOA • Serverless = use cloud provider platform • Similar challenges • inter-service (module) dependencies • operational complexity • security 18 Serverless and Microservices
  15. • Choosing the runtime • Java - well established, lots

    of libraries • NodeJS - ES6/7 feels quite like Scala, lots of libraries • Python 2.7 - good for scripting, favoured by the client • Things to consider • packaging function code and dependencies • code reusability • ease of adoption • Frameworks • Serverless (formerly JAWS) • Apex • Claudia.js 19 Development
  16. • AWS IAM to the rescue • id/secret based authentication

    • policy based access control (explicit, users, groups, roles) • AWS STS for granting privileged access temporarily • API keys for API Gateway • Separate AWS account per environment • Admin access via master account 21 Security
  17. • Challenges • multiple accounts • multiple stacks • inter-stack

    dependencies • global namespace resources • post-provisioning tasks • orchestration • AWS CloudFormation • API Gateway not supported • CF template language not ideal • HashiCorp Terraform • API Gateway supported • bespoke config generation solution (perhaps could be replaced with Terraform templates) 23 Infrastructure Provisioning
  18. • Local development still useful/required • Unit testing Lambda functions

    (mocking out AWS dependencies) • Packaging Lambda functions • dependency management • configuration management • versioning • Integration and functional testing • Infrastructure provisioning testing • Provisioning/deployment orchestration using Jenkins with Pipeline plugin 24 Continuous Integration / Delivery
  19. • AWS CloudWatch metrics • Lambda invocation counts, error counts,

    durations • API metrics • DynamoDB metrics • AWS CloudWatch logs + ElasticSearch + Kibana • JSON log format • additional business specific attributes • transaction tracing • AWS CloudTrail • API Gateway • AWS API calls Monitoring / Logging / Auditing 25
  20. Current challenges • Platform capabilities still not complete or mature

    • Tooling is seriously lacking • Patterns and practices not established yet Predictions (or hopes) • More investment from cloud providers and users • Cloud providers will consolidate their platforms even more to make building serverless systems easier • New capabilities geared towards serverless 26 The future is serverless …