Category Archives: Software Architecture

APIs and Alan Moore Characters

It was originally intended to be a straightforward conversation about APIs, but thanks to Ian Murphy of Enterprise Times several Alan Moore characters managed to enter the discussion. Magic is certainly something we can all use in organizing our APIs and automating our processes.

Failing that, it’s important to cut ties with the past and implement best practices for an API first design approach, to ensure the APIs provide the service the consumer needs and wants. Just wrapping existing code with an API is unlikely to cut it, although this is a tempting shortcut. Generally in this area however, you get what you pay for.

It’s also a lot better to take security into account from the start, rather than having to redo things and remediate potential vulnerabilities just as you are about to deploy to production.

And it’s very intersting that we are basing our APIs on REST now – understandable, of course, but interesting that the best practices for HTTP (which embodies RESTful principles) evolved from a completely different stream of technology development than WSDL-based Web services and traditional middleware.

As unexpected as it might seem, if you think about it, Alan Moore’s dr & Quinch characters are a good fit for the kind of chaos monkey style of resiliency testing helpful to improve the stability of APIs.

And – thanks for this one Ian – who initially thought of Mina Murray as the best one to impress upon independent minded developers the need to follow a common purpose, just as she did for the League of Extraordinary Gentlemen. I’m just as sure she would be capable as I am that some API dev teams would benefit from such leadership. This is a constant challenge with dev teams, of course. Just not sure everyone really needs a vampire to lend a hand.

Anyway , it was great fun to approach the topic this way, and I hope Ian won’t mind if I mention that he told me he has actually seen one of Alan’s spoken word performances. I’m sure that was really cool, and potentially disturbing.

Now, I only wish old Moore titles would increase in value the way DC and Marvel title recently have, since he is by far the best writer in the field today. Maybe this has something to do with movies…

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.

Do You Need to Develop for the Cloud?

And other notes from last week’s IASA NE cloud computing roundtable (more about the meeting format later – also note the Web site currently does not have up to date information – we are volunteers after all ;-).

We had good attendance – I counted 26 during the session, including folks from Pegasystems, Microsoft, Lattix, Kronos, SAP, The Hartford, Juniper, Tufts, Citizens Bank, Reliable Software, Waters, and Progress Software,  among others (I am sure I missed some), providing an interesting cross-section of views.

The major points were that no one is really thinking about the cloud as a place for accessing hosted functionality, and everyone is wondering whether or not they should be thinking about developing applications specifically for the cloud.

We touched on the landscape of various cloud computing offerings, highlighting the differences among Google, SalesForce.com, Microsoft, and Amazon.com.  Cloud vendors often seem to have started with trying to sell what they already had – Google has developed an extensive (and proprietary) infrastructure for highly available and scalable computing that they offer as Google App Engine (the idea is that someone developing their own Web app can plug into the Google infrastructure and achieve immediate “web scale”).

And Salesforce.com had developed a complex database and functionality infrastructure for supporting multiple tenants for their hosted application, including their own Java-like language, which they offer to potential cloud customers as Force.com.

Microsoft’s Azure offering seems to be aiming for a sort of middle ground – MSDN for years has operated a Web site of comparable size and complexity to any of the others, but Microsoft also supplies one of the industry’s leading application development environments (the .NET Framework). The goal of Azure is to supply the services you need to develop applications that run in the cloud.

However, the people in the room seemed most interested in the idea of being able to set up internal and external clouds of generic compute capacity (like Amazon EC2) that could be related, perhaps using virtual machines, and having the “elasticity” to add and remove capacity as needed. This seemed to be the most attractive aspect of the various approaches to cloud computing out there. VMware was mentioned a few times since some of the attendees were already using VMware for internal provisioning and could easily imagine an “elastic” scenario if VMware were also available in the cloud in a way that would allow application provisioning to be seamless across internal and external hosts.

This brought the discussion back to the programming model, as in what would you have to do (if anything) to your applications to enable this kind of elasticity in depoyment?

Cloud sites offering various bits of  “functionality” typically also offer a specific programming model for that functionality (again Google App Engine and Force.com are examples, as is Microsoft’s Azure). The Microsoft folks in the room said that a future version of Azure would include the entire SQL Server, to help support the goal of reusing existing applications (which a lot of customers apparently have been asking about).

The fact that cloud computing services may constrain what an application can do, raises the question of whether we should be thinking about developing applications specifically for the cloud.

The controversy about cloud computing standards was noted, but we did not spend much time on it. The common wisdom comments were made about being too early for standards, and about the various proposals lacking major vendor backing, and we moved on.

We did spend some time talking about security, and service level agreements, and it was suggested that certain types of applications might be better suited to deployment in the cloud than others, especially as these issues get sorted out. For example, company phonebook applications don’t typically have the same availability and security requirements that a stock trading or medical records processing application might have.

Certification would be another significant sign of cloud computing maturity, meaning certification for certain of the service level agreements companies look for in  transactional applications.

And who does the data in the cloud belong to? What if the cloud is physically hosted in a different country?  Legal issues may dictate data belonging to citizens of a given country be physically stored within the geographical boundary of that country.

And what about proximity of data to its processing? Jim Gray‘s research was cited to say that it’s always cheaper to compute where the data is than to move the data around in order to process it.

Speaking of sending data around, however, what’s the real difference between moving data between the cloud and a local data center, and moving data between a company’s remote data center?

And finally, this meeting was my first experience with a fishbowl style session. We used four chairs, and it seemed to work well. This is also sometimes called the “anti-meeting” style of meeting, and seems a little like a “user-generated content” style of meeting.  No formal PPT.  At the end everyone said they had learned a lot and enjoyed the discussion. So apparently it worked!

Stay tuned for news of our next IASA NE meeting.

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.

IASA New England Meeting October 2

Sorry for getting this out a bit late, have been on the road the past couple of weeks…

I just wanted to let everyone in the Boston area know we’re having the next meeting of the IASA New England chapter next Thursday, October 2 from 5:00pm-8:00pm at the Microsoft office at 201 Jones Road, Waltham, MA 02451.

I will be talking about why interoperability is so hard, and then Brian Kelly and Yev Bronshteyn
will be giving an overview and demo of the new Artix WCF product, which provides native interoperability between WCF and Java.

Click here for an abstract of the presentation and registration information.

Hope to see you there!

Abstraction and control in REST vs RPC

One of the biggest debates in the software industry is about getting the level of abstraction right. By this I mean a level of interaction with computers higher than binary code or machine language – in other words, anything that presents humans with a more natural or intuitive abstraction of a CPU’s instruction set and binary data storage format.

Computers are after all fundamentally stupid electrical systems that have to be told exactly what to do. At the end of the day, everything is just 1s and 0s – the bit is either on or off. But it is really hard for us humans to work with computers at that level, so we keep trying to make it easier for people to tell computers what to do. Getting the abstraction right is key to developer productivity, but it’s a constant struggle. Abstraction layers typically remove flexibility and control from one level in order to simplify things at the next.

Years ago you could hear developers saying they would never use COBOL because it was much too slow and verbose compared to assembler. Yet COBOL remains a very widely used language.


It was not too long ago you heard the same complaint about relational databases – they were just too slow compared to hierarchical and network databases. And don’t forget the Web – I remember when we called it the “world wide wait” since it took so long to render a basic page.

In other words, it is sometimes more important to make it easier for people to tell computers what to do than it is to give them complete control. When we introduced high-level “English-like” language abstractions for the the Digital business software product set on VMS in the late 80s (which included an RPC in the ACMS product) we endured constant complaints from developers who wanted more flexibility and control. In those days distributed computing programmers were used to the fine-grained control over remote conversations available in the dominant LU6.2 peer-to-peer protocol.

In fact at the time most transaction processing people thought we were nuts to base a TP monitor on RPC. They thought the only way to do distributed computing was to explicitly program it. We thought it was more important to make the developer’s life easier by abstracting the distributed programming steps into what we called the Task Definition Language (TDL). You still knew you were calling a program in another process, but you didn’t have to open the channel, establish the session, format the data, check that every send that needed one had a reply, etc. (ACMS is still in production in some pretty demanding environments.)

This afternoon I finally caught up up on Steve Vinoski’s recent article and blog entries about the “evils” of RPC. If you aren’t already among those who have read them thoroughly, I’d encourage you to. Including the comments, it’s one of the best discussions of the merits and demerits of RPC and REST that I’ve ever seen. The core of his argument is that the RPC abstraction is not helpful – in fact the opposite. Explicit programming is preferable when creating distributed applications.

As someone in the middle of designing another RPC based system (Distributed OSGi), though, I’d like to weigh in with a few thoughts. 😉

As I’ve said before, the distributed OSGi design does not really represent a new distributed computing system. The goal of distributed OSGi is to standardize how existing distributed software systems work with OSGi, extending the OSGi programming model to include remote services (today the standard only describes single JVM service invocations).

Because the design center for OSGi services is the Java interface, RPC or request/response systems are a more natural fit than asynchronous messaging. In fact because we are trying to finish up our work this year 😉 we have postponed tackling the requirement for asynchronous communication systems to the next version.

Anyway, after carefully reading the article and blog entries, I believe Steve is not against RPC per se. He wants people to think before just automatically using it because it’s convenient. He wants to be sure anyone involved in building a highly scalable, highly distributed system considers the superior approaches of REST and Erlang, which were designed specifically for those kinds of applications. Absolutely no argument there. I am a big proponent of using the right tool for the right job, and RPC is not always the right tool.

In the OSGi work, we acknowledged early on in the process that transparent distribution is a myth. We recognize that constraints may be imposed upon an OSGi service when it is changed from a local service to a remote service, including data type fencing, argument passing semantics, latency characteristics, and exception handling. All of this has been the subject of lively debate, but the benefits of introducing distributed computing through configuration changes to an OSGi framework far outweigh the liabilities.

In our case, therefore, making it easier for OSGi developers to create and deploy distributed services is more important than the loss of flexibility and control available when using local services only. The biggest cost of software development is still human labor, and providing helpful abstractions, incluiding RPC, continues to be an important goal.

This isn’t to say anyone should blindly use RPC, or use RPC in place of REST where REST is more appropriate. It is simply saying that ease of use – making it easier for humans to do something like distributed computing – can sometimes be more important than technical concerns such as being too verbose or too slow.

Kicking off New England IASA

IASA.jpg

Apparently they are still working on the homepage for the New England chapter of IASA, but at least the date and agenda for the initial meeting are set (register here).

The first meeting is set for June 17th from 5-8 pm at the <a href=”Microsoft Office in Cambridge.

The topic is “Software Factories,” which is one of my favorite subjects due to its relationship to domain specific languages.

The speakers are directly involved in developing and applying concepts researched and implemented within the Microsoft Factory initiative, which should provide a very interesting, “practitioner-oriented” view.

Many of you may be familiar with the sometimes heated back and forth discussions in the blogosphere over the years around the different approaches to the problem, whether MDA. MDA/UML, or what Microsoft is doing. This is one of those “holy grails” of software, which is to improve the level of abstraction at which we humans deal with computers, improve our productivity, and help reduce the overall labor costs of software development.

The meeting starts at 5 with a reception, followed by an introduction to IASA at 6. After that John Slaby of Raytheon and Jezz Santos of Microsoft will let us know what’s going on with software factories.

I think it’s great that we’re starting a local chapter of the association of software architects, and hope to see you there!

Update 6/6, see Bob’s blog for additional details.

Definition of Software Architecture

Last week in San Francisco I had dinner with my good ol Microsoft MVP solutions architecture buddy Beth Massi and her significant other, Alan Griver. We had a great time weaving our way through the crowds at the St. Patrick’s Day block party on Front Street but we could not get close enough to the bar to get a beer and ended up at the nearby Gordon Biersch’s for dinner.
During the conversation over dinner Beth gave about the best definition of software architecture I’ve heard – I’m not sure I have the wording exactly right, but it was basically that software architecture is all about figuring out how to put together things that were never designed to work together in the first place.
Meaning things like J2EE and .NET were not designed to work together but since they are often used in the same companies, someone has to figure it out.