What are Microservices ? | Microservices in action | THE SCIENTIFIC GUY

Microservices c# | Microservices java | microservices example

Hello Dear Readers of The Globe, 

Welcome back to my blog. As a software engineer by profession, I try to keep myself updated with technologies and also like to clear my doubts regarding its working and purpose. I see many people searching for terms in regard to latest technologies on google and they too want it to understand it as quickly as possible. 

I had this thing in mind that, as I am a software engineer by profession and blogger by passion it would be beneficial for me and for other people if I explained them the concepts in much simpler and easier way. It would add knowledge in me as well as I would be somehow will be able to help others in understanding things. As sir Richard Feynman have said, when you learn and share more, it builds good habit in sharing toughest problems or things to others in simplest forms as well as enriches one’s knowledge base. 

Hence now onwards I have thought of to blog on things like programming language (C#.NET), Software Engineering, Microservices, the evolving .NET Ecosystem, Best practices, Design Patterns, Tools and Technologies. 

Today we are going to learn & understand about microservices. You would have heard of this thing and whether you are java, C#.NET, python or any other language-based programmer and working in service-oriented architectures and designs, your organization may be having this microservices architecture in place or may be thinking of moving towards it. 

Don’t worry if such architecture is not in place in your company. But at least you should be familiar of SOA(service-oriented architecture). If you are completely new to microservices even its fine because today, we are going to learn what actually this architecture comprises of and what’s need for it to get this adopted. 

What are microservices ?

A microservice is an architectural pattern where every application function is its own service, and these services are deployed in containers, and these containers speak with each other via APIs. 

Monolithic vs Microservices

To better understand what a microservice is, let's compare it to a monolith. A monolith is a server-side system based on a single application. In dot net we have dll’s & In Java, for example, the application will be deployed in WAR or JAR files, and that's how it gets put into production. 

The thing about a monolith is, initially it's easy to develop, deploy, and manage. So let’s get a better understanding through an example. In this case, let's pretend we're a e-commerce platform and we sell various different products. In a monolithic world, that application might look like this. 

What are Microservices ? | microservices example
Monolith Application Architecture. 


We'd have a user interface. Another component would be the inventory system. We'd have a component that generates recommendations. based on user inputs. We'd have a cart. Some sort of a payment and ordering component. And then we also have a reporting engine as well. 

The thing to understand about monoliths is that, traditionally, they have a lot of shared libraries, so they're highly dependent on each other. If you change a library, you need to understand the ramifications of these changes. You could effectively take a whole application down to your change. Another challenge around a monolith is that you're locked into the framework and the language that the team picked when they built it. So additional componentry, as it gets added, needs to be written in those frameworks and languages, even if better ones are out there. So, that can be a problem as well. 

Another challenge is the growth. So, this might be great initially, but what happens is, user feedback comes in and the development team adds additional capability – additional functionality. In this case, we'll add in New service 1, 2, 3 & 4. 

So, what happens is as the application gets larger, it's less and less likely that people on the team can understand the whole thing unto itself. They might know little sections about what the application does and how it operates, but, holistically, that's a challenge. And that could lead to a lot of trouble in trying to deploy it as well as maintain the application. 

Speaking of deployments, deploying a monolith as it gets larger becomes more of a heroic task, where a change window needs to be implemented - usually on a Friday night - and the ops team would have to go wrestle with this monolith in trying to get it deployed to production and have it stabilized and ready for Monday morning when the load comes back on top of it. So that's a challenge there unto itself. 

Another challenge with the monolith is the ability for it to scale. In this example with the product company, if there's a high demand for tickets and there is lots of users, maybe. the payment system becomes under duress and it has some contention - it needs some help. In that situation though, the way to fix that would be to deploy the whole application again and that could be interesting. In this case, we have one version the application running right now. When the load comes up, we need to deploy the second version of the whole thing. That can take time, and by the time it gets deployed and stabilized, that peak might have subsided. And in that case, you've done nothing for your users because you've missed it - they're already gone. So that's one way to look at it. That's a monolith. 

Let's take a look at the same application deployed as microservices.

 

Microservices Architecture| microservices example | microservices architecture c#
Microservices Application Architecture

 

So, in a microservices-based deployment, we'd still have our user interface - that's a service inside of its own container. We'd have the inventory service. We'd have the recommendation engine deployed in its own container as a service - the cart, for example. We'd have some type of a payment capability as well as the reporting. Now, each one of these talks to each other, where needed, via APIs. 

There are benefits you'll see right off the bat. We'll understand that the team responsible for the reporting engine can use the language and framework that they want to use. The team that runs the cart, for example, can use their own language and their own framework that best fits their requirements. So that's a really interesting benefit. 

Number two, you're able to actually iterate at will. These containers and these services are front-ended by a DevOps pipeline. As a developer builds code or checks in code into the pipeline, it goes to the automated testing, once all that passes, that code can be deployed into production immediately. You're no longer beholden to the speed by which the other teams can operate. So, you're able to iterate faster, bringing value to your customers at a faster pace, which is wonderful. 

Additionally, if there is a change that breaks part of that service or breaks, in this case, the reporting engine, the whole application doesn't fall over. It still works. So, effectively, by using this model, you're reducing your risk, you're implementing smaller changes, and you're increasing value over time. 

Another really cool part is that you can actually add in new components over time, just like we did on the monolith. So we can add in New service 1,2…N. And they can all be in different languages and frameworks, which is wonderful. And they just communicate, again, over APIs. 

Another benefit of the microservice-based architecture is its ability to independently scale. If there are a lot of people trying to purchase products at the same time, and the purchasing or that payment system is under duress or is under some contention, the platform can spin up additional containers to help with the load. And when the load subsides, those containers can go away. So that's a wonderful way for the application to naturally breathe. 

So, let's review really quick: A microservices architecture is one where every application function is its own service deployed in a container and they communicate over APIs. You're given the ability to have independence with respect to the language and framework that you choose. You're able to iterate fast and when needed, and you're able to scale independently. So that's what makes microservices really interesting. 

If you liked this tech blog on microservices then please share it with your friends or colleagues who want to understand this architecture and main purpose of it. 

That's all for today. See you all in  next intresting tech blog wherein we will breakdown and learn new technology or concept. Stay tuned & thank you for spending time to read this blog.

Post a Comment

0 Comments