There is a process we need to follow when designing Microservices architecture. We must not forget that designing Microservices architecture should be methodical. The worst thing that can happen when designing Microservices architecture is to rush into development. It should be like “Plan more, Code less”.
The more you plan, the more you think about the overall system mapping, the more you know what you are going into, the less you will code later.
And of course, the less we code, the fewer bugs we create and the less maintenance we have.
Following this process is critical to the project’s…
I will be listing down my articles about K8s best practices here, so we will have one stop place to access all as I write more in future.
More to follow :)…
One of the most common topics when talking about Microservices is breaking monolith to Microservices. A lot of organizations trying to go this path of converting their existing legacy monolith to modern Microservices system. There are various reasons for such migrations and we have to be prepared for such requests.
Many times organization wants to improve the current system and it believes that migrating to Microservices will do just that. This is not always the case as we have discussed earlier.
If you decided to go with the change, then you must make sure its is thoroughly planned and must…
If you read my previous articles, we have discussed what needed to design a robust, reliable and easy to maintain Microservices architecture. In reality, things are not going in correct way always. Microservices requires thorough design and a lot of the work is happening before writing the first line of code. They are not “Fire and Forget”. You can not just say to the developers that we are going to do Microservices and good luck with that ;).
In-fact, its quite easy to make mistakes that will cause the project to fail. …
We discussed lot about Microservices and why they are so good. Sometimes you should not use the Microservcies architecture. Microservices are not one-size fit-all solution. Designing every system as a Microservices system is a mistake which can lead to a lot of problems. There are cases where they should not be used. Even if we used, they might even cause damage and lead to failures.
Therefore use of Microservices should be evaluated on a case by case basis.
Small Systems
Small systems in general should not use Microservices. Small systems with low complexity should usually be a monolith. We should always remember…
We will discuss one of the most important aspects of the Microservices system, which is the logging and monitoring. Without proper logging and monitoring, we are going to have a lot of problems with our system. It might lead to its failure too.
As I said earlier, this is extremely important in Microservices projects even more than monolith. The reason for that is that in Microservices, the flow goes through multiple processes. In this case its difficult to get holistic view of the system or entire flow. Most of the time in traditional monolith, we can examine logs and see…
We will discuss one of the newest concept of Microservices architecture, which is “Service Mesh”. This is one of the hottest topics in Microservices architecture world and there are growing number of products, implementation and articles. It is also one of the most misunderstood concepts.
In order to take real advantage, we should know what it is and when we should use it or when not to use it.
What is Service Mesh?
In single sentence, it is managing all service-to-service communication aspect in a Microservices architecture. In addition, it provides some additional services that we will explore later.
Problems Solved by Service Mesh
As you know, Microservices communicates…
Testing Microservices based system has its own challenges and you should be well aware of them and the way to handle them. Testing is important in all systems and all architectural types. No system should ever go to production without going through a rigorous testing phase to make sure there are as few bugs as possible. Of course, no system is absolutely bug free, but we should try our best to minimize the number of bugs.
In Microservices, we have lots of processes and the moving parts and the potential of things going wrong is much bigger. In addition, testing…
Deployment of Microservices is extremely important. Remember the “Infrastructure Automation” attribute of Microservices architecture? This is exactly this. Slow and complicated deployment will render the whole system ineffective and useless.
In the Microservices system, we have lots of moving parts and if we have to test and deploy each one of them manually, then we are going to have a problem. The whole deployment cycle, building, testing and deployment must be as fast and as efficient as possible. If it is not, we will find out that working with monolith was actually simpler and quicker.
CI/ CD (Continuous Integration and Continuous Delivery/Deployment)
This means full automation of…
Now we know the basics of the Microservices architecture and its good time to revisit the problems we discussed earlier with other types of architectures to see how much Microservices deal with them.
We discussed problems caused by Monoliths and SOA. Microservices solve these problems.
Lets see how exactly are they doing it?
Single Technology Platform
We discussed that with Monolith’s all the components must be developed using the same development platform. Since monolith is by definition is a single process, there is no room to develop various components of it in different platform. That is not always good.
We want to be…
Ishan Liyanage
Passionate Technical Lead, Senior Software Developer and free and open source software advocate
