#iswithin | Explore Tumblr Posts and Blogs

knoldus · 7 years

Link

Ever wondered why do companies like Apple, eBay and Netflix care so much about microservices? What makes this simple architecture so special that it is being hyped so much? Is it worth the pain and efforts to shift an entire running application from monolithic to microservices architecture? Many such questions came to our minds when we started using the microservices in our projects. In this blog, we will try to cover the answers to these questions and have a deeper look into the microservices architecture and compare it with the monolithic architecture.

What Are Microservices and how are they different from Monolithic?

Microservices are small, autonomous services that work together. Let’s simplify this definition a little bit more. Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. Codebases grow as we write code to add new features. Over time, it can be difficult to know where a change needs to be made because the codebase is so large.

Within a Monolithic system, we fight against these forces by trying to ensure our code isWithin a monolithic system, we fight against these forces by trying to ensure our code is more cohesive, often by creating abstractions or modules. Microservices take this same approach to independent services. We focus our service boundaries on business boundaries, making it obvious where the code lives for a given piece of functionality.

Why not Monolithic Architecture?

The main question here is that if we have a fully functional monolithic application running, why is there a need to convert it? Why is there a need to increase the overhead and put in extra efforts? And also is the conversion worth the pain and efforts?

The first thing we need to understand is that “Monolithic Applications are not Evil”. Change and Evolution are a part of life. Although monolithic applications did solve many of the classic architectural problems like Deployment (as it is to be deployed as a single unit) and also testing it is also easier, it has far many drawbacks as compared to the benefits. The major problems we face while working with the monolithic applications include :

Scalability – Scaling the application can be difficult – a monolithic architecture is that it can only scale in one dimension. On the one hand, it can scale with an increasing transaction volume by running more copies of the application. With a monolithic architecture, we cannot scale each component independently. So the entire application needs to be scaled even though most of the applications might not require scaling.

Reliability – Another problem with monolithic applications is reliability. Bug in any module (e.g. memory leak) can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.

Availability – Even if one service fails, the entire application has to be brought down. As all the services are deployed as a single unit, it is a headache to pull down the application each time a service fails or a bug appears up.

Agility – In a monolithic application, even if a small component in an application has to be changed, the entire application needs to be repackaged and assembled together. So we can definitely say that application has reduced agility since rebuilding the whole application takes a decent amount of time.

Continuous deployment – If you bring in Continuous delivery in to picture then it fails miserably on this side since even for a small change in the application, build time increases tremendously and it definitely decreases the frequency of Deployments. Moreover, You must redeploy the entire application on each update even if it is a small change.

Software Stack Autonomy – Monolithic applications have a barrier to adopting different software stack. Since changes in frameworks or languages will affect an entire application it is extremely expensive in both time and cost.

Apart from these issues, there are many other issues that programmers keep facing while working with the monolithic applications. So taking these issues into account, there seems to be a requirement for a different architecture which can at least resolve some of these issues. This is where Microservices come into the picture.

Microservices – A Saviour?

So now, we have gone through some of the problems one can face while working with the monolithic applications. So, can the microservices overcome those problems? Are they any better or are they just another architecture that is being hyped?

So, as we have already seen, that the main idea of Microservices is to split your application into a set of smaller, interconnected services instead of building a single monolithic application. Each microservice is a small application that has its own architecture consisting of business logic.

Now that we have a rough idea about the microservices, let us go through some of the advantages that microservices provides us which the monolithic architecture couldn’t :

Scalability : Each Micro Service can scale independently without affecting other Micro Services. Thus it definitely serves an advantage over monolithic application wherein a lot of resources are wasted for scaling unrequired services since they are all packed together into one single deployable Unit.

Reliability : A microservice’s fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith. Even if one service fails, other microservices are highly available and the failed micro service can be rectified very quickly

Availability : Rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith. The failed micro service can be rectified very quickly with as minimal downtime as well.

Agility : Changes in a particular micro service can be done very rapidly and can be deployed very quickly which makes it highly suitable architecture forever-changing business requirements meaning highly agile environment.

Continuous deployment : The microservice architecture enables each microservice to be deployed independently. As a result, it makes continuous deployment possible for complex applications. Moreover, Unlike Monolithic Applications, code changes in microservices can be done very quickly with changes in business requirements which results in a faster development cycle.

Software Stack Autonomy : With microservices, as each service is independent and each service is a new project, each service can be developed in any language that is best fits for the requirement. Thus, different software stacks can be used for different microservices.

Apart from these microservices also provide us with certain more advantages :

Management: The application development effort is divided across teams that are smaller and work more independently.

Data decentralization : There is no centralized database. Each module has its own, so there’s data decentralization. You can use NoSQL or a relational database depending on the module.

Better Understandability : The distributed services make it easier for a new developer to understand the functionality of a service. Also, as a particular module is dedicated to a particular service, it helps the developers to have a better understandability of that service rather than trying to figure out the entire application.

and the list goes on and on………..

But wait, No one is Perfect right? Neither are Microservices

Just because something is all the rage around the industry, doesn’t mean it has no drawbacks. Believe it or not, Microservices are not perfect. They do have a different set of drawbacks. Let’s have a look at some of them :

Operational Complexity: You need a mature operations team to manage lots of services, which are being redeployed regularly.

Testing : Testing a microservices application is also much more complex than in case of a monolithic web application. For a similar test for a service, you would need to launch that service and any services that it depends upon.

Deployment : Deploying a microservice becomes more complex with many jobs, scripts, transfer areas, and config files for deployment in case of distributed systems.

Multiple databases and transaction management : Microservices has the partitioned database architecture. Business transactions that update multiple business entities in a microservices-based application need to update multiple databases owned by different services.

Communication : With microservices, each service communicates through API/remote calls, which have more overhead than with monolithic software’s interprocess communication calls.

The Complexity of a Distributed System : As a distributed system microservices introduce a level of complexity and several issues to take care of, such as “network latency, fault tolerance, message serialization, unreliable networks, asynchronicity, versioning, varying loads within our application tiers etc.”

Now we have a rough idea of what monolithic and microservices are and what there pros and cons are.

To summarize, The Monolithic architecture better suits simple, lightweight applications. Whereas, The Microservices architecture pattern is the better choice for complex, evolving applications despite the drawbacks and implementation challenges. So one needs to make their choice wisely before starting off with either of the architectures and also consider that the efforts you put in for the transformation or migration from monolithic to microservices are worth the pain and complexities.

In our next blog, we will be looking forward to talking about some of the best practices one should take care of while moving towards the Microservice architecture. So stay tuned for more.

Hope this helps. Happy Coding

#WordPress

0 notes