Michael Groner's Blog

I'm looking for two students in the St. Louis area for a part time internship here at Appistry. This position will report to me, Appistry's Chief Architect.  During the internship we will work on prototypes of distributed algorithms to use in upcoming releases of Appistry software.

Requirements:

• Currently a senior or graduate student in Computer Science or related field
• Able to work at least 15 hours a week
• Familiar with C/C++, Java
• Familiar with TCP/IP and network programming

If you are interested or have any questions about this position, please contact me at michael@appistry.com.

How often do you demonstrate your development builds to your customers during development of a release?  Unfortunately if you are like most agile teams that I encounter the answer is not very often, if ever.  If you are practicing agile software development you know about the importance of working in short increments.  But do you really extract all the value you can from your iteration?  Let me elaborate with a real life example I encountered recently.

About a month ago I traveled to a customer site to discuss EAF's future direction.  After the meetings, we headed back to the airport for the return flight.  I had been up since 4:00 A.M. and I couldn't wait to get home.  As I approached my gate, I learned that my plane had been delayed for maintenance issues.  As I had just made the travel plans several days earlier, I knew that another airline had flight back to my hometown and that I could probably get a seat on that flight.

This is where my frustration began and the inspiration for today's post. When I asked the gate attendant if the other flight had a seat available, here is what ensued:

Me: "I am pretty sure that American Flight 5455 is traveling to St. Louis in an hour.  Can I get on that flight?"

Gate Attendant: "Sure let me check my computer..." click click click click click click click click click....

Five minutes later

.... click click click click click click click click click ....

"... hmmm...  I forgot the sequence code.  Oh yeah 'next next list list'" (Don't ask me what that meant.)

....click click click click click click click click click ...

"... Why yes Mr. Groner, I can get you on that flight"

Not only was I tired and frustrated, you should have seen the impatient people behind me as they waited for my question to be answered. I kept thinking to myself... "This must be the most unfriendly user interface ever built.  Couldn't they have done something to make this smoother for the gate attendants?"

Every iteration should end with a demonstration to the customer

I'm sure that the attendant's reservation system was built years ago with non-agile methods, but just think what could have been built if a real gate attendant would have gotten a chance to see the system every two weeks as new functionality was added.  I'm sure early along the way an attendant would have said "You have got to be kidding me. I can't be typing for minutes just to get someone's flight switched.  You have to re-architect this interface."

Admittedly, my gate attendant example is a bit contrived, but the take away is the same, regular and often demonstrations from developers to the user base is an essential agile practice.

Consider the benefits:

• Obviously, the immediate user feedback it essential to agile practices.  How else are you going to course correct your development efforts from iteration to iteration if the customer doesn't have a good sense of the work product as it grows?
• During iteration planning, developers know they have to focus on complete features as they are going to have to demonstrate them in a short time.
• Customers have the pressure of clearly articulating their user stories.  It's a very easy for developers to say "so really, in two weeks what are you expecting to see this application do?" 
• In my opinion, demonstrations combat scope creep and pressure the team to get done on time.  Knowing that you will have to get up in front of your customers at an established time in the future will keep your focus on the task at hand.
• Demonstrations promote the DONE=DONE mind set.  At almost every end of iteration demonstration I go to I hear at least one user say "Can I have this build now? It is useful to me already".  It's hard to accomplish that with half completed stories.
• Finally, the demonstrations greatly improve communication paths and confidence between the business and engineering side of the house.  See my post on regular, small releases as I go into detail on this.

It's sad to me how many teams I encounter that consider themselves "agile" that don't follow through on this practice.  I find it essential and addictive.  If you don't do this in your organization try it, just once.  At the end of your next iteration plan establish a time for the demonstration with the customer.  Watch how it influences all members of the agile team.  You will be glad you did.

Microsoft TechEd 2008 was held in Orlando, Florida the week of June 2nd.  I was fortunate to attend many of the technical sessions.  I was surprised how many speakers were conveying the same message: 

CPU speeds are topping out.  If you want your applications to run faster and better you are going to have to build your applications in a new way.  The solution isn't just to learn how to multi-thread your applications.  The solution lies in building your applications into smaller units of code called tasks that can be moved around to the different cores of a multi-core machine.

Even in Bill Gates' keynote speech he said

The... "need to take programs and break them down into parallel execution units now becomes absolutely necessary."

This statement was music to my ears.  Why?  It is the same model that we have been using for fabric computing since our beginnings in 2001.  Now we are starting to see this message more and more as cloud computing is gaining acceptance.  It's interesting that Appistry and Microsoft were driven to the same place for different reasons.   As I said, Microsoft's motivation is speed.  Developers have relied on faster and faster machines to accomplish more and more ambitious software projects.  Relying on faster machines to accomplish your goals is a thing of the past.  Only by decomposing problems and executing them in parallel will one gain application speed ups in the future.

When we at Appistry starting building EAF our motivation wasn't just application speed,  but also scale and reliability.  We were determined to build a framework that you could depend upon.  We advocate building your applications into smaller execution units (which coincidentally we also call tasks) and adding declarative information about how these tasks aggregate into your application.  With this information the a framework is able to make a decision on the best configuration and execution of your application across machines.  Whether it is a single dual core machine fabric or 500+ cores distributed around a data center, the framework is able to manage your system because it is written out of loosely coupled, well defined tasks.

A Challenge

So, here is my challenge to you as a developer.  Think about your most recently developed application.  Think about the code you wrote for your business logic and the code you wrote to handle the sequencing, threading, scaling, and reliability. Now, can you identify those business logic components and consider running them each, as logical standalone tasks, in a distributed framework?

Once you can accomplish that goal, you are on your way to building the "right" code for the future.  Applications that can be run on one core or many cores.  Applications that can scale to many machines with just simple configuration changes.  It's what we at Appistry have been advocating for some time, and now Microsoft is too. 

As I said in a previous post, I had the pleasure of attending a presentation by Ron Jeffries at the St. Louis XP User's group meeting back in January.  Another portion of his talk that really hit me was on the subject of "done equals done."

"Done equals done" is another way to reference the XP practice that an iteration should result in releasable bits. Of all the items Ron talked about, this is the one topic that I have always felt challenged by.

Here at Appistry we tackle very difficult problems. We often experiment. We often make interface changes at the end of an iteration to provide the best solution to the user. Typically this has resulted in documentation and QA lagging an iteration or so behind main development efforts. Our end of iteration build will pass build, unit, and integration tests but will usually not be run through our full QA suite. Ron says we have been doing this wrong.

Consider the impact of mandating "done equals done" within your development team:

• QA and documentation will never come to development in the course of an iteration to ask how something from last iteration worked.  This keeps the focus of the whole team on the current stories.
• Development/QA will no longer have to guess that a 4 to 6 week QA cycle at the end of implementation will be enough and cross our fingers that we aren't going to go long.
• Management gets to decide when we are going to publicly release the build because there is always build ready to go.  (See my previous post on smaller releases help management.)

Developers will have to change our level of commitment during iteration planning. We aren't just building our stories, we are making sure we are really, truly done. Clearly we won't complete as many stories within a single iteration, but we are just fooling ourselves that we are saving time. We incur a time penalty with the context switch of completing docs and QA tests during subsequent iterations.

If there was one action item I set for myself after the meeting it was to incorporate this practice to our normal methodologies.  I strongly suggest that you consider applying "done equals done" to your practices as well.

Lately when I talk to architects and administrators about the Appistry fabric, I often hear the same question: "Is your fabric the same thing as a grid or cloud?"

The confusion is understandable.  We software types can't construct a good naming convention without someone else trying to overload them.  In this post I am going to provide my best definitions of the phrases cloud, grid, and fabric.  Each are valuable tools, but with different meanings and usage patterns.

Cloud computing

Cloud computing is the newest term on the block.  We often hear of clouds available at Google, Amazon, or IBM, but what is it?

A cloud is simply a collection of computational and storage resources which can be dynamically allocated and made available for use on demand.

That's it.  There's not much more to it. 

Given the interest in virtualization efforts, it shouldn't be surprising that organizations are assembling large numbers of machines to be dynamically allocated.  The cloud isn't the software that is your application, but it could be your system's computational foundation. 

The most visible cloud out there is Amazon's EC2.  With an EC2 account, you can rent machine time to your needs.  This makes EC2 very interesting to organizations looking to reduce hardware and operations cost. 

However, clouds have their drawbacks.  As the cloud resources are dynamic, your system configuration will need to be able to handle changing situations.  For example, in some cloud implementations the IP address you have today may not be the same as the IP address you get tomorrow.  Additional effort is needed to tie your overall system together and make sure that it stays together.

Grid computing

Grids have been around since the late 90's.  The first time I encountered the term was in reference to the Globus toolkit. 

A grid is collection of confederated machines providing directory services, security, auditing, and remote execution.

In its early stages the purpose of the grid was to share access to large computers.  Universities might have a large system that sat idle some of the time but overtaxed at other times.  By joining the grid, a university could trade access to their machine when it was idle for access to another institution's machine when they needed more than one. 

One well known grid system is the SETI@home project.  Most of us have seen machines running the SETI@home screen saver as the desktop computer searched radio telescope data for extraterrestrial intelligence.  Each of the desktop machines became a participant in the SETI@home grid. 

In time, the concept of grid evolved past cross-institution boundaries and into the data center.  An organization might put together many machines into their own grid.  The grid infrastructure creates a directory of machines and available resources.  These systems provide an application developer with a tool to partition out segments of processing.  These jobs can get allocated, scheduled, and submitted to the grid for processing.

A challenge of traditional grid computing originates from its roots of tying together independent machines.  Elaborate work must be done to create islands of responsibility within the grid.  Some grid machines are responsible for creating the central registry of machines and resources while others are machines doing processing work.  Grid administrators have the responsibility of making the appropriate connection and keeping the individual grid components running.  A traditional grid can be a difficult tool to install and maintain.

Fabrics

When we at Appistry started referencing our product as a fabric, one goal was to abstract away the complexity of building traditional grid systems. 

Fabrics are a grid-based software infrastructure enabling virtualization of application services with reliable execution and simplified operation across any number of computational resources. 

One characteristic of fabric systems is that they will appear as a single computational resource independent to the number of machines that actually participate in the fabric.  We wanted to refer to the application and its distributed infrastructure as a single entity you can depend upon.   All of the plumbing to tie together the fabric is "under the covers" and made simple for developers and administrators.

Fabrics are enhancements over traditional grids with their simplicity and reliability.   The fabric administrator doesn't have to partition and manage separate traditional grid-level software services such as directory services and computational nodes.  The user doesn't have to discover or schedule work to individual machines.  When hardware failures occur, the fabric handles the error mechanisms so that the user is unaware that a failure even occurred.  Fabrics are well suited for either SOA style request/response applications as well as large scale HPC applications, where as traditional grid systems are often best suited for HPC style applications.

Fabrics can have cost/performance advantages as well.  Fabrics are typically built from commodity hardware as failures are handled automatically by the fabric.  These attributes reduce hardware and operational costs.  We have customers using 100+ worker fabrics managed by less than one person.

Putting It All together

So the question becomes, can we put these systems together?  The answer is a resounding yes.  Once you understand the strengths and weakness of each approach, you can see how clouds, grids, and fabrics can work together.

For example, we at Appistry are seeing more and more organizations try to take advantage of cloud computing concepts.  These groups are "renting" clouds from groups like Amazon or building their own clouds to dynamically allocate within their organizations. Cloud administrators rapidly find that their cloud solutions are not sufficient.  They need a fabric infrastructure to facilitate the scale, reliability, and management needs of the overall system. 

In Conclusion

I hesitated to put this post together.  Surely, as soon as I hit "post" another use of the terms cloud, grid, and fabric will be thrown into the community.  However, when trying to build distributed systems, it is good to understand what each of these solutions brings to the developers and administrators.