What are microservices really all about? – Microservices Basics Story.

Web applications have been growing very very incredibly very complicated over time the first web applications from the past did very simple
rudimentary things I don’t know like to tell you the time or something nothing too fancy but over time web applications have started becoming better bigger quicker more complicated bigger scale bigger user base bigger everything and today we have web applications that can you know to find something from the whole internet in a matter of milliseconds or find what cabs are available around you all over the world in milliseconds these
are incredible feats if you think about it and they need incredibly complicated code to be developed and applied and this complexity becomes
harder and harder to maintain

we have nice modular architecture on the code side of things isn’t enough to handle the complexity during development time who cares about how the application is deployed right ??

well with the type of applications we are talking about the complexity needs to handle not just at the coding side of things they also need to be
handled at the runtime or execution side of things having a single thing that you’d apply didn’t work anymore this way of having a single application called the monolithic application or monolithic architecture

Mono means single lithic means stone the single stone

Meaning of Monolithic

what are some of the disadvantages of the monolith

lets have an example :-

You want to push a new feature to your big monolithic application
alright so among all the code comets that you want to apply is the single code commit by this new guy the company has just hired may not so sure
about him, he probably doesn’t know much and he’s still learning but his first code commit ever is just sitting there and you’re worried what do you do well you need to test the whole thing before you deploy the whole application you never know which part of the application that commits might have broken.

well I’m exaggerating here of course but the fact remains since everything since the whole application is being deployed every time
you need to test the whole application every time you’de apply because anything in it could have a bug introduced and yeah you have automated
tests and all that jazz but it has a problem

The second problem with monolithic architectures scalability

here is an example online e-commerce sites they have very unpredictable traffic spikes right so let’s say there is a sale on some product people rush to the site like crazy and after the sale is over the traffic slows down
similarly, during holidays there is a spike and there is a dip, Thankfully these days we have elastic servers so when the traffic spikes up
the number of application server instances are increased but then when the traffic goes to normal the extra servers are retired that’s
great but imagine an entire eCommerce website deployed as a single monolith, this monolith has shopping functionality
user profile the returns functionality whole lot of other stuff
let’s say there’s a traffic spike on the shopping pages when the server scale-up notice that all the other functionalities should scale up as well
even though nobody’s using them they have to scale up because the whole thing is just one single applli9cation so a big eCommerce site
has to be a lot more money to create these duplicate instances of the application then only a small protein of the app actually needs to be scaled up during the time of those spikes.

Back when we are deploying to desktop machines we had to install the whole app on a single machine we didn’t have a choice but
wait now we have web applications the applications actually decide on a server the user was sitting at home on their computer or phone they don’t care where your application is or have you deployed or have you executed they just need one main entry point application to talk to and from
there one can run a single application on one machine or ten applications on ten machines nobody cares.

So here’s an idea rather than have the whole application smushed into one monolith and deployed into one machine why not split the application
smaller mini-applications then you can deploy mini-application on different machines you can have them talk to each other over the network and
together work as the bigger application take for example the e-commerce site you could create a shopping catalog application that has the shopping catalog functionality and you deployed on a separate server you order processing done another server use profile application on another server and let’s say when the user wants to see the shopping catalog the view application is another application makes a REST API call the catalog application API and say hey give me the list of products to show and the API returns the list and then the view application returns an HTML for that list so many applications talk to each other over the network by calling each other’s REST API to get whatever they want from each other okay well how would this help first

• The risk of deployment is eased making a change to the shopping catalog application well it’s a separate application you can test and apply just that you don’t have to test and apply The rests of the application.

• Second, scaling no problem during the holidays you scale up only the shopping catalog application you’ll be creating more seven senses only for many applications that you need so these mini-application or services are what are technically called microServices.

• Microservices are a way of breaking your application or service down into standalone independent application that can be run on different hardware or server instances they all talk to each other over a REST API and work together to provide the functionality of your application or product

So all that fancy organization that you’ve been making to the code during development time well you can have fancy organized separation of concerns for your application in their deployed
the state as well so you no longer have one application to build and apply you have several individual application that I’ll do like a small thing each but work together work with each other at runtime to form your actual complete application as far as your users are concerned

Now what are the advantages of microservices we’ve covered this you have flexibility different teams can create and apply microservices independently they can put them on different servers or even build them in different languages or platform these microservices talk to each other through rest so it really doesn’t matter what language you actually use you no longer have to use common language or platform

what they can be scaled separately during the shopping traffic spikes just scale whatever microservices are most used the other microservices are unaffected there are many more advantages of course but you all have to realize this opens up a whole lot of questions for all the advantages that that microservice have they also have some problems as well earlier you were dealing with one application now if you’re dealing with tens or maybe hundreds of mini-application int the form of microservices so you need to make sure you’re not making things worse in general okay
so you’re separating the application into microservices what does this separation look like how do you ideally split your application up into microservices so for example for every feature you need add to
your application if you need to make changes to ten different microservices it kind of defeats the purpose so you need to separate this application where then there’s a problem of how to make sure you microservices
discover each other on a single machine on a monolith it’s fairly obvious HUG services call each other but with microservices how do the services know which REST API endpoints to call in which environment do you hard code these URLs or do you have a process around service discovery so there are a whole lot of questions here that need to be answered and this,

In a nutshell, is the whole thing about microservice architecture answering and solving for these problems is exactly what microservice architecture is all about and it’s a sign own and it’s even part of its own before we wrap up this video though I should clarify that there isn’t a right or a wrong way to do these things in fact not all applications need to be architected as microservices no matter how buzzworthy the team is right now there are
many application that should be built with a monolithic architecture, please
don’t believe that microservice is somehow better than one of the tech applications they’re just different and both approaches have their own pros and cons.