What's New in AWS Serverless and Containers 亞馬遜 AWS 於 2018 年 11 月底在美國拉斯維加斯所舉辦的第七屆 AWS re:Invent 2018 大會，在 AWS 客戶、合作夥伴、媒體人士、產業分析師及 AWS 員工共襄盛舉下，與會人數再創新高，超過 5 萬人。會中 AWS 發布超過 20 款雲端方案，且一半以上專攻雲端 AI、機器學習、物聯網，包括對 SageMaker 強化更多進階功能，推出第一款專用的機器學習推論晶片、加入深度的機器學習運算法支援，及其他包括儲存、資料庫、混合雲、邊緣運算 IoT 等解決方案。而具備微型機器學習能力的迷你自駕遙控車 DeepRacer 的現身，驚人之舉不僅抓人眼球，深入客戶體驗的用心，更成功抓住全球使用者的心。 為讓您與全球先進技術同步，共享最新趨勢資訊，解決您開發機器學習和發展 AIoT 所遇到的難題，AWS 台灣團隊將於 2019 年 1 月 31 日 (四) 舉辦《AWS re:Invent 2018 Recap 台北》，特別嚴選最適切國內諸位先進和企業需求的內容，從「技術創新」、「AIoT」兩大分組議程，發表 AWS 的新服務和新方案。大會除了邀請亞馬遜 AWS 大中華區首席雲計算企業顧問 (Principal Evangelist) 張俠博士分享 AWS 的解決方案藍圖外，眾多 AWS 資深專家也將分享包含機器學習、深度學習推理加速等新方案，完全託管的文件系統、資料庫，無伺服器、容器技術與安全性，以及大數據與分析、物聯網服務應用、儲存方案等最新技術。歡迎您親臨會場，全方位體驗 AWS 新服務將能為您創造的驚人創新之效益。

1. What’s New in AWS
Serverless and Containers
Pahud Hsieh(謝洪恩)
Specialist Solutions Architect, Serverless

2. Agenda
• Lambda Layers
• Lambda Custom Runtime and Runtime API
• Firecracker
• Amazon API Gateway Websocket Support
• AWS App Mesh
• AWS Cloud Map

3. Lambda Layers

4. Photo by Thibault Mokuenko on Unsplash
A way to centrally manage code and data
that is shared across multiple functions

5. Lambda Layers Use Cases
• Custom code, that is used by more than one function
• Libraries, modules, frameworks to simplify the
implementation of your business logic

6. Lambda Layers Benefits
• Enforce separation of concerns, between dependencies and
your custom business logic
• Make your function code smaller and more focused on
what you want to build
• Speed up deployments, because less code must be
packaged and uploaded, and dependencies can be reused

7. Using Lambda Layers
• Put common components in a ZIP file and upload it as a Lambda Layer
• Layers can be versioned to manage updates
• Each version is immutable
• When a version is deleted or permissions to use it are revoked,
functions that used it previously will continue to work, but you won’t
be able to create new ones

8. Using Lambda Layers
• In the configuration of a function, you can reference up to five layers
• One of which can optionally be a custom runtime
• When the function is invoked, layers are installed in the execution
environment in the order you provided
• The overall, uncompressed size of function and layers is subject to the usual
unzipped deployment package size limit (256MB)

9. How Lambda Layers Work
• Order is important because each layer is a ZIP file, and they are all
extracted in the same path
• /opt
• Each layer can potentially overwrite the previous one
• This approach can be used to customize the environment
• For example, the first layer can be a custom runtime and the second layer adds
specific versions of the libraries you need
• The storage of your Lambda Layers takes part in the AWS
Lambda Function storage per region limit (75GB)

10. mthenw/awesome-layers
https://github.com/mthenw/awesome-layers

11. mthenw/awesome-layers
https://github.com/mthenw/awesome-layers

12. mthenw/awesome-layers
https://github.com/mthenw/awesome-layers

13. mthenw/awesome-layers
https://github.com/mthenw/awesome-layers

14. mthenw/awesome-layers
https://github.com/mthenw/awesome-layers

15. Lambda Custom Runtime
and Runtime API

16. Photo by Jeremy Lapak on Unsplash
A simple interface to use
any programming
language, or a specific
language version, for
developing your
functions

17. Lambda Runtime API
You can now select a custom runtime in the console (provided in the
API/SDKs/CLI) as the runtime of a Lambda function
With this selection, the function must include (in its code or in a layer) an
executable file called bootstrap
• The runtime bootstrap is responsible for the communication between your code and
the Lambda environment
• Your code can use any programming language

18. Runtime Boostrap
The runtime bootstrap uses a simple HTTP based interface to
• get the event payload for a new invocation and
• return back the response from the function
Information on the interface endpoint and the function handler are
shared as environment variables

19. Using Custom Runtimes
For the execution of your code, you can use anything that can run in
the Lambda execution environment.
• For example, you can bring an interpreter for the programming language of your
choice.
You only need to know how the Runtime API works if you want to manage
or publish your own runtimes
As a developer, you can quickly use runtimes that are shared with you as
layers
• Custom runtimes can be shared as layers so that developers can pick them up and
use their favorite programming language when authoring Lambda functions

20. Open Source Runtimes
• C++ (AWS)
• Rust (AWS)
• Erlang (AlertLogic)
• Elixir (AlertLogic)
• Cobol (Blu Age)
• Node.js (NodeSource N|Solid)
• PHP (Stackery)

21. Firecracker

25. Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code

26. Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
One Function
One Account
Many
Accounts

27. Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
cgroups,
namespaces,
seccomp,
iptables,
& chroot

28. Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
virtualization &
device
emulation

29. Hardware
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
EC2 instances
on EC2 Nitro platform

30. Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
Firecracker
EC2 Bare Metal

31. Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
One Function
Many
Accounts

33. % of Resources
Doing Useful Work
(vs. idle or waste)

34. With Lambda:
Pay only for useful work.

35. Inside Lambda:
Optimize To Keep
Servers Busy

37. Available Sandboxes For a Function

38. Bad: Balance The Load
60% 60% 60% 60% 60% 60% 60%

39. Good: Concentrate The Load
99% 99% 99% 99% 0% 0% 0%
Cache Locality
Ability to Autoscale

40. Server
Bad: Pack Server With One Workload
Workload
Workload
Workload
Workload
Workload
Workload

41. Server
Better: Pack With Many Loads
Workload
Workload
Workload
Workload
Workload
Workload Take advantage of
Statistical Multiplexing

42. Server
Best: Placement Optimization
Workload
Workload
Workload
Workload
Workload
Workload Pick workloads that
pack together well.
Minimize contention.

43. Firecracker Hypervisor vs. Others
↓ Startup time
↓ Memory overhead
= Performance
↑ Flexibility

44. Firecracker Unlocks
Higher Utilization and Scale

45. Amazon API Gateway
Websocket Support
General
Available

46. Introducing: API Gateway WebSocket APIs
Invoke AWS services
like Lambda, Kinesis, or any
HTTP endpoint based on
message content
Build real-time two-way
communication applications
chat, alerts and notifications,
and streaming dashboards
Fully managed APIs
to handle connections and
messages transfer between
users and backend services
Pay for what you use
based on connection minutes
and messages transferred
Stateful connection Stateless connection
Amazon API Gateway
WebSockets API
Public
endpoints on
Amazon EC2
Lambda
functions
Any other
AWS service
All publicly
accessible
endpoints
Amazon
Kinesis
Mobile apps
Chat
AWS IoT
devices
Dashboards

47. AWS App Mesh

48. Introducing AWS App Mesh
Visibility and control for
microservices on AWS
App Mesh is a service mesh

49. Monolith
Microservices increase release agility
Monolithic application Microservices

50. Monolith

51. Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service

52. Rust
Database
DB
Database
Rust
GoNode.is
Java
Node.is
Node.is
Infrastructure team
Service
Teams

53. Containers
Database
DB
Database
Containers
λContainers
VMs
Managed
Service
Managed
Service

54. What is needed
Consistent
communications
management
Complete visibility Failure isolation
and protection
Fine-grained
deployment controls

55. Why service mesh proxy
vs. Libraries or app code
Overall—migrate to microservices safer and faster
Reduce work required
by developers
Follow best practices Use any language
or platform
Simplify visibility,
troubleshooting, and
deployments

56. OSS project
Wide community support, numerous integrations
Stable and production-proven
“Graduated Project” in Cloud Native Computing
Foundation
Started at Lyft in 2016
App Mesh uses Envoy proxy

57. App Mesh configures every proxy

58. Today App Mesh is available as a preview for all
customers
Observability and traffic control
Easily export logs, metrics, and traces (available)
Client side traffic policies—circuit breaking, retries (coming soon)
Routes for deployments (available)
AWS container services compatibility
Today: Amazon Elastic Container Service (Amazon ECS) & Amazon
Elastic Container Service for Kubernetes (Amazon EKS)
Coming soon: AWS Fargate

59. AWS Cloud Map

60. Complexity of modern architectures
• Wide variety of resources
• Complexity grows exponentially
• Multiple versions and stages coexist
• Infrastructure scales dynamically
• Unhealthy resources are replaced

61. Service Discovery
Finding the location of a service provider
myapp: {10.24.34.5:8080, 10.24.34.6:8080}
mylogs: {S3bucket1, S3bucket2}
How to find resources to connect to?

62. Server-side service discovery pattern
- Connections are proxied
- Discovery is abstracted away
- Availability and capacity impact
- Additional latency
Client
Service
Provider
Service
Provider
Service
Provider
Request Request
LB +
Service
Registry
Register
Register

63. - Clients connect directly to providers
- Fewer components in the system
- Clients must be registry-aware
- Client-side load balancing
Client
Service
Provider
Service
Provider
Service
Provider
Service
Registry
Request
Register
Register
Register
Query
Client-side service discovery pattern

64. Existing solutions require setup and management
Service
Registries
Service
registry
doozerd
SmartStack
Eureka

65. Build the dynamic map of your cloud
Define convenient names
for all cloud resources
Discover resources
with specific attributes
Ensure only healthy
resources are discovered
Use highly available
DNS and regional API

67. Registry for all cloud resources

68. Registry for all cloud resources

69. AWS Cloud Map registry
cloudmapdemo.com
backend
Name = backend
DNS record = A
TTL = 60 sec
Health Check = Yes
Instance-1
172.10.0.1
Instance-2
172.10.0.2
Instance-3
172.10.0.3
• Namespace
• Service
• Service Instance

70. Register resources for API + DNS discovery mode
1. aws servicediscovery create-public-dns-namespace --name
cloudmapdemo.com
2. aws servicediscovery create-service --name frontend
--dns-config “NamespaceId=%namespace_id%, DnsRecords=[{Type=A,
TTL=60}]”
3. aws servicediscovery register-instance --service-id %service_id%
--instance-id %id%
--attributes
AWS_INSTANCE_IPV4=52.89.144.60,
stage=beta,
version=1.0,
ready=yes

71. Register any cloud resource for API discovery
1. aws servicediscovery create-http-namespace --name shared
2. aws servicediscovery create-service --name logs --namespace-id
%namespace_id%
3. aws servicediscovery register-instance --service-id %service_id%
--instance-id %id%
--attributes
ARN=arn:aws:s3:::cloudmapdemoservicelogsbeta1,
stage=beta,
shard=s_1,
read_only=no,
path=/mylogs

72. Secure name resolution via API calls
aws servicediscovery discover-instances --namespace-name shared --service-name
logs
-->
{ "Instances": [
{
"InstanceId": "i1",
"NamespaceName": "shared",
"ServiceName": "logs",
"HealthStatus": "UNKNOWN",
"Attributes": {
"read_only": "no",
"path": "/mylogs",
"shard": "s_1",
"ARN": "arn:aws:s3:::cloudmapdemoservicelogsbeta1",
"stage": "beta”
}
}
]
}

73. Name resolution via DNS
dig +short A frontend.cloudmapdemo.com
-->
52.89.144.60
52.26.95.129
34.214.232.177

74. Take-aways
• Lambda Layers
• Lambda Custom Runtime and Runtime API
• Firecracker
• Amazon API Gateway Websocket Support
• AWS App Mesh
• AWS Cloud Map

75. THANK YOU！