Hello Everyone. This will be the first part of my multi-part series which will explain the concept of microservices and how to orchestrate calls between them keeping in mind things like performance, latency and scalability. At the end of this series I intend to have a fully functional multi-tiered application which follows best practices for design and implementation. I will concentrate on one component per post and also share the source code on Git for your learning purpose and reference. CONCEPTS:  WHAT IS A MICROSERVICE ? The traditional way of building web applications was to build one single artifact (say WAR file) which will have all your functionality wrapped inside of it. This single application will do everything from serving user requests, running reports, CRON job, interfacing with databases and other external third part services. This kind of application is said to be Monolithic in nature. Microservice based architecture emphasizes on not having a single deployable artifact but to have multiple smaller independently deployable artifacts.  Each smaller artifact deals with only part of the applications functionality. All modules work together to provide the functionality required of the application. Advantages of Microservices over Monolithic 1. FASTER DEVELOPMENT Faster releases and changes out the door !!! Microservices consists of smaller independently deployable modules in comparison to a single deployable artifact in Monolithic architecture. This means that each application has its own code based. So, you can easily split your team into smaller functional teams and have them work independently on different modules without having each other step over one another or be blocked on some dependencies. If at all there are any dependencies, those can be easily mocked and the work can be carried out without any interruption. 2. BETTER UNIT TESTING More confidence with well tested code !!!! Since each module is just dealing with a subset of functionality provided by the application as a whole, it much easier to test manually or using automated tool. Its also easy for developers to write unit tests 3. CHOICE OF TECHNOLOGY Keep your tech stack up to date !!! The main goal is for all modules to work well together. It is not necessary for all of the modules to leverage the same technology or frameworks/libraries. Each team can choose to implement the module they own in whatever technology they have expertise in. This also means that it’s easier to keep the applications tech stack up to date with contemporary library versions and dependencies while giving each team the independence to do what they want. 4. SCALABILITY Scale independently, when and how you want !!!! Each module can be independently scaled up (vertical) or sideways (horizontal) to handle any spike in incoming requests. Modules performing any heavy lifting can scale vertically while those handing light weight stateless requests can scale horizontally. Microservices help you scale out and back again once the traffic spike is gone. 5. VIRTUAL MACHINE OR INSTANCE CONFIGURATION Save $$$ with infrastructure !!! With microservices you no longer need to have all your VM's or nodes have the same amount of resource. You are free to allocate more resource to more demanding modules and keep light weight modules on lean hardware. This will eventually help bring down the computing/infrastructure cost. 6. DOWNTIMES Less downtime impact !!!! Each module can be deployed independently without affecting the others. Also, if system is architectured well, the application can still be functional when one or more less important modules are brought down for maintenance or due to some issue. 7. MONITORING More granular monitoring More precise monitoring of the applications. Depending on what tools you are using one can easily find out how each module is performing and how its contributing towards any request latency. 8. EASIER PROBLEM ISOLATION Save time !!! Its much easier to isolate a problem to a particular module. This saves time and energy and avoids you having to debug the entire application as a whole. SOME DRAWBACK OF MICROSERVICES 1. PROBLEM ISOLATION AND TROUBLESHOOTING Since now you are dealing with a distributed system, it becomes difficult to isolate where something is breaking. It is easier to isolate the module but sometimes or most of the times the breaking module might have dependency on other modules for data. The incoming data might be the problem which could be due to an issue in the other module. Each developer would have a higher responsibility to understand the overall system and how different modules interact with each other. 2. OPERATIONAL OVERHEAD Many modules and different teams means that there is always some deployment happening somewhere. There is an operational overhead to take care of the deployments and ensuring that the updated components play well with the other existing components. 3. SPEED OVER DUPLICATION If the application is large there is a very possibility of having duplication of code/functionality in different modules. But this is a compromise that one has to make when demanding faster development and shorter release cycles for an application.

Different

Keep

Mind

Check out my Blog

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

MICROSERVICES - PART 1

Too Long; Didn't Read

Companies Mentioned

Elankumaran Srinivasan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

MICROSERVICES - PART 1

Too Long; Didn't Read

Companies Mentioned

Elankumaran Srinivasan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES