Adding Simplicity - An Engineering Mantra

Compute Power, Is Your Architecture Green?

In a recent article, Mahope addresses the issue of how software efficiency is impacting data center planning. This article rang particularly true for me as I've recently been pushing the concept of optimizing TPS/watt. As the article states, data centers are becoming constrained by power. (Technically power and cooling, but reduce your power consumption, you reduce your cooling problem so I focus on power).

How big is the power problem? Well, it's big enough that vendors are starting to market their energy efficiency as a feature. It's also big enough that a new law has been passed, mandating the EPA to study power consumption in data centers (government and private) in the United States. I'll skip the comments about how that will help, but needless to say, if it made the Congressional docket, there must be something to it.

What should we be doing in our software architecture to improve this? There are some concrete steps that I have started taking and hopefully other architects will join me.

Measure transactions/watt. This is a new metric for me. But if you don't measure it, you can't improve it. SPEC has formed a power and performance committee which will be useful for an initial calibration of vendor equipment, but ultimately the transactions you need to optimize are yours. It may be hard to initially set targets for transactions/watt but measuring and monitoring the metric will certainly lead to better awareness of how the application is doing over time.

Drive up server utilization. Large deployments tend towards specialization of servers to ease with management and to segment availability. This leads to situations where server utilization is incredibly low. It's not unusual to see server pools be created to provide isolation of new service. The initial traffic volume will use 50% of one server. Availability design requires three servers to meet SLA. So you now have 3 servers running at 17% utilization, essentially wasting 83% of their watts. There is an opportunity to leverage virtualization to provide logical isolation while driving utilization higher. Alternately, M+N fail over solutions where the fail over nodes are shared across many primaries can also help.

Use deployment patterns. Standardizing the patterns you use for software deployment improves the possibility of sharing hardware amongst multiple services. Design patterns so services can be safely share one server and require components to conform to the deployment pattern.

Optimize, optimize, optimize. There are always diminishing returns for optimizing but I believe the trend for the last several years has fallen way short of those inflection points. I won't be so bold as to declare a savings that can be realized but with the millions of dollars that companies face to solve their power crisis, I will say that I'm sure that a year of runway exists just through improving software efficiency.

As software architects, power consumption is now squarely in our camp to manage. There is plenty we can do to improve the quantity of power our data centers consume. But this has to become a clear focus for 2007 and forward. This is not just a hardware problem any longer.

Technorati Tags: architecture, engineering, http, java, performance, programming, scalability, services, soa, software, to_read, toread, uddi, web

A Real eBay Architect Analyzes Part 3

In his ongoing interview, Duncan Cragg addresses business functions in Part 3. I have been stepping in for my imaginary friend but in this installment, I am going to switch to a different format. Rather than try to answer the questions directly, I will address specific aspects of the interview that I think are ripe for discussion.

Let me start out by stating in general, I believe either the declarative or imperative model can be applied. eBay is looking at both because there is merit to both approaches. My issues instead are with claims that I believe are overstating the benefits of REST. Duncan makes assertions about common content types in a couple of places. The two quotes that I'll call are:

We can read data at a URI with GET. We will usually understand that data when we get it, because it has a standard content type at a number of layers - perhaps from character set up to Microformat via XML and XHTML.

and

There's also the expectation of standard Content-Types, sub-types and schemas in GET and POST, rather than custom eBay WSDLs and schemas, that I mentioned before.

I've been on record for a while now with the assertion that as you move from common concepts like media or messages the availability of common formats will decrease. Duncan's example cite the resources User, Item, Offer, and Feedback. I might expect to find a common type for User. Item and Offer are unique to auctions (they differ from product and sale). While Feedback might exist in other systems, the semantics vary in each of those systems so expecting to find a common schema is a bit of a reach. I certainly wouldn't preclude eBay and the other auction sites working on a widely used format to represent an auction (which is not a product, so those formats don't work) but there isn't any current activity in that area.

A concrete example of my point is the current state of maps. There are at least two popular map interfaces that are completely incompatible. My assertion is that vendors will invent formats to serve their needs which causes divergence as you move away from common media. Roy Fielding has argued that consumers will drive the vendors back to standards but I'm not sure I agree. Video is arguably a common media type with high consumer demand. Yet the pressure from consumers has been on clients to support the dozen or so video formats, not on the content producers to standardize.

Another point that Duncan continues to make is that REST offers better scalability than SOAP. From the article:

It's scalable because of all the reasons I mentioned before: the cacheability of the basic data operations and their parallelisability through partitioning.

Plus now we have parallelisability of the application of the business rules. There's nothing more parallelisable than a declarative system.

I don't believe claims of improved parallelism following declarative vs process oriented interactions. Partitioning is about how you architect your implementation not inherent in the interaction style. We have created a massively parallel system that implements SOAP interfaces and has the ability to scale horizontally to incredible levels of parallelism.

As a counter example, state style interactions can actually lead to lower levels of efficiency in the implementation. When a client makes an imperative statement like CompleteSale, we are completely clear on the intent of the operation. We can immediately go to work on the processing and manage it as efficiently as possible. But if the client passes back an Item (which consists of over 200 state elements) with some state changed, the first task we have to perform is determining the state transition. This will involve retrieving the item and potentially other state in the system. All of this is a precursor necessary to determine intent. This certainly increases the resource requirements.

We need to partition along functional as well as data lines. We have separate functional pools for revising an item and finalizing a sale due to the different load characteristics. Since I can't efficiently deduce intent from the REST POST I have a new challenge of how to partition my functionality. So, you can see that eliminating a clear statement of intent from the information passed by the client, makes it more challenging to partition my architecture.

As always, I'm looking forward to part 4!

Technorati Tags: architecture, asynchronous, atom, ebay, engineering, events, http, programming, protocol, rest, services, soa, software, to_read, toread, web

WSDL - Why Services Don't Launch

Last week was enlightening. I'm working on a project that is providing a set of services for internal consumption. The interface is actually pretty simple. We have four entities, CRUD on 3 of the entities and two operations on the fourth. Conceptually the interface can be described in five minutes. It can be expressed rigorously in any OOP language in about an hour. (The service implementation is considerably more complex, but the interface is relatively straightforward).

We opted to implement the services using SOAP. Enter WSDL. The conceptual interface was translated into WSDL which took more than a day. Once the WSDL was finally validating, we were able to generate code in Axis. Then we moved on to C# and GSOAP. Neither of them would work without further modifications to the WSDL. Another day lost on compatibility. Once the servers were deployed, we ran into issues where GSOAP generated code that compiled but didn't work. There were name space challenges. What took the engineers an hour to express in Java was taking days to express in WSDL. And I want to reiterate that this is a relatively simple interface.

Why didn't we just write the interface in Java and use java2wsdl to generate the WSDL then? Well, one reason is that the services have to be split for security reasons which leads to different ports in WSDL terms. Auto-generated WSDL would not have captured the common types with the appropriate file structures. And philosophically, if WSDL is my implementation neutral interface definition language, then it seems I should be writing it, not generating it from a specific implementation of the interface. Finally, from a stylistic point of view, I'm still waiting on the code generation process that makes files that are easy to read and understand by humans.

As long as we're on the subject of human readability, WSDL fails miserably at this quality. It is similar to reading XML schemas, only harder. Some of you may decide at this point that I'm not much of a software engineer if I find XSD and WSDL difficult to read, and so be it. But I can read a DTD and RELAX NG specifications with ease. I would expect any specification that purports to be a mechanism to allow developers to communicate interface semantics to be clearly understood by developers and not force them to rely upon tools to translate into languages they know.

"So what", some will argue. WSDL is about allowing tools to generate interfaces and is not intended for human consumption anyway. I'll argue that it lacks sufficient constraints to allow that to work well either. What does a java.util.Date map into in C++? What does an unsigned long long map into in Java? The entire XSD type space is available in WSDL which leaves the door open for developers to create unusable interfaces, especially if these interfaces were code generated from an implementation interface.

Yes, I am a heretic. I dare to boldly state that WSDL is an impediment to building services. I'm sure the intentions were good and honorable but the result misses the mark. There is a next generation WSDL in the works but it doesn't appear the primary goal is to improve either of these issues. If anything, I am concerned that 2.0 will get further from human readability than 1.1.

What is the answer? I don't think the answer is to abandon the concept of specifying interfaces. Quite the contrary, I am a big fan of having a way to express the semantics of interfaces in a way that is better defined than natural languages. The specification should support more than just SOAP interactions though. Ideally, I would like an IDL that could accomplish the following goals.

• Provide syntax and semantics that are more readily understood by developers. I think XML is a reasonable tool for such an IDL but the focus should be on readability. Think RELAX NG vs XSD and you have the idea.
• Support a variety of interactions. SOAP has WSDL although there is no reason a new IDL couldn't easily express SOAP interactions. It should also be possible to describe REST interactions with this IDL.
• Provide more control over the transport binding. The primary transport in use today is HTTP. My IDL would allow me to leverage all HTTP operations, specify headers that are meaningful as well as the content-type of the body. This would allow operations that supported any of the available media types to be expressed. Other transports could be supported but in each case, the binding semantics need to leverage the full richness of the transport.
• Don't preclude code generation. There is nothing wrong with code generation, I just feel that it should go from the IDL to the implementation and not vice versa. Partial code generation should also be supported, say for example just type handling.

I have spent the past few weeks thinking about how such an IDL might look. I've also struggled with questions of usefulness and adoption. I'm certain that having nothing is the wrong answer and my experience to date with WSDL tells me it is a suboptimal solution.

What do you think? Leave your comments or trackbacks and let me know.

Technorati Tags: architecture, engineering, http, java, programming, wsdl, rest, scalability, services, soa, software, to_read, toread, web