Software Architecture

So you’d developed your product a few months or even years ago. It works fine, but now that you want to expand its  features. You try to hire new developers and are told that the framework that you used is no longer used widely. The world, apparently has moved on and all the cool guys are using fancy new technologies.

The cakePHP 1.x application that you wrote is now very hard to maintain and the best thing you can do now is rewrite it in a modern framework.

At this point, I imagine, you’re faced with a dilemma: should you rewrite , or should you continue to maintain the beast that very few people want to work on.

Naturally, if you talk to a new developer, they’ll tell you its better to rewrite it since you’d eventually have to do that anyways. Nobody uses that obscure software framework that seemed like a good idea.

If you, however, listen to experienced programmers/ leads you’ll hear quite a different story

Joel sums it up best in this blog.

Things You Should Never Do, Part I

They did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch.

~ Joel On Software

 

Over time I have, too made the same mistake more than once. I decided to rewrite an application that I had developed : BestRoomies that had run its course. It was written in Zend 1 and if we’ve learnt anything about PHP frameworks, the major version changes EVERYTHING. So I decided to replicate the application in Rails, throwing away months and months of work.

Did I come up with a swanky new application that performed exactly like the one I’d left? No!

I got bored a few days after starting and gave up on the idea of revamping it. This is ofcourse a personal experience and might not be a problem with people who can avoid getting distracted from work by the sound of air.

So trust me when I say: Rewriting code from scratch doesn’t solve problems.

You can read Joels’ article for an excellent insight on why its a bad idea. If you must replace your code, do it step by step. Developers love to rewrite from scratch and as an Architect and Project Manager, I can guarantee that 9 out of 10 young developers will advise you to do the same.

RESIST!

Having said that: Is it a good idea ever to restart from scratch ? Yes, there are few

  1. Its a POC. POCs are supposed to be small application that test the idea that you want and are then discarded. You then use the experience to restructure the application and rewrite it. (How Companies treat them is a different issue)
  2. It doesn’t have any real users. If it hasn’t gathered significant traction and you want to tackle inherent problems in the framework/language,  you can do this
  3. You want to completely redo the application, its features and everything. Okay, so doing the above is a bad idea if you already have users. More than one company has done this with devastating results (Peopleperhour, for example), but if that is what you must do, you can consider rewriting

As a rule of thumb, if  you must rewrite, do it early in the life cycle of the application. Once people start using  it, donot rewrite from scratch as it will cause more problems that its worth taking on.

BUT

There is merit in listening to the guy who says that the new features require a different framework or a new database technology would be beneficial for it.

This is sometimes true. You could use neo4j to easily generate recommendations based on complicated algorithm. The herculean task will cause nightmares in mysql.

Microservices: Byte sized services!

You might have heard the term somewhere… Perhaps when you were researching architectures. You might even have come across a rather scary and confusingly labelled diagram at http://microservices.io/patterns/microservices.html

So from the above link, you will get all kinds of information about how amazon makes 150 calls per request to get data to display on home page…but very little information about how that works out.

So what is this microservice thing?

Put simply, when different separate applications deliver different pieces of data on a page.

Say, you have a PHP application which displays blogs. The user can view blogs, add them, edit them etc.

When you want to expand this to include comments, you can create another application which has access to the same database

Then the application that shows the blogs can make a call to the comment application to get the comments and show them on the page.

This is a very simple  example of micro services.

simplephpmicroservice

This also is not the proper way to architecture an application. The blog is dependant on the Comment Application, so in a syncronous set up, there is no real advantage to using this. The response time might be slightly slower, and with caching, the response time could improve significantly, but there still is quite a bit of coupling.

A better way of doing this would be to render the blogs via html and load comments through javascript. Let’s have a look at how this would work

simplephpmicroservice-1

Why not go full javascript? We’ll do that, but this article is not about microservices alone. I also want to highlight how you can avoid a rewrite of your application by adding little microservices and connecting the data with javascript.

The idea here is that you add some javascript code(React is ideal for this sort of stuff) that displays the new feature you want and then you can make it in whatever framework you want. So why don’t we write the Comment Application in nodejs and store the comments in MongoDB?  Well why not!

simplephpmicroservice-2

Now you have two completely separate  applications that do different things and are still linked with each other.

So how does it work?

  1. User visits domain.com/blogs/1
  2. PHP application receives the request and displays the blog, then creates a javascript widget to get the comments
  3. The widget sends a request to GET comments.domain.com/blogs/1/comments
  4. The app looks up document comments and searches for those with blog_id 1
  5. It sends the comments as JSON and the javascript widget renders them
  6. When the user wants to add a comment, he directly interacts with the api itself which sends a request POST comments.domain.com/blogs/1/comments

So how does it know whether the user is logged in? Sessions can be shared using redis,  ofcourse

On such a small scale and functionality, it might seem trivial to make an application just for comments and so micro services might seem rather… gratuitous, right ?

Well, millions of blog use this exact architecture, except that the comments are rendered by a third party : Disqus

Any third party service that you use on your website: Analtyics, Disqus, PubNub, etc are all examples of Micro Services in action. We just don’t assign fancy names to it.

This is ofcourse the case when you’re exapanding. If you had to architect a complex application now, you could do it from scratch in a far more pleasing manner using an SPA

simplephpmicroservice-3

This is how ideally the app should like : You have clear seperation of concerns.

 

The comment application might need to check the blog, or other auth data. It can cache the said data on its own end as well, if needed. Web hooks may be used using a message queue if the two need to update each other about some stuff.

We used this architecture for an ecommerce product where it was becoming very hard to work with Magento alone. So we decided to let Magento run the ecommerce front and push other features: Comments, likes, Following, Feed to a nodejs application which used neo4j as the database.  You can read about this here: http://www.sourcefuse.com/ecommerce-the-social-way/

 

bbd

In summary, micro service architecture can be very useful when you chose to expand your architecture. It offers you the advantages of simplified scaling, caching, seperation of concerns and allows entirely  different development teams to tackle the problems that they can best.