Why To Use Microservices?
There are several reasons why you should use the Microservices approach to build your fintech platform when compared to a monolithic platform.
- The platform is easier to develop and maintain
- Easier to adjust the platform to specific customer demands
- Future proof
- Not stuck with one form of coding language, different parts can be written in different languages, making the language decision easy, best tool for the job
- Being able to spread the services over several instances, if one fail, the next take over, no more crashes
- Better security since the different services can be monitored individually
- If one service would fail (unlikely) the rest of the application would still continue to function, AWS says this Service independence increases an application’s resistance to failure. In a monolithic architecture, if a single component fails, it can cause the entire application to fail. With Microservices, applications handle total service failure by degrading functionality and not crashing the entire application
- Monetary savings, let’s say that one functionality takes a lot of resources, you don’t have to scale up the whole platform, just that service
- You can have several versions running simultaneously of the same service, allowing for version 1, 2, 3 of the platform to have subversions that fit the current customer, for example, let’s say that A = Login only with email and B = Login with username OR email), the result will be much faster code since you avoid an If/else statement (simplified):
- When one service grows, you can analyze it and divide it into several services
- And this is the big one, you can reuse your services, just like a code library but way easier
Pitfalls
As with everything, there are pitfalls and there will be bumps in the road when you start your journey towards using Microservices. A couple of things to keep in mind:
1. Documentation
Make sure you document the different Services properly, if you are a programmer you have probably used tools like Swagger before, that’s great but don’t stop there, make sure you also write something about the purpose of the Service, why you chose to build it with the current language and so on. Giving this a more “human” approach will help the next programmer a lot.
2. Think
Think before you act, you might say, “We always do that”, and we are sure you do, but when it comes to Microservices you have to take it a bit further. This is one of the tradeoffs, normal planning has to be done, but you have to think BIG, every Service you will build will be alone out their in the big world, ready to be consumed by anything you throw at it, so make sure you plan ahead, if you are building a SaaS solution, let’s say a bookkeeping system, make sure that your Service is prepared for when you add for example the invoice module.
This is a very short introduction when it comes to Microservices, this tutorial is basically here only to tickle your interest and make you curious, the next article will go more deeply in some of the basics.
Who Uses Microservices Today
From smaller companies to large enterprises, that are industry leaders, Microservices architecture is used across different applications today. This thread here on Quora shares the perfect examples of where you could see Microservices in action.
How To Move To Microservices
There are several ways to move your current platform to Microservices, as usual, they all have their pros and cons. There are two extremes, the first being to basically copy the platform that you have and create a “clone” using Microservices, the second being that you take one small piece of your platform (preferably a piece that you are updating or changing in some way) and create that piece by using a Microservice.
As previously stated, these are the extremes, we would never suggest to take any of these approaches (even though in one case we had to, more about that in a later article). The best approach to moving to Microservices is to find a way that lies between the two extremes.
Let’s start with looking at the two extremes and how that would affect your business. If you go all in and change everything at once, you will most likely run into several problems, the first thing to think about is how you develop your current platform. Most likely your platform is not stale, it constantly evolves so with this approach, when you have a clone of your platform, it will be outdated, of course, you could stop developing your platform as it is now, but most likely your customers would not approve of that.
If you take the other approach, and single out one small piece of functionality and simply build a small Microservices, you might end up with something that doesn’t work later on, the reason is that building a small Microservices is easy, many get tempted to take this small piece and just start to build. One example here would be your login functionality, it’s easy to set up the DB, it’s easy to enable your platform to communicate with the Microservices that handles the login functionality. But you have to think broader you need to keep the end goal in sight, what about compression, security, dB type and so on. It’s very easy to make a simple hack and think that you are on your way of building Microservices but it’s very likely that you will shoot yourself in the foot.
