Micro-Services Architecture

Ever been in this situation?

   You have put lot of efforts in developing an application by employing best practices and design. Quite happy with what you’ve done, no big issues have been reported. The system is almost decoupled and every business domain resides in its own dll(s) and you have been releasing your product in 2 weeks iteration. Great, Great…

However,

   As the system grows, it makes the life a bit harder. You’ll notice any changes to the system involve building and deploying a new version of the application. The best approach would be a good deployment strategy which is usually taken care by tools. By manual updates, still doable!

To make matters worse,

   If your managers have some scalability in their minds or your apps are being deployed on the cloud or any other reasons that tie change cycles together, this is the beginning of your clients’ frustration. A change to small part requires the whole system’s rebuilt. It would make you pure evil after some updates. Evil, Evil…

 ‘Microservice architecture’ comes to your rescue. In short, building a suite of small services (usually communicating over http), each running its own processes. They’re independently deployable…

Micro-services (By Martin Fowler)

http://martinfowler.com/articles/microservices.html

Is Facebook to be the 'next' Facebook?

This article caught my attention among gazillion comments regarding Facebook/WhatsApp deal.

Is Facebook to be the 'next' Facebook?

If you'd like to have clue how WhatsApp is overwhelmingly working. Please take a look at the photo.

Asp.net MVC 5 Application Lifecycle

A great diagram for MVC developers, both in Macro & Micro views.

Microsoft's Lifecycle of an Asp.Net MVC 5 Application

A high-level view of the MVC application lifecycle, where you can understand the major stages that every MVC application passes through in the request processing pipeline. And a detail view shows details of request processing pipeline.

Having another look at the lifecycle, couple of aha moments:

-          BeginExecute Method runs before Controller.Initialize method

-          AuthenticationFilters are executed before and after action method

-           ActionFilters are the closest methods to the action method

-          Async action methods may be invoked in a different worker thread

PHP or Asp.net?

Recently, a friend of mine asked me a mind blowing question.
   Over a decade development in Microsoft world,Well ... nice. But why did you pick that wagon early on your career?

I just replied with fair few things and I tried my best to convince him that was the only game in the town.
However, I found it interesting to see what the key factors would be for other developers. A little googling, and I was fascinated by the result.

These two resonated with me a lot:
Rob Conery: I Had a choice, PHP or .Net
Darcy : It was 2001 and I had a decision to make

To model first approach or …

A thoughtful blog post by Frans Bouma:

Code-first O/R mapping is actually rather silly.

After years of debating over model-first approach has made it easy to test your application and POCOs. After I picked NHibernate 6 years ago, I realized making the changes to the model was a breeze. 

The changes are more manageable and smoothly ripple through your classes and database tables.

However, looking back on it seems more interesting to me. 

The idea is pretty valid to me. We do not persist objects to database, we persist their contents, which are their entity instances. On the hand, serializing data from technology to the other usually means having same the content. For instance, .Net objects can be easily serialized to Json. But in this case, objects are mapped to tables and saved.

Maintaining existing software architecture

Evolutionary design is a very hard to tackle task. All of us have been in the situation when joining a new team and wanted to augment an old feature to a new design. It’s really hard to be in sync with other team members. 

Many times when a developer complain about messy code, it’s really because of a lack of consistency in the design. Adding a new feature needs assessment and so does the evolutionary design.

The article by Jimmy Bogard (Curbing long tail design) elaborated on the ‘Law of two’. Meaning only allow at most two designs in your system. Before doing other changes to the design, move all existing features to the new design. If you’re working in small steps, this shouldn't be much of a problem.

Why we do not document code?

This post led to a hot technical discuss today.

Why we do not document code?

If we’re serious about the piece of code, we have to write some useful documentation. Amazingly, I have noticed among many of my colleagues that the hard part is not coming from laziness! It’s the full understanding of a system/component that makes you feel sluggish to write a decent document for your code.

Some business processes are really complex to rephrase them into human language. Of course, the fear of any misunderstanding gap seems to be the source of all ignorance.