OSGi Community Event 2017 Presentation by Emanoel Xavier (Intel) and Tim Ward (Paremus) Open Security Controller (OSC) aims to increase the security of workloads running in cloud and data centers by orchestrating security virtual network functions (VNFs). To achieve that, one of the main design goals of OSC is to allow vendor customization while keeping its core code neutral. Additionally, as an open source project, another import design principal for OSC is code habitability. Evolving from a legacy monolithic application to a modularized one through OSGi has enabled OSC to implement these goals. Bringing together a diverse group of security services and software defined network (SDN) providers was key to building the OSC community. This was possible due to the OSC plugin model using OSGi which allows specific vendors to integrate OSC with their existing solutions with minimum effort. Beyond its plugin model OSC also makes use of OSGi in its core components. This enables better extensibility, testability and overall maintainability of its code base. These aspects are key to OSC as it relates to the new and dynamic areas of SDN and security VNFs in cloud and data center environments and it must be able to easily adapt to the constantly changing requirements and technologies pertaining these fields. In this talk we will explore the journey for turning OSC into a modularized application using OSGi, highlighting some of the achieved results, key learned lessons and the next steps for this work. https://www.opensecuritycontroller.org/

1. AJourneyfromaMonolithtoa
ModularizedApplication
ApproachandKeyLearnings
Emanoel Xavier Senior Software Developer, Intel
Tim Ward CTO, Paremus
1

2. 2
Notices and Disclaimers
Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software
or service activation. Learn more at intel.com, or from the OEM or retailer.
No computer system can be absolutely secure.
Tests document performance of components on a particular test, in specific systems. Differences in hardware,
software, or configuration will affect actual performance. Consult other sources of information to evaluate performance
as you consider your purchase. For more complete information about performance and benchmark results, visit
http://www.intel.com/performance.
Intel, the Intel logo and others are trademarks of Intel Corporation in the U.S. and/or other countries.
*Other names and brands may be claimed as the property of others.
© 2017 Intel Corporation.

3. Modularity through the ages…
3
A little history

4. 4
Adam Smith
The Wealth of Nations
(1776)
Division of Labor
“…the trade of a pin-maker: a workman not educated to
this business could scarce, perhaps, with his utmost
industry, make one pin in a day, and certainly could
not make twenty.”
“But in the way in which this business is now carried on,
it is divided into … about eighteen distinct operations,
which, in some manufactories, are all performed by
distinct hands”
“Those ten persons, therefore, could make among them
upwards of forty-eight thousand pins in a day. Each
person, therefore, making a tenth part of forty-eight
thousand pins, might be considered as making four
thousand eight hundred pins in a day.”
SMALLER SPECIALIZED CONCURRENT

5. 5
Henry Ford
The Moving Assembly Line
(1910)
Modularity & Productivity
parts and car
“come to you”
83 parts. 1 step/min
from 12h to 90 mins “continuous build”
interchangeable
parts
model

6. “The major advancement in the area of modular programming has been
the development of coding techniques and assemblers which (l) allow
one module to be written with little knowledge of the code in another
module, and (2) allow modules to be reassembled and replaced
without reassembly of the whole system. This facility is extremely
valuable for the production of large pieces of code, but the systems
most often used as examples of problem systems are highly-
modularized programs and make use of the techniques mentioned
above.”
– David Parnas, On the Criteria to Be Used in Decomposing Systems into Modules (1972)
6
Modularity in Software

7. 7
Apollo 16 Lunar Lander
Module (1972)
“... the systems most often used as examples of problem
systems are highly-modularized programs and make use
of the techniques mentioned above.”
A telling phrase…
“Modularity is too hard to be worth it”
Mixing the problem with the solution
The problems are complex
Modularity makes the solution possible

8. Modularity today
8
Fast forwarding

9. 9
1970s 2017
Modern modular software – vision

10. 10
1970s 2017
Modern modular software – reality

11. 11
Modularity is not magic
Forgotten past lessons
70s: Low level modularity for
low level coupling
Late modularity == expensive
tech debt

12. (Serves One)
12
The recipe for a monolith

13. Starting a new project
13
Nobody
plans to
write bad
code
Things will
be different
now
Well
defined,
modular
design
we have all
been there
Sonar*,
Findbugs*,
100% CC
intended
modularization

14. Growing the project
14
Mgmt needs
more code
Here, more
devs
Flexible
processes
more
requirements.
6 months
deadline
but, Karl, your
best coder is
gone
That is ok, we
are “Agile*”

15. Growing the project
(6 months later)
15
almost done
processes
and tools
some
workarounds
needed
worked overtime.
“paper” release
people catching
up with Karl’s
code.
code reviews
that’s ok.
track and fix
later

16. Renewed interest
(6-12 months later)
16
customer:
shows
interest
sales:
delivery in 6
months
no one is
familiar with
the code
+4 new members,
+20 years worth
work
+1 headache
no previous team
member.
Karl’s code is still
around

17. 17
Do any parts of this seem familiar?
Gall’s Law:
“A complex system that works is
invariably found to have evolved
from a simple system that
worked. A complex system
designed from scratch never
works and cannot be patched up
to make it work. You have to start
over with a working simple
system.”
 Nobody sets out to write bad code
 Successful projects are bound to
become complex
 Complexity must be managed

18. (Serves One)
18
How OSGi helps

19. 19
imposes
API boundaries
hides
implementation
details
automates
dependency
management
enforces
dependencies at
runtime
facilitates
composition

20. 20
 Won’t magically turn a monolith into a
modularized application
 Will provide you the tools for that
 Won’t automatically fix all coupling
issues, “shortcuts” and technical debt
 Will make them more evident
 Won’t fix API leaks
 Will enforce your APIs

21. 21
Getting results
Planned and
managed
API changes
Work with it,
not against it
OSGi:
ongoing
commitment

22. How OSGi helps
22
 Limits complexity to smaller pieces
– Divide and conquer
 Pieces can be more easily and predictably
replaced
– No runtime surprises
 Easier to understand dependencies fan out
 Better testability

23. 23
OSC 101

24. 24
How it started
 Intel closed source project
 Application and deployment of security
virtual functions
 Let’s extend it !
 Let’s build a community around it!
– Spring 2016 => Summer 2017
Seemsfamiliar?

25. 25
OSC in SDI
LOCATIONUTILIZATION LATENCY SECURITY
Infrastructure
Attributes POWER PERFORMANCE
Infrastructure
Attributes
Servers
Virtualization
Containers
Virtual
Router
Virtual
SAN
Scale
Out
Storage
Apps SDN/NFV SDS
Infrastructure
Pool
VMs
Virtual
Firewall
Virtual
Switch
Policy based automation
Self service portal
Service
Orchestration Compute Network Storage Security
Pool of virtualized
resources
Platform
capability aware
Centralized and
automated

26. register
setup
26
OSC in action
Plugins
OSC
Security
Manager
SDN
Controller
Data Center
 Plugins
 VNF Image
 Virtualization Connector
 Manager Connector
 Security Group
 Deployment
 Security Policies
IPS,
NGFW,
ADC

27. 27
OSC logical components
osc-core
sec-mgr-plugins sdn-ctrlr-plugins
sdn-ctrlr-apisec-mgr-api
OpenStack4j*
RabbitMq*
Fabric8*
OpenStack
KubernetesH2 DB
VNF Catalog
Plugins
BL services Sync tasks
Security Mgr Services SDN Ctrlr Services
UI REST API
OSGi , h2db-jpa,
apache.aries.jpa,
vaadin, logback,
…

28. 28
The path to open source
Community members diversity
SDN Providers and Security Managers neutral
! OSC Plugins Model
Dependency conflicts
REST Services?
 Redundant endpoints
 Not conducive to early adoption
 Legacy plugins

29. 29
The journey starts…

30. 30
Modularizing the plugins
osc-server
sec-mgr-plugins
1. Build dependencies
2. Runtime dependencies
3. Startup dependencies
osc-controller
sdn-ctrlr-plugins
sec-mgr-apisec-mgr-api
pom.xml pom.xml
whiteboard
pattern
whiteboard
pattern
OSGi Resolver
BAR Installer

31. 31
Modularizing the plugins
osc-server
sec-mgr-plugins
osc-controller
sdn-ctrlr-plugins
sec-mgr-apisec-mgr-api
whiteboard
pattern
whiteboard
pattern
OSGi Resolver
BAR Installer
 Smaller footprint
 Simpler service registration
 Earlier plugin validation
64 /110
packaged
dependencies
OSGi Http
Service
Whiteboard
Plugins
Lifecycle

32. 32
Are we modular yet?

33. 33
Perceived modularization
Implemented Lacking
"…Curved Walking in Humans”
Gregoire Courtine, Journal of Neurophysiology

34. 34
Does it matter?
SDN/SDI
maintainability
clean
dependencies
semantic
versioning
isolation
extensibility
Open
Source
incremental
build
clean
dependencies
semantic
versioning
runtime
enforcement
unit testing

35. 35
The journey continues….

36. 36
OSC uber bundle anatomy
 Common monolithic to
modularized migration path
 Flat classpath
 Transparent non-bundle
dependencies
 No isolation between internal
packages
osc-server
uber bundle
uber bundle
core
BL services Sync tasks
DB access
UI REST API

37. 37
Database access: osc-domain
 Only @Entity classes
 JPA API & Apache Aries JPA
 OSGi Transaction Control Service
 Unidirectional dependency
osc-server
uber bundle
core
BL services Sync tasks
DB access
UI REST API
osc-domain
hibernate-core, h2databasehibernate-jpa-api

38. 38
User interface: osc-ui
 New project: osc-service-api
 UI views as DS components
 OSGi managed views
osc-server
uber bundle
core
BL services Sync tasks
UI
REST API
osc-domain
osc-ui
osc-service-api

39. 39
REST API: osc-rest-server
 Uses the osc-service-api
 JAX-RS service classes
 No more domain entity references
from the DTOs
 New service APIs and DTOs
osc-server
uber bundle
core
BL services Sync tasks
REST API
osc-domain
osc-ui
osc-service-api
osc-rest-server

40. 40
Modularized OSC
 5 new smaller bundles
 DS, Interfaces, clear contracts
 Improved dependencies scopes
 Auxiliary uber bundles
– Non OSGi dependencies
 Incremental build
osc-server
osc-server
core
BL services Sync tasks
osc-domain
osc-ui
osc-service-api
osc-rest-server
+

41. 41
Are we modular yet?
End of journey?

42. No…
42
 Modularization, like good code, is an ongoing effort
 There are multiple degrees of modularization.
– A gradual approach is recommended
– But don’t go back.
 OSGi is not a magic wand, but makes the job possible
A monolith will only get
you so far. For a longer,
pleasant (and modular)
journey you will need
not only the right tools
and frameworks. The
right mindset is just as
important.

43. Thankyou!
Emanoel Xavier Senior Software Developer, Intel
Tim Ward CTO, Paremus
43
www.opensecuritycontroller.org
Come join our community!