Where can you use serverless? How does it relate to APIs, integration and microservices?

Session: IDPA018
Where can you use serverless?
How does it relate to APIs,
integration and microservices?
Kim Clark, Integration Architect
Offering Management for Hybrid Integration
Brian M. Petrini, Technical Offering Manager
IBM Business Process Management

IBM Cloud University 2017 | October
Please note
IBM’s statements regarding its plans, directions, and intent
are subject to change or withdrawal without notice at IBM’s
sole discretion.
Information regarding potential future products is intended to
outline our general product direction and it should not be
relied on in making a purchasing decision.
The information mentioned regarding potential future products
is not a commitment, promise, or legal obligation to deliver
any material, code or functionality. Information about potential
future products may not be incorporated into any contract.
The development, release, and timing of any future features
or functionality described for our products remains at our sole
discretion.
Performance is based on measurements and projections
using standard IBM benchmarks in a controlled environment.
The actual throughput or performance that any user will
experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in
the user’s job stream, the I/O configuration, the storage
configuration, and the workload processed. Therefore, no
assurance can be given that an individual user will achieve
results similar to those stated here.

Defining “serverless” architecture and FaaS
Comparison with microservices
How will FaaS be used?
“No function is an island”
Summary of design considerations
2
Agenda

So is serverless really new? Couldn’t all apps be described as serverless?
Cloud-based Software as a Service
(SaaS) applications completely
abstract users from the fact that there
are ”servers” beneath them, but that
doesn’t necessarily mean they are
build on a ”serverless architecture”
from a developer point of view.

“serverless” generally refers to Function as a Service (FaaS)
4
Functions
(FaaS)
Messaging
API Mmgt.Integration
Datastores
Composition
Security
Cognitive
IoT
When a developer is creating a complete solution, there are many other
capabilities required that could also be described as being “serverless”.
From here on we will primarily be talking about FaaS

© 2017 IBM Corporation l Interconnect 2017
Costofentryoffirstfunction
Increasing abstraction from infrastructure
Bare Metal
Virtual machines
Functions
Containers
• Reducing infrastructure cost
• More fine grained cost models
• Less operations cost
• More “cattle” less “pets”

FaaS benefits
• Cost reduction
– Near-instant provisioning, near zero initial costs, dynamically usage pricing
– Startup and running cost can be directly related to the business value of the function.
• Reduction and elimination of infrastructure concerns
– elastic scalability, cross function independence, hosted and managed environment, high
availability, disaster recovery, infrastructure orchestration, container packaging, infrastructure
operations
• Accelerating time to market
– Increased agility, shortened build/deploy pipeline, minimal framework code,
Still need to worry about: code quality, code versioning, multiple environments, testing,
application monitoring…
6

The following are common for FaaS
but are not defining characteristics
• Cloud hosted and managed. Today, most people first encounter FaaS
via cloud based provider, but there is no reason why a FaaS capability
such as Apache OpenWhisk couldn’t be stood up on your own
infrastructure. However, that would typically mean it would have to be
in-house managed.
• Multi-tennant. Large implementations of FaaS make use of the
economies of scales provided by multi-tenancy. However, private or
dedicated FaaS platform installations could provide many of the same
benefits, so long as you have the volumes of work to make the
overhead of the platform balance out. Question as to who’s running the
infrastructure.
7

8
Agenda

Monolithic vs microservice architecture vs function as a service
Siloed application
Presentation
Logic
Microservice
application
µService
µServiceµService
µService
µService
µService
µService
FaaS application
f() f() f()
f() f() f()
f() f() f()
f() f() f()
f() f() f() f() f() f()
f() f() f() f() f() f()
Data
This is an over-simplified comparison

The same benefits that make microservices
architecture attractive also apply to FaaS
Small scoped, independent, scalable components
Agility
Faster iteration cycles
Bounded context (code and data)
Scalability
Elastic scalability
Workload orchestration
Resilience
Reduced dependencies
Fail fast
10

How is microservices architecture different from FaaS?
Is FaaS an instantiation of microservice architecture?
• Microservices is conceptual architecture. A set of guiding principles,
encouraging an deeply componentised application architecture. There are no
“microservice platforms” as such although there are certainly platforms and
frameworks you can use to implement a microservices but generally.
• FaaS is a concrete platform capability. There are many publically available
platforms specifically providing “function as a service” capabilities such as IBM
Cloud Functions (based on OpenWhisk). They are the embodiment of an
opinionated microservice style platforms with a focus on complete abstraction
from infrastructure implementation.
11
FaaS is an embodiment of microservice principles in an opinionated and fully managed platform
FaaS is “microservice architecture as a service” but for a specific flavor of microservice

What decisions does FaaS make on your behalf
FaaS makes choices on the following, then hides them from you:
– Container orchestration
– Service discovery
– Aggregated logging and monitoring
– High availability
– Auto-scaling
– Anything running on FaaS complies implicitly to most cloud-native principles
(e.g. 12factor.net)
– …more
12

You need to know a lot to implement microservices well.
How much do you need to know to implement FaaS well?
Microservices by Martin Fowler/James Lewis
1. Componentization
2. Organized around Business Capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary Design
http://martinfowler.com/articles/microservices.html
13
12 factor apps (for cloud-native)
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII. Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
http://12factor.net
Containers, orchestration frameworks, event sourced applications, eventual
consistency, CQRS, circuit breaker, bulkhead, service discovery, sidecars, routing
fabrics, continuous delivery, agile programming, test driven development, contract
driven development, domain driven design, centralised logging, polygot runtimes…
Everything in bold or outlined with is significantly simplified by FaaS. Everything else, is still up to you!
However, getting started is much more straightforward as the platforms already exist.

Agenda
14

Ideal load characteristics for FaaS
• Volatile/sporadic loads
– Volatile/sporadic load: The combination of auto-
scaling and a associated granular elastic cost
model means that it is best suited for
volatile/sporadic workload.
– CPU focused volatile/sporadic load. Particularly
well suited to CPU centric work due to the cost
model, so long as the workload is volatile/sporadic.
– Elastic parallelization of batch ( which are by nature
volatile/sporadic)
• Prototyping:
– Since there is no stand-up time and minimal cost
for new environments, it is well suited to fast
prototyping.
– In a sense prototyping is sporadic usage in itself.
15
The greater the variation the better. i.e. high standard deviation
time
work
time
work
time
work
sporadic
load
volatile
load
constant
load

Common examples of FaaS implementations
• Event/stream processing
• API implementation
• Mobile backend
• Image processing
• Batch Processing
• Cognitive enrichment
• Scheduled task automation
• IoT
• Chatbots
• …
16
See use case presentation from
Frederick on Thursday

How will IBM leverage FaaS in our products?
• Use products to provide triggers and targets for FaaS
• Introduce products as runtimes containers in FaaS
• Build products components using FaaS
• …
17

18
Agenda

Functions must receive their data from somewhere
and deliver there result to something
19
function()source target
source
source target
target

Primary invocation patterns for FaaS
(how are you going to feed your functions!)
Asynchronous events
(non-blocking)
Receives events
Source delivers an event and
receives and acknowledgement,
but does not wait for it to be
processed by the function itself.
Synchronous API
(blocking)
Exposed as an API
Caller waits for the processing of
the request to complete and then
receives the result of the function
20
source
function()
eventsfunction()
API

API Management
21
function()
API
API consumer
API consumer
API consumer
APIGateway
Developer
Portal
API
Manager
API Gateway:
• Decoupling/routing
• Traffic management
• Security
• Translation
Developer portal:
• API discovery
• Self subscription/administration
• Account usage analytics
API Manager:
• Plan/product design
• Access management
• Policy administration
• API plan usage analytics

Event
Provider
Open event emitter
ecosystem Open interface
for event emitters
Periodic IBM Cloudant IBM Message Hub
Mobile Push Github IBM App Connect
Q: How would you
manage your
incoming events
source
function()
events

Downstream interaction patterns - Blocking
function()
API
Blocking request/response with sync transport
• Simplest to implement, just call an API.
• Provides request/response pattern
• Poor use use of FaaS compute, as we pay for
function() to wait whilst target processes it.
Target
System
Slow downstream systems could result in significant escalations in cost. Where
downstream blocking requests (e.g. HTTP calls to APIs) are slow to respond,
remember you are paying whilst waiting.
• Ideally convert to a fire/forget, but in many cases you do need the response
• Circuit breaker pattern would significantly reduce how often you pay for waits
Note: Wasted memory/threads have always been an issue but in the past the concern was using up
resources on a server you have already paid for. Now it’s a 1:1 cost problem.

Anti-pattern: Functions calling functions
Blocking request/response chain using sync transport (e.g. HTTP based APIs)
f1() f2()
API
Poor use use of FaaS compute: the calling functions (f1, f2, f3) are mostly just waiting, whilst the work
is done by the target system, but you’re still paying for all of them. So in this case, you’d be paying 3x
more than if the logic had been within the same function.
You are also incurring the additional latency and compute of network hops and serialisation/parsing.
Usually results from
• Over-decomposition into overly fine-grained functions. Just because we can break the solution
into individual functions, doesn’t mean we have to pick the smallest possible granularity. Small
functions should be sub-functions within a single higher level function.
• Too much emphasis on runtime re-use of functions. Functions are broken out in order to make
them re-usable). In FaaS, just as in microservice architecture, it is often better to re-use by copy
at development time, rather than by reference at runtime.
As a rule, reduce/avoid the need for synchronous inter-function communication
f3()
API API
Target
System

Downstream interaction patterns - Asynchronous
function()
Target
System
event stream
function1()
Non-blocking fire/forget chain with async transport
• Relatively simple to implement, but requires configuration
of event stream
• Fire-forget pattern, so no “reply” from target system
• Efficient use of FaaS compute as functions perform
continuous compute, and only when events are present.
Non-blocking request/response using async transport
• Hardest to implement, requiring multiple additional
patterns
• Provides request/response pattern
• Efficient use use of FaaS compute
Target
System
function2()
• This is a classic correlation proglem. How does function2() get context of the request in order to process the response? a)
persistent storage – slower, may not scale b) contained in response message – increases payload and related parsing.
• If function1() exposed as API it will not be able to respond with the result, only an acknowledgement. How do we get the
response to the caller? Callback url? Would have to be contained in the request, passed through the target system intact.
Caller would have to host the callback url and correlate the responses.

Orchestrating sequential invocations
Synchronous “orchestration”
• Easy to implement. Simple sequential logic.
• FaaS compute used inefficiently as f1() is mostly
waiting on target systems rather than working.
• Target systems need only provide an API.
• Simple to monitor whether function has
succeeded or not.
• Retries require idempotent targets.
Asynchronous “choreography”
• Hard to implement. Logic distributed across
multiple functions. (though note that OpenWhisk
has a first class notion of chains/sequencing)
• FaaS compute used efficiently as functions do not
wait for responses.
• Target systems must provide a messaging based
interface.
• Hard to monitor where a given sequence has
reached
• Non idempotent targets can be accommodated.
26
f1()
API API API
f1a() f1b() f1c()
Target
System
Target
System
Target
System
Target
System
Target
System
f1d()
Target
System
Consider using a separate orchestrator such as
the new “compose” capability https://ibm.biz/serverless-composition

Planning your event content
27
function()source
What’s inside a trigger event?
Meta-data
Data for manipulation
Unchanging data

Considerations around data shared across functions
• Shared entities
– Need patterns to handle concurrent access. Optimistic locking or eventual consistency patterns required. (see
separate slide)
• Request context for asynchronous response processing
– If implementing a truly asynchronous request/response, the response would come back to a separate function with
none of the data from the request being available. This can be handled using an external storage of the request
data under a correlating key. However, it inevitably introduces latency into the request and response handling.
• Reference data for rapid access
– In order to reduce data look up times, reference data could be loaded on container warm up and held in memory.
However, if the data volume is high, this increases startup time of the container, slowing down the platform’s ability
to react to changes in load. It also increases memory usage. Significantly more complex problems arise if the
reference data is volatile.
• Session state
– The function cannot hold “session” data relating to a current user, or other consumer of the function, or downstream
connections. Function code must be completely stateless, since subsequent requests cannot be expected to come
back to the same server.
– Any attempt to make sessions “sticky” to a particular instance of the function would be unsupported by a FaaS
platform as it would break the elastic scalability
– Use of remote persistence for session data increases latency and potentially reduces scalability
28Ideally the function should be initiated with all required data

What might a complete solution incorporating FaaS look like?
29
function()
polling
System of
Record
System of
Record
Integration
event
stream
function()
Local
storage
function()
Integration
API gateway
function()
API gateway
event
stream
API gateway
function()
event
stream
System of
Record

µService
µService
µService
µService
µService
µService
f()
f()
f()
f() f()
f()
f() f()
f()
f()
f()
f()
f()
f()
f()
f() f()
f()
f() f()
f()
f()
f()
API gateway
µService
µService
µService
API gateway
API gateway
Generally
available API
Local API
Application
boundary
f()
f()
f()
f()
API gateway
f()
f()
f()
f()
f()
f()
f()
API gateway
f()
f()
f()
f()
f()
API gateway
f()
f()
f()
f() f()
f()
f() f()
f()
f()
f()
f() f() f() f()
f()
f() f()
f()
f()
API gateway
µService
Microservice
component
f()
Serverless
function
µService
µService
µService
API gateway
API gateway
µServiceAPI gateway
Silo
application
Silo
application
API gateway
Silo
application
API gateway
Silo
application
µService
µService
µService
API gateway
µService
f()
f()
The gateways are the way the boundaries are defined and enforced.
Boundaries make complex environments manageable
API gateway
This diagram focuses on APIs, but the same applies to messaging based interfaces.

31
Agenda

Summary of key FaaS design considerations
• Use of the FaaS cost model
– Constant workload. If you have constant workload FaaS may not be the most economical infrastructure model in the long
term. (see separate slide).
– Functions making blocking calls to other functions. Blocking crosstalk/inter-communication between functions should
generally be avoided as they introduce latency, and result in inefficient use of the cost model, and reduce scalability. (see
separate slide)
– Slow synchronous downstream requests. Slow downstream systems could result in significant escalations in cost. Where
downstream blocking requests (e.g. HTTP calls to APIs) are slow to respond, remember you are paying whilst waiting.
– Over zealous polling: Using a timer input to periodic polling could result in many empty poll results. You might end up paying
more for empty polls than you are for processing the occasional events. Solutions: a) Call back pattern e.g. webhooks but
requires that the endpoint supports it b) Event connectors (“Open event emitter” framework) – e.g. let App Connect do the
event discovery.
– Composition/Aggregation: Downstream calls to do aggregations/compositions would result in long calls from the consumer
side. Consider pushing these out to integration (e.g. App Connect) (see separate slide)
• Shared data. FaaS functions do not retain state. State must be stored externally. (see separate slide)
• Ownership boundaries. As functions proliferate, how to you retain manageability both in terms of
monitoring, ownership, etc. (see separate slide)
• Event content. Need to analyse the makeup of the function input and break out what is key metadata (event
information, state), data for processing, and data that is not processed. Consider claim-check patterns etc.
Seek well suited use cases, and design with FaaS considerations in mind
32

Looking for
more
information?
Commercial offering home:
http://ibm.biz/functions
Open-source offering home:
http://openwhisk.org
This and other Kim & Brian presentations
https://www.slideshare.net/kimjclark
https://www.slideshare.net/brianmpetrini

Countless capabilities
HYBRID CLOUD
IMPLEMENTATION
CLOUD & DATA
DESIGN
IDENTIFY
OPPORTUNITIES
DIRECTION &
SCOPE
BUSINESS
CASE
OPERATIONAL
MANAGEMENT
FRAMEWORK
GOVERNANCE &
ORGANZATION MODEL
CLOUD
TECHNICAL
SUPPORT
CLOUD NATIVE
SOLUTION
TRANSITION
WORKLOADS
UNLOCK DATAMANAGED
APPS
IBM Cloud
Professional
Services
IBM
Bluemix
Garage
IBM
Analytics
Services
3 practices
Services
immersed in
startup DNA
and the newest
technologies
Cloud Advisory
Services and
integrated
solutions for
hybrid cloud
Analytics-
based solutions
that empower
your data
5 principles
1. METHODOLOGY & ASSETS
We provide the most potent hybrid cloud
methodology and assets available.
2. DEEP SKILLS
We curate the most agile, deeply-skilled
expert teams in the industry.
3. FAST SUCCESS
We champion prescriptive, guided cloud
adoption journeys with adaptable
blueprints.
4. CONFIDENCE
We enable transformations by empowering
our clients.
5. WORLD-CLASS SUPPORT
We deliver world-class support to make
sure you succeed.
It’s not just about building a cloud infrastructure –
it’s about strategically adopting cloud to realize its benefits
Stop by the Services Booth in the expo
to talk about how we can help

Notices and disclaimers
Copyright © 2017 by International Business Machines Corporation
(IBM). No part of this document may be reproduced or transmitted in any
form without written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been reviewed
for accuracy as of the date of initial publication and could include
unintentional technical or typographical errors. IBM shall have no
responsibility to update this information. This document is distributed
“as is” without any warranty, either express or implied. In no event
shall IBM be liable for any damage arising from the use of this
information, including but not limited to, loss of data, business
interruption, loss of profit or loss of opportunity. IBM products and
services are warranted according to the terms and conditions of the
agreements under which they are provided.
IBM products are manufactured from new parts or new and used parts.
In some cases, a product may not be new and may have been
previously installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or product
plans are subject to change or withdrawal without notice.
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented
as illustrations of how those customers have used IBM products and
the results they may have achieved. Actual performance, cost, savings
or other results in other operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been prepared
by independent session speakers, and do not necessarily reflect the
views of IBM. All materials and discussions are provided for
informational purposes only, and are neither intended to, nor shall
constitute legal or other guidance or advice to any individual participant
or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal
requirements and to obtain advice of competent legal counsel as to
the identification and interpretation of any relevant laws and regulatory
requirements that may affect the customer’s business and any actions
the customer may need to take to comply with such laws. IBM does not
provide legal advice or represent or warrant that its services or products
will ensure that the customer is in compliance with any law.

Notices and disclaimers
continued
Information concerning non-IBM products was obtained from the
suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products in
connection with this publication and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not warrant the
quality of any third-party products, or the ability of any such third-party
products to interoperate with IBM’s products. IBM expressly
disclaims all warranties, expressed or implied, including but not
limited to, the implied warranties of merchantability and fitness
for a particular, purpose.
The provision of the information contained herein is not intended to,
and does not, grant any right or license under any IBM patents,
copyrights, trademarks or other intellectual property right.
IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS,
Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document
Management System™, FASP®, FileNet®, Global Business Services®,
Global Technology Services®, IBM ExperienceOne™, IBM
SmartCloud®, IBM Social Business®, Information on Demand, ILOG,
Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON,
OpenPower, PureAnalytics™, PureApplication®, pureCluster™,
PureCoverage®, PureData®, PureExperience®, PureFlex®,
pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®,
Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®,
StoredIQ, Tealeaf®, Tivoli® Trusteer®, Unica®, urban{code}®, Watson,
WebSphere®, Worklight®, X-Force® and System z® Z/OS, are
trademarks of International Business Machines Corporation, registered
in many jurisdictions worldwide. Other product and service names
might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the Web at "Copyright and trademark
information" at: www.ibm.com/legal/copytrade.shtml.

IBM Bluemix OpenWhisk
Supported
Languages
Multi-
language Support
Community
Efforts
… and more to come
JS/NodeJS 6
Java
Python 3
Swift 3
Docker
Haskell
…
Scala
What is OpenWhisk?

Non-blocking
Blocking
Periodic
Support for
different invocation
models
What is OpenWhisk?

Supports
higher-level
programming
constructs Chaining/
Sequencing
Action
1
Action
2
Parameter
Binding
What is OpenWhisk?

Granular pricing
Pay only for the exact time your actions run. When
an action is not invoked, it’s not in memory, so you
don’t pay anything.
What is OpenWhisk?

Pricing model
Time an action was running *
memory allocated to action
$0.000017 per GBs
Free tier: 400000 GBs
What is OpenWhisk?

Managed service on
IBM Bluemix
bluemix.net/openwhisk
FaaS platform to execute code in
response to events
What is OpenWhisk?

Triggers
(response)
Rules
Actions
(code)
Source
(events) Results
What is OpenWhisk?

IBM Bluemix OpenWhiskWhat is serverless aka FaaS?
Runs code only on-demand on
a per-request basis
Serverless
deployment &
operations model No servers Just code

a per-request basis
“Serverless is for
compute what
object storage is
for storage”
No servers Just code

a per-request basis
Optimal
utilization &
granular pricing

a per-request basis
Scales on
a per-request
basis

Where can you use serverless? How does it relate to APIs, integration and microservices?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Where can you use serverless? How does it relate to APIs, integration and microservices?

Similar to Where can you use serverless? How does it relate to APIs, integration and microservices? (20)

Recently uploaded

Recently uploaded (20)

Where can you use serverless? How does it relate to APIs, integration and microservices?