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

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

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.