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). Gatling is a scalable performance testing framework providing a rich and flexible DSL written in Scala. If you need to perf/load test a REST API or a web app you can use Gatling to generate a substantial amount of load and define your testing scenarios with ease. Rafal will provide an overview of the DSL and show how easy and productive using Gatling is, including a live demo.
About Rafal Gancarz
Rafal GanCarz is a Lead Consultant for OpenCredo having joined the company in 2014. Rafal is responsible for leading engagements for OpenCredo with its clients. He is a technologist with experience in high quality distributed systems, improving project delivery and building high performance Agile teams.
2. 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
3. 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 (?)
5. • 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
6. 6
The Arcadian or Pastoral State, Thomas Cole (1834)
That all makes sense … happy days :)
7. • 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
8. • 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
9. • 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
10. • 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
11. • 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
12. • 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
13. • 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
14. • 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
16. • 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
17. 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
18. • 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
19. • 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
21. • 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
26. 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 …