With the increased presence of cloud and hosted services, enterprises are relying more on cloud services to reap benefits of economies of scale, gradually shifting the burdens of maintaining infrastructure to cloud providers. Functions as a service (FaaS) is the next step in this shift. FaaS focuses on running an operation on demand without having to worry about the infrastructure or the scale. AWS Lambdas provide an easy way to create serverless operations, helping enterprises to reduce their infrastructure costs. Yet at times, these transitions are hindered due to the need of changing consumer apps. WSO2 API Manager 3.1 makes this transition smoother by allowing organizations to expose RESTFul interfaces using Lambdas. WSO2 API Manager 3.1 enables you to secure, throttle, manage, and monitor APIs created out of Lambda operations, minimizing impact on consumer applications. This deck explores: - How you can use Lambdas for Backend processing - Exposing a Lambda function as a REST API in WSO2 API Manager - Underlying architecture and different design options that are available for you

1. Exposing Lambda Functions as
Managed APIs
Fazlan Nazeem
Associate Technical Lead, WSO2
Amila De Silva
Software Architect

2. Agenda
● What is Serverless
● Why should you think about serverless
● API Management for Serverless Functions
● Lambdas with WSO2 API Manager
● Demo
● Q&A

3. What is Serverless

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 you think about
Serverless

6. 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

7. 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.

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
● 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.

10. 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

11. API Management for Serverless
Functions

12. 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.

13. 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

14. Lambdas
with WSO2 API Manager

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 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

17. Options
● Using Access Keys
● Connecting using AWS IAM roles

18. Demo

19. Q & A

20. ● 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

21. 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

22. THANK YOU
wso2.com