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.
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.
Having said that: Is it a good idea ever to restart from scratch ? Yes, there are few
- 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)
- 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
- 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.
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.
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.
Now you have two completely separate applications that do different things and are still linked with each other.
So how does it work?
- User visits domain.com/blogs/1
- The widget sends a request to GET comments.domain.com/blogs/1/comments
- The app looks up document comments and searches for those with blog_id 1
- 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
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/