Words to live by

DSC00392

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.

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 ?

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.

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.

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 !

Is Java Dead Yet ?

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.

EASE INTO THE CLOUD : Red Hat Virtual Event

RH_EAP6_banner_468x60_9405757_0512_it.png

Join our online virtual event next Wednesday (June 20th) at 11am ET and hear us talk about some exciting new JBoss products – JBoss EAP 6 and JBoss Data Grid. We have separate developer and operations tracks with speakers from the product teams and customers ready to share their experience of these exciting new technologies. Sign up for free here.

The death of bloated, heavyweight, monolothic enterprise Java …

… 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).

junk in the trunkPhoto 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.

JBoss Data Grid – Making Big Data Work

Screen Shot 2012-04-13 at 10.11.51 AM.png  

This week Red Hat extended the Early Access program for JBoss Data Grid with the availability of the BETA – available to existing customer and future customers.

Traditional (typically relational) spinning-rust data stores have become one of the biggest economic and technical impediments to extracting the true value from the increasing amount of data that is available to organizations today.

JBoss Data Grid is a distributed, in-memory, fault-tollerant key-value store that is architected for large scale, mission critical applications. JBoss Data grid is built on the Infinispan open source project which is the natural evolution of JBoss Cache – which has been a core part of JBoss products for many years.

There’s a huge amount of activity around BigData and NoSQL as people look for more appropriate solutions to store, manage and analyze data – JBoss Data Grid and in-memory solutions in general provide orders-of-magnitude performance and scalability benefits without necessarily having to completely re-architect the data tier. The intrinsic distribution also provides a high-degree of fault-tollerance without the additional cost, complexity and overhead involved in traditional data stores.

So, give it a spin; and give us some feedback.