Exposing Lambda Functions as
Managed APIs
Fazlan Nazeem
Associate Technical Lead, WSO2
Amila De Silva
Software Architect
Agenda
● What is Serverless
● Why should you think about serverless
● API Management for Serverless Functions
● Lambdas with WSO2 API Manager
● Demo
● Q&A
What is Serverless
Serverless
● not permanently - Resource are allocated in response to events
● Good for stateless processing
● Resources are dynamically allocated when requests are made.
● Invocations are short lived.
“The ability to run a service, without allocating servers
permanently”
Why should you think about
Serverless
Latest step in cloud evolution
Each advancement
enabled Developers
to focus more on
code and less on the
infrastructure.
Image Credit : https://medium.com/royallyserverless/the-cloud-evolution-9ad1c9b3dccc
Latest step in cloud evolution
● There have been different stages in cloud evolution.
● On-prem servers - Enabled businesses to move into internet.
● IaaS - Enabled servers to be hosted on cloud, without worrying about
physical servers
● PaaS - Enabled App hosting without worrying about infrastructure
● FaaS (Serverless) - Enabled performing the operation without worrying
where it is run
● Each advancement enabled Developers to focus more on code and less
on the infrastructure.
Cost effective solution
● Cloud advancements lowered the barriers to enter. FaaS has
brought this even down.
● No burden of running Physical server for a long time - only
pay for the usage.
○ If you are stepping into the business then FaaS presents
you a cost efficient alternative.
○ If you are thinking of bringing down costs, Serverless
offer a good strategy
● No Servers - no hassles
Enforces scalability
● Better Aligns with MicroServices Architecture
○ Functions can be thought of as functional decomposition of a Monolith
○ Different functions have different scaling characteristics
○ Application as a whole uses resource optimally.
● Event driven by nature
○ Serves well for stateless applications.
○ Reacts in real-time and raises more events.
AWS Lambdas
● AWS’s implementation for Serverless.
● No servers to Manage.
● Pay for what you use.
● Can be triggered through different events
○ Change in System State (file upload to S3 Change)
○ Actions triggered by user (HTTP Request Event)
● To consume the Lambda over HTTP
○ Use SDK
○ Use CLI
○ Expose through API Gateway
API Management for Serverless
Functions
Serverless only manages infrastructure
● Serverless only takes care of running and scaling the backend.
● On the consumer side these services are still accessed as normal
RESTFul services.
● When exposing to public couple of things need to be handled.
○ Security & Throttling is more critical now
○ Serverless functions wouldn’t expose a structure
○ Docs/Resources available in the API would be helpful to identify
the structure
○ For billing and analytics purposes user’s context need to be
identified.
Gateway insulates changes better
● Having an intermediate layer is beneficial in many ways
● Changes happening with the backend are not visible to the client
○ Gateway is the only point of contact for consumer Apps
○ Depending on different factors, backend can be hosted serverless or
on premise.
○ GW would hide these changes from consumers
● Some serverless functions requires HTTP requests differently formed.
○ AWS Lambda would require a synchronous HTTP Request Event.
○ This can be done through AWS CLI or using SDK
○ If the Gateway had this functionality integration will be much easy
Lambdas
with WSO2 API Manager
Prior to 3.1.0
● Even with pre 3.1.0 releases, customers used Lambdas by
○ Exposing them through AWS GW
○ Using custom mediation policy to do the intermediate transformation.
○ Hosting a web app or a similar service to do the transformation
● All these methods would involve custom development or would cost an
extra hop.
With API Manager 3.1.0
● Instead of an HTTP endpoint you can specify a Lambda
○ Consumer Apps wouldn’t notice the difference
● All Security/Throttling policies can be applied similar to a normal
API.
● Aggregating different Lambdas to create a single API
Options
● Using Access Keys
● Connecting using AWS IAM roles
Demo
Q & A
● Download and try out:
https://wso2.com/api-management/
● Slack Channel:
https://app.slack.com/client/TLVKGQN84/CLVKGR3BN
● GitHub:
https://github.com/wso2/product-apim/issues
Webinars to Follow
Apr 28
Creating a Scalable and Decentralized API Management Architecture
With WSO2 API
Apr 30
gRPC Support With API Microgateway 3.1
May 5
Deploying GraphQL Services as Managed APIs
May 12
Overview of API Microgateway 3.1
THANK YOU
wso2.com

Exposing Lambda Functions as Managed APIs

  • 1.
    Exposing Lambda Functionsas Managed APIs Fazlan Nazeem Associate Technical Lead, WSO2 Amila De Silva Software Architect
  • 2.
    Agenda ● What isServerless ● Why should you think about serverless ● API Management for Serverless Functions ● Lambdas with WSO2 API Manager ● Demo ● Q&A
  • 3.
  • 4.
    Serverless ● not permanently- Resource are allocated in response to events ● Good for stateless processing ● Resources are dynamically allocated when requests are made. ● Invocations are short lived. “The ability to run a service, without allocating servers permanently”
  • 5.
    Why should youthink about Serverless
  • 6.
    Latest step incloud evolution Each advancement enabled Developers to focus more on code and less on the infrastructure. Image Credit : https://medium.com/royallyserverless/the-cloud-evolution-9ad1c9b3dccc
  • 7.
    Latest step incloud evolution ● There have been different stages in cloud evolution. ● On-prem servers - Enabled businesses to move into internet. ● IaaS - Enabled servers to be hosted on cloud, without worrying about physical servers ● PaaS - Enabled App hosting without worrying about infrastructure ● FaaS (Serverless) - Enabled performing the operation without worrying where it is run ● Each advancement enabled Developers to focus more on code and less on the infrastructure.
  • 8.
    Cost effective solution ●Cloud advancements lowered the barriers to enter. FaaS has brought this even down. ● No burden of running Physical server for a long time - only pay for the usage. ○ If you are stepping into the business then FaaS presents you a cost efficient alternative. ○ If you are thinking of bringing down costs, Serverless offer a good strategy ● No Servers - no hassles
  • 9.
    Enforces scalability ● BetterAligns with MicroServices Architecture ○ Functions can be thought of as functional decomposition of a Monolith ○ Different functions have different scaling characteristics ○ Application as a whole uses resource optimally. ● Event driven by nature ○ Serves well for stateless applications. ○ Reacts in real-time and raises more events.
  • 10.
    AWS Lambdas ● AWS’simplementation for Serverless. ● No servers to Manage. ● Pay for what you use. ● Can be triggered through different events ○ Change in System State (file upload to S3 Change) ○ Actions triggered by user (HTTP Request Event) ● To consume the Lambda over HTTP ○ Use SDK ○ Use CLI ○ Expose through API Gateway
  • 11.
    API Management forServerless Functions
  • 12.
    Serverless only managesinfrastructure ● Serverless only takes care of running and scaling the backend. ● On the consumer side these services are still accessed as normal RESTFul services. ● When exposing to public couple of things need to be handled. ○ Security & Throttling is more critical now ○ Serverless functions wouldn’t expose a structure ○ Docs/Resources available in the API would be helpful to identify the structure ○ For billing and analytics purposes user’s context need to be identified.
  • 13.
    Gateway insulates changesbetter ● Having an intermediate layer is beneficial in many ways ● Changes happening with the backend are not visible to the client ○ Gateway is the only point of contact for consumer Apps ○ Depending on different factors, backend can be hosted serverless or on premise. ○ GW would hide these changes from consumers ● Some serverless functions requires HTTP requests differently formed. ○ AWS Lambda would require a synchronous HTTP Request Event. ○ This can be done through AWS CLI or using SDK ○ If the Gateway had this functionality integration will be much easy
  • 14.
  • 15.
    Prior to 3.1.0 ●Even with pre 3.1.0 releases, customers used Lambdas by ○ Exposing them through AWS GW ○ Using custom mediation policy to do the intermediate transformation. ○ Hosting a web app or a similar service to do the transformation ● All these methods would involve custom development or would cost an extra hop.
  • 16.
    With API Manager3.1.0 ● Instead of an HTTP endpoint you can specify a Lambda ○ Consumer Apps wouldn’t notice the difference ● All Security/Throttling policies can be applied similar to a normal API. ● Aggregating different Lambdas to create a single API
  • 17.
    Options ● Using AccessKeys ● Connecting using AWS IAM roles
  • 18.
  • 19.
  • 20.
    ● Download andtry out: https://wso2.com/api-management/ ● Slack Channel: https://app.slack.com/client/TLVKGQN84/CLVKGR3BN ● GitHub: https://github.com/wso2/product-apim/issues
  • 21.
    Webinars to Follow Apr28 Creating a Scalable and Decentralized API Management Architecture With WSO2 API Apr 30 gRPC Support With API Microgateway 3.1 May 5 Deploying GraphQL Services as Managed APIs May 12 Overview of API Microgateway 3.1
  • 22.