This document discusses the threats and opportunities of going serverless on AWS. It covers limitations on deployment package sizes for Lambda functions, how Firecracker is used to power Lambda, and that serverless may be cheaper but not necessarily simpler due to underlying complexity. It also discusses development patterns like microservices and monolithic approaches. Frameworks like AWS SAM and the Serverless Framework are presented. Considerations around infrastructure setup, local development environments, security, logging/tracing, and loss of control are also covered. Opportunities of serverless like automated infrastructure management and cost/time savings are highlighted.

1. Going serverless on AWS
The Threats and Opportunities of Going Serverless
Valentyn Nastenko
nastenko@zeoalliance.com

2. Figleaf
The choice to be private is
all yours.
https://figleafapp.com

4. Development environments: Limitations
> aws lambda update-function-code --function-name limits-test --region us-east-1 --zip-file fileb://./50MB.zip
An error occurred (RequestEntityTooLargeException) when calling the UpdateFunctionCode operation: Request must be smaller than
69905067 bytes for the UpdateFunctionCode operation
>aws lambda update-function-code --function-name limits-test --region us-east-1 --s3-bucket limits-test-foobar-bucket --s3-key 250MB.zip
An error occurred (InvalidParameterValueException) when calling the UpdateFunctionCode operation: Unzipped size must be smaller
than 262144000 bytes
In practical terms, this means that the size of your deployment package’s zip
file would be around 100 MB—assuming a deflation of 40%.

5. MicroVM: Firecracker
Remember that it’s Lambda’s prerogative to create a new container. You shouldn’t expect your function to
run on a warm container; you should just be happy when it does.
.@awscloud uses #Firecracker to power
#Lambda, where it replaced EC2 to host
#serverless compute jobs. With a boot
time of .125 microseconds, this runtime
can fire up 150 Micro-VMs/sec -- Holly
Mesrobian

6. Serverless is cheaper, not simpler
Take the canonical HelloRetail serverless project code and inspect how much
complexity is left-out.
The “project”, the services’ dependencies on PaaS and each other, the
deployment order, event types and schemas and many more are not covered by
the framework.
They are partially scripted, partially documented, but mainly residing in the heads
of the “uber-architects” or as tribal knowledge (which, in software, is also known as
“trouble knowledge”).

7. Development environments: Patterns
1. Microservices Pattern
Benefits of Microservices Pattern:
● Total separation of concerns. Each job/operation is in a separate unit of deployment (i.e., a separate Lambda function), allowing
you to modify your application’s components individually, without affecting the system as a whole. This is a very agile and safe
pattern, especially in production.
● Each Lambda function handles a single event making your functions easy to debug, since there is usually only one expected
outcome.
● This separation of concerns is also great for autonomous teams. They can push functionality into production independently.
Drawbacks of Microservices Pattern:
● You will end up with a lot of functions, which is harder to manage and can result in a lot of cognitive overhead. Lambda functions
tend to be more granular than traditional microservices, so be ready for a lot of them!
● Performance could be slower. When functions handle a single job, they are called less, resulting in more cold starts.
● Deployments will be slower, since multiple functions have to be provisioned.
● You could reach the CloudFormation template file size limit quickly, especially if you’re using custom resources.

8. Development environments: Patterns
2. Services Pattern
Benefits of Services Pattern:
● This will result in less Lambda functions that you need to manage.
● Some separation of concerns still exists.
● Teams can still work autonomously.
● Faster deployments.
● Theoretically better performance. When multiple jobs are within a Lambda function, there is a higher likelihood that Lambda
function will be called more regularly, which means the Lambda will stay warm and users will run into less cold-starts.
Drawbacks of Services Pattern:
● Debugging gets slightly more complicated, since the Lambda function is handling multiple jobs, and has different outcomes.
● Requires creating a router to call the right logic based on the request method or endpoint.
● Bigger function sizes due to putting multiple operations within the same Lambda function.

9. Development environments: Patterns
3. Monolithic Pattern
Benefits of the Monolithic Pattern:
● A single Lambda function is much easier to comprehend and manage. It’s more of a traditional set-up.
● Fast deployments, depending on the total code size.
● Theoretically faster performance. Your single Lambda function will be called frequently and it is less likely that your users will
run into cold-starts.
Drawbacks of the Monolithic Pattern:
● Requires building a more complex router within your Lambda function and ensuring it always directs calls the appropriate logic.
● It’s harder to understand performance. The Lambda function will run for a variety of durations.
● You can easily hit the Lambda size limit in real world practical applications due to the larger function size.

10. Development environments: Frameworks
UP
AWS SAM

11. Development environments
● Open Source Framework
● No CloudFormation
● Supports other platforms as well
● Takes care of nasty deployment things
● Support offline mode
● Extend the Serverless Framework with community driven plugins
● Huge community

12. Infrastructure setup

13. Developers will need to devop

14. Development environments: Local Development

15. Security
1. Event-data injection, leading to OS command injection
2. Improper exception handling and verbose error messages,
leading to sensitive information disclosure
3. Insecure Serverless Deployment Configuration, leading to
sensitive data exposure
4. Over-privileged function permissions & roles, leading to DB
data leakage and S3 bucket data tampering
5. Inadequate function monitoring and logging- the application
doesn't properly log application layer attacks and errors
6. Insecure 3rd Party Dependencies
7. Application layer Denial of Service
8. An undisclosed *critical* issue, as a bonus!
https://github.com/OWASP/Serverless-Goat

16. Security: FunctionShield
“All serverless developers should use
FunctionShield as part of every new function
they develop” (Yan Cui, Principal Developer,
DAZN)

17. Complicated deploys

18. Logging, error management and tracing
Lightweight, agentless error monitoring
for front-end, back-end, and mobile

19. Logging and tracing: X-Ray

20. Loss of control

21. Loss of control
AWS's S3 outage was so bad Amazon couldn't get
into its own dashboard to warn the world
For S3, we believe we understand root
cause and are working hard at repairing.
Future updates across all services will be on
dashboard.
— Amazon Web Services (@awscloud)
February 28, 2017
I can't change my mouse sensitivity
because @razer @razersynapse
servers are down 🙄 cc @internetofshit
— Callum Mellor-Reed (@callummr)
February 28, 2017
Joys of the @internetofshit - AWS goes down.
So does my TV remote, my light controller, even
my front gate. Yay for 2017.
— Brian (@Hamster_Brian) February 28, 2017

22. Loss of control

23. Loss of control

24. Opportunities:
● Automated Infrastructure Management: An entire chain of manual infrastructure management processes is eliminated as
users no longer need to coordinate and manage resource for increasingly distributed software components that constitute
modern apps.
● Cost and Time Saving: The operational costs and time is reduced as no system administration processes are required to
package and deploy the apps.
● High Scalability and Optimized Resource Utilization: The cost barrier to scale apps is also reduced as serverless IT
workloads don’t require dedicated resources. Every application request is met with continuous and independent scalability
requirements, yet the users are charged only during the period that requests are served.
● Truly Agile Business Processes: Since the application deployment process is (apparently) decoupled from the underlying
infrastructure, Agile and DevOps-driven organizations are can maintain flexible IT operations and business processes. The
constraints due to hardware complexity and infrastructure configuration limitations have less impact and role in dictating IT-
driven business operations or app functionality. Agile teams can aim for faster development sprints and deploy iterative
improvements or changing app functionality with fewer constraints.
● Reliability and Performance: Services like AWS are inherently resilient and can guarantee performance SLAs most of the
times. Serverless architecture offers the convenience of reducing the opportunities of hardware misconfigurations that
potentially lead to performance degradation with traditional app deployment practices.

25. Thank you for your attention
Valentyn Nastenko
nastenko@zeoalliance.comhttps://goo.gl/T3SqRy