Most people that I talk to still say no, there is no way that you can build anything in the FinTech area in the cloud, it just doesn't work, there are regulations, laws and so on that prohibits that. But if we ask about the specifics, nobody can really answer.
The reason for that is that there is nothing that prevents you from running your digital banking solution in the cloud. We specialize in AWS so it will be used as an example but ofc this applies to any cloud vendor with the same level of security.
So let's get a couple of things straight right away:
Statement: No banks use cloud solutions!
Answer: Read a bit more of example Bankinter, Stripe and Capital one (Capital One, Stripe, Bankinter)
Statement: Cloud providers are not compliant in our area!
Answer: They really are, have a look here.
Statement: Cloud providers are not as secure as doing things in-house!
Answer: They are way more secure than your normal setup in-house. Have a look here. If you were to mimic this in-house, that would really cost you an arm and a leg, if you use AWS, its included (simplification, but you know what it means).
OK, that's a small bit about the security and compliance in the AWS platform, now over to the fun stuff, the Microservices.
First of all, what is Microservices?
Microservices are a type of approach to building a mobile bank software platform (or program or whatever you want to call it, we will stick with platform).
A Microservice (note the singular) is pretty much what it sounds like, it’s a very small Service, focusing on one or very few tasks. Let’s look at Gmail for example, you can divide that into several Services, let’s look at a few:
Login
Retrieve email from the server
Send email
Now we have identified some Services, if you are a programmer, you might want to call these Services for Functions, Subroutines, routines, procedures or whatever, but its basically the same thing. Please note that in reality, a Service like Login would most likely be divided into several Services, but let’s keep it simple for now.
So, what is Microservices (note the plural)? Well, that is a collection of several Microservices. Think of it as Lego or some other type of building blocks that forms your entire platform. That doesn’t mean that everything must be a Microservice hosted on AWS, you can, for example, host a couple of HTML pages on your own server that consumes some Microservices that are hosted on AWS. I just know that you techies out there are asking one question: “How big part of the platform has to consist of Microservices for the platform to be called a Microservice platform?”, well, there is no clear answer to that question, but you simply have to go with your gut feeling, in a later tutorial, we will show how to move from a monolithic platform to a Microservices platform. When did the platform become a Microservices platform, at 50%, 70%? There is no real answer.
You don’t have to host everything on AWS, but it helps, AWS have a lot of features like security, encoding and so on that is really good. You can achieve that without using AWS to 100%, but it would require a little bit more work. But everyone’s situation is different, so you would need to figure out what is best for you.
So, is that it? That simple?
No, there are more to it. Microservices are pretty new when it comes to “IT time” so this might change in the future and different people have a different approach to things, but one can summarize a Microservice (note the singular) as a service that:
Have a very well-defined purpose
The Service runs in its on process
It communicates through HTTP API (there are variations here, more about that later)
It can be stopped and started independently of other Services
It can be upgraded and downgraded independently of other Services
It should have no knowledge of other Services and have to be able to “act on its own”
Why Use Microservices?
There are several reasons why you should use the Microservices approach to build your 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 having sub versions that fits 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.
Use case
Here is a very simple use case for a Microservice (remember that this is the first tutorial and I keep things simple). Let’s say that you have a SAAS application, it’s bookkeeping software. You then add the functionality to upload scanned images for receipts. You have tried and tried to calculate just how much storage you will need, but you can’t figure it out, there is no way of knowing. The solution is a Microservice that handles the upload of images and documents and storing them on AWS.
This solves a number of problems, first of all, the storage you get on AWS can be scaled up and down easily, no need to invest in HW to meet the worst-case scenario, but the real benefit is in the Microservice itself since you will most likely have a mobile app where for example people that travel can upload their expense receipts, with the Microservice you have already written the API for that mobile app, no need to reinvent the wheel. You are all set!
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 per 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 taking any of these approaches (even though in one case we had to, more about that in a later article). The best approach to move to Microservices is to find a way that lies between the two extremes.
Let's start by looking at the two extremes and how they would affect your business. If you go all in and change everything at once, you will most likely run into several problems, 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 built 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, and 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 to building Microservices but it's very likely that you will shoot yourself in the foot.
So, what's the best way to approach migrating your current platform to Microservices? You will have to find your own way of doing that as there is no general approach that works for everyone. But if you stuck with this question feel free to contact our team for advice, we would be happy to share our knowledge and experience!