modularity, microservices and containerisation - neil bartlett, derek baum

www.paremus.com

Transforming the Way the World Runs Applications

Copyright © 2012 Paremus Ltd. May not be reproduced by any means without express permission. All rights reserved.www.paremus.comParemus July 2012

Modularity, Microservices and Containerisation

[email protected]

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

Paremus Service Fabric Overview November 2009

• Docker reigns supreme…

• Also:

• Rocket (CoreOS)

• Solaris Zones

• FreeBSD Jails

• etc

Containers



• Reduce the pain of shipping apps to production.

• Kill off “It Works for Me” syndrome.

• Increased security.

What Containers are Claimed to Solve



• Reduce the pain of shipping apps to production.

• Consistent way to ship and run applications.

• You already know how to run any image.

• Increased security.

• Hugely powerful for opaque, 3rd Party parts of your app:

• MySQL, ZooKeeper, Hadoop, …

What Containers Actually Solve



• Configuration approaches vary widely.

• Dependencies still exist!

• OS kernel version, CPU, GPU

• Network

• Dependent Services

• Orchestration (solutions are nascent).

What Containers Don’t Solve



• Modularity!

• Application code is untouched by containerisation.

• Greatest strength and greatest weakness.

• All too easy to build containerised monoliths.

• Just as hard to maintain, evolve.

What Containers Don’t Solve



• “… 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.”

• From the Gospel of Martin Fowler ;-)

Microservices



• Small services

• Own process

• Lightweight communications

• Independently deployable

• Automated deployment

• May be written in different languages

Microservices



• Separate processes add overhead.

• Security risks: every service adds to attack surface.

• Sometimes worth it, sometimes not.

• This is an implementation choice.

• Should not be required by the architectural definition.

Microservices



• OSGi is a great implementation tech for both of these patterns.

• First: Microservices

An OSGi Approach



• OSGi Services == Microservices

• Lightweight communications, independently deployable, yada yada.

• Defer the decision to go remote.

• Service boundaries are hard to anticipate

• (From 11+ years OSGi development experience!)

OSGi Microservices



Scale Out…

Consumer Provider

Consumer Provider



Consumer Provider

… and Scale In

Consumer Provider



• OSGi Remote Services Admin.

• Transparent discovery and distribution for OSGi Services.

• Better (but not limited to) OSGi at both ends.

Options

Provider



• OSGi Remote Services Admin.

• Transparent discovery and distribution for OSGi Services.

• Better (but not limited to) OSGi at both ends.

Options

ProviderConsumer



• REST.

• Layered over OSGi Services (whiteboard).

• RFP-173: JAX-RS Services — OSGi Enterprise R7 (hopefully).

• Interim: hstaudacher/osgi-jax-rs-connector works well*.

Options

* But careful of CDDL/GPL on Jersey.



• Begin your microservices application in OSGi.

• Just write interfaces and components!

• As the need arises, separate into processes.

Summary



• Second: Containers

An OSGi Approach



• Containers are implementation agnostic.

• OSGi gives us internal modularity.

• Turtles all the way down.

• Reuse APIs and component from your Repository.

• Use the Resolver to assemble container content, minimise image size.

• Bndtools 3.1+ may support “export as Docker image”.

• Easy deployment for Ops people familiar with Docker.

OSGi Inside



• Paremus Packager — announced at EclipseCon, Boston 2013.

• Integrates lifecycle of external apps into OSGi.

• Originally used custom process launcher.

• Rewritten early this year to support Docker.

• (non-Dockerised processes still supported).

• Bundles can depend on containerised services.

• Resolver can solve and provision these dependencies.

OSGi Outside



OSGi Outside

Consumer

Require-Capability:com.paremus.packager.pkg.MySQL Endpoint

resolve

Paremus Service Fabric



Consumer

Require-Capability:com.paremus.packager.pkg.MySQL

MySQLPackageWrapper

Provide-Capability:com.paremus.packager.pkg.MySQL

resolve provision


Endpoint

Start or AttachContainer

OSGi Outside



Consumer


MySQLPackageWrapper


resolve provision


Endpoint;uri=jdbc:mysql://192.168.0.1:3306

Start or AttachContainer

OSGi Outside



• Temporal Dependencies

• Packager knows when the container is running and available.

• Publishes the URL of that service to the distributed app:

• e.g.: jdbc:mysql://192.168.0.20:3306

• Using OSGi Remote Services (yay standards)

• Injectable by any OSGi component.

• Including other Packager wrappers!

OSGi Outside



WordPress


MySQLPackageWrapper


resolve provision


Endpoint;uri=jdbc:mysql://192.168.0.1:3306

Endpoint;uri=http://192.168.0.20:80;

app=WordPress 4.1

OSGi Outside



OSGi Outside

DEMO



Packager

Paremus Packager and Demos at docs.paremus.com

modularity, microservices and containerisation - neil bartlett, derek baum

Technology