What are Microservices?Examples Code,Tutorials and More ~ Technical Strom

There's a lot of buzz about microservices. These days everybody wants to create applications using the microservice architecture in this post let's look at,

What are Microservices?

But rather than reading out a like a list of architectural concepts we will approach this from a completely different place by me telling you a story that you really need to know. let's go back in time to the old days when we didn't have anything called microservices(one of the most important skills for Java developers)in fact we'll go so far back he'll go to a time when a computer was big enough to fill the room must have seen pictures of one of these things you would walk up to that computer you would give it all the instructions it needs to compute then it would take it and it would execute it all right fast forward a little bit to desktop machines again programs resided on the desktop machine the programmer application contains all the instructions that are needed to execute so when people would write applications for it their code would be compiled down and the whole thing would be installed on the computer in one go.

And it's been stalled on the same computer think of purely desktop only apps okay something like Microsoft Word or a text editor that you install on your machine this has historically influenced how we write code when we need to write an application we would start a new code project and we would add functionality into that project need more functionality add more code and so the size of the code base for any given application keeps increasing over time so,

what starts as a small codebase might end up turning into a large complex codebase over time and people realize this there were best practices that were created to handle large projects developers were recommended to break things up into modules so rather than put all your code into a single mess of a codebase create smaller modules and compose your application from these modules small independent parts that were focused on just doing a small amount of functionality these modules were supposed to be reusable so a simple module could be added to another project to help another application.

see isn't this awesome and then once you've created your application this way you're ready to build this whole application and deploy this on the machine that runs your application notice something here when coding your application you have all these modular constructs right nice fragmented organized pieces of functionality pieces code that composed together to form your application but still what you're doing is composing them to form one application and when you build it and apply it all those small pieces all get smashed together into one giant ball of distributable that is your final application build and that's what you'd apply to a machine again take the example of your text editor installer or Microsoft Word installer no matter how the developers of that application have modularized and organized their source code the final distributable the final executable is just one thing but everything's mush together this is important to remember.

Nice fancy modularized organized structure of the code but one application so the final deployed entity smashed because nobody cares how the application looks on the user's machine right and everything needs to be deployed on to one machine anyway this used to work for the most part for desktop applications people would happily develop and deploy applications this way and then and then there came along two things that would revolutionize and maybe even associate some changes to the way we build applications

What were those two things?

First was the onset of web applications people started to move away from applications that needed to be installed on the machine and towards web applications that would be installed on a remote server machine somewhere on the internet and then you from your machine can use your web browser to access the result off that execution on the remote machine think server-side applications the server would prepare the HTML that your web application needs to show and no applications are actually deployed on your machine but from your browser perhaps you just use your browser the actual application would be deployed on the server somewhere and your requests go to that thing and that process is it does whatever it needs to do and then returns back a response.

Now you might ask me how does this change things well for the most part nothing much changed initially the only change was instead of developers installing their applications and all the different users machines they would install them on just one server and all the users who just point to that seven access that server this was awesome right everybody gets automatic updates very cool but then the core and the deployment model was still the same nice fancy modularized organized structure of the core but all that composes to just one application and the final deployed entity smashed rather than deploying the smash on the user's machine they without deploying that smash in one place on the server then at some point of time due to various different reasons some people started wondering.

There must be a better way but wait let's pause the story for a bit and let's look at one other development that's been happening to applications over the years turns out web apps 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 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 hang on.

We have nice modular architecture on the code side of things isn't that 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 be handled 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 was called the monolithic application or monolithic architecture.

Mono means single lytic means stone the single stone monolithic this is the smash basically.

What are some of the disadvantages of this monolithic model?

(1) The bigger the deployment the more challenging the deployment let me give you an example let's say 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 comment by this new guy the company has just hired me 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 commit 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'd 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.

(2)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 back 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 a 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 application so a big ecommerce site has to be a lot more money to create these duplicate instances of the whole application then only a small portion of the app actually needs to be scaled up during the time of those spikes there are a few other challenges.

But I won't go into all of them now let's go back to the story - that one guy who said there must be a better way so the idea is like this back when we were 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 on you 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 smashed into one monolith and deployed into one machine.

Why not split the application into smaller mini applications then you can deploy these mini applications 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 catalogue application that just has the shopping catalog functionality and you deployed on a separate server your order processing done another server use a profile application on another server and let's say when the user wants to see the shopping catalog the view application which is another application makes a REST API call to the catalog applications 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 these 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 rest of the application. secondly scaling no problem during the holidays you scale up only the shopping catalog application you'll be creating more seven senses only for the many applications that you need so these mini applications our services are what are technically called microservices.

Microservices are a way of breaking your application or service down into standalone independent applications 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 finds the organization that you've been making to the code during development time well you can have fancy organized separation of concerns for your applications in their deployed state as well so you no longer have one application to build and apply you have several individual applications that I'll do like a small thing each but they 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 micro services independently they can put them on different servers or even build them in different languages or platforms these micro services talk to each other through rest.

So it really doesn't matter what language you actually use you no longer have to use a common language or platform what else 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 also have to realize this opens up a whole lot of questions for all the advantages that that microservices 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 applications in the form of micro services so you need to make sure you're not making things worse in general okay so you're separating 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 to add to your application if you need to make changes to ten different micro services it kind of defeats the purpose so you need to separate these applications well then there's a problem of how to make sure your micro services discover each other on a single machine on a monolith.

Examples of Microservices Frameworks for Java

(1)Spring Boot. This is probably the best Java microservices framework that works on top of languages for Inversion of Control, Aspect Oriented Programming, and others.

(2)Swagger. Helps you in documenting API as well as gives you a development portal, which allows users to test your APIs.