ibm bluemix technical deep dive - ibm - united states · ibm bluemix technical deep dive simon...

© 2014 IBM Corporation 1

IBM Bluemix Technical Deep Dive

Simon Moser ([email protected]) Senior Software Engineer , IBM Bluemix @mosersd ICACON’15, Budapest, May 2015


Who am I ?

- Senior Software Engineer in the Bluemix Development Group at the IBM Research &

Development Lab in Boeblingen, Germany

- Chairman of the TOSCA Technical Committee at OASIS

- Lecturer on Cloud Computing at the University of Jena, Germany


New Modes of Engagement Systems of Record

Data & Transaction Integrity Smarter Devices & Assets

• Data & Transactions

• App Infrastructure

• Virtualized Resources

• Expanding Interface Modalities

• Big Data and Analytics

• Social Networking

Next Generation

Architectures

New models of product & service innovation are emerging

Architecture of Cloud Native

Applications

A monolith

Easy to understand, but mostly not agile, doesn’t support innovation, continuous delivery is

hard.


In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Martin Fowler, Thoughtworks, March 2014

µServices: Rise and cultural change


NOT Measurable, e.g. In the sense of lines of code ,

number of operations, etc.

Qualititive Microservices –role, responsibilities, capabilites, focus, scope

µServices

Loosely couple service oriented architectures with bounded contexts ….

Adrian Cockroft

SOA definition was good ... but we messed it up the

implemention – all important stuff went into the ESB which became the monolith

– We missed bounded context, which allows maximum freedom of

deployment – I deploy when I want, don‘t have to ask you

–Bounded context is another word for domain (speak same language)


> Rapid

Provisioning

> Basic Monitoring

> Rapid Application

Deployment

> DevOps Culture

You must be this tall …


Bluemix: IBM’s Cloud Platform

• DevOps

• Big Data

• Mobile

• Watson

• Business Analytics

Bluemix service categories

• Database

• Web and application

• Security

• Internet of Things

• Cloud Integration

• API management &

Integration

Developer experience

• Rapidly deploy and scale

applications in any language.

• Compose applications quickly

with useful APIs and services

and avoid tedious backend

config.

• Realize fast time-to-value with

simplicity, flexibility and clear

documentation.

Enterprise capability

• Securely integrate with existing

on-prem data and systems.

• Choose from flexible

deployment models.

• Manage the full application

lifecycle with DevOps.

• Develop and deploy on a

platform built on a foundation of

open technology. Built on a foundation of open

technology.

Build, run, scale, manage, integrate & secure applications in the cloud

© 2014 IBM Corporation 13 13

Bluemix structure


Bluemix offers different compute models to run your code

14

CloudFoundry

application Docker Container Virtual Machine

Consistent experience:

• Common service binding & consumption model

• Common user ID & permissions model

• Ability to hook into common routing layer

expanding

Level of

abstraction

Flexibility


DEMO + Q&A

15

Conclusion

Bluemix Platform for developing Cloud Native Applications

Environment Provisioning

Service Registration & Discovery incl. Exhausive

Service Catalog

Configuration Management

On Demand Scaling

Monitoring

Failover / Resilience

Routing / Load Balancing

Free choice of deployment mechanism 17

Still more Curious ? Find me and I show you more

18


Capabilities and User Experience Existing Emerging

Primary Workload Types Systems of Record

(Transactional) Systems of Engagement (+ Record)

(Big Data, Analytics, Mobile/Social Channels)

Delivery Model Planned Incremental (DevOps)

Development and Operations Team Sizes

100s and Costly 10s with built-in DevOps automation

Release Frequency Months to Years Days to Weeks, based on business opportunity

Integration Frequency Weeks Continuous

Infrastructure Deployment Days Minutes

Time to Value Planned Opportunistic

Operational Model Systems Management Built in to application, Recovery Oriented

Computing, Continuous Availability

Service Sourcing Develop Consume and Assemble

(Public and Private)

Comparing Systems of Record and Systems of Engagement


Cloud Operating Environment Architecture

Cloud Operating

Environment

Development Services

Operational Services

Infrastructure Services

Application Services

CREATE CONSUME

CAPACITY CONTROL

• Enable applications to be rapidly & incrementally composed from services

• Deliver application changes continuously • Enable continuous availability • Support fit-for-purpose programming models &

services • Embed manageability of services & application • Workload Optimized & Elastic

APPLICATIONS / WORKLOADS

• Persistence • Messaging & Workflow • Scripting & Programming

Languages

• Compute, Storage, Network • Clustering & Elasticity

• Logging • Monitoring • Security

• Code Repository & Version control

• Continuous build & Test


Cloud Foundry PaaS Cloud Foundry services registry and runtime management layer. Components are dynamically discoverable and loosely coupled, exposing health through HTTP endpoints so agents can collect state and act on it.

Cloud Foundry Components *

User Authentication and Authorization

Router

DEA Pool

Service Gateway Apps

Service Connector

Health Manager

Messaging

Cloud Controller

Build Packs

Cloud Foundry BOSH

Micro Clouds

Private Clouds

Public Clouds

Service Nodes

* Source: Pivotal presentation on CloudFoundry


Basic Premises

Fail Fast

Self-healing

Horizontally Scalable Components

Distributed State

No Single Point of Failure

Should be as simple as possible

Basic Design

All components loosely coupled

Few “Classes”, many “Instances”

Messaging as foundation

Addressing and Component Discovery

Command and Control

JSON Payloads

HTTP or File/Blob for data transport

Basic Patterns

Event-driven

Asynchronous

Non-blocking

Independent, Idempotent

Message Passing

Eventually Consistent

Kernel Components / Attributes

All dynamically discoverable

Launch and scale in any order

Can come and go as needed

Monitor via HTTP and JSON

Location independent

Cloud Foundry Design *

[*] Distributed Design and Architecture of Cloud Foundry (Derek Collison):

http://www.slideshare.net/derekcollison/design-of-cloud-foundry

ibm bluemix technical deep dive - ibm - united states · ibm bluemix technical deep dive simon...

Documents