NetKernel News Volume 5 Issue 12

October 3rd 2014

• Repository Updates
• NetKernel Gradle Plugin: Build Automation Tooling for ROC
• Enabling Continuous Deployment
• Boston Visit

There are no Apposite updates this week.

We are very pleased to announce the immediate availability of the official NetKernel Gradle plugin.

Gradle is increasingly becoming the standard Java/Groovy build automation tool of choice. Therefore it made sense to provide a NetKernel specific gradle plugin as our officially supported toolchain for NetKernel build automation.

The plugin provides a wide range of tasks and its scope ranges from simple utility tasks for developers, through to enabling full, complex CI build automation processes for NetKernel solutions.

Usage

The plugin is provided from the official NetKernel maven repository and so can be used direct from Gradle with no installation needed.

All of the detail, and a full reference guide to the availabe tasks, is provided in the Reference Book

Overview

When it comes to developer tools it often feels like there are as many opinions as there are developers.

For the longest time we've stayed on the fence and simply allowed the fact that NetKernel is Java-based, to be sufficient to use any of the wide variety of Java tools to build NetKernel modules (IDEs, Ant, Maven etc - the fact that most NetKernel modules don't have any statically compiled code to build, notwithstanding).

However with concepts like micro-services now entering the mainstream consciousness we feel validated and emboldened. And so we are increasingly aware that we need to set a clear direction and agenda for Resource Oriented Computing. And that has to include the tool chain - because, frankly, its not fit for purpose.

The problem with the state of the art in developer tooling (you name it - they're all very alike in this respect) is that they have the characteristic of regression to the monolith.

By which I mean, they allow you to create independent components but, as projects get larger, rather than maintaining independence, they tend to take the easy option and head down the "oh just lump it all together as a monolithic blob" path.

Monoliths are the dinosaurs of our time. Their time is nearly done.

Having tilted at the windmills, I'd better hurry to explain the plugin's model...

Enabling Continuous Deployment

The diagram below provides a schematic overview of the usage model envisaged for the NetKernel plugin.

In the diagram the linking arrows represent development lifecycle transitions typical to development projects. The NetKernel plugin provides one or more tasks for each of these transitions.

Important: The role of repositories

It is important to understand that the NetKernel plugin is designed so that all artifacts come from and are published to repositories (either Maven or Ivy - and any possible future repository models supported by Gradle).

Artifacts include: build dependencies, NetKernel module deployments, frozen snapshots of base configurations of NetKernel and final production images of complete NetKernel application instances.

In the diagram the blue cylinders named "Maven Repo" are not necessarily the same repository. It is possible to employ a multi-repository configuration for development, test, stage, production etc. Equally, for simplicity, you can do everything with just one repository.

The Pizza Model

NetKernel is a very flexible platform and provides a wide range of modules from its own Apposite repository.

To avoid regression to the monolith, its helpful to clearly distinguish the job of configuring your base-line NetKernel platform, from creating the application set of modules that you will deploy to a configured instance.

To keep it simple, the NetKernel plugin is based on a conceptual Pizza Model, in which our ultimate aim is to produce a perfect pizza - a production instance of NetKernel, configured with our tested application modules and any necessary additional Apposite-provided NetKernel modules.

To create a pizza you need just two things.

1. A pizza base
2. Toppings to go on it.

A well run pizza business understands that you don't start (1) and (2) from scratch for every pizza order.

An efficient pizza factory has an independent process to create a range of bases.

A second independent process prepares a variety of toppings

A third independent process "creating a pizza" then just involves choosing a ready-to-use pre-built base and applying the specific toppings before baking the pizza.

The completed pizza is checked against the order to make sure its correct. Finally the pizza is given to the delivery person and released for consumption.

The NetKernel plugin provides:

• tools for creating bases (configured NetKernel instances)
• tools for creating and applying toppings (building modules)
• tools for assembling and baking the combined pizza
• tools for testing the complete order
• tools for delivering the final product - either as a static monolith (boo) or as a dynamic continuous deployment (hurray!)

Role of Repositories

Unlike in the pizza business, where using freezers is frowned on, software configurations can be frozen perfectly and thawed instantly.

In the NetKernel plugin's Pizza Model, using repositories is exactly like using a freezer.

The NetKernel plugin can:

• configure and freeze base NetKernel instances and then store them indefinitely in a repository(s).

• build and assemble application modules and store them indefinitely in a repository(s).

• select and thaw a base and apply a configuration of frozen application modules (make the pizza)

• test the combination. If it passes, freeze the complete production image (a "ready-to-eat" pizza)

• select and thaw a production image and start it in production - or alternatively...

• select and thaw a proven base image and continuously deploy updated configurations (the never ending evolvable pizza!).

Freezing to the repository ensures that the build, assemble, test, deploy processes can happen asynchronously and with independent quality assurance checks for each process. Unlike with pizzas, using the freezer is very efficient and delivers consistently high quality.

Scenarios

So what can you do with the Gradle plugin's tasks? Here's just a very short set of examples.

• Install a brand new copy of NetKernel with no knowledge and apply all its updates and freeze it as a stable base image.
• Build a single module or multiple modules, deploy them to a clean base image and then freeze the complete pizza.
• Continuously Integrate change sets by building deploying and xunit testing the combination.
• Thaw a frozen NetKernel image to a cluster of cloud instances and fire them up.
• Continuously deploy a tested set of modules to a cluster of cloud instances.

Eliminate the ROC Application Barrier to Entry

We think creating and distributing your own NetKernel ROC solutions just became very simple. You can...

• Create a single build script for your open public github application, that with one task builds the modules, installs NetKernel, deploys the application, starts it, runs the xunit tests, and leaves it running for someone to play with.

• Provide a single packaged NetKernel instance with your ready prepared application - with a copy of build.gradle and execution of "gradle" it would download the instance and start it running.

Further Reading

At this point you need to grab a copy of Gradle 2.1+ and read the detailed reference docs to see examples for each of the avaiable tasks.

Don't worry you don't need to learn Gradle to get started - the cut-and-paste example configurations are all you need to do any of the scenarios described above.

Acknowledgements

The development of the plugin has been a team collaboration: Brian Sletten initiated the project and provided the first steps, Nic Spilman contributed to the core plugin codebase and figured out parameterization of tasks, Randy Kahle has provided a number of tasks. Finally the 1060 team have implemented the core NetKernel specific tasks and provided the general conceptual model.

We are very grateful to everyone who's contributed and we know this is only the beginning, with plenty of opportunity to add new features. For example, there is already a 'module templating' capability in incubation...