UP3 take 3

I pre-paid for the much anticipated UP3 band in December 2014, was dissapointed with the release delay 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 XX months, more so  when the second band failed for exactly the same reason after just XX months; as did my Wife’s first band after XX months. After all this I decided enough was enough – 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 XX day and all they could do was send me a replacement.

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

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 (I suspect practice has made them good at this).

Come on Jawbone – you can do better than this – redesign the band casing / battery, make it waterproof as you orginally claimed and give your loyal but possible reluctant customers and free / cheap upgrade. 

Red Hat a leader in In Memory Data Grids (IMDGs)

Fast on the heels of the Forrester Report on Mobile Infrastructure Services where Red Hat’s Mobile Platform was positioned as a leader,  this week Forrester released a new report for In Memory Data Grids and again Red Hat is positioned as a leader.

As they say in the report “There Is No Better Way To Achieve Blazing Fast Performance At Scale” – something I’ve been saying since we released the first version of JBoss Data Grid a couple of years ago. Another way to think about this is that there’s no better way to ruin a perfectly decent user experience that having slow, un-responsive applications. In memory data grids offer a quick solution to this without the cost and risk of major application re-architecture.

As with all Red Hat products, Red Hat JBoss Data Grid is pure Open Source and is based on the upstream Infinispan project.

More information on Red Hat JBoss Data Grid here.

Red Hat a leader in Mobile Infrastructure Services

When we made the decision to acquire FeedHenry last fall (almost a year to the day) – we wanted to be sure we were getting behind the future generation of mobile platforms and not trying to compete in the past. FeedHenry’s cloud-native mobile platform is focussed on developing and deploying the back-end (wiring data-sources and services) while keeping the front-end app. development open to customer choice. It’s also a first for Red Hat for a product line supporting node.js as the runtime for developing application logic. JavaScript on the front-end and the back-end is pretty powerful and a mobile platform that doesn’t support that would be pretty limiting today.

More validation of our choice comes in the form of Forrester’s recent report – “Mobile Infrastructure
Services, Q3 2015″ – diagram shown below.

Forrester’s research uncovered a market in which AnyPresence, Kony, and Red Hat lead the pack. Appcelerator, Kinvey, IBM, Microsoft, Oracle, and SAP offer competitive options. MobileSmith is a market Challenger.

The Forrester Wave™: Mobile Infrastructure Services Q3 2015

Now that FeedHenry is part of Red Hat and the integration with Red Hat’s broader cloud and middleware portfolio is progressing that Red Hat Mobile Application Platform’s market presence will improve considerably and Red Hat will advance further up and to the right .

Red Hat has moved into this market through acquisition of FeedHenry, and is quickly moving to connect its backend-as-a-service offerings to Red Hat’s own extensive set of integration tooling, JBoss Fuse.

Congratulations to the Red Hat Mobile team – this is a great way to celebrate the first anniversary !

DevOpsDays DC 2015

Making the most of the calm before the storm that is Red Hat Summit, I raced up to Alexandria, VA for a few days to attend DevOpsDays DC 2015, hosted at the pretty stunning USPTO offices. I heard from the organizers they reached capacity 400+ and sold out within a few days.


Interesting mix of neck beards and suits. And there were some very senior suits – eg. Mark Schwarz (CIO of USCIS) – he had a keynote but sat through pretty much *every* talk over the two days – he clearly thought that was a good investment. and I’m sure he’s a very busy guy. Very unscientific poll – 2/3rds of the people I spoke with were Ops (not Dev background) and about 50% were public sector (vs private).

The Public Sector companies / individuals who spoke at the show (or who I spoke with) were all bought into agile and DevOps (self selected group I guess) – huge possible gains for organizations working with / for the Gov. – huge challenges as well. On taht note, I recently came across this Wired article that provides some good insight into how Public Sector IT is changing.

Red Hat was probably the biggest company sponsoring – others were Ansible, Chef, Elastic, Puppet, Sonatype and a bunch of smaller companies (mostly public sector tech consulting)

Aside from Shawn Wells (Red Hat) co-preso. on OpenSCAP, the best talk was Joshua Corman (CTO at Sonatype) “Continuous Acceleration with a Software Supply Chain Approach”

tl;dr – open source usage is booming, becoming a higher priority target for hackers so more high severity CVEs than ever. Projects are often slow to react and release fixes, vendors are even slower and customers are even slower. Basically we’re all doing a bad job. Treat the software supply chain like Toyota do – fewer, better managed suppliers, higher velocity delivery pipeline (ie. DevOps). Ergo – use Maven to at least understand your dependencies.

Second best talk – Ken Johnson and Chris Gates “Devoops and how I hacked you”. tl;dr – don’t download and run random stuff from the internet unless you expect to get seriously pwned. Ran through popular OSS tools and outlined the most common exploits – pretty eye opening. You could have heard a pin drop if it weren’t for the noise of people txting their colleagues to check wether  X, Y and Z were patched and updated. Basic stuff – default , unencrypted passwords. Old versions with known, well advertised but fixed exploits. Adopt devops so it doesn’t have to take 6 months to roll out a new (secure) version of Jenkins, WordPress, Drupal, etc.

Schedule : http://devopsdaysdc2015.busyconf.com/schedule

Recordings : DevOps Day 2015 on Livestream

Breakouts :

I joined a couple of the Open Space breakouts but was more interested in seeing what was popular. Here are the top four :

  1. Docker overview – 50ppl – poll – who’s using in prod – just 2 – it was actually only 1 – the other was a pre launch startup
  2. CI / CD – 100% about Jenkins. Most of the questions about scaling and performance or resilience.
  3. Secure automation
  4. Burnout and suicide prevention (sadly)

All in a all a good value show – will definitely make the time next year – though I suspect they’ll need a bigger venue.



Words to live by


Seen on a recent Reddit : Choose three hobbies :

  1. to pay the bills
  2. to keep you healthy
  3. to encourage your creativity

For me that would be software – though still looking for that pre-IPO opportunity so I can do more of 2 & 3; running / cycling (used to be soccer); and making / fixing stuff – more than happy to DIY vs. pay someone.

I’d add – it’s important to find the balance once you found your three things.

Photo is team Sharples – probably around 2001, Santa Cruz / Big Basin or thereabouts.

Net Neutrality

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.


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 ?

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.xReactiveXNetflix 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.


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.

Further Reading 

“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

Still here

OK, spent a few hours yesterday importing some older posts from a backup – so (modulo a few images) I have all my posts since 2008. I also re-registered my softwhere.org domain and attempted to set some mappings in WordPress – if you’re reading this then it’s probably worked. I’ve forgotten a lot of the DNS basics so still need to do some research getting a sub-domain (blog.softwhere.org) to map to this blog.

I realize blogging about blogging is pretty sad and I will start posting some more interesting content here real soon – I’ve just got to iron the last few issues.

I’m Back

After a blogging hiatus – I thought I’d give blogging another try. Rather conveniently – I found this old WordPress blog still active so I’ll continue here. FWIW – between this blog and now – I did have an another hosted WordPress blog but let the domain expire last year due to inactivity. As part of the refresh on this site – I’m going to try and recover some of the posts.

I’ll use this blog to share my thoughts on some of the trends, issues and emerging technology that is impacting the tech. industry.

Fear Uncertainty and Cluelessness

I’m generally impressed with the quality of our competitors FUD and anti-JBoss marketing. Our competitors may not be super-smart but they generally make up for it in raw man-power (or girl power) and can usually produce reasonably well researched; well articulated arguments. But this latest piece from Oracle is way, way below their usual standards. It contains a multitude of blatantly incorrect statements – most seemingly not through malice but more likely through pure ignorance and laziness.

The only conclusion I was able to draw from the blog post (and it’s not easy to draw any conculsion) is that Oracle answer to pretty much anything is “we can make anything better with Engineered Systems”. If that’s Oracle strategy then they probably need to salvage the hardware business they’ve managed to run into the ground.

By and large, the blog post is of such poor quality that it barely deserves a response but Shane produced one anyway – I guess it presents such an easy opportunity to make Oracle look clueless.

Come on Oracle – get your act together !