Complexity, Components & Clouds (Paremus)

www.paremus.com

Complexity, Components &Clouds

Copyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.www.paremus.comFITE Club (London) April 2010

Dr R NicholsonFITE club - April 2010

www.paremus.com

http://www.paremus.com




www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.

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’)

(m)

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’)

(m)

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



https://adaptevolve.paremus.com/?p=18

https://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/



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



http://en.wikipedia.org/wiki/Complex_system

http://en.wikipedia.org/wiki/Complex_system



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





IaaS

SaaS

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





A

B

C

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

= 1

= 3

= 1

Target State Runtime State

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

Deploy





M!del

Target State

"Structure#SLA$

Runtime

Entity

Monitor

Provision Delta

Planned Deltase.g. Configuration

changes

Unplanned Deltase.g. Resource

failures

= 1

= 3

= 1




Bundle

Bundle

Bundle

Bundle

BundleBundle

Bundle

Bundle

Bundle

Bundle

Bundle

Bundle

Bundle

BundleBundle

Bundle

Bundle

Bundle





M!del

Target State

"Structure#SLA$

Runtime

Entity

Monitor

Provision Delta


changes


failures

= 1

= 3

= 1




Bundle

Bundle

Bundle

Bundle

BundleBundle

Bundle

Bundle

Bundle

Bundle

Bundle

Bundle

Bundle

BundleBundle

Bundle

Bundle

BundleNecessary Complexitymasked by ‘Nimble’





Runtime State

= 1

= 5

= 1

Target State

To change a complex runtime System simply change its model!

Re-Configure






= 1

= 5

= 1

M!del

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





CEP

Store

Processinga-e

u-z

input stream

CEP

Store

Processinga-b

y-z

input stream

Dynamic Scaling in response to Load





System !

System "

System #

$Group A%

$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

war

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

EAR

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



message:%3C163824867-1246262625-cardhu_decombobulator_blackberry.rim.net-423254383-@bxe1080.bisx.produk.on.blackberry%3E

message:%3C163824867-1246262625-cardhu_decombobulator_blackberry.rim.net-423254383-@bxe1080.bisx.produk.on.blackberry%3E



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/



http://uk.osgiusers.org/Main/HomePage

http://uk.osgiusers.org/Main/HomePage

http://www.manning.com/hall/

http://www.manning.com/hall/



www.paremus.com/servicefabric

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

Thank You

www.paremus.com/nimble



http://www.paremus.com/servicefabric

http://www.paremus.com/servicefabric



http://www.paremus.com/nimble

http://www.paremus.com/nimble

Technology

Complexity, Components & Clouds (Paremus)