Welcome to this series of tutorials around Microservices hosted on AWS, we will start out with the basics and follow up with more advanced tutorials, if you have any special requests for a specific topic, just let me know and if enough people shout out about it, I will cover that topic.
What is 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:
- Forgot password
- Retrieve email from server
- 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, as a programmer myself, I wish there were an answer to that question, but you simply have to go with your gut feeling, in a later tutorial, I 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
- The platform is cheaper to develop and maintain
- Easier to adjust 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
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:
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
Think before you act, you might say, “We always do that”, and I’m 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.
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 a 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 easy, 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. (Quora thread)
Happy coding everyone!