Containers vs serverless - Navigating application deployment options

© 2017 IBM Corporation l Interconnect 2017
Containers vs serverless
Navigating application deployment options
@DanielKrook
Daniel Krook

Software Architect, IBM
Bare Metal
VM VM
VM
Virtual machines
Functions
Containers

IBM Bluemix Containers vs Serverless@DanielKrook
Cloud computing options in the post-VM world are overwhelming

But containerization is a given for cloud applications
Enables greater density, faster startup, and
more consistent application deployment.
Eases 12 Factor application delivery, handles
operational concerns (lifecycle, scale).
Enables polyglot microservices architectures
using the right language runtime for the job.
JavaScript
JavaScript
JavaScript
Swift
Java

So which containerization approach will work best for you?
Platform
Orchestration
Containers
Serverless
Cost
Performance
Maintenance
Experience

Kubernetes, Cloud Foundry, and Apache OpenWhisk

Let’s look at three common container deployment models
Full control over infrastructure
and maximum portability
Focus on the application and let
the platform handle the rest
Auto-scaled, event-driven applications
that respond to a variety of triggers
Containers-as-a-Service Platform-as-a-Service Functions-as-a-Service

Each containerization approach has its particular advantagesIncreasingfocusonbusinesslogic
Decreasing concern (and control) over stack implementation
Containers
Applications
Functions

Kubernetes on the IBM Bluemix Container Service
Build and deploy portable applications with flexibility and control over configuration that
run anywhere without the need to reconfigure and deploy for different environments.
Beneﬁts Target audience
• Native, managed Kubernetes
experience.
• Supports secure binding apps
to Watson and other APIs.
• Scans Docker images and live
containers for vulnerabilities
and malware.
• Developers and teams who want control over how their application and all of its
dependencies are packaged and versioned, ensuring portability and reuse
across deployment platforms.
• Developers looking for high performance among a cohesive set of
interdependent, independently scaling microservices.
• Organizations moving containers to the cloud and who are experienced with end-
to-end cluster deployments.
Containers-as-a-Service

Cloud Foundry through IBM Bluemix Instant Runtimes
Deploy and scale applications using a broad set of runtimes, binding to a catalog of data,
AI, IoT, security services, without having to manually configure and manage servers.
• Complete, distributed, scalable,
production grade Platform-as-a-
Service framework.
• Buildpacks and brokered
services provide Cloud Foundry
extensibility.
• Developers who want a deployment platform that enables them to focus on
application source code and ﬁles (not packaging them) and not worry about the OS.
• Developers who are creating more traditional HTTP-based services (apps and APIs)
with routable hostnames by default.
• Organizations that are comfortable with a more stable model of cloud computing that
has been around for a longer period of time (comprehensive docs, many samples).
Platform-as-a-Service

Apache OpenWhisk hosted on IBM Bluemix
Execute code on-demand in an auto-scaled, managed environment through event-
driven triggers. Write functions in JavaScript, Swift, Java, Python, or custom Docker
images. Declare mappings to event sources. HTTP API gateway support built-it.
• Platform to run short lived container
instances with application code in
response to speciﬁc events
• Provides a scalable, polyglot, and
extensible platform for integrating
many event sources at granular
cost
• Developers who want to focus purely on business logic within individual functions
that automatically scale in response to demand and closely tie transactions to cost.
• Developers and teams creating non-HTTP applications, such as those that
respond to database changes, IoT readings, asynchronous, non-performance
critical tasks.
• Organizations that are comfortable adopting cutting edge technology in an area
where standards and best practices have not yet been thoroughly established.
Functions-as-a-Service

Serverless is a great ﬁt for non-HTTP workloads as well
Execute logic in response to database change
Perform analytics on sensor input messages
Provide cognitive computing via chatbots
Schedule tasks performed for a short time
Invoke autoscaled APIs and mobile backends
bit.ly/bx-sl-wl

Deploying a simple application to each platform

Deploying a JavaScript application to each platform
APPLICATION
PUBLIC NETWORK CLOUD NETWORK
FIBONACCI
AS APP
FIBONACCI
AS CONTAINER
OpenWhisk
FIBONACCI
AS ACTION
app.js (or handler.js)
lib/ﬁbonacci.js
bit.ly/bx-mdo
Sample app has 3 HTTP API endpoints
- Compute Fibonacci number  
after n iterations.

- Run the computation for t
milliseconds.

- Simulate a crash of the service  
by exiting the process.

Deploying the Fibonacci application to Kubernetes
Clone the sample code
curl http://169.48.137.10:30080/fibonacci?iteration=1000
curl http://169.48.137.10:30080/fibonacci?duration=5000
curl -X POST http://169.48.137.10:30080/fibonacci?crash=true
Test against the public IP given
git clone https://github.com/IBM-Bluemix/multiple-deployment-options
cd services
Build locally, and push to the
IBM private container registry
bx cr login
bx cr namespace-create krook
docker build -t registry.ng.bluemix.net/krook/fibonacci:latest .
docker push registry.ng.bluemix.net/krook/fibonacci:latest
Create a Kubernetes cluster
with the new Container Service
bx cs cluster-create --name oscon
bx cs cluster-config oscon
export KUBECONFIG=...
Deploy the set of containers to
that cluster
vi fibonacci-deployment.yml (update namespace)

kubectl create -f fibonacci-deployment.yml

Deploying the Fibonacci application to Cloud Foundry
curl http://fibonacci-service-oscon.mybluemix.net/fibonacci?iteration=1000
curl http://fibonacci-service-oscon.mybluemix.net/fibonacci?duration=5000
curl -X POST http://fibonacci-service-oscon.mybluemix.net/fibonacci?crash=true
Test against the hostname
cd services
Update conﬁguration as
needed, push the application to
the cloud
bx cf login
vi manifest.yml (update hostname)
bx cf push

Deploying the Fibonacci application to OpenWhisk
curl https://openwhisk.ng.bluemix.net/api/v1/web/.../default/fibonacci?iteration=1000
curl https://openwhisk.ng.bluemix.net/api/v1/web/.../default/fibonacci?duration=5000
curl -X POST https://openwhisk.ng.bluemix.net/api/v1/web/.../default/fibonacci?crash=true
Test against the hostname
cd services
Update conﬁguration as
needed, push the application to
the cloud
wsk property set --apihost openwhisk.ng.bluemix.net --auth xxxxxxx
npm install
node deploy.js --install (convenience script that wraps the wsk CLI)

Day two operations: It’s running! Now what?

Day two operations: With power comes responsibility
Add more resilience by scaling
each service
bx cf scale fibonacci-service-oscon -i 3
kubectl scale --replicas=3 -f fibonacci-deployment.yml
Conﬁrm new instances have
been created in Cloud Foundry
bx cf apps
name requested state instances memory disk urls
fibonacci-service-oscon started 3/3 256M 1G …
Conﬁrm new instances have
been created in Kubernetes
kubectl get pods
NAME READY STATUS RESTARTS AGE
fibonacci-deployment-838971134-44cxv 1/1 Running 0 21s
fibonacci-deployment-838971134-k3cn3 1/1 Running 0 21s
fibonacci-deployment-838971134-l3rkh 1/1 Running 2 4d

Day two operations: Better!

So how do you actually choose a deployment option?

Considerations for selecting a containerization platform
• Control over runtime environment (runtimes,
versions, minimal OS).

• Greater reusability and portability of container
images.

• Great fit for bringing containerized apps and
systems to the cloud.
• No need to manage underlying OS.

• Buildpacks provide influence over the
runtime, giving as much or as little control
(sensible defaults) as desired.

• Great fit for many existing web apps with a
stable programming model.
• OS, runtime, and even container lifecycle is
completely abstracted (serverless).

• Autoscales in response to demand, with an
associated granular cost model.

• Great fit for emerging, non-HTTP, event-driven
workloads involving IoT, data, messages.

• More responsibility over package configuration
(security patches).

• Need to understand distributed systems.
• Loss of control over operating system,  
possibly at the mercy of buildpack versions.

• Limited to HTTP/HTTPS
• An emerging computing model, rapid
innovation with less comprehensive and stable
documentation, samples, tools, and best
practices.

Containers-as-a-Service Platform-as-a-Service Functions-as-a-Service

Performing your own in depth assessment of each platform
Score that against the cost for
the services. It's not always
about compute, particularly in
a highly distributed serverless
solution.

How much does this service
cost? Am I assuming certain
features are built-in?

How much will dependent
services cost?

Is latency between services
an issue?
Experiment with each
approach. Find what works
best for your app from a
functionality and development
experience.

What if I need to change the
code of my service?

How do I ensure continuity
of service while I deploy the
update?

How much control do I really
need over the runtime?
Gather performance numbers
such as time to recovery with
Kubernetes and Cloud Foundry as
well as cold starts with OpenWhisk.
Explore other non-functional
characteristics.

How do I secure my service?

How do I make my application
resilient to a data-center failure?

What if my service fails? Will the
platform automatically recover?
Will it be transparent to end-
users?
Evaluate features Measure operations Consider integrations

Some considerations for running on more than one platform
Split components of your application across deployment targets
Think about matching the right technology to the right job, for example I have an IoT demo that uses both a Cloud
Foundry application and a set of OpenWhisk actions. Serverless isn't a magic bullet, but a new option to consider.
Design your application for more than one deployment target
Another design choice is to make your code as generic as it can be, allow it to be tested locally, and rely on
environment variables to inﬂuence how it runs in particular environments. The FlightAssist app shows this.
Continue to use your existing DevOps pipelines for any of the approaches
Kubernetes, Cloud Foundry, and OpenWhisk can all be driven by command line tools, and the same Docker image
can potentially be reused across platforms.

Consider abstractions, such as the Serverless Framework, for JavaScript applications
Or perhaps one of the other options like Zappa or Lambada that help port existing Python WSGi and JAX-RS REST
API applications from traditional hosting to a serverless platform (still exploring ports to OpenWhisk).

Learn more

Deploy the sample app to all three services on Bluemix
github.com/IBM-Bluemix/multiple-deployment-options (bit.ly/bx-mdo)
Learn about FlightAssist, a more in-depth study with data services
github.com/estesp/ﬂightassist
See more Kubernetes, Cloud Foundry, and OpenWhisk samples on GitHub
github.com/IBM
Prefer to work hands-on with a developer advocate?
developer.ibm.com/code/work-with-us
Get started evaluating each option for your application

Learn about serverless with Apache OpenWhisk at OSCON

Additional material

Kubernetes on the IBM Bluemix Container Service
1. Use the bx command line (with cs and cr
subcommands) or Bluemix GUI to manage clusters,
images, and containers.
2. Push your Docker images to your private
Bluemix registry.
3. Deploy containers to the cluster, and make your app
accessible from the Internet.
4. Bind a Bluemix service to your pods to bring extra capability
to your containers.
5. Monitor the health of your cluster and apps on Bluemix

Cloud Foundry through IBM Bluemix Instant Runtimes
1. Choose the cf command line or Bluemix GUI to manage
your web apps.
2. Create your web app by using Bluemix user interface or
the bx cf command line.
3. Edit and version your code in Bluemix DevOps or local
development environment.
5. Bind app services by using Bluemix user interface or the cf
command line.
6. Provision monitoring services to manage the health of your
applications.

Apache OpenWhisk hosted on IBM Bluemix
1. Choose the wsk command line or Bluemix GUI to create
your actions (functions).
2. Choose the wsk command line or Bluemix GUI to create
your event triggers.
3. Choose the wsk command line or Bluemix GUI to map
triggers to actions.
4. Choose the wsk command line or Bluemix GUI to monitor
action invocations.

Containers vs serverless - Navigating application deployment options

More Related Content

What's hot

Similar to Containers vs serverless - Navigating application deployment options

More from Daniel Krook

Recently uploaded

Containers vs serverless - Navigating application deployment options