DevNation and Red Hat Summit 2016

Posted on June 24, 2016 by Rich Sharples

It’s that time of year again (OK Summit is actually fairly late this year) but you get my drift. DevNation / Summit alternates between Boston and San Francisco – this year we’re at Moscone North and West in San Francisco.

Two events for the price of one – can’t be bad. DevNation is by developers and for developers. Red Hat Summit is for our partners, customers and prospects and has technical, strategy and business tracks revolving around our commercial offerings.

Would love to catch up with friends, colleagues, customers and prospects.

Here’s where you can find me :

Sunday 26th, 5.30pm – 8.30pm PDT – DevNation Welcome Reception (travel gods willing)

Monday 27th, 9.30am – 11.45am PDT – DevNation General Session

Monday 27th, 8.30pm – 10.00pm PDT – Technical Leadership Meet and Greet, Thirsty Bear

Tuesday 28th, 10.15am – 11.15am PDT – Session – “The current state of enterprise languages, frameworks, and platforms”, Room 2020

Tuesday 28th, 11.30am – 12.30pm PDT – Session – “Build your game plan for enterprise Java 2020”, Room 3005

Tuesday 28th, 3.30pm – 4.30pm PDT – Panel – “Red Hat containers roadmap”

Wednesday 29th, 6am – 7am PDT Red Hat Summit 5k Run / Walk. In customer, press and analyst meetings all day, then …

Wednesday 29th, 8pm – APBG party (aka the JBoss Party) – you’ll have to use your contacts to get an invite (eg. come to one or all of my sessions above) !

I’m actually around ’til Friday morning and have some spare time on Thursday if anyone wants to catch up.

JBoss EAP 7 BETA Available !

Posted on December 19, 2015September 11, 2026 by Rich Sharples

Screen Shot 2015-12-19 at 2.25.41 PM

Today Red Hat released JBoss EAP 7.0 BETA. This is the culmination of a couple of years of hard work by the JBoss EAP team at Red Hat and the broader WildFly community. I would like to thank them for their dedication and hard work and offer congratulations on achieving another huge milestone and major step forward in establishing Open Source in the enterprise and JBoss EAP as the open source standard for Java EE.

JBoss EAP 7 is a significant release in every respect; the last major EAP release (EAP 6.0) was back in June, 2012 and after 4 minor feature releases and numerous patch releases, EAP 6 is now just 8 months away from entering its long-term maintenance phase. While EAP 6 will be fully supported for many years to come – all new development and new features will target EAP 7 and beyond.

While Java EE 7 brings a major set of new features to EAP 7 (see below) it’s only a small part of what defines JBoss EAP 7. There are many other major updates in the release to help us keep up with demands of our customers, industry trends and align with other Red Hat products and initiatives.

New high-performance web subsystem based on Undertow – supporting Servlet 3.1, WebSockets, HTTP Upgrade
Undertow can also be deployed standalone as a lightweight, scalable proxy / load-balancer.
Move from JacORB to the standard OpenJDK ORB
New high-performance messaging subsystem based on Apache ActiveMQ Artemis – same searing performance as HornetQ with expanded protocol support and Artemis is now the standard message broker for all JBoss products.
Support for Java EE 7 – full and web-profile and Java SE 8.
Enhanced (JSR-352) batch support – including cluster support, management (liste, start, stop, resume) of batch jobs and IDE (JBDS 9.0) integration
Improved upgrade experience from previous versions of EAP / WildFly and better support for competitive migrations using Windup.
Improved JNDI, EJB, JMS and WS interoperability between EAP 7 and older versions – useful for side-by-side upgrades.
Ability to manage EAP 6 domain hosts and servers
Improved management console; easier navigation, and much better support for large scale domain configurations.
Graceful shutdown – allows servers to quiesce without aborting in-flight requests or transactions

Also the following features are available as Technical Preview :

A new JGroups based DistributedWorkManager
Execute JavaScript (using JDK8’s Nashorn), access JNDI and invoke CDI and JPA EntityBeans from JavaScript
HTTP 2.0 – connection multiplexing, header compression and server push

Major enhancements to Java EE 7 include :

Websockets – JSR-356
JSON Processing – JSR-353
Concurrent Utils for Java EE – JSR-236
Batch Processing – JSR-352
JAX-RS 2.0 – JSR-339
Servlet 3.1 – JSR-340
JMS 2.0 – JSR-343

A more detailed refresher on on Java EE 7 features here.

As always – you can download the BETA via the Red Hat Customer Portal or from JBossDeveloper if you don’t have access. Release notes are here. And you’ll need some developer tooling to go with that – JBDS 9.0 is available for download here.

Give the BETA a try and give the team some feedback.

UP3 take 3

Posted on November 30, 2015September 11, 2026 by Rich Sharples

I pre-paid for the much anticipated UP3 band in December 2014, was dissapointed with the release delay and the downgrade from waterproof to splashproof but opted for the discount vs get my money back because I thought it was worth waiting for and worth waiting for Jawbone to get it right. I was dissapointed when my first band failed after just 6 weeks, more so when the second band failed for exactly the same reason after just 3 months; as did my Wife’s first band after 3 months. After all this I decided enough was enough – I gave Jawbone a chance to explain how they have addressed the expanding case design issue. They didn’t even accept that it was a known issue so I demanded my money back – afer explaing the design flaw to a couple of tech support assistants and one manager I was told they wouldn’t be able to give me a refund as my original purchase was beyond the 60 day limit and all they could do was send me a replacement. I couldn’t find that time limit easily in their returns policy.

So here I am after 6 months with my 3rd band and my wife with her 2nd band expecting both to fail before Ground Hog Day – essentially a reluctant customer. As most marketers know – if there’s one thing worse than a non customer – it’s a reluctant customer.

Here’s the thing – the band (aside from previously mentioned design flaw) is very good – it does everything I want in the right form-factor. I think the iOS software is the best on the market in my opinion and they’ve done a decent job of iterating the band software to extend batery life and make sleep tracking easier. Their customer service rocks – they’ve never hesitated to process a return and done it very quickly each time – I suspect practice has made them good at this.

My message to Jawbone – you can do better than this; you have to do beter than this – it’s a very competitive market. Redesign the band casing / battery, make it waterproof as you orginally claimed and give your loyal but possible reluctant customers and free / cheap upgrade path.

Net Neutrality

Posted on February 26, 2015September 11, 2026 by Rich Sharples

The FCC decision for Net Neutrality is a monumental decision but may not actually have much impact unless it continues to receive support – it’s obviously going to be challenged, and may be thrown out completely by whoever takes over the Whitehouse.

It’s unfortunate this has become a partisan issue – with the right seeing it as government control of the Internet and siding with the big carriers. IMO – anyone siding with the big carriers on this one has to be wrong.

UPDATE :

These editorials are worth reading :

“Net neutrality’s next chapter: How experts saw today’s milestone and next steps”, Gigaom

Micro services – the new architecture for digital engagement ?

Posted on February 21, 2015February 28, 2015 by Rich Sharples

Disclaimers and excuses.

I’d like to think I know as much or more than the average tech. pundit when it comes to building large-scale, resilient systems. In a previous life I spent the best part of a decade building large complex distributed systems for space, transport, telco. and utilities using CORBA, DCE, COM, WS*, REST, etc. So for what it’s worth here are my views on the latest architectural buzz-word du-jour – microservices. I’ve also heard numerous terms to describe the ideas behind microservices :

μservices (this one is bankrupt)
hipster-SOA (I like that one)
MSA (why does everything have to be a TLA in this industry ?)
agile SOA (this one has some merit)
SOA-2.0 (Just. No.).

I think I’m going to stick with microservices until someone proposes a better alternative. But Agile SOA – yeh – I like that.

There are lots of articles on the web about microservices, and I’ve included links to what I believe are the better ones below. I’ve also seen quite a few conference presentations (some good, some bad) and they all fall into one of two categories :

In the trenches, doing it today, at scale for real customers.
Higher-level description and fundamental principles

There really aren’t many of the former and this post falls into the latter category. I haven’t been a “real” developer for at least 15 years and I won’t show any detailed blueprints or code in this post. But I do intend to share some of my experiences, research and what I’m hearing from customers, analysts and other tech. pundits. I’ll also answer some questions I’m already being asked; a small sample here :

Isn’t a microservice architecture just SOA ?
Is this just the next software vendor buzz-word du-jour ?
How many LOC (Lines Of Code) is a microservice ?
Are there any applicable standards ?
Is an architecture build on APIs microservices ?
How do microservices relate to agile and DevOps ?
Where can I buy a microservice product ?

At this point I should add – these are my words and my opinion but they are heavily influenced by my role here at Red Hat where I run Product Management and where I have responsibility for a bunch of Red Hat’s Middleware products. I’d like to think I’m generally fairly impartial but I can’t promise not to be a little biased here and there. Finally – I’m learning here as well – I welcome challenges, questions, feedback and discussion. Comments are open.

New challenges.

So what has changed that has people across the industry questioning the architectural approaches and design decisions they’ve made in the past; or more importantly looking at alternatives to those architectures and practices for developing the next generation of applications ? A number of things :

Technical / architectural debt

When we talk about Applications in the Enterprises – we’re more often than not talking about complex compositions of intercommunicating systems – often developed over many decades using an array of technology. Individual elements of the “system” have their own release cadence, dependencies and often different owners with different goals. An increasing amount of energy is required to merely keep things running and avoiding outages that impact the business. Less and less energy is available to create competitive services and applications to serve the business.

The rise of DevOps

There is a strong headwind from the DevOps movement to radically change the way software is delivered and maintained. An essential element of DevOps is the notion of Continuous Delivery – a continuous stream of small, incremental chances to production applications instead of large disruptive upgrades. This requires an agile process and solid automated build and test using modern software development tools and practices.

Greenfield Opportunity – Digital Engagement

A shift towards developing net new systems that are focussed externally vs internally – if you follow Gartner – that’s the shift towards Systems of Engagement (or Innovation) or mode 2 applications using their Bi-modal IT vernacular. Or IDC’s third platform. Or Forrester’s “The Age of the Customer”.

Open Choice

During the last decade and a half – when building an application for the enterprise – there were two dominant choices – Java EE or .NET. More recently developer’s choices have expanded and IT has been willing to support a broader range of technologies. Especially for the kinds of green-field systems described above, developers are much more likely to make choices beyond the mainstream IT approved stacks and pick fit-for-purpose technology (eg. node.js for mobile, PHP for web, Java for middle-tier logic and back-end integration) Open source has made the technology that supports building resilient, distributed, web-scale applications far more accessible to far more developers. As with many other areas of technology – the innovation is happening in open collaborative communities and not in the ivory towers of traditional software vendors. Some notable examples are vert.x, ReactiveX, Netflix OSS.

Anatomy of a Micro-service

Microservices build on the same solid principles of good software design long espoused by practitioners of Object Oriented Systems and Service Oriented Architectures. Namely :

Loose coupling in all dimensions – time, lifecycle, type, location, interface, version.
Clearly defined purpose.
Autonomous – eg. taking responsibility for failure, resilience, security, etc.
Explicit Boundaries – self contained implementation; dependable public APIs.
Standards-based wire protocols, not language-specific APIs for interoperability (assuming heterogeneous technology)
Policy & Meta-data driven – favoring configuration changes over code changes

Microservices can only be useful in an underlying environment or with a platform that provides a means for :

service discovery
service replication (for availability and scaling)
dependency resolution and management
service failure detection and recovery
reliable and flexible build, package and deploy toolchain
service monitoring, alerting, eventing and introspection

Many of these technologies and solutions exist today and have been used successfully with monolithic and SOAs for many years but microservices deployments may push existing tools to the limit for a number of reasons – scale and heterogeneity. So this begs the question – “How is microservices different from SOA ?” Well, firstly – it’s not about size. We shouldn’t get too hung up on the “micro” prefix – services (micro or otherwise) should have a well-defined single purpose and a stable API – it shouldn’t matter if the implementation is 100 lines of COBOL or 900 lines of Scala. Some would argue it’s about the underlying technology – some pundits claim microservices is a movement against and away from traditional SOA and integration technology and vendors. I’m not convinced this is a major differentiator or driver for microservices – there are many ways to implement micro services and few people will be willing to completely burn their IT portfolio to the ground and start again. Well, I’m not completely convinced – I do think the whole integration space has become associated with large proprietary software vendor stacks and overly complex standards – I can understand why people are looking for a more agile, lightweight alternative. For me – the major change in thinking is something that we haven’t been talking about in the SOA world much in the last decade and that is operational agility and flexibility. Essentially, I believe microservices is good SOA principles married with modern DevOps practices – it’s an architecture that supports a fast cadence of continuous change in an operational environment vs big-bang upgrades with long release cycles. That’s an architectural approach married with an agile process for delivering the new breed of customer engagement applications I discussed previously.

Some Cautionary Notes

Building reliable, maintainable distributed systems is hard and many of our previous assumptions about software development no longer apply. As we learnt with CORBA and COM – moving objects / services out of process adds latency, performance and code overhead. It introduces failure scenarios and potential security exploits that didn’t previously exist – eg. well constructed in-memory function calls rarely if ever fail; add an air gap and everything changes – the code overhead to handle failures, retries, security, etc. likely eclipses the application complexity (and cost) itself. This was also true moving from non-SOA to SOAs. Managing service dependencies is also a challenge – we faced similar challenges building distributed systems with DCE, DCOM and CORBA and more recently SOAs and that underlined the importance of governance and API management tools, but microservices architectures will exacerbate the issue as we increase the number of services. Decomposing applications into fine-grained services each with their own process-space and possibly their own container / virtual-machine introduces additional resource utilization and process management overhead. Finally and as I mentioned above – micro services architectures build on solid SOA principles to solve some very real operational bottlenecks – I strongly suspect that successful microservices practitioners are also successful agile and DevOps practitioners.

Summary

Microservices is an architectural style that builds on solid principles of good software design – when used in a mature DevOps environment it can increase the cadence of change without increasing the risk and cost of maintaining large, complex systems. It delivers operational flexibility and agility but it comes at a cost. It requires developers to understand distributed systems development and requires sophisticated systems and application management tools. Ultimately people will have to make the tradeoff between operational agility and development complexity Microservices represents an evolution not a revolution and IT practitioners should avoid micro service envy and rush to re-architect perfectly serviceable applications without discrete problems in mind than can be solved with a move to microservices. Oh, and if someone tries to sell you a microservice product – run away as fast and far as you can.

“What is so Special about Microservices? An Interview with Mark Little” , InfoQ, February 2015 “Micro services : Decomposing Applications for Deployability and Scalability”, Chris Richardson, InfoQ, May 2014 “Micro services” by Martin Fowler, ThoughWorks, March 2014 “Micro-Services – Java, the UNIX way” by James Lewis, ThoughWorks, Sept. 2013

Is Java Dead Yet ?

Posted on June 28, 2012September 11, 2026 by Rich Sharples

This question has been asked many times over the last 13 years or so; I’ve answered it numerous times in various dark corners of the web related to these kinds of discussion. But the question came on our JBoss EAP 6 and Data Grid Virtual Launch today, so here’s this year’s answer.

In a word – No.

For a longer answer, here follows my attempt at a substantiation.

It’s part of my job to know what’s coming next and I’ve been tracking a number of sources that track technology adoption and popularity for many years. The first is specific to programming languages – the Tiobe Index.

The question most people have is why after XX years is C still so popular ? My explanation is that it’s still the standard language for embedded devices – device drivers, network appliances, automation systems, etc. And the embedded market has absolutely exploded in the last 5 years.

The death of bloated, heavyweight, monolothic enterprise Java …

Posted on May 7, 2012September 11, 2026 by Rich Sharples

… and the rise of the lightweight, agile, dynamic, modular Enterprise Java.

Java EE has long had the perception of being slow, bloated and monolithic. While the Java EE specification doesn’t prescribe a lightweight, modular implementation; neither does it preclude one. So the negative perception of Java EE is more to do with certain implementations than the standard itself. The two dominant commercial vendors of (Oracle and IBM) have, over the last 10 years, done a lot to re-enforce the perception that Java EE has to be complex, bloated and expensive. While at JBoss we’ve been pushing in a different direction for many years. Each of the last major release of JBoss AS has incrementally pushed modularity closer to an ideal where you only pay for what you need (in memory, complexity, CPU).

Photo Credit : “Junk in The Trunk”, zappowbang (CC, some rights reserved)

The latest version (JBoss AS 7) – which is also the underlying technology for Red Hat’s commercially supported product (JBoss EAP 6) has pushed the lightweight theme as far as to completely erode the difference between lightweight web containers (like Tomcat) and “heavyweight EE servers”. As far back as 2008 (through the advances in mobile devices and JBoss miniaturization) it’s been possible to run a full Java EE server on something as small as a smartphone; last year at Red Hat summit we ran the entire JBoss keynote demo (starts about 35min) on a cluster of cheap plug-top computers (far less powerful than today’s smartphone).

So it’s great to see IBM following our lead and pulling their own miniaturization stunt – Websphere running on a Rasberry Pi – very cool. Great to see IBM joining us to help change the perception of Java EE.

Rethinking Enterprise Java

Posted on July 21, 2011September 11, 2026 by Rich Sharples

JBoss AS 7 has been out for a week or so – probably not enough time for opinions to be formed but the feedback I’ve seen so far has been overwhelmingly positive. But that isn’t the subject of this post.

You probably didn’t see Red Hat’s press release as those things are typically only read by the press so I wanted to draw to you attention a single paragraph :

“JBoss Application Server 7 represents a major milestone in the evolution of Java application servers from complex and monolithic to more lightweight, modular and agile. This release will enable developers to re-think how they develop and deploy enterprise Java applications.”

I wrote that and I meant it. Over the last 5 years there has been a significant difference between the Java EE servers like JBoss, Weblogic and Websphere and Apache Tomcat. Tomcat has been the poster-child for the lightweight container movement (but we shouldn’t forget Jetty and Resin – both very capable servers) and has established itself as probably the most popular Java run-time.

But I think we’re at the point where there is no-longer a lightweight division between Java EE servers and Tomcat (and other Web Containers) – some good blog posts here and here that discuss typical developer requirements like startup time and deployment speed (make sure you read the comments). When we’re at the the point where we’re discussing sub-second differences between startup or deployment times then I think we have convergence. I think we’re at a point where you can no longer paint Java EE servers into the big, slow and heavy corner and Tomcat into the lean and fast corner.

Developers have more choice today than ever before – they can choose a lightweight container but no longer have to make a tradeoff between footprint and features. Or start with a basic server like Tomcat and incrementally build a full featured application server from the ground up as more features like caching, persistence, transactions, messaging, view layer are required.

OK before the Glassfish fanboys chime in – yes Glassfish did a great job of addressing light-weight needs for Java EE some time ago but by any available measure Glassfish still doesn’t represent a mainstream choice like Tomcat, JBoss, Weblogic or Websphere.

Java Container Popularity and a Prediction

Posted on January 3, 2011September 11, 2026 by Rich Sharples

Hey, 3 days into the New Year and my second blog post !

Another day, another survey – this one from Tools Vendor ZeroTurnaround. From what I can tell survey participants were self-selected – but the results underline what has been a solid trend over the last several years and I’ve seen the same in internal surveys I’ve commissioned.

Below is the 2009 / 2010 Container Popularity chart. Note the significant decline of Websphere and Weblogic and the growth in leaner, Open Source containers like JBoss, Jetty and Tomcat.

Screen shot 2011-01-03 at 10.55.01 AM.png

Glassfish bucked this trend – likely due to uncertainty about it’s future under it’s new owner Oracle. JBoss showed only a little growth – I’ll put this down to a fairly slow year in 2010. But 2011 is going to be very, very different. We already have a Java EE 6 Web Profile container (released last week) and JBoss AS 7 is taking shape pretty rapidly. With our increased attention to slimming the footprint and increasing the speed of adopting new technology and standards like Java EE 6 — my prediction is that JBoss will catch or overtake Tomcat in the next year.