Seeing Micro Service in Astronomical Perspective — Thought Experiment
This is just one of many perspectives of seeing micro services that I made in order to make our imagination stays fresh, because the only limit of human is their mind. And telling you that most of the technologies we enjoy are based and closed related to our nature and the whole universe. Before starting our thought experiment, we need to understand the most basic fundamental of the ingredients for building an entire micro services. Here, we split it to 3 layers of the structure which are: the Infrastructure, Back-end and Front-end. These 3 layers are inbound to each other, so whenever one layer gets a problem and the others will follow. To understand why, we need to take a look what those 3 layers are actually doing.
- Infrastructure (The Big Bang)
The infrastructure layer is basically the starting point of building your application to be able to run. This includes the servers/clouds, databases, networks, nginx, message queuing like kafka or nsq and many more. You’re not making a app without working on some of these. But in micro services, you’re thinking huge, long term, efficient, and scalable infrastructure to support all of your services to be able to run perfectly with tiny rate of failure. - Back-End Service (The Time)
Why we need to think the back-end service as the time frame of the universe of micro service? The work of back-end service is mainly focus on recording the non-stop flow of data. That also contains the business logic, the data storing logic, and delivery to the front-end side. So, the bottom line is all about non-stop, always increasing data. The easiest example in order to give you a clear image about back-end (the time) is through digital video, it has data it stores in compressed format contains the image and the sound at the specific timeline. - Front-end Service (the matter)
In front-end every interaction counts, because this layer is the closest part of user satisfaction, and it helps to show how helpful, meaningful and easy to use your product is. And this part is where the change is constantly happening from old to new part of your product, since it always tries to adjust the user satisfaction to get the best value possible. And of course, the change is always containing the meaning and excitement that could help to improve the user satisfaction.
A question may appears in your mind why should we need to have another perspective that seems unrelated to micro service? This theory is just one from many ways to describe how micro service seems to behave and its nature. Based on those 3 fundamentals, it seems that Infrastructure is the core of everything, and yes it is. But, the other layers aren’t going to be used to describe how you should see the micro service from astronomical perspective. Instead we are going to use the best force in the universe, the Gravity. The more critical or with hugely dependents from other services are, the bigger the gravity it has. let’s see the image example below:
As you can see, here we describe the Sun as Infrastructure since it is a core of the services. But we don’t use term Back-end or Front-end to determine how we should see the micro service, since both of those are important and tie to each other as one. In this example, we see common terms which are Before Sale Services as described as Huge Planets since it carries huge dependencies to be used by other services. And after sale or unrelated to sale services, which also important but carry less dependencies to be used by other services.
Let’s put that perspective into a scenario. Say we have a service that handles the user experience to buy a product. Since it is a old architecture, the service covers add to cart, order management, payment, and and delivery management. In a year, your startup becomes a huge hit with traffic run 300% more than last year. But, Instead focusing on old architecture, you instead focus more on new feature. And this service has big dependencies that being used by other service.
In this perspective, this becomes a huge planet with massive gravity. let’s describe this service as the Jupiter of our micro service planetary system. Just Imagine or search it on internet, what would happen if Jupiter instantly removed? In the real planetary system, It won’t be scary in human time perspective since it would take a quite long time to reach the real disaster on earth, but not in the universe time perspective. And, what could happen to your micro service if your Huge Service instantly gone? It instantly becomes a real disaster to your user, and impacting the other services.
The more huge a service’s dependencies are being used by other service is, the more complex the system and code is. And of course, the bigger gravity of failures it has. No matter what there is no service that can run perfectly fine without failures, “anything that can go wrong, can go wrong”. In order to achieve the tiny rate of failures, we need a new view from the same perspective. Let’s expand our micro service not just as solar system, but beyond that point of view. Take a look of the picture below:
In this scenario, you have the center of galaxy or the galactic center where the supermassive black hole in Sagittarius A* located. Therefor you have the infrastructure that hold all your micro services together to stay stable. But, from this view, you won’t see any massive any massive service with its massive gravity of dependencies. Because they are more distributed and diverse. If you have balancedly distributed micro services and not creating another black hole service in your system, you could achieve a micro service with tiny rate of failures to support the stability of your application.
Conclusion
- Distribute the risk balancedly
analyze how big the risk of failures each micro service you have, with a good historical data of monitoring system. Never conclude something without data because it may caused you spending unneeded effort to diversify the risk of your micro service. But also always be aware of it. - Always have plans and visions
“Anything that can go wrong, will go wrong”, that’s why it is important to have scenarios and technical planning. Build your architecture and your system with well planning, analyzing and writing down the scenarios with your teams. Beside helps the teams to think critically, this could help build communication and awareness to your team about the importance of the micro service. Never stop updating your service, no service’s code that has no tech debt. - Perspective matters
Perspective is the way of how we process the data inside our brain. But with too much or less information to process, we wouldn’t make a good decision. If you’re isolating your view to see overall situation, you cannot achieve the truly micro service that support each other services, in order to bring the tiny rate of failures and stability to your application and products. Because there’s no miracles to achieve that, miracles are illusions caused by insufficient observation and understanding. So, always open your view, start question how good your micro service is, and do your research.
