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.

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.

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 :

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.

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.

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.

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.

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.

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.

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

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.

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.

The Product Manager, JBoss User Experience (UXP) and Mobile Platforms Group is looking for a Product Manager, to be responsible for the overall product life cycle of Red Hat’s User Experience Platforms including Mobile and Portal. The Product Manager will be responsible for determining the market requirements for a successful product and driving the overall product strategy. This Product Manager will also work closely with the product development and engineering teams to determine product priorities and plan product releases and determine the product roadmap.

JBoss Enterprise Application Platform is the market leading platform for innovative and scalable Java applications. Integrated, simplified, and delivered by the leader in enterprise open source software. Responsible for the overall product life cycle of Red Hat’s application platform products marketed under the JBoss brand name. Responsible for determining the market and technical requirements for a successful product and driving the overall product strategy. Will work closely with product development to determine product priorities and plan product releases and determine the product roadmap.

The Sr. Product Manager will be responsible for the overall product life cycle of Red Hat’s JBoss Enterprise SOA platform, Enterprise Service Bus, BPEL engine, related tooling and integration with related technologies. The individual will be responsible for determining the market requirements for a successful product and driving the overall product strategy. This person will work closely with product development and engineering to determine product priorities and plan product releases and determine the product road map.