Hi everyone.
I'm Vanji from California
and I work as a solution
engineer with WS02. It
is an open source
integration company. During
my free time I volunteer
with a Apache Synapse project
as a project committee
member and a comitter.
This talk mainly going to cover
API management and how API
management play crucial role to
enforce the quality of services
on top of serverless functions.
So as a very first tip, let's
quickly review what is
an API?
An API is the digital asset
and contract between developers
on how, when to interact to
obtain the data or push the data
into ecosystem. Having said
that, now APIs also
recognized as a product of
the 21st century in the
digital transformation era.
Since most of us already family
with these concepts, I'd like to
move on to other topics.
Like how the most of the APIs
are deployed, mostly they are
three different approaches
taken by most of the
organization right now. So, they
are like deploying API in bare
metal. Or virtual machines or
containers. This infrastructure
maybe on or rented by on demand
by the organizations.
However, as most of us know, the
cost and complexity of
infrastructure does not come
alone, but also comes with other
critical challenges that can
impact return on investment.
Like managing the servers,
operating the servers.
Securing the servers, time to
market to take your product
or sale of the services or the
cost of the idle time.
So and I can keep on telling
about these an so on.
So one of the potential
solution to overcome this
problem is serverless
functions.
So what is that all about?
Serverless is about the ability
run this service without
allocating servers permanently.
And resources are dynamically
allocated when the request made
for these invocations are very
short lived and the best match
for the serverless
and stateless processing.
Further, this also enable
developers to focus on more on
code and less on infrastructure.
Currently in market there are
many vendors providing these
serverless functions, and I have
listed few over here.
For discussion purposes going
forward, I will take a AWS, Azure
and IBM offerings in my later
stage of my presentation, but
for right now I'm not going to
get into the more details, but
let's move on and talk about
the API management.
So API management as this
the term sound APM management is
software ecosystem that allow to
publish API for cataloging,
enforcing the use of policies,
controlling the access of
the API, naturing the
subscription subscriber
community like forum
documentation and so on, for
the collecting the
metrics and analyzing the
usage statistics also helped
the API provider to understand
about what can be improved in
API ecosystem. For the reporting
on the performance, maintaining
of the lifecycle of the API, an
monetization of the API and I
can go on. But
it has three main core
functionality's to maintain all
these API management ecosystem.
So first of all, to enforce
the security, there is a
component that belong to and
govern the artifacts that we
are enlisting in the API
management. There is a main
need of that, and proxying the
runtime is also another core
part of the API management.
However, when we getting into
much more deeper dive into this
system, we can also look into
these fact much more deeper. I
have listed some
functionalities, but for
discussion purposes I have to
break these into three main
features, but that what we
discussed previously. But if I,
if you ask me to pick a few of
the main features that I would
consider to talk further, I will
choose six main features.
And they are implementing the
security around the API,
cataloguing the API,
API absorbability, monetization
of the API, rate limiting of
the API, and control the access
with the marketplace
for the API.
Putting all of these into one
big picture and summarizing
will illustrate there will be a
gateway acting as a central
place to route the traffic and
other components to provide the
necessary management plane
activities. But as you see in
the illustration, the gateway
receive the most of the runtime
request to do the necessary
orchestration and apply the
quality of services that we have
already defined for that API
using the publisher.
When we expose the API
through API management its well
known as the managed API. So as
you see in this picture we do
have multiple different
components that acting
together to enforce these
quality of services. So one of
that is the publisher and then
developer portal. The
publisher is nothing but a
portal that allow
the API developers to comment
endless their API's to the wider
community to access it.
The app developers and API
consumers usually come to a
developer portal or marketplace
and discover those API and get
the subscription from there.
Then from there on the any API
consumption goes through like
gateway and gateway do the rest
of the orchestration using with
the key management to validate
the keys and talked with the
traffic manager to enforce the
traffic management policies and
collect the real time data so
that it can make the better the
providers can make better
decisions. But importantly,
as you see over here, there
are a few other main
elements in this picture,
like microservices, Web
Services, and enterprise
service bus are running
behind the scene to
expose the necessary business
functionalities, but our focus
here is mainly serverless
functionality, so I'm going to
move on to that. So most of
the serverless function provided
also a gateway functionality's.
However it is not fulfilling the
enterprise need. Most of the
enterprises with different
business unit may or may not use
the different infrastructures as
a service vendors. For example,
one business unit can use the
AWS is another business unit may
use the Azure.
However, there might be a need
of Aggregated API platform to
expose these API's and
functionalities to their
internal or external consumers
of these API.
Therefore, there is a need of
managing the portfolio of the
serverless functions
from the different platform in a
single management ecosystem, to
allow the organization to
enforce the unified quality of
services across the platform.
Looking into this and mapping
this concept with the
previously illustrated
image of API management it
simply expose the serverless
function while the Common
Gateway and enforce the quality
of services like rest of the
managed API. So this provide
many benefits, including a
single marketplace, to enlist
the serverless functions and
also provide a single identity
provider so that all the
identity can be managed in
single platform an further it
also can be rate limited. I mean
in one single platform.
So as you see over here
I have depicted few of the
serverless function providers
like AWS Lambda, Azure, or IBM.
However, moving forward, there
are few other
benefits of this, adapting the
API management platform as well.
One of the benefits
that I see right now.
So, if there is a API already
available that running on top of
the, let's say bare metal in and
it's written in Java and if the
organization choose to migrate
to the follow serverless
function right now let's discuss
that the API is simply exposing
a GET method when the payment
API with the latest resource
resource invoked by client it's
simply returning back
JSON payload
and when we want to migrate this
into a serverless functions,
so the same similar
implementation can be written as
a function in any of the
serverless function vendors,
for example, let's take a
AWS Lambda, and in this case
I have written very simple
Lambda function to handle this
invocation. As I illustrated the
previous one, that simple JSON
payload has been written over
here, but as you see on your
left hand side, the response is
coming back from the serverless
function is a very simple string
rather than the well implemented
payload, so this can be one of
the disadvantage or the
complexity that you can
find during the migrations
of serverless functionality and
this is also mean the
contract between API
consumers and the API
providers is being broken
and implementing the API
consumer app will be very
costly and time taking.
Go to market will be delayed and
there can be many other
implications as well.
To solve this there is,
I mean, I mean there is an
option that what we can do we
can utilize the API
management ecosystem to do
the necessary message
transformation and do the,
rather than completely rewriting the
entire implementation for the
both API providers and
consumers. So most of the
modern API management
ecosystem come with
implementation where it allow
you to do the necessary message
transformations or header
transformation or do the
necessary orchestration in-built
within the gateway itself.
So as you see over here, the
API management is acting as a
proxy in between the client
and the payment API and doing
the necessary transformation
rather than just sitting in
between and enforcing the
quality of services.
Further, I mean, there is
another good advantage that we
can talk about here is most of
the serverless functionalities as
we discussed previously can
allocate the resources on
demand and execute on demand and
so this may cause some delays
during the first few request/
response and this can this gap
can be closed by API
management and API managmer can
act as cache provider,
for given requested nature.
So I do have a quick
demonstration over here I like
to present to you guys.
So in this demonstration, what
I'm going to do is I'm going to
utilize two different products
over here. One is AWS Lambda
functionality, serverless
functionality. At the same
time, also will be using the
AWS API manager to
expose these API
serverless function. So as a very
first step I will get into the
Lambda function. I have already
written very simple API using
Python and it is a serverless
function that right now running
very simple message and
returning back status of
200 when this being invoked.
Then also I do have a my local
deployment of the AWS API
manager and I will be
creating very simple API over
here. Let me name it as a
payment API.
Version as one point
1. As of now, let me skip
the endpoint and choose a
business plans for the API
consumers so that they can
choose from it. As API provider
I can define these
and I'm creating this API and as
you see, the lifecycle of this
is still in the creation state,
not in the public, published
state. So as a very couple of
steps what I'm going to do, I'm
going to integrate with the AWS
Lambda so that I can right away
access the functions that I have
been created already. So as a,
since this is running on my
local machine, I don't have the
the IAM of AWS and I cannot
access the AWS
credentials today so if you
have deployed this in AWS
instance itself it will pick up
and use the credentials to do
the necessary interactions. So, so
that what I have done I have
already downloaded my keys from
AWS. I'm going to provide
those over here.
And I'm going to choose the
region that I'm in right now.
You just rest my California.
This one.
So as you see, I
have added the
necessary integration
between AWS Lambda
over here, but
I haven't add any resources for
them, so let me do that. Let me
remove the unknown
APIs over here. Let me save that.
And.
I'm going to choose my
functionality's over here there.
I already know they ARN since
the integration is there, they
are and will be pop up over
here. And I have just this. So
as I inform already, right? So
you can do other quality of
services, but translating that
I'm right now I'm going to skip
those activities and going to
deploy this though. Since I
have added the necessary
resources functions and API
details now I can go ahead and
publish this API. So what I'm
going to do since all the
checkpoint is done looking,
published this API and it is
ready to consume.
So.
Let me check this out in my
developer portal the marketplace
it's appearing there. So
no picture with
my credentials over here.
And I'm going to add a new
application. It's nothing but
collections of API to manage the
keys and everything
in the right manner.
I have been in the application
and then we generate keys so that
I can access the security and
enforces security over here.
Copy that key.
What I'm going to do
since I already have
access, I haven't subscribed, I'm
I'm going to go ahead and
subscribe to that application,
which is Serverless Days
application with a Gold plan,
and I'm subscribing to them.
But what I'm going to do now,
since I have a new subscription,
let me quickly regenerate the
key.
I don't need any scope
right now.
Getting back to work with
payments.
I have done the necessary.
Subscription so that I can try
out this API. So this API is
going to act as a very simple
REST API, but underneath the
implementation is the serverless
functions that we have
implemented in the Lambda.
So what I'm going to do, I'm
going to provide the key that I
already got. I'm going to
try this out.
So as you see over here, the
response is coming back from the
back end. So as API
provider what could have done is
I have engaged
over here an added the other
quality of services, for
example, over here the
message mediation. Nothing I
mean, very simple.
What do you call mediation
policies or the orchestration
policies that I could have
added everything.
During the request response
this will be engaged
and this message could be
transformed as we discussed
previously. Is there any
questions so that I can answer
them and help you too
understand this further,
thank you.
