Michael Groner's Blog

Developer’s Guide to Cloud Computing

Michael — Thu, 31 Dec 2009 00:21:35 +0000

“So where do I as a developer go to learn more about cloud computing and the ecosystem of tools available to me?”

This is the question that kicked off this series of blogs. I was on a panel at CloudCamp St. Louis fielding various questions about converting applications to cloud architectures. Having helped many Appistry customers build cloud oriented solutions, I was happy to help the group get acquainted at these concepts. Unfortunately, I didn’t have a good answer for this person. With as much writing and talking as there is about cloud computing, I don’t know of any single one-stop resource to learn about the concepts and tools from a developers perspective. I’m going to try to fill that gap.

My goal is simple. I want to advance the concepts of cloud computing so that we can all take advantage of this new technology. I firmly believe that building applications to cloud principles is necessary and will become inevitable for a large category of applications. I’m going to accomplish this goal in three parts:

First, I’m going to introduce the what’s and why’s of cloud computing for the developer coming to speed on the topic.

Second, I’m going to review cloud architectures to illustrate the important application and infrastructure principles to achieve the goals listed in part one.

Third, I’m going to provide a catalog of tools and services available in the cloud computing ecosystem. There are more and more success stories of using cloud computing. I hope to include of these stories in this list.

There’s the introduction. Please make yourself heard and let me know what you think of the series. I look forward to your feedback.

MapReduce talk from Lambda Lounge Presentation

Michael — Wed, 18 Nov 2009 21:25:46 +0000

In September I presented on the foundations of MapReduce and MapReduce applications at the St. Louis Lambda Lounge.

It always surprises me how simple the MapReduce algorithm is and how few people really understand it. After the talk I had multiple people approach me and say “I have had elements of MapReduce on my applications for a long time and didn’t know it.”

Here are my slides from the talk.

VMWare + SpringSource: VMWare moves up the cloud stack

Michael — Wed, 12 Aug 2009 18:59:17 +0000

The VMWare/SpringSource acquisition announcement took me by surprise. My first question was what is VMWare getting themselves into? I have always thought of VMWare as the “Switzerland” of infrastructure tools. Whether you are Windows or Linux, C++ or Java, packaged software or open source VMWare can help you build, test, and deploy your environment. Why are they giving up their independent status by picking a Java framework like Spring?

Then I recalled the SpringSource’s acquisition of Hyperic earlier this year. Hyperic is the open source monitoring tool that watches over many different application servers, databases, and other computing utilities. Clearly, the Hyperic products are of great benefit to VMWare. VMWare suffers as their tools do not have any vision into what individual virtual machines are doing at a given moment. Their systems can tell when a single VM is running hot and attempt to move it to a different computer, but this might not help if the problem is two processes suddenly running hot on the same VM. Hyperic is full of application level performance data to help with this situation.

It isn’t necessarily the Spring framework itself that VMWare is interested in. It is the combination of the Hyperic platform layer with the VMWare infrastructure tools. The union of the two systems will allow VMWare to greatly improve system utilization by moving entire virtual machines or just individual processes around a cloud computing system with percision. This is VMWare moving into the Platform as a Service (PaaS) space of cloud computing.

But this still leaves the question of Java. Clearly attaching to Java will attack Microsoft with their .NET and virtualization efforts. However, why should VMWare pick only one language? One line from the VMWare blog clarifies this apparent limitation:

We have early efforts underway around .Net, PhP, Ruby, and J2EE, and will continue to focus on expanding these as well as newcomers in the rapidly evolving development world.

VMWare is trying to work will all technologies. They will maintain their “Switzerland” status. It will be interesting to see what acquisitions, partnerships, and announcements VMWare will come out with next. I expect there will be more to come shortly.

Which principle was it? Open-closed or dependency inversion?

Michael — Thu, 29 Jan 2009 16:43:18 +0000

In my last blog entry I discussed how Test Driven Development (TDD) lead me to a greater understanding of the Open-Closed Principle (OCP). The general feedback from the post was very positive. However, several readers asked a question that I would like to answer. They pointed out that although I was discussing OCP, my example really displayed the Dependency Inversion Principle (DIP). Was my blog post misleading?

Just to recap, here is the example I used in the previous post:

testDefault(self):
  member = Member("test member")
  membership_list = MembershipList()
  membership_list.add_member(member)
  command = GetMembershipListCommand(membership_list)
  result = command.execute()
  self.assertEqual(["test member"], result)

This is a simple test for my “GetMembershipCommand” function. When I realized that I didn’t like the coupling created between my test function and the other production classes in my project, I altered the test to this:

test Default(self):
  command = GetMembershipListCommand(DummyList())
  result = command.execute()
  self.assertEqual(["test member"], result)

The dependency inversion principle states:

High level modules should not depend upon low level modules. Both should depend upon abstractions.

In my example, I clearly used the dependency inversion principle. My GetMembershipListCommand no longer depends on the lower level Member and MembershipList classes – it only depends on the interface. But does that mean I missed the point of OCP? I don’t think so.

OCP is about the flexibility of your classes, not a specific implementation pattern. Can you construct a class for which the implementation can stay constant, even though you can extend the behavior? What might these techniques be?

Most examples I have seen focus on sub-classing the parent class and overriding methods
I claim that OCP is achieved in my example above by injecting classes with behaviors to the parent class
I have also built classes to which behaviors and extensions are passed directly as functions or command classes

No matter which of these techniques I use, I know one thing to be true: although the base class’ implementation has not changed, its behavior has been extended through these techniques.

In a recent podcast with Scott Hanselman, Robert Martin reviewed the SOLID principles. One point that Martin made is that the dependency inversion principle (DIP) is basically a restatement of OCP with “a 90 degree rotation”. OCP states the goal of not having to modify a class to extend behavior. DIP provides an implementation guideline that we should depend on abstract classes as much as possible.

I clearly used dependency injection to modify the behavior of the classes being tested. TDD showed me where I wasn’t using techniques like dependency injection to easily and thoroughly test my objects. My effort resulted in classes that satisfy the open-closed principle. It was very satisfying to see multiple principles converge on the single goal of clean code.

So what do you think? Is my definition of the open-closed principle on the mark or too liberal?

How TDD clarified the Open/Closed Principle for me

Michael — Thu, 22 Jan 2009 22:19:18 +0000

The open/closed principle (OCP) (a software concept whose definition I could recite, but whose meaning I hadn’t internalized until recently) simply states:

Software entities should be open for extension, but closed for modification.

Correct application of the open/closed principle results in classes with high reusability, as the classes are built with extension in mind. OCP also provides consistency because established classes do not change after completion. Any developer will agree that reusability is a noble goal, but how do we know when we have achieved it?

I think OCP eluded me because of the illustrations I have seen in the past. Examples focused on depending on interfaces within a given class or function instead of a concrete class. When new behavior is needed, a separate class implemented to the same interface can be substituted to extend behavior. Factually, I knew this, but I was never certain that I applied OCP well. When I reviewed my older code I often felt that my classes were too tightly bound to single classes and had little reusability. The examples provided no metric to show when I was off course.

Fortunately for me two separate events came together that helped me understand what I had been missing. First, I listened to Scott Hanselman’s podcast with Robert Martin on SOLID principles. Martin did a great job illustrating each of the SOLID principles, so they were fresh in my mind. Second, as I was working on my latest project, I became frustrated with a unit test that I was constructing.

The test itself took more effort to construct than it should have. The setup phase of the test was long and complex. The test was fragile, as it depended on other classes in my project. To keep my tests clean I realized that my class should be able to correctly function with no dependence on other classes within my project.

And that was it. That was the moment I fully understood the open/closed principle. A well designed class can be tested in isolation by injecting necessary behavior. The ability to inject behavior fulfills the “open” attribute of the open/close principle. Good unit testing practices led me to good class construction.

Let me go through a simple example test case to illustrate:

testDefault(self):
  member = Member("test member")
  membership_list = MembershipList()
  membership_list.add_member(member)
  command = GetMembershipListCommand(membership_list)
  result = command.execute()
  self.assertEqual(["test member"], result)

This code tests my GetMembershipListCommand. (This is a simple example for illustration.) This class simply returns the contents of the membership list. Notice that I had to import two data structures outside my GetMembershipListCommand class to establish the test. The setup of the test requires as many lines as the execution and validation sections of the test.

Knowing that I want my test cases to run isolated from the other classes, I constructed dummy/mock objects to provide behavior implementations to the class being tested. Converting to dummy/mock objects immediately showed me that my class was more coupled to lower-level classes than I had believed. I had to restructure my classes to meet the injected interface/behavior. Once completed, my base classes were much more cohesive and the overall set of classes become decoupled.

In the end, the update was simple. My new test case looks like this:

test Default(self):
  command = GetMembershipListCommand(DummyList())
  result = command.execute()
  self.assertEqual(["test member"], result)

Instead of being dependent on the Member and MembershipList classes, my new implementation is only dependent on the interfaces I use. I am now able to remove any imports of classes outside my GetMembershipListCommand class and verify that my code is fully decoupled from other objects.

It doesn’t look that different, but it is much more flexible:

It is now easy to create a more straightforward test case – I can build specific dummy objects to meet my needs.
My classes are fully decoupled from other classes within the project and much more reusable.
My unit tests were much easier to read.
Test failures are isolated. A bug in a dependent class will no longer create failures in higher level classes.

So I finally got it. Application of the open/closed principle was achieved when I started injecting behaviors into my test cases. My higher-level classes no longer need to know about lower-level implementation details. The only thing they need to share is a common interface. It seems so simple now, but I hadn’t seen it before. TDD showed me the way. I now recognize that if my unit tests become complicated and contrived then OCP is probably being violated.

My code is cleaner, more easily supported and more modular all because of good application of SOLID principles that were achieved through good application of TDD.

End of iteration demonstrations – The agile practice you probably aren’t practicing

Michael — Thu, 03 Jul 2008 16:30:50 +0000

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 says you need to change how you are building your applications

Michael — Fri, 27 Jun 2008 19:40:24 +0000

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.

DONE equals DONE

Michael — Wed, 23 Apr 2008 20:16:23 +0000

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.

Grids, Clouds, and Fabrics. Oh My!

Michael — Wed, 16 Apr 2008 17:29:00 +0000

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.

Smaller Releases Help Management as Well as Developers

Michael — Tue, 11 Mar 2008 21:11:32 +0000

Ron Jeffries presented at the St. Louis XP User’s group meeting back in January. As he put it, the topic of the presentation was anything that came to his mind at the moment. He simply stood at the front of a crowded room and talked while drawing on an overhead projector.

I won’t try to transcribe the entire meeting, but there was one statement that has stuck with me that I wanted to share.

“Smaller Releases Help Management”

Ron spent a lot of time on this subject. When he first said it I though “of course that is obvious”. As he continued, he brought out finer points that I hadn’t considered as much.

At the beginning of a project customers are going to ask for as much as they can get. It is a natural reaction to the belief that software is hard and releases always take longer than they should. It’s somewhat circular, but if you believe that you aren’t going to get your release for a long time, it better have everything and the kitchen sink in it.

Once a release becomes too big, everything is affected negatively. Product doesn’t get into customers hands, so no value is derived. Management gets upset because they don’t have anything to manage. Developers stress because there is so much to do and an unlikely deadline to meet. The implementation itself doesn’t get appropriate feedback and starts to wither on the vine.

Think of all the things that free up when a release is broken down:

High value stories can be put into customer’s hands earlier. It’s not everything you want in your larger release, but you can get value to your company now.
It gives your customers/product managers something to manage.
- Maybe we learn that the first or second release is sufficient and the remaining stories can be dropped for a new project.
- Maybe we learn that the effort is taking longer than expected. We can use the release we have, but set expectations accordingly.
- Maybe we learn that resources should be reallocated between releases to deal with changing priorities
Developers get constant feedback that their code is working and a sense of completion much earlier

As I said, at first blush the fact that smaller releases are better is no real surprise. The real take away is the effect of smaller releases on the management team. With more releases come more choices and more feedback. Developers always want to know their choices and feedback, don’t be surprised that your managers want them as well.

Your best technique to provide choices and feedback is a smaller release.