Category Archives: Java

What everyone gets wrong about microservices

Martin Fowler has collected a lot of good information about microservices, but does not understand their origin as the “right size” unit of work for commodity data center infrastructure. This is apparent from his advice to start with a monolith and decompose it, as if the target deployment environment had no bearing on design.

I suppose that’s the way he and many others would naturally approach it, given the frame of reference is the traditional 3-tier application server model and the abstraction of Java from the hardware and operating system it runs on. This leads him and others to view of microservices as an evolution of development practices to facilitate rapid change, rather than a fundamental shift to design for appropriately sized units of work.

I give Martin a lot of credit for identifying and defining development best practices, including helping establish the agile method. But microservices did not originate as a development best practice in the 3-tier app server environment. Nor did it become popular because people were deconstructing monoliths. Microservices are a creature of the infrastructure they were designed for – the commodity data center.

I don’t think Martin and others viewing microservices as a development trend takes into account the strong relationship of the deployment infrastructure to the origin of the microservices design pattern. I give Martin a lot of credit for including Stephan Tiklov’s clear rebuttal to the monolith-first silliness though.

Google invented the commodity data center infrastructure about 20 years ago, and this has become the de facto infrastructure for IT since then. It is the most cost effective IT infrastructure ever built. Pretty much all Web companies use it, and most pre-Web companies are planning to adopt it. Their original servers are in the computer history museum for this reason (photos below).

Commodity data center infrastructure offers a compelling range of benefits in addition to cost-effectiveness, such as auto-scale, large data set capacity, and automatic resiliency, among others. In order to achieve those benefits, though, software has to be engineered specifically to run in this environment, which is basically where microservices come from. Some core design assumptions allow a very high tolerance for hardware and software failures, but these assumptions are very different from the assumptions on which the traditional IT infrastructure is based, and applications have to be broken into smaller units of work suitable for deployment on PCs and connected via network into larger units of work.

I can understand a view of development best practices unconnected to deployment infrastructure considerations – after all, the traditional IT industry has been on a path for years to “write once, run anywhere” and it’s easy to assume that language and operating system abstractions will take care of harware infrastructure mapping considerations.

But in the case of microservices, it is a big miss to ignore the target deployment infrastructure as the origin of the design pattern, since both the hardware and the software on which they are intended to run has such different characteristics.

Second Edition of TP Book out Today

It’s hard to believe, but the second edition of Principles of Transaction Processing is finally available. The simple table of contents is here, and the entire front section, including the dedication, contents, introduction and details of what’s changed, is here. The first chapter is available here as a free sample.

Photo of an early press run copy

Photo of an early press run copy

It definitely turned out to be a lot more work than we expected when we created the proposal for the second edition almost four years ago.  And of course we originally expected to finish the project much sooner, about two years sooner.

But the benefit of the delay is that we were able to include more new products and technologies, such as EJB3, JPA, Spring,  the .NET Framework’s WCF and system.transactions API, Spring, SOA, AJAX, REST/HTTP, and ADO.NET even though it meant a lot more writing and rewriting.

The first edition was basically organized around the three-tier TP application architecture widely adopted at the time, using TP monitor products for examples of the implementations of the principles and concepts covered in the book. Then as now, we make sure what we describe is based on practical, real-world techniques, although we do mention a few topics more of academic interest.

The value of this book is that it explains how the world’s largest TP applications work – how they use techniques such as caching, remote communications (synchronous as well as asynchronous), replication, partitioning, persistence, queuing, database recovery, ACID transactions, long running transactions, performance and scalability techniques, locking, threading, queuing, business process management, and state management to process up to tens of thousands of transactions per second with high levels of reliability and availability. We explain the techniques in detail and show how they are programmed.

These techniques are used in airline reservation systems, stock trading systems, large Web sites, and in operational computing supporting virtually every sector of the economy. We primarily use Java EE-compliant application servers and Microsoft’s .NET Framework for product and code examples, but we also cover popular persistence abstraction mechanisms, Web services and REST/HTTP based SOA, Spring,  integration with legacy TP monitors (the ones still in use), and popular TP standards.

We also took the opportunity to look forward and include a few words about the potential impact on TP applications of current trends toward cloud computing, solid state memory, streams and event processing, and the changing design assumptions in the software systems used to power large Web sites.

Personally this has been a great project to work on, despite its challenges, complexities, and pressures. It could not have been done without the really exceptional assistance from 35 reviewers who so generously contributed their expertise on a wide variety of topics. And it has been really great to work with Phil again.

Finally, the book is dedicated to Jim Gray, who was so helpful to us in the first edition, reviewed the second edition proposal, and still generally serves as an inspiration to all of us who work in the field of transaction processing.

IBM/Sun Post: I Forgot About Solaris

When I wrote about IBM’s potential interest in acquiring Sun to gain control of Java, I forgot about the Solaris factor. But this was mentioned in yesterday’s Times article about the acquisition, and I have seen it mentioned other places as well.

What I forgot about was Red Hat and Linux. IBM sells a lot of Red Hat Linux. After Red Hat acquired JBoss in 2006 they began competing with IBM’s WebSphere division, which must have put strain on their partnership around Linux. IBM started hedging its bets with Novell’s SUSE Linux, but open sourcing Solaris would give IBM its own alternative to Red Hat Linux.

Add that to the potential for gaining control of Java and you have two pretty compelling reasons for IBM to acquire Sun.  Of course there are probably any number of other factors, but these strike me as the most strategic.

Maybe IBM wants control of Java

The hot topic of debate today is the breaking news story that IBM is in talks to acquire Sun. Dana Gardner doubts this, and a bunch of myFB and Twitter friends ask the obvious questions in their status updates: Why the heck would IBM want to do this?  

I haven’t seen anyone yet bring up the Java question.  As co-chair of the OSGi EEG and formerly 9-year employee of a Java vendor, I have seen the battles between Sun and IBM over the control of the Java langauge up close.  It has never been a pretty picture.

Recently I was asked about Jonathan Schwartz’s blog entries about Sun’s future direction and corporate strategy. The content of these entries has been subject to the usual praise and criticism, but I haven’t seen anyone talk about what’s so obviously and painfully missing – at least for someone active in the Java community and trying to push the ball forward (e.g. enterprise OSGi). Where is the talk about leading the Java community? Where is the talk about collaboration with IBM, Oracle, Progress, Tibco, and others? Where is the description of how helpful Sun is toward Apache’s Java projects (especially Harmony)?

IBM has ported many products onto the OSGi framework during the past several years, including flagship products such as WebSphere Application Server and Lotus Notes. Never mind the fragmentation in the Java community caused by the disagreement over SCA.  What about Sun’s recent announcement that they were going to reinvent Java modularity in the Open JDK project, all on their own, without input, without regard to what happens to OSGi?  What kind of potential change cost does that represent to IBM and all the other Java vendors who have ported products onto OSGi?

The potential acquisition of Sun has been debated so far mostly in terms of the business value Sun has – that is, in the context of where it is still making money, as if that were the main or only reason for an acquisition. But I say again, what about the unrealized potential for collaborative leadership in the Java community? Sun obviously isn’t paying attention to this, but  IBM might be.