Posts Tagged ‘architecture’

Martin Fowler’s article on micro-services

June 1, 2014 Leave a comment

Martin Fowler and James Lewis have an article on micro services here

Though my first reaction to it was, “what, isn’t this SOA”, the article itself had a sidebar which mentioned “service orientation done right”.

Worth a read, Excellent stuff as usual from thoughtworks folks.

To some extent, I felt Martin Fowler is taking an U-turn on

Hence, we get to my First Law of Distributed Object Design: Don’t distribute your objects!

How, then, do you effectively use multiple processors? In most cases the way to go is clustering (see Figure 7.2). Put all the classes into a single process and then run multiple copies of that process on the various nodes. That way each process uses local calls to get the job done and thus does things faster. You can also use fine-grained interfaces for all the classes within the process and thus get better maintainability with a simpler programming model.

Quote from Patterns of Enterprise Application Architecture (PoEAA) Chapter 7 Distribution Strategies.

Yes, yes,

  • I am aware of the terms that Fowler uses here “Objects” – I always thought he used objects here in the sense of component objects / service objects – Earlier in this chapter he uses “With separate remote objects for customers, orders, products, and deliveries. Each one is a separate component that can be placed on a separate processing node.” So I believe he uses object in a broader sense in the First Law of Distributed Object Design.
  • Granted today we have a faster network stack
  • His argument about coarse grained interfaces was spot on.
  • Also I understand the benefits that micro services brings.

I think, he that he should rewrite his Distribution Strategies Chapter in PoEAA to include the micro services alternative as well.

Your thoughts?

In search of a client-side templating solution

December 20, 2013 3 comments

After a long time I am posting a technical entry. I am in search of non intrusive client-side templating solution. The following are the requirements

  • Non intrusive Should not require something like

ko.observable, ko.mapping and then,‘Employees’)

Ember.Object.create, tableMetadataModel.get(‘name’), tableMetadataModel.set(‘name’, ‘Employees’)

The problem with these kind of solutions is that these solutions are no longer Plain Old JavaScript Objects. They introduce a tight coupling with the templating library / framework which is implicit.

  • Is reactive / supports ‘Live Templates’ To Quote from Wikipedia

For example, in an imperative programming setting, a := b + c would mean that a is being assigned the result of b + c in the instant the expression is evaluated. Later, the values of b and c can be changed with no effect on the value of a.

In reactive programming, the value of a would be automatically updated based on the new values.

A modern spreadsheet program is an example of reactive programming. Spreadsheet cells can contain literal values, or formulas such as "=B1+C1" that are evaluated based on other cells. Whenever the value of the other cells change, the value of the formula is automatically updated.

In this specific context, when I update the name of the table object by setting an alias like

table.alias = ‘e’

It should automatically update in the UI.

  • Two-way data-binding

when I update the name of the table object by setting an alias like

table.alias = ‘e’

It should automatically update in the UI.

And when I update the alias in the UI, it should update the object model.

  • Model as the single-source source of truth In this specific context, when I update the name of the table object by setting an alias like

table.alias = ‘e’

All the places in the UI where table is rendered as a view should be updated.

Reactivity and Two-way data-binding go a long way in helping Model as the single source of truth.

  • Modular
  • Supports defining templates in external files and plays nice with requirejs text plugin.

  • Performs efficiently
  • Supports r.js optimizer & requirejs text plugin

For example splitting the application into small modules that have a single responsibility requires writing many modular templates. But i may result in poor performance if we make many calls to load them from the browser. Bundling them with the r.js optimizer for example can reduce this performance hit.

Granular re-rendering

Reactive templates should not mean the whole template is re-rendered every time model changes.

For example modifying an item, adding an item or deleting an item in a list should not re-render the whole template and instead just re-render / add / delete the concerned item nodes and the whole list or worse the whole template.

No dirty checking

    For example angularjs uses dirty checking that impacts the performance negatively.

Read this to see what I mean

  • Plays nice with other legacy frameworks / libraries
  • Recently I tried my hand with Polymer Web Components Stack. I ran into a hard to identify issue. Finally the issue was joint.js(+jquery) which I was using in conjunction with polymer was walking the DOM tree and made an assumption that the root node is the document node. Which is not true when it comes to shadow dom.

  • Fits well with Nicholas Zakas’s Scalable Application Architecture
  • Can I find the templating solution that fits well with Nicholas Zakas’s Scalable Application Architecture? Time has to tell.

object.observe, web components based?

    Some sort of a dom based templating solution based on object.observe on the modern browsers and an object.observe polyfill in other browsers which do not support object.observe should be good. But looks like knockout, ember etc are not taking up the object.observe route yet. May be I will end up forking knockout and implement one myself.

A build-time two-step transform view?

    Taking a hard dependency on a single templating solution, esp. for a product does not seem right.
    Are there any adapters / abstractions available that help one switch templating solutions over the same Model?
    Any suggestions comments would be welcome.

The Twelve-Factor App

April 23, 2012 Leave a comment

A write-up on practices of developing / deploying a saas app –

On code reviews and maintainability

May 19, 2011 Leave a comment

Prakash has a very good post on Maintainability here. Please go read it first.

I will expand on pair programming point a bit and add my perspective.

You add more members to the team. They start writing code. Even though you can educate your developers about how the code is written, but everyone brings some baggage with them (culture, how they worked in previous projects, companies etc…)


There is a gap in terms of skill level, experience level and understanding (being on the same page with respect to the architecture, design, development practices) when the team ramps up. We need to pair at least till the gap is bridged.

I see two aspects to maintainability, preventive and reactive. Both are equally important. Pairing is probably one of the tools in the the former and reviews the later. Reactive probably has a negative connotation to it so i might reword it as ongoing effort or continuous effort.

This just like how we should handle Performance. Design for performance and still plan for performance tuning when things fall out of place.

To generalize aim for the best and ideal, you won’t reach there because there is always a gap between ideal and real. So when things fall out of place have checks and counter measures to pull them back on track.

As some one who hates reviews I have come to a compromise that they are necessary evil.

Some words of advice for the aspiring architect

January 20, 2011 2 comments

Some advice to people who want to take up software architecture as a profession.

I won’t say that I am the perfect architect and I had followed all of this advice myself. Some of this I am still trying hard to implement myself and I have failed in a few occasions. But I do understand that these are the goals and I have to aim high to hit high.

“There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves.”

And some these lessons have been learnt by peeing on the electric fence. Yeah I have had very few people to observe and books like “97 things every architect should know” weren’t out there then.

Can I become and architect in the next 21 days, 24 hours?

No it is not possible to teach yourself architecture in 24 hours. May be 21 days. Well No again. Why? Read Peter Norvigs classic here.

"Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.

An architect should be able to work at / communicate at varied levels of abstraction.

If you are a hands on developer aspiring to move into the role – You should be able to ‘see the forests for trees’ or raise your level of abstraction when needed. This is a very helpful when

  • You need to dive into an existing system and understand it.
  • Communicate with stake holders without over whelming them with the details.

If you are into the role for sometime now you should be able to dive into the details when it is required. The devil is in the details :-). This is very helpful when 

  • You are estimating / breaking down the system to provide commitments to stake holders
  • Communicate with other members of the development team (you need to speak to a developer in a lower level of abstraction).

An architect should have knowledge in a breadth of technologies.

An architect should be a Jack of all trades. Do not misunderstand this quote, the full quote will probably be a better one

"Jack of all trades, master of none, though oftentimes better than master of one".

How can you learn all the technologies coming out today, especially that the technologies are coming out at a frantic pace?

Welcome to meta-learning. Learn things at a meta level, meaning both Windows Azure and Google App Engine are PaaS. If you learn them at a conceptual level and correlate the concepts between them it is easier. Same applies to .NET and J2EE. But if you do not know the underlying concepts, this becomes really hard and virtually impossible. Of course there will be nuances specific to a technology which you have to learn as well.

Remember the Golden Hammer rule:

If all you have is a Golden Hammer, everything looks like nail.

Use the power of networks, community.

Learn from the community, Contribute to the community. I will quote ayende here.

Another point that I want to bring up is the importance of professional networks to bring information to us. No one can really keep track on all the things that are going on in the industry, and I have come to rely more & more on the opinions of the people in my social network to evaluate and consider alternatives in areas that aren’t offering acute pain. That allows me to be on top of things and learn what is going on at an “executive brief” level. That allows me to concentrate on the things that are acute to me, knowing the other people running into other problems will explore other areas and bring their results to my attention. – from

It is the age of networks damn it, Use Twitter, RSS, Stackoverflow, Quora whatever…

The people who you work with are Important

If you are not working with bright developers who keep pushing you to the the next level, demanding managers who keep pushing you to the next level, You will be mediocre. Choose your colleagues carefully.

  • When was the last you heard about a cool concept/technology from a colleague?
  • When was the last you participated in a good tech talk as a team?
  • When was the last your colleague suggested you a great article / book?
  • When was the last when your manager suggested you a technology you have never heard of?

An architect should understand that time is not an infinite resource

Engineering is not about perfect solutions, It is about doing the best you can with Limited resources – Randy Pausch, The Last Lecture

You cannot design / architect every aspect of the solution to perfection. Instead an architect should identify what are the most important modules of the system and focus his effort on making them the best. Eric Evans talks about this under the head of Strategic Design.

As an architect if you make any technological mistakes, it is amplified because of the number of people who follow you

Do not learn on the job, learning is continuous and you should have to learn things before hand. Keep a practice ground,  may be a pet project, may be code & design katas. Even though this applies to any programmer, this applies even more to architects.

Sprint Zero is really important

People are good at emulating something that’s already there. So setup a good representative sample usage of the proposed architecture in code.

Know your limitations as an architect working from a vendor side @ an offshore location

Expect you to be heard less, having less voice in a few scenarios.

Learn to disagree and commit

This is the most important thing that you need to learn as an architect. Not always your opinion will be given a fair consideration (no matter how hard you believe it). You have the following options

  • Learn to either disagree gracefully but still commit for the other alternative.
  • Ask for forgiveness than for permission. Implement your solution and prove that it works better, anyone can raise objections to solutions in air (not implemented) but very few can resist the hard reality.

Learn when to quit

Since you have not become an architect in 21 days and became one through your hard earned knowledge there will be many occasions when other stakeholders (esp. higher up ex: Clients, Project Managers) will be hell bent on implementing what you think as the obvious wrong solution. If you too strongly believe in what you think should be the solution, explaining it and moving out of the solution implementation is a very valid alternative. Keep your ego in check in these scenarios and you have the options listed in Disagree and Commit. Remember that your stakeholders are too stressed that they start believing in laetrile, they are human too.

If you raise hell about a problem, they focus on you more than the problem. You become the problem.

You cannot swim against the current for long, you have to either swim with the current or swim out of it.

Expect to work for the worst

I know this is flamebait and a highly biased personal opinion. The sorry state of software project management is that people take up the profession because they cannot keep pace with technology any more. It is very likely that you will end up working for managers like that, prepare yourselves. Expect the worst; you won’t be disappointed if you end up working for one.

A corollary to that, when you do get to work with good Managers, do whatever it takes to be with them. The others might think you are insane / mad but it doesn’t matter.

If you are an aspiring architect / practicing architect and if you have stopped keeping up with technology, its time to quit the profession.

Stay on top of development

This becomes really crucial if you are hands on guy. Coding your modules as well as staying on top of other modules becomes really hard. Code reviews are a good way to understand what is going on in the rest of project and learning a few techniques from your team members.

Comment source commits into the Version Control System and have a Source Monitor like SVN Monitor, read the comments periodically (may be once in two days). Dive in to the source when needed. Reviewing every line of code is impossible, so pair with new members yourselves or pair new members with existing team members till they pick up the project idioms and practices. This can keep the review effort to minimum.

Automate mundane things using a static analysis tool like NDepend.

Bridge the generation gap

I have to do much better here. As an experienced architect (Since you have not become an architect in 21 days)  the people in your generation are likely to be your managers or other peers. The people in your team who you lead technically will be in the next generation. It is natural that you hang around with people from your age of development, generation of development (Those are the people with whom you can have discussions like – When we were programming in ASP / COBOL yada yada yada). This widens the generation gap further and alienates you. Connect across generations. As an architect you have no other option. I always used to see earlier generation people as perfectionists (old school), There is every probability that my team is thinking the same way about me and your team about you.

Expect that you will make a lot of mistakes, forgive yourselves

The life of a software architect as a long and rapid succession suboptimal design decisions  taken – Philip Krutchen

And live to guide the aspiring architects, make a difference.

Happy Architecting, And do not  pee on the electric fence, read the books, learn the concepts, observe practicing architects / tech leads / lead programmers.

Cloud Computing Vendor Map

November 21, 2010 3 comments

I have created a Cloud Computing Vendor Map imposed on service models to understand the vendor offerings in the Cloud Computing space. It is primarily based on Peter Laird’s Cloud Computing Taxonomy. It is a big list, so please click on the image to see the original sized image. SaaS will be a huge list and I haven’t included all the vendors there.

Cloud Vendor Offerings

Do let me know if you want to see any additional products / services or if anything is classified wrong.

Original taxonomy from Peter Laid – Peter Laird’s Cloud Computing Taxonomy

Cloud Service Models

November 21, 2010 3 comments

Cloud Software as a Service (SaaS). 


What the consumer can do?  

ü Use the provider’s applications running on a cloud infrastructure.  

ü Limited user-specific application configuration settings

 What the consumer cannot do?  

û Manage or control the underlying cloud infrastructure like  

§ network,

§ servers,

§ storage

û Install consumer-created or acquired business applications, application servers operating systems, or other software  


Cloud Platform as a Service (PaaS). 


What the consumer can do?  

ü Install consumer-created or acquired business applications developed using provider platform

ü Limited application hosting environment configurations

 What the consumer cannot do?  

û Manage or control the underlying cloud infrastructure like  

§ network,

§ servers,  

§ storage  

û Install consumer-created or acquired application servers, operating systems, or software developed using other platforms which are not supported by the provider.


Cloud Infrastructure as a Service (IaaS). 


What the consumer can do?  

ü Install consumer-created or acquired business applications developed using any  development platform, application servers, operating systems  

ü Application hosting environment configurations  

ü Manage or control the underlying cloud infrastructure like  

§ limited control of select networking components (e.g., host firewalls),  

§ servers,  

§ storage  

What the consumer cannot do?  

û manage or control the underlying cloud infrastructure


Application Platform as a Service (APaaS) 


APaaS is flavor of PaaS. In particular if we think of PaaS as middleware services like the Application Server as Service (e.g. Web Role / Worker Role of Microsoft) APaaS is an Higher level of abstraction, Yefim Natis of Gartner calls it as the Extended Application Server.

In particular it is like using Business Application Framework instead of the plain PaaS offering. In the Enterprise development space it’s like using vanilla .NET Framework for developing Business Applications vs. using xRM (CRM as a Platform to develop LOB Applications) or SharePoint as a Development platform.

APaaS is the same Application Platform / Business Application Framework concept extended to the cloud. If the Application Platform is available as a Service it is called APaaS whereas if it licensed as Product for use in Public / Private clouds it is called a Cloud Enabled Application Platform (CEAP) / SaaS Enabled Application Platform (SEAP). Jothy Rosenberg and Arthur Mateos call this Framework as a Service instead in ‘The Cloud at your Service’

Examples of APaaS include, LongJump, Examples of CEAP/SEAP include expanzPlatform, Apprenda SaaSGrid

Further Application Platforms can be classified based on who is the target audience, the Biz User or the Developer.

Cloud Stack

Information summarized from:

The Cloud at your Service

A Brief QA on PaaS / APaaS

NIST Definition of Cloud Computing v15

Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS)