Complexity, Components & Clouds (Paremus)

www.paremus.com

Complexity, Components &Clouds

Dr R NicholsonFITE club - April 2010

www.paremus.com

FITE Club (London) April 2010

“Fight Club is a metaphor for the need to push through the walls we put around ourselves and just go for it”

“...probe the frustrations of the people that live in the system...”

FITE Club?

What do we mean by Complexity?

Complexity

Information ��!"#"!$"%"&

A suitable Representation

Complexity

Information ��!"#"!$"%"&

A suitable Representation

Volume = V

pressure = P

Temperature = T

Information ��!"#$#%&

(x,x’)

(y,y’)

(z,z’)

Information �!"1(m,x,y,z,x',y',z')

Complexity

A suitable Abstraction

Volume = V

pressure = P

Temperature = T

Information ��!"#$#%&

(x,x’)

(y,y’)

(z,z’)

Information �!"1(m,x,y,z,x',y',z')

Complexity

A suitable Abstraction

Accidental Complexity

•Redundant Information

•Same System may be fully described in a more succinct manner

•Ability to easily re-factor enables Accidental Complexity to be driven out over time

Necessary Complexity

When all accidental complexity is stripped away - we are left with necessary complexity...

• The actual ‘structure’ of the System

• Adaptive Systems are by necessity more complex than non-adaptive Systems

Strategies for dealing with necessary complexity?

• Abstraction

• Perhaps a change Perspective / Representation

Virtualisation - Emulates the characteristics of an entity

Abstraction - Masks the complexity of the entity (physical or virtual), providing a simplified description

Abstraction and Virtualisation are orthogonal & complementary concerns

• As system complexity increases - stop attempting a microscopic description use emergent macroscopic characteristics

• Boundaries - Where/when does it makes sense to change point of view? • Several such boundaries may exist!• Manage via emergent macroscopic properties and operational complexity should

dramatically reduce• Conversely virtualisation ‘strategies’ never decrease operational complexity

Abstraction & Virtualisation

Source - Richard Nicholson - Paremushttps://adaptevolve.paremus.com/?p=18

Components: Why?

as change occurs

modules and theirdependencies

isolate change

Components: The need to Abstract!

Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/

?Reuse Release Equivalence: Unit of reuse is the unit of release!

Components: Something is Missing?

Reuse Release Equivalence: Unit of reuse is the unit of release!

Components: Something is Missing?

Components: Benefits

- reuse- reduce complexity- ease maintenance- increase extensibility

Reduces Complexity HOW?• OSGi Modularity - enables rapid ongoing code

refactoring - essential for driving out Accidental Complexity

• OSGi Modularity - provides the required abstraction, masking Necessary Complexity

Components: Benefits

- reuse- reduce complexity- ease maintenance- increase extensibility

Increases architectural agility!

Reduces Complexity HOW?• OSGi Modularity - enables rapid ongoing code

refactoring - essential for driving out Accidental Complexity

• OSGi Modularity - provides the required abstraction, masking Necessary Complexity

Components: Modularity is not a new story

“First they ignore you, then they ridicule you, then they fight you, then you win.” -- Mahatma Gandhi

Components: Modularity is not a new story

OSGi is a disruptive technology that will transform how enterprise Java applications are designed, developed, and managed!

“First they ignore you, then they ridicule you, then they fight you, then you win.” -- Mahatma Gandhi

90% of application lifetime cost concerns maintaining and evolving the Production Systems

Modularity is a MUST

Components: Business Driver

Clouds

Cloud: The bandwagon is rolling!

What are the critical characteristics required of any

credible Cloud solution?

Cloud 1. An Elastic Resource Landscape

•All resource is transient

•Resource landscape will expand / contract over time

•Resource characteristics will change over time

Cloud 2. Simplicity through Abstraction

• Manage Populations - not Instances

• Manage Business Systems - not Components

Complex Systems tend to suffer correlated & cascading failures!

A system accident is an "unanticipated interaction of multiple failures" in a complex system. This complexity can either be technological or organizational, and often has elements of both.

(Normal Accidents - Perrow 1984)

Cloud 3. Robust & Recovery Oriented

Complex Systems tend to suffer correlated & cascading failures!

A system accident is an "unanticipated interaction of multiple failures" in a complex system. This complexity can either be technological or organizational, and often has elements of both.

(Normal Accidents - Perrow 1984)

Cloud 3. Robust & Recovery Oriented

• Agile Systems - Are Robust Systems

• Robust Systems - Are Agile Systems

• Self-Forming / Auto-Repairing

• Optimised for MTTR not MTBF

• No single point of failure (SPoF)

• No single point of reference (SFoR)

Deployment via VM images NOT GOOD ENOUGH

Remember - Reuse Release Equivalence: Unit of Release is the unit of Reuse!

Cloud 4. Must understand Composite Systems

Cloud 5. Is Multi-Tenant

Isolation / Visibility - control at all levels of structural hierarchy / abstraction:

• Groups of Systems

• Groups of Composites within a System

Cloud 6. Is Architecturally Invisible

The Cloud runtime while providing options should not constrain or enforce:

• Communication protocol

• Middleware Services

• Data Services (CAP)

• Caching Services (CAP)

• Or type of development framework

Cloud 7. Support Adaptive / Reactive Applications

Deployment via VM images IS DEFINITELY NOT GOOD ENOUGH

Dynamically assemble, and if necessary re-assemble, in response to changes in operational / business environment:

• Rapid patch / fix and roll back capabilities

• In future?

- Dynamic component re-wiring to account for co-locality

- Policy based roll-back based on System behaviour

- Self-Tuning / SLA aware Service assembly behaviours

The Paremus Service Fabric

(1..m) “Systems” may run upon a single Service Fabric

(1..n) “private Resource Clouds” may contribute to a Service Fabric

Atlas Resource Management

Service Fabric ! Production

"#"Cloud ! Blue$ "&"Cloud ! Red$"os%name!Darwin$$$

‘Target State’ driven resource acquisition

• Ongoing discovery

• To join a Service Fabric - Atlas agent must have appropriate X509 certificate

• Only resource with correct characteristics are assimilated into Service Fabric

• Resource may leave at any point in time

Create a “Red” & “Blue” Service Fabric

Management & Monitoring

ProvisionerSystem Managers

RegistryService Advertisements

RepositoryOSGi bundles

System DescriptionsNimble Policies

WAR EAR

General artifacts

Service Fabric - Infrastructure Services

Principles:• No ‘special’ nodes

• Node ‘Roles’ may/do change over time

Techniques:• Dynamic Group formation & subsequent membership

• Dynamic leadership election

• Eventual Consistency across group members

Service Fabric - A Model-Driven Runtime

System Description Running System

A model of the desired business service is submitted. The Service Fabric dynamically deploys all required business and infrastructure components.

Abstraction ‘Form’

Corresponding runtime Entity

Service Fabric - Model-Driven Management

Target State Runtime State

The Service Fabric continually compares the runtime structure with its corresponding model

Deploy

Target State

"Structure#SLA$

Runtime

Entity

Monitor

Provision Delta

Planned Deltase.g. Configuration

changes

Unplanned Deltase.g. Resource

failures

Bundle

BundleBundle

Bundle

BundleBundle

Bundle

Target State

"Structure#SLA$

Runtime

Entity

Monitor

Provision Delta

changes

failures

Bundle

BundleBundle

Bundle

BundleBundle

Bundle

BundleNecessary Complexitymasked by ‘Nimble’

Runtime State

Target State

To change a complex runtime System simply change its model!

Re-Configure

Target State

"Structure#SLA$

Runtime

Entity

Monitor

Provision Delta

changes

failures

To change a complex runtime System simply change its model!

Anatomy of a Business System

System Target State

SCA StructureScaling Behaviour

(Replication Handlers)

Resource Contract

= (cost_center=engineering)

= !(os.name=Windows)

= (os.name=linux) & (CPU.speed > 3 Ghz)

= fn(z)

= fm(y)

= fl(x)

Composites &Bindings

Scale behaviour Resources required

Processinga-e

input stream

Processinga-b

input stream

Dynamic Scaling in response to Load

System !

System "

System #

$Group A%

Scoping & Visibility

Level Description

Composite A service at composite visibility is only bound to references within the same composite

System A service at system visibility is visible to any reference in a composite in the same system

GroupA service at group visibility is visible to any reference within composites in systems in the same group

FabricA service at fabric visibility is visible to all references within the fabric

PublicA service at fabric visibility is visible to all references within the fabric

Development

The Service Fabric does not mandate any particular IoC framework. A System may consists of any mix of:

• Java POJO’s

• OSGi Declarative Services

• OSGi Blueprint

• iPojo

• Spring and Spring DM

• Google Guice / Peaberry

• Scala (or any other language that targets the JVM)

System Architecture - Communication

Service Fabric does not enforce any particular architectural ‘form’

• Messaging middleware / protocols are the concerns of each System; via choice of bindings and infrastructure components

• SEDA, ESB, Broker, P2P patterns are all possible

• Low latency, batch grid, order matching & transactional message based Systems may be concurrently supported on the same Fabric

System Architecture - Data / Caching

Service Fabric does not enforce an particular data model.A true No-SQL Platform as a Service (PaaS):

• Unstructured data processing - Hadoop

• Key / Value - Voldemort

• Column - Cassandra

• Graph Database - Neo

• Relational - Derby, MySQL

A self-configuring PaaS

warEAR

Service Fabric - ‘I need to deploy a Servlet containers for this WAR based service!’

Avoid middleware lock-in. Avoid bending you business systems to the dictates of monolithic middleware. The Paremus Service Fabric is a PaaS runtime that dynamically assembles and

configures itself around the requirements of each business service it hosts

What to know more?

• Talk to Paremus.

• on OSGi? Join UK OSGi Forum - http://uk.osgiusers.org/Main/HomePage

• on OSGi? Buy the Book - http://www.manning.com/hall/

www.paremus.com/servicefabric

http://felix.apache.org/site/apache-felix-sigil.html

Thank You

www.paremus.com/nimble

Complexity, Components & Clouds (Paremus)

Technology

Clouds and Climate: Forced Changes to Clouds SOEE3410 Ken Carslaw Lecture 4 of a series of 5 on clouds and climate Properties and distribution of clouds

Complexity 11-1 Complexity Andrei Bulatov Space Complexity

How do clouds form? LECTURE 6, Clouds

CLOUDS WEIGHT THE OF A WORD. CLOUDS CLOUDS CLOUDS

Clouds, Clouds, and more Clouds!

Managing Scale and Complexity of Next Generation HPC Systems and Clouds Peter ffoulkes Vice President of Marketing April 2011

Bootstrapping OpenStack Clouds - Rackspacec1776742.cdn.cloudfiles.rackspacecloud.com/downloads/pdfs/dell...Beyond Bootstrapping: ... To scale and reduce complexity, clouds must rely

Clouds Finding Out What Clouds Are All About. Cirrus Clouds

How the INDIGO-DataCloud computing platform aims at helping … · 2016-07-03 · CLOUDs for unusual (scale, complexity) and/or infrequentrequirements. A fourth is data managementin

The invigoration of deep convective clouds over the ...€¦ · undetectable clouds (the abovementioned small clouds or clouds with weak optical signature) decreases as a function

Clouds Cumulus CU Low clouds - cumuliform -. clouds Cumulus CU Low clouds - cumuliform -

Managing Scale and Complexity of Next Generation HPC Systems and Clouds

CLOUDS. What are clouds?

Polar Mesospheric Clouds (PMCs) -also known as- Noctilucent Clouds (NLCs)

Why do clouds turn gray? CLOUDS - mrspruillscience€¦ · Stratus Clouds Stratus clouds are uniform grayish clouds that often cover the entire sky. They resemble fog that does not

SPACE COMPLEXITY & TIME COMPLEXITY

Paremus service fabric

Kinds Of Complexity Worst-case complexity. Average complexity. Amortized complexity

Clouds clouds everywhere

Clouds - Free Kids Books · There are three major types of clouds: cirrus clouds, stratus clouds, and cumulus clouds. Each type of cloud looks different. Some are found high in the