Let's begin with the most common statements on using cloud solutions for online banking platforms I frequently get from clients:

Statement #1: No banks use cloud solutions!

Answer: Read a bit more of example Bankinter, Stripe and Capital one (Capital One, Stripe, Bankinter)

Statement#2: Cloud providers are not compliant in our area!

Answer: They really are, have a look here

Statement #3: 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, thats a small bit about the security and compliance in the AWS platform, now over to the fun stuff, the Microservices.

What are Microservices? 

Microservices are a type of approach to building a 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:

1. Login

2. Forgot password

3. Retrieve email from server

4. Send email

Now we have identified some Services, if you are a programmer, you might want to call these Services for Functions, Sub routines, 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 have 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.

Is 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”

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

How to move to Microservices

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.

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 your 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.

The best approach to move to Microservices is to find a way that lies between the two extremes. For example, 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, 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.