When you are writing custom piece of software for particular customer, the strategy is simple – do your best to satisfy the customer as much as possible with the minimal development efforts/investments. In order to achieve that you need to design architecture in that way to predict as much number of future changes as possible, make your product easy to change and move sequentially forward in the future. That’s why you split your architecture into layers, you create abstract interfaces, you apply concrete implementations, and finally you make your architecture pluggable and easy to extend.  You rely on 3rd party libraries, you try  to re-use previous experience and code snippets/libraries. Of course you are facing a lot of other development challenges here, as everyone does in software world today, but the key question is how to save efforts on product development. Do more with the help of less.

This question leads us to that idea that almost every company that has specialty, tries to build a platform instead of developing an ad-hoc solution each time from scratch. They develop platform that is easy to customize for particular customer. If the job is done properly (by perfect beings in perfect world:), number of your customers will not depend on number of development investments. Profitable model.Write once, sale many times.
That reminds me one of easy to scale patterns – write once, read many times(read optimized scenario requires you to optimize data at write time)
In this case the challenge is to split you product architecture into bricks. Easy to replace, easy to rebuild, easy to append. Another challenge is how to build ideal platform, the framework that can be easily customized for any customer…and keep it simple. Both, on UI and code level. That’s true art, to build the system that’s complex in a whole, at the same time consisting of simple disjoint blocks.

So, we examined companies that sell products and platforms. But there are companies that don’t sell products and nevertheless stay alive in software business. They do have own products, but they sell advertising. Google is the best example. This is indirect model. The profitability lies in a number of users using a product. Nobody will use Google AdWords if few clients use Google Search.So, to stay alive in this business you need to keep existing customers and constantly gain ground using new ones. Like a shark, keep moving or you will die. Other competitors will intercept your users.

In order to serve such incredible number of users you need to scale your product easily. You need to do less job with a less number of machines in a cluster. Electricity bills matter here. Performance, fail-over, load balancing, capacity reserve. All these items are answers to one simple question stated by the business model – how to handle large number of users/content transparently and efficiently without expensive hardware infrastructure at the same time saving development efforts.

The main idea is that everything has its origin, like anything in a universe. Everything starts from something and leads to something. There is a reason for everything around us. And each day, on each page of code you can make your influence on the company in whole.

Unfortunately, as it usually goes, our coding life is not so appealing. Sometimes you do nothing but just update your Eclipse, you look for new features and bugfixes, but surprisingly some stupid plug-in consumes your CPU cycles and prevent Eclipse from breathing freely.
Sometimes it’s a set of other non-technical factors that makes your coding muse leave…

But from time to time some annoying bug appears assigned to you, and you realize that you don’t want to fix it at all. By no means I’m telling that you don’t like fixing bugs at all. Bugs are part of our life, accept it. It’s a good thing to do – fix them. But I would like to touch those bugs that are injected because of architecture. Somewhere deep inside you understand that global factors caused these bugs.

Looking around you will find a lot of books on software design. They talk a lot about software quality and how software processes are connected to it. They all tell you not-todo-things. Clear set of things you should avoid to do. Why? Because it’s simple to describe someone’s failure and try to guess origins. There is plenty of examples in the field already. They’ve got a lot todo – put it on paper.
However, I guess that a couple of guys on our planet still know how to write software in a right way, but usually they don’t like writing books

Each software type is special, it requires a set of specific patterns and approaches. You need to combine a lot of ingredients in order to get perfect soup. In case of software, you should be ready to make another soup at any worth-while point. Moreover, architecture should be self-explanatory, it shouldn’t take a lot of developer’s efforts to decide where he should put new piece of functionality. It’s a function of a lot of params.
So, almost everyone faces a moment when there are no uncovered challenges left in the projects he is working on. You know technologies, you know your domain area, sometimes only introducing new frameworks makes you smile.

So, the truth is, that your next challenge should be re-writing you project in that way, that it will be easy to fix bugs and it will be difficult to discover difficult-to-fix architectural bugs, there will be a minimal of “chain bugs” – when changes in one places screw up others. Your architecture will protect you. Like technology makes impossible for drunk tram driver to hurt people walking around, due to rails.

And in order to solve this puzzle, you need to question yourself each time you are looking at newly discovered bug – “What’s the origin of this?”

The key of its efficiency is an architecture represented by a set of isolated nodes that don’t know aware of each other. The client makes decisions on data management. This provides very high scale-out factor.

On the other hand, in regular cluster-based systems there is a master server and slave nodes. Slave nodes are very helpful as they help to distribute and speed up read requests. But as soon as write activities occur in a cluster, it’s a pain to broadcast all changes to all nodes. The deployment schema becomes inefficient.

As always, it’s a chain of trade-offs to be considered…

Enjoy – http://www.linuxjournal.com/article/7451