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
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?
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
What do we mean by Complexity?
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Complexity
Information ��!"#"!$"%"&
A suitable Representation
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Complexity
Information ��!"#"!$"%"&
A suitable Representation
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Components: Why?
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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/
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
?Reuse Release Equivalence: Unit of reuse is the unit of release!
Components: Something is Missing?
Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Reuse Release Equivalence: Unit of reuse is the unit of release!
Components: Something is Missing?
Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Components: Benefits
- reuse- reduce complexity- ease maintenance- increase extensibility
Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Components: Benefits
- reuse- reduce complexity- ease maintenance- increase extensibility
Increases architectural agility!
Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Components: Modularity is not a new story
“First they ignore you, then they ridicule you, then they fight you, then you win.” -- Mahatma Gandhi
Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
Source - Kirk Knoernschild (Burton Group)http://techdistrict.kirkk.com/2010/02/26/osgi-devcon-slides/
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
90% of application lifetime cost concerns maintaining and evolving the Production Systems
Modularity is a MUST
Components: Business Driver
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Clouds
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Cloud: The bandwagon is rolling!
What are the critical characteristics required of any
credible Cloud solution?
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Cloud 1. An Elastic Resource Landscape
•All resource is transient
•Resource landscape will expand / contract over time
•Resource characteristics will change over time
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Cloud 2. Simplicity through Abstraction
• Manage Populations - not Instances
• Manage Business Systems - not Components
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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)
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Cloud 5. Is Multi-Tenant
Isolation / Visibility - control at all levels of structural hierarchy / abstraction:
• Groups of Systems
• Groups of Composites within a System
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2010 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
The Paremus Service Fabric
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
M!del
Target State
"Structure#SLA$
Runtime
Entity
Monitor
Provision Delta
Planned Deltase.g. Configuration
changes
Unplanned Deltase.g. Resource
failures
= 1
= 3
= 1
Target State Runtime State
Service Fabric - Model-Driven Management
The Service Fabric continually compares the runtime structure with its corresponding model
Bundle
Bundle
Bundle
Bundle
BundleBundle
Bundle
Bundle
Bundle
Bundle
Bundle
Bundle
Bundle
BundleBundle
Bundle
Bundle
Bundle
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
M!del
Target State
"Structure#SLA$
Runtime
Entity
Monitor
Provision Delta
Planned Deltase.g. Configuration
changes
Unplanned Deltase.g. Resource
failures
= 1
= 3
= 1
Target State Runtime State
Service Fabric - Model-Driven Management
The Service Fabric continually compares the runtime structure with its corresponding model
Bundle
Bundle
Bundle
Bundle
BundleBundle
Bundle
Bundle
Bundle
Bundle
Bundle
Bundle
Bundle
BundleBundle
Bundle
Bundle
BundleNecessary Complexitymasked by ‘Nimble’
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
Runtime State
= 1
= 5
= 1
Target State
To change a complex runtime System simply change its model!
Re-Configure
Service Fabric - Model-Driven Management
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
= 1
= 5
= 1
M!del
Target State
"Structure#SLA$
Runtime
Entity
Monitor
Provision Delta
Planned Deltase.g. Configuration
changes
Unplanned Deltase.g. Resource
failures
Target State Runtime State
Service Fabric - Model-Driven Management
To change a complex runtime System simply change its model!
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
CEP
Store
Processinga-e
u-z
input stream
CEP
Store
Processinga-b
y-z
input stream
Dynamic Scaling in response to Load
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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)
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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
www.paremus.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
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.comCopyright © 2009 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.
FITE Club (London) April 2010
www.paremus.com/servicefabric
http://felix.apache.org/site/apache-felix-sigil.html
Thank You
www.paremus.com/nimble