An interesting pick from the Thoughtworks blog. In this article Ford and Parsons position microservices as “one of group of architectures that support certain evolutionary behaviors”, explaining common characteristics of evolutionary architectures that can also be found in microservices.

I think this moves the attention back to an important line of thought that often gets lost in microservices discussions these days: the principles behind the architectural decisions and technical choices that add value to the business.

In my opinion the term “microservices” didn’t benefit to the overall change in direction we see today, because it moves the focus from the complex whole to the single parts, which may be an explanation why many people wrongly assess microservices in lines of code or other implementation details.

The term “evolutionary architecture” seems to achieve quiet the opposite: “evolutionary” is a reasonable hint to the guiding principles (far better then “micro”) and “architecture” forces you to think about concepts and cross-cutting concerns (opposed to “service”).

There are two ways of constructing a software design:
One way is to make it so simple that there are obviously no deficiencies,
and the other way is to make it so complicated that there are no obvious deficiencies.

Updated visual appearance

The look and feel now builds on Patternfly. With more and more JBoss projects moving to patternfly, this will provide a more consistent look&feel across the portfolio.

Changes to the information architecture

We’ve moved things around a bit:

‘Deployments’ are a top level category in their own (used to be under ‘Runtime’)

‘Domain Overview’ moved to ‘Domain’ (used to be under ‘Runtime’ as well)

This allows to us to better address certain edge cases when configuring domains and has a clearer affordance when managing to specific server instances.

Extended Subsystem Support

The following subsystems have been revamped or completed:

EE

Undertow

Messaging

IO

Batch

Most of them have been either incomplete or missing and the new implementation provides access to the full subsystem configuration options.

New Model Browser

The model browser (Footer > Tools > Model Browser) has been completely revamped. It’s value/purpose has not been quiet clear in the past. I guess most people simply used to look up the management model documentation and get a general overview. However it now supports editing resources directly and a much better interaction and visual appearance.

On it’s own it might be used as a minimal GUI for Wildfly.Core at some point.

Ability to view logs form the console

Harald Pehl did a great job implementing this one with support from James Perkins. The log viewer (‘Runtime’ > ‘Platform’ > ‘Log Viewer’) allows you to browse through or tail server logs. It’s a feature that’s been missing for a long time and I am happy to see it included in Wildfly 8.2. It will become especially useful when managing domains.

Picket Link Integration

The picket link management UI is now part of the default distribution. That means any Wildfly instance that uses the Picketlink subsystem can now be managed by default.

Improved runtime monitoring

The ‘Runtime’ category has been revisited and cleaned up. We’ve added new attributes and improved those views that didn’t have a clear purpose.

Plenty of bug fixes

This release does include over 50 bugfixes spread across the whole UI. You might not have noticed all of them but this will certainly improve the overall user experience when working with the management console. Thanks to everybody reporting and fixing these issues.