Microservices, Legacy Applications, and the Relational Database

Microservices architecture enables flexible architecture and speeds up your development process. But, often people are confused as to where to start.  The obvious choice is to use a microservice architecture for all new applications.  However, you have a ton of time and money invested in legacy applications. Applications that handle your user authentication and access to your company’s core products and services should be rewritten.  You should definitely leverage those legacy applications to get to microservices faster.  And, you can do it without changing your existing Database Schema!

Understand that you have a three-tier application already.  The microservice portion is just a different view.  Instead of a pretty HTML page, the microservice user will see a JSON document behind a RESTful API.

Furthermore, since you are only changing the view portion of your application, your business logic and data model will not change.  That is outstanding news as those parts are rather tricky and can be brittle as your application ages.

So, in this use case, you can imagine we are taking a user authentication application and creating a microservice version of it.  Other platforms would then use this microservice for authentication. Perhaps we can authenticate mobile users this way, or we will offer authentication services to third parties in much the same way that Google and Facebook do with their accounts.

Sometimes, you will want to create a new microservice that has no previous application like it.  For example, imagine a microservice that will embed some of your customers’ data in another webpage like YouTube offers with their videos.  For that, you might need to not only create a new view but also a controller.  What you should avoid doing is creating a new data model; that means use the Database Schema you have today!  Leverage your existing Database Schema using a new VIEW in your database (Note: this is not View as in Model-View-Controller; this is the Database object).

The point is to limit the amount of work you must do to accomplish your task.  Think “Minimally Viable Product.”  One of the biggest temptations in adopting new technology is to want to use it independently of legacy applications that use older technologies.  That reminds me of bands that dislike playing their bigger hits (looking at you, Oasis) and prefer to either skip them or pay lip service to them.  Remember: those applications are “legacy” applications for a reason.  They have stood the test of time and they work.  As you begin to experiment with new technologies and architectures, strive to use the legacy applications’ success to your advantage.