Modeling Failure Scenarios

The inter-connectivity of the web as a hyper-linked pool of resources is spreading to applications as services are becoming more and more dependent on each other.

This new trend is requiring the architects to think more thoroughly about the fragility of the systems they design. My latest paper that was published on InfoQ deals with modeling the failures of dependent services upfront in the design phase/ This exercise lets the architects model and help implement systems that can deal with failure in a predictable manner.

Here is an excerpt from the paper

The increase in number of integrated systems in today’s enterprise solutions necessitates dealing with dependency and environment failures in a systematic way. By modeling dependency failures at the architecture stage, system response to failures can be communicated, tested and implemented reducing the business risk and cost.

In this paper, we will introduce system failure modeling. System failure modeling is a technique that helps anticipate dependency and environment failures and take pro-active action in the early architecture stage of a solution.

We will use a four step process to build failure models. Each step will gradually uncover the necessary information to create the failure models. At the end of the paper we will explore different tools and patterns available to architects that enable design and implementation of desired system responses to different failure modes.

You can click here to read the rest of the paper.

New Perspective

I was at QCon in San Francisco (qconsf.com) lats month a couple months ago. Coming from a Microsoft infused environment and lately being involved in Java world, it was a great experience. Seeing the open-source view of the software world was a real eye opener. I am not really at a point where I can say one view is better than the other, but there are quite a bit of differences in how software is designed and developed.

While I was there I had a couple of observations.

1. Java as a platform

I was part of a few discussions where there was growing distrust in Oracle in terms of keeping Java up to date and supplying the fresh features to the Java software community. There is a clear trend of creating specialized languages to solve certain problems on the Java stack. JRuby and Scala are two that are the two that come to mind right away but I think there will be quite a number of them in the coming years.

This may go many different ways but realistically I think this trend will follow and reach almost a biforcation at the JVM itself. I would not be surprised to see specialized implementations of the JVM in the coming years. Which begs the question, can the fragmentation of the JVM resemble the Linux distributions?

Frankly, I hope this does not become true as it would create yet another management nightmare for IT folks all around the world.

PS: Seeing that Oracle has been checking in some code that deals with commercial JVMs only strengthens the argument above.

2. Polyglot Programmers are increasing in number

The number of tools at the disposal of software architects are increasing in number. From NoSQL solutions to programming languages, there are a plethora of choices out there. This is especially true in the non Microsoft world (where most tooling and platforms are provided by Microsoft with some open-source library/framework that has been recently picking up).

This movement creates specialization opportunities for programmers. You can now be a Clojure guru or a memcached expert and create the best looking cocktail of technologies for the project at hand. The long term impact of this movement may have an impact on the average team size that is needed to support an operation. Although not a big concern for start ups, I think enterprises will be vary of this as it will require a larger number of people on staff to support these non-uniform solutions.

3. Agility is propagating

A couple of years ago, agile development was the buzz word. Although certain organizations and people confused it for doing a haphazard sloppy job, certain companies got it right. Now the trend is to move agility from just software creation to product creation, and in some cases organization management. More and more product companies are implementing agile in all aspects of their operations not just producing code. This is going to re-shape employee expectations in the coming years.

 

Developer Hero Profile Published

I have been playing around with the Windows Phone 7 platform for a while now. It is a good platform to quickly create applications using the day-to-day language/IDE and get something fun out there.

At this point I have quite a number of applications published in the Marketplace. Microsoft has taken some interest in some of them and has selected me for their Developer Hero Program.

Here is a link to the article with some background on how I came up with the ideas for the apps. Check it out.

My Mobile Development Experience on iOS, Android and Windows Phone 7

My mobile development itch started as soon as the iPhone came out. I just wanted to create some quick apps/games as a hobby. Over the course of next couple of years I developed on the iOS/Android and WP7 with different experiences/features/limitations. Below I summarize my personal experience in different platforms.

Full Disclaimer: I am not developing primarily for monetary purposes, since this is a side project it needs to be fun for me and I have been using .NET since the first beta.

iOS Development with Objective-C ~ circa 2009

Although architectural approach looked perfect on paper (use of MVC, clear separation of different responsibilities), the development experience with IDE and the language was a while different story. Simple things such as creating properties would require 3 disconnected steps, the libraries were a left-over from the Next Systems (NS-prefix on everything) and frankly for someone with Java/C# experience on a day to day basis it felt like I was going back in time to develop on a device. Long story short, I was not having enough fun to develop on the iOS to make it a hobby. I suppose since I was not quite interested in the monetary rewards that comes with iOS development, I lost interest and stopped altogether.

iOS Development with Titanium ~ circa 2009/10

Then I used Titanium to see if it was possible to come up with a simple application using JavaScript for behavior and a JS like layout language. Yes, it was possible and it was pretty quick too. I actuallly published one application. However, since Titanium was an abstraction on top of the native API, certain lower level things were not quite accessible. It remains a viable option to create a form over data type of  application within a couple hours, but for games and more complex applications it was not really a good candidate in my opinion.

Andoid Development with Titanium ~ circa 2009/10

While I was at it, I figured it would be interesting to see if the same code-base I used for iOS using Titanium would compile and run on Android. Unfortunately the experience was not that great. Credit to Titanium folks who really try hard to create a consistent cross-platform compatible API and I admit that it is a very hard problem get 100% right and make everyone happy. 
Although 80% of the code-base just worked fine, certain things kept just crashing and I was not too keen on isolating every single issue and then forking the code, so I stopped there.
Android Development with Java ~ circa 2010
After the not so successful try with Titanium on Android, I went ahead and started looking into Android SDK. Farnkly, I love the architecture. It is well thought and makes complete sense to any programmer who looks at it for the first time (unlike the iPhone SDK). I created a couple of prototypes and deployed onto the emulator everything worked fine and I was happy. Since I did not have an Android device at that time, I did not test on the device. The only thing that I did not like about this was how slow the Simulator was and each compile/deploy took forever on a reasonably good machine (dual-core, 4GB ram etc).

 

Windows Phone Development with Silverlight: ~ 2010


When they announced Windows Phone 7 SDK beta prior to the device launch, I did not pay much attention to it. Then one day, I realized it was using Silverlight. Since I had used Silverlight on a couple of projects I had a good idea on how to get started on it. I downloaded the SDK and within 6 hours I had ported the game done in Titanium over the course of 2 weeks. I have to admit that C# and Silverlight with Visual Studio are my comfort zone. That probably has much to do with the fact that it took so little time.

One thing that was not too exciting on the Windows platform was that it is way too simple to get started and create the apps just like the VB6 days. Stuff everything into the UI control handlers and let the code execute in the UI thread and eventually lock the thread by doing web-bound I/O.  Hopefully, certain frameworks that are available out there will emerge and somewhat force developers to use the MVVM pattern when developing apps on the WP7.
As per gaming experience, I certainly love the XNA model. It was my first introduction to XNA with WP7 and it is very simple to grasp and run with. I definitely recommend looking into WP7 with XNA to all developers who are trying to get into game development.

Conclusion


In my experience, working with iOS using the intermediary language/platform such as Titanium was a good enough way to create some line of business apps or simple things. Android has a great SDK but really suffers from JDS (Java Development Syndrome) on the windows stack – hopefully Linux environments are faster/more stable, and Windows Phone 7 development is the easiest for existing .NET developers, has great IDE/environment support.
I am really hoping to use MonoTouch and MonoDroid in the next couple of months to see if cross-compilation/execution of mobile apps is possible with C# or will people have to wait for HTML5 to be available on all platforms.

Moving away from GoDaddy

I had been using GoDaddy’s domain registration services for a long time (this domain is also being served by them) despite their tacky commercials and confusing UI. I always found the hassle of switching carriers to be too much effort as long as the service did the job. After all, how many times do you need to go back and play around with your domain settings after the initial purchase/setting.

However seeing Bob Parsons kill an elephant in Africa while making the entire village wear GoDaddy hats was something I really could not stomach. So effective today, I will start moving my domains away from GoDaddy (about 60 of them) to another provider like NameCheap.com.

For those of you wondering how you can do this quickly (through the complicated UI that GoDaddy has that practically makes this impossible) here is a guide on how to switch your domains from GoDaddy to another provider.

I hope many follow the lead and do not put the $1-2 year savings every year above some good ethics both as a person and as a corporation.

Software Design for Tablets

There is quite a bit of interesting posts about tablets these days with the introduction of new players such as the Motorola XOOM, ViewSonic ViewPad and Galaxy Tab to an Apple dominated space. This blog post by Jon Stokes talks about how the user’s own hands get in the way of human-computer-interaction when using the tablet and block the view, making things much harder to focus on and decreasing the valuable real estate.

Even if you hate them, tablets are here to stay. They cater to the needs of most people who want to just digest information from the web on the go. Nothing ground breaking here so far but let’s take a look at how this information is actually different…

Some of the most common tasks performed on the tablets are:

  1. Watching videos
  2. Flicking through pictures
  3. Reading the news/magazines
  4. Consuming social content (mainly looking at bits of text from your updates and sending out bits of updates)

Do you see a trend here? The amount of input required to complete these actions are at most 2-3 taps on the screen. This is the key to designing any user-acceptable software for the tablet: reduce the input to output ratio with considerable think time between user inputs.

Let’s look at some examples of this in games and apps:

1) Angry Birds: carefully calculate what you think might happen, set the bird free (or on fire!) and just observe the impact.

2) Words with Friends: think about the word you will form and then put the tiles on the board with 4-5 taps

3) Facebook: browse through pictures of friends and latest status updates.

4) Twitter: read the tweets of people you follow

This is exactly why I cringe when I see applications like “focused writing” on the iPad. I just cannot possible imagine an adult sitting down and trying to type more then 3 sentences on a 10″ iPad while covering the lower part of the screen with a keyboard, making sure that there are no typos and then with the rest of the attention she has left focus on what she was actually trying to type. Tablets are meant to be information “consumption devices” where large amounts of data are distilled into smaller bits and the user quickly consumes the data and moves on.

This is right in line with how the society behaves in the past 20 years. The progression of people reading books to blog posts to 140 character messages shows us how much majority of  people value snippets of shallow information over deep thinking about a particular topic.

The actual work of creating the content should mostly be left to other input devices. So next time you start thinking about the scope of that tablet app, make sure you let the user consume more than he produces.

Cohesion in technical teams and your role as an architect

Coming to a software project later on, some things don’t tend to make sense. Why are there two services here instead of one? How come you are not using this way of message passing instead of that, why is your data format XML instead of JSON? Wait, you did not use a grid CSS layout?!

In my experience so far most of the answers to these questions are answered within the first 1,000 lines of code that you lay out in the beginning of the project whatever stack you might use you will run into similar (if not same) questions and you need to have the answers to such questions.

Lets face it, software design is as much artisan work as much as it is engineering.  Just like most paintings have a deeper story than what you can first spot in the beginning, most software architectures/designs have a story behind them. Unfortunately, as engineers by training (or scientists in my case) software crowd tends to get confrontational with black and white examples/dogmas when joining/taking over a project. Suggestions can be right or wrong, useful or futile, but if you can dodge most of the futile arguments and let people make the point for arguments that they strongly believe in the value of, why not do it?

But how do you make sure people argue something that is at least of some value to the project? Give them the best tool they can use: data.

In this case the data a software developer/architect needs usually falls into three categories:

  1. Data Flow -> where is the data coming from, why is it stored there, why are you moving it around and how is this achieved?
  2. Process Flow -> Why is the business process (even if you are writing a social photo sharing site there is a process flow don’t let the enterprisey word scare you) split over X number of nodes? How does this help you when considering scaling, response time and overall deployment plan?
  3. Team Dynamics -> Certain decisions are not always made in the light of sole technical sense. When there are two people on a project there is politics. Sometimes compromises need to be made to move projects forward. Best one can do in this case is to explain the thought process of what was considered, and why it was not chosen.

You might say, isn’t all this already there in code, database, emails? Yes it is there. Unfortunately for us though, no one goes back to hunt information. Part of your job, especially as an architect, is to make sure you collect/present/maintain this data. The reason present is bold is for (maybe not) obvious reasons; the quality of telling the story is just as important as the story itself.

Doesn’t sound exciting but this is the single best thing you can do if you want to have a cohesive technical team that works together despite differences in opinion.

 

Parallel Input Output to Speed up Your Apps

My new whitepaper has been published a couple of days ago. This article stems from a client experience where code had to be transitioned to a team of developers non multi-threaded programmers who needed to maintain a parallel application. A simple overview of a possible framework has been also outlined in this paper. Note that Microsoft’s Task Parallel Library also has some similar concepts (and it was released a couple months after this paper was originally written..)

 

In recent years, chip manufacturers have stated that CPU speeds cannot continue to increase. Instead, hardware manufacturers have begun to create chips with more cores, making them available on lower-priced hardware. The responsibility now falls to the software industry to take advantage of these multiple-core processors.

There are currently a plethora of parallelization frameworks available that take advantage of the multi-core machines. Most examples, however, are focused on more scientific or computationally intensive operations such as dealing with prime numbers, ray tracing, or working on matrix operations. Although these are great ways of utilizing the extra horsepower that multiple cores provide, they certainly do not directly help the average enterprise application.

Unfortunately, enterprise development has traditionally not required a multi-threaded development focus for the majority of applications. Consequently, development teams in most enterprises are not well versed in multi-threaded programming. Therefore, just introducing the requirement for parallel I/O via multi-threaded programming with no automated guidance in the form of frameworks and tools is a recipe for disaster.

In this whitepaper, we look at how developers can take advantage of multi-threaded code to reduce the response time of an expense application by 70% by simply applying parallel I/O concepts without changing the current code structure or requiring new training for the development team. Through the use of a parallel I/O framework, development teams can create multi-threaded applications without having to deal with the complex programming of multi-threaded code.

Click here to read the rest of the article…

 

Amazon, Free Books, what?

If you are a Kindle owner, you know the drill. You like a book, go to Kindle store pay $9.99, $13.99 and get the book you want to read under a minute on your kindle.

Today as I was shopping around for a new book, I came across a hidden treasure that I had no idea about. It turns out Amazon is giving away (yes, it turns out they do that!) free books. Not just a few either about 5,000 of them! Most of them are on the public domain, nothing shocking but at the same time if you meant to read a classic for a long time you can do that for free now. Check out the books http://www.amazon.com/tag/kindle%20freebie?ref_=tag_dpp_cust_itdp_s_t&store=1

The saying goes “What’s the difference between a best seller and a classic? Everyone knows the name of the classic but no one has read it!”, if you want to change that go ahead and read some classic!