2. Best Practice in AWS ECS and Serverless
• Last Updated: April/19 2016
• Scheduled for 45 minutes
- The Challenges
- Foundational Concepts of ECS and Serverless
- New Challenges
- The Future
• Q & A
3. A Bit About Me
• Both an IT Pro and developer for the past 15 years
• Chief Architect of Astra Cloud(miiicasa.com) from Taiwan
• Experienced in IoT cloud platform across multiple AWS regions globally
• AWS All-5 Certificates holder
- AWS Certified Solution Architect - Associate
- AWS Certified SysOps - Associate
- AWS Certified Developer - Associate
- AWS Certified Solution Architect - Professional
- AWS Certified DevOps Engineer - Professional
6. Challenges
• You pay too much for EC2 instances
• pay even much for micro services
• Complexity in Infrastructure
• VPC, subnet, routing-table, NAT, NACL, security groups, ELB, ASG
• Complexity in A/B testing and B/G deployment
• CFN re-deploy, EB env swap, CodePipeline/CodeDeploy, OpsWorks, etc.
• complexity means error-proneness
8. Questions
• Can I just focus on my service stack unit, instead of computing unit(EC2) ?
• Self-Healing, Auto-Scaling, AZ-balancing ?
• Log Consolidation ?
• Immutable and Stateless Architecture ?
• Cost Optimization and Resource Optimization ?
• still having full control on my tech stack (frameworks and languages)
• simple deployment, A/B and B/G ?
9. a highly scalable, fast, container management service that makes it easy to run, stop,
and manage Docker containers on a cluster of Amazon EC2 instances.
AWS EC2 Container Service
11. Auto Scaling Policy Design
• scale out spot on 30%-60%
• scale out on-demand when >= 60%
• scale in on-demand when <60%
• scale in spot when <=30%
• with minimal 1 on-demand or RI
12. Simply Put
• on-demand/RI 打底 spot伸縮
• on-demand scale out last, scale in first
• try spot fleet if you need couples of instances(
lets talk about it next time )
14. Benefits and Tips
• Leverage ELB to build micro-services
• Monitor service loading by CloudWatch and adjust spot fleet to scale out/in services/tasks
dynamically
• Self-healing in container level
• Fully-managed deployment and rolling update with revisions
• Better resource utilization
• Consolidate application logs to CloudWatch Logs
• Create filter, metrics and build alarms from CloudWatch Logs
• Push your docker images to ECR and deploy across regions with exactly the same image
20. Is there a way to move the code in
a cloud native way?
21. “No server is easier to manage than no server”
- Werner Vogels, Amazon CTO
AWS re:Invent 2015
22. AWS Lambda AWS API Gateway
“a compute service where you can
upload your code to AWS Lambda
and the service can run the code
on your behalf using AWS
infrastructure”
“a fully managed service that
makes it easy for developers to
create, publish, maintain, monitor,
and secure APIs at any scale”
31. Pros
• cloud native with your business code in Lambda
• no infrastructure to manage
• leverage AWS PaaS infrastructure at scale
• custom or federated authorization
• very minimal cost for small-medium teams
- 30m requests = $11.63 per month (Lambda)
- $4.25 per million requests(API Gateway)
33. Cons - Lambda Limit
• Lambda soft limit concurrency is 100
• 300 seconds max duration per invocation
• Lambda in VPC restriction
- private IP addresses
- ENIC limit(default 20*5=100)
34. Cons - API Gateway
• 500-1000 QPS per AWS Account
• 5M requests / month = $18.79
• 100 QPS = $974.07 / month = 31,350NTD
• No async or parallel invocation with Lambda
35. Cons - Performance
• push and pull invocation model of Lambda
• -> delegation with higher memory
• no connection pooling
• -> always open/close conn in handler scope
36. Cons - Development
• CloudWatch debugging
• immature CI/CD toolchains
• lack of PHP, Ruby and Golang
• re-deploy the whole bundle could be a pain
38. Use ECS
• financial concern - When you have traffic more than 100QPS+
• operation concern - Long running process or API service
• language concern - Golang, PHP, Ruby, etc.
• performance concern - need really big memory or CPU-
optimized
• protocol concern - websockets, MQTT, other TCP protocols
39. Use Serverless
• small project, simple business logic
• focus on the code only
• no infrastructure management
• stateless
• quick micro services implementation
• simply integrated with other AWS services
- i.e. API Gateway update DynamoDB, Kinesis, SQS as service proxy.
40. Conclusions
• containerize your stack, and try serverless as much as you can
• build stateless application
• immutable architecture - every computing component can be replaced and scaled with
no impact
• focus on your business logic, instead of the infrastructure, forget your infrastructure
• try not use any EC2, if necessary, avoid SSH into EC2 for manual operation
• fully-managed and fully-automation is the way to go
• embrace event-driven cloud computing