The Next Wave

Thursday March 30, 2006

The next wave of Software - Moore meets Metcalf meets Rock (and don't forget Gilder)

One of the discussions I've been having and ideas I've been promoting as I've traveled around doing various talks at conferences, customer site and universities (this week in Australia / New Zealand) is the notion that we are rapidly approaching an inflection point ... one that has significant repercussions for those of us building and maintaining software in the industry today.

Background

In these discussions, I've been using what were previously considered as hardware-only "laws" and applying the principles behind them to software development. As a refresher, the laws in question are the following:

• Moore's Law - an observation related to chip complexity and unit cost, the essence of which for this conversation is that the number of transistors we can cram onto a piece of silicon is roughly doubling every 24 months. Another way of looking at this is, of course, complexity

• Rock's Law - an observation on what it takes to manufacture those chips. Consider it the economic corollary to Moore's Law and it states that the cost of building those chips doubles every 4 years. As the chips become denser and more complex, the cost of building a new fab plant to manufacture them (as well as all the services including R&D around them) is going up

• Metcalf's Law - this law states that the value of a network is equal to the square of the number of nodes on the network. Simplistic example: if you have one phone, it's value is limited. Add a second (now you can call that other phone), the value of what is now a phone system goes up. Add a third (and so on), the value increases exponentially

One reason for the move towards clusters of lower-cost chips is the recognition and application of these laws as applied to hardware design and the systems built from them. From an economic sense, at some point it makes more sense to not build denser (and more costly) Big Hunks of Silicon(tm), but instead create clusters or networks of lower-cost chips which provide the same functionality but at a lower cost. Although Metcalf was really talking about networks, I believe the same applies when looking at these networks-in-the-small, that is that the value of those compute systems increase to the square of the number of nodes in that network

• Gilder's Law - this law states that bandwidth (the "size of the pipe") triples every 12 months. The implication is that connecting all those systems becomes even more possible and reasonable as the bandwidth goes up (and as a result of Metcalf's law, the value of the network goes up even further as the network can now scale to sizes unachievable before)

Hardware "laws" applied to Software

It is my belief that the principles behind the above hardware laws can be applied to software as well. For example:

• Moore (complexity) - At the coarsest level, the number of components and/or services in any given application or software system is increasing year over year (unlike hardware though it's much higher than double ... the creation and use of components and services in software is inherently easier than in hardware). For the sake of argument I'm assuming that at a minimum, that number is squared (so the number of services or components available in a given software system will exponentially increase)
• Metcalf (value) - Like hardware, the value of the application or system will increase by the square of the number of services or components in the system

• Rock (cost) - The cost of building the network of services (not the services themselves ... we have a pretty good handle on that) goes up as the scale of those service-based systems increases. Simply put, it's taking a larger effort in terms of resources and time to build, deploy and manage larger and larger scale software systems

• Gilder (bandwidth) - As the bandwidth increases, this increases the number of service connections we can allow for in our software systems thus resulting in larger (and more complex) service-based applications.

The evolution of software systems and their complexity

As the software development industry has evolved, we've gradually moved from what were mostly monolithic systems built using structured programming languages (Fortran, Cobol, etc.) to mainstream applications built from collections of objects. These object-oriented systems drove not only OO methodologies and architecture but promoted component re-use ... something which wasn't used as extensively in the Days of Structure (sounds like a movie title ... )

Beyond objects (yes, all you Smalltalk folks will bring up the fact that you were already sending messages ... no offense, but I believe we're moving beyond that here), we are now moving into service-based systems of a scale unheard of in the past. It's not so much the presence of services but rather the complexity which results from the aggregation of these services from sources which frequently exist outside the firewall rather than from within it as with most stand-alone software today. The result is an explosion of services and connections to services scattered across the globe:

So services result in a geometric change in complexity ... obviously at runtime (and there are loads of folks who are building out the enterprise infrastructure to support them) but also at development and maintenance time. Without change, the scale to which these apps can grow is limited (assuming you don't want to live with the consequences of scaling quality and risk aversion as well). Building what I like to think of these new hyper-scaled systems will require a constant evolution of not only the runtime platforms they run on, but the development tools which build and maintain them.

Another interesting analogy between H/W and S/W here is how we at Sun have looked at improving the network, computing and the data center by paying close attention to three principle areas: Availability, Reliability and Scalability. The terms are pretty self-explanatory ... for software:

• Scalability - How big can I scale my system ... and it's no longer just a monolithic application ... who remembers the below chart ? These "applications" (that term needs to be replaced ... I believe applications are now passe´ ... they are services in their own right ) will be BIG ... including everything from "standard applications" to phones, your toaster, RFID tags you name it ...

• Reliability - Can I trust the services I'm using ? Remember, you don't own them ... so the presence of Identity systems, credentials and security are crucial

• Availability - I'm building an app that is dependent upon some service coming from "somewhere" ... will it be there when I need it ? What kind of guarantee do I have that it's a service I can depend on ?

All of this is going to require a new generation of development platforms (that's runtimes and tools) than exist today ... if you look at today's tools, they are actually designed for yesterday's problems (they are designed to primarily solve the structured and object-oriented languages and applications ... we can partially manage new service-based systems with them but fairly quickly now we will exceed their capacity to deal with them).

At the high level some of the changes required to both improve the ease-of-development experience in modern applications as well as to deal with increased complexity can be captured in the following:

• Languages and platforms. Extend the capabilities of the languages and platforms such that they enable easier (and less risky) development practices. The changes made in the last few years in the Java platform are prime examples of that type of improvement. For example, the use of annotations to allow for more declarative programming as well as removing the requirement for explicit specification of complicated metadata that previously had to be hand-coded. This (obviously) simplifies development but also reduces the risk for silent errors in code that have to be dealt with upon deployment and maintenance. Similarly, other changes like the addition of enumerations and other language features to the Java language reduce risk and improve the development experience

• Deep knowledge. Use the deep knowledge available to compilation, tools and runtime environments to improve the reliability of applications running on the platforms and networks. For instance, inversion-of-control changes in Java EE 5 (by this I mean letting the container do what work it can for you so you don't have to) will greatly increase the reliability and ease the development process (look, for instance, at the advantages that a system that manages persistence for you can do)

• Adaptive environments. Different tasks require different tools. Different users are using those tools. Depending on the task or the audience (or both), the tools should adapt accordingly. The simplest example ... if I'm building a web service, why do I need the GUI design tools at my fingertips ? They clutter my desktop and detract from the user and development experience. Which leads me to the next point ...

• Abstraction. As part of adaptation, use abstractions to allow for highly effective visual and non-visual modeling and development during the process of building, deploying and maintaining services and systems of services / applications. For example, while working against the same common model (my code), I should be able to work within:

A specifications view

A graphical programming view

A pattern view

A UML view

A code view

A packaging / assembly view

A business process model view

And so on ...

The general alignment with adaptation is not only should my tool adapt to my task or type of developer/development, it should provide the optimum view of what is under development at a given time ... if it's most efficient to "code" using a UML model at a specific instance in time, do so ... if I'm modeling the process, use a business process tool ... if I need to get my hands dirty let me at the code.

• Development Process. Lastly, encompass the entire development process (not just compile-edit-debug). This means, at least in part, Application Lifecycle Management (ALM). Being able to build services and systems of services using well-established processes (and pick your methodology ... which one isn't important, only that you have one) which go from requirements, to specifications and all the way to end-of-life are crucial as the ability to deliver predictability in both the development process and the end-result is a must when systems go hyper-scaled ... the results of not building these highly-scalable, highly-reliable and highly-available software systems properly will be extraordinarily expensive to fix once deployment begins.

Next time I'll "go product" (or at least "go technology") and talk a little bit about how we (Sun) are working on the next phase of "attacking complexity" within the development platform space. I would, of course, be interested in observations, criticism and real-world stories where building to the next generation system have caused a new way of looking at the computing world. Posted by brewin Mar 30 2006, 02:04:42 AM PST Permalink