Guide to Microservices

What is Microservices?

Microservices is an architectural design for building a distributed application using containers. Microservices get their name because each function of the application operates as an independent service. This architecture allows for each service to scale or update without disrupting other services in the application.

Ahh lesser techie definition required ?? Down below

So, Let’s imagine a government is trying to build or develop a Highway in their country but how the government will gonna plan for it. Well, answer they will divide the process into small processes and that’s it. they will build the highway in phases and even there will be more division for eg. material providing, testing, transportation for creating a system.

And that’s how in system design or software development for creating the big Distributed system we decompose the processes for developing. for like there will be many services running independently for supporting other services to become a proper system. like in this image given above.

Why it is better from other architecture

What sets a microservices architecture apart from more traditional, monolithic approaches is how it breaks an app down into its core functions. Each function is called service and can be built and deployed independently, meaning individual services can function (and fail) without negatively affecting the others. This helps you to embrace the technology side of DevOps and make constant iteration and delivery (CI/CD) more seamless and achievable.

Think of your last visit to an online retailer. You might have used the site’s search bar to browse products. That search represents a service. Maybe you also saw recommendations for related products — recommendations pulled from a database of shopper preferences. That’s also a service. Did you add an item to an online cart? You guessed it, another service.

That’s Why Microservices architecture are used so much in the Tech Industry so much

Advantages of Microservices

Developer independence: Small teams work in parallel and can iterate faster than large teams.
Isolation and resilience: If a component dies, you spin up another while and the rest of the application continues to function.
Scalability: Smaller components take up fewer resources and can be scaled to meet the increasing demand for that component only.
Lifecycle automation: Individual components are easier to fit into continuous delivery pipelines and complex deployment scenarios are not possible with monoliths.
Relationship to the business: Microservice architectures are split along business domain boundaries, increasing independence, and understanding across the organization.
Ready for market faster: Since development cycles are shortened, a microservices architecture supports more agile deployment and updates.

How can anyone start with Microservices?

Okay, First you should you know blah, blah, blah, blah, blah…….Well, you just need to know splitting up a process or decomposing the system. and just Design a system. That’s how easy is

First, try to make partition in services which you want to or could be
Second, Design to make run services independently from each other
Try to make services contributing to a service flow
Decide which building tools you will use for particular services.
Services synchronization (Most Important )
Building and deploying
Making standards
Fault Resolving
Monitoring and logging
Production Deploying

Challenges of Microservices

There will advantages but with some challenges also

Building: You have to spend time identifying dependencies between your services. Be aware that completing one build might trigger several other builds, due to those dependencies.
Testing: Integration testing, as well as end-to-end testing, can become more difficult, and more important than ever.
Versioning: When you update to new versions, keep in mind that you might break backward compatibility. You can build in conditional logic to handle this, but that gets unwieldy and nasty, fast.
Deployment: Yes, this is also a challenge, at least in the initial setup. To make deployment easier, you must first invest in quite a lot of automation as the complexity of microservices becomes overwhelming for human deployment.
Logging: With distributed systems, you need centralized logs to bring everything together. Otherwise, the scale is impossible to manage.
Monitoring: It’s critical to have a centralized view of the system to pinpoint sources of problems.
Debugging: Remote debugging through your local integrated development environment (IDE) isn’t an option and it won’t work across dozens or hundreds of services
Connectivity: Consider service discovery, whether centralized or integrated.

Examples of Microservices in Action

Let’s look at some examples of microservices in action. The enterprises below used microservices to resolve key scaling and server processing challenges.

1. Amazon

In the early 2000s, Amazon’s retail website behaved like a single monolithic application. The tight connections between – and within – the multi-tiered services that comprised Amazon’s monolith meant that developers had to carefully untangle dependencies every time they wanted to upgrade or scale Amazon’s systems.

Here’s how Amazon did it:

Developers analyzed the source code and pulled out units of code that served a single, functional purpose.
They wrapped these units in a web service interface.
For example, They developed a single service for the Buy button on a product page, a single service for the tax calculator function, and so on.

Amazon assigned ownership of each independent service to a team of developers. This allowed teams to view development bottlenecks more granularly and resolve challenges more efficiently since a small number of developers could direct all of their attention to a single service.

As for connecting the microservices to form the larger application:

The solution to the single-purpose function problem was the creation of a rule, to be adhered to by developers, that functions could only communicate with the rest of the world through their own web service APIs. “This enabled us to create a very highly decoupled architecture,” said Brigham, “where these services could iterate independently from each other without any coordination between those services, as long as they adhered to that standard web service interface.”

Amazon’s “service-oriented architecture” was largely the beginning of what we now call microservices. It led to Amazon developing a number of solutions to support microservices architectures – such as Amazon AWS (Amazon Web Services) and Apollo – which it currently sells to enterprises throughout the world. Without its transition to microservices, Amazon could not have grown to become the most valuable company in the world – valued by market cap at $941.19 billion on Feb. 28, 2020.

2. Netflix

According to a Netflix:

Our journey to the cloud at Netflix began in August of 2008, when we experienced a major database corruption and for three days could not ship DVDs to our members. That is when we realized that we had to move away from vertically scaled single points of failure, like relational databases in our data center, towards highly reliable, horizontally scalable, distributed systems in the cloud. We chose Amazon Web Services (AWS) as our cloud provider because it provided us with the greatest scale and the broadest set of services and features.

In 2009, Netflix began the gradual process of refactoring its monolithic architecture, service by service, into microservices. The first step was to migrate its non-customer-facing, movie-coding platform to run on Amazon AWS cloud servers as an independent microservice. Netflix spent the following two years converting its customer-facing systems to microservices, finalizing the process in 2012.

3. Uber

This microservice example came not long after the launch of Uber, the ride-sharing service encountered growth hurdles related to its monolithic application structure. The platform struggled to efficiently develop and launch new features, fix bugs, and integrate their rapidly-growing, global operations. Moreover, the complexity of Uber’s monolithic application architecture required developers to have extensive experience working with the existing system – just to make minor updates and changes to the system.

Here’s how Uber’s monolithic structure worked at the time:

Passengers and drivers connected to Uber’s monolith through a REST API.
There were three adapters – with embedded API for functions like billing, payment, and text messages.
There was a MySQL database.
All features were contained in the monolith.

To overcome the challenges of its existing application structure, Uber decided to break the monolith into cloud-based microservices. Subsequently, developers built individual microservices for functions like passenger management, trip management, and more. Similar to the Netflix example above, Uber connected its microservices via an API Gateway.

Moving to this architectural style brought Uber the following benefits:

Assigned clear ownership of specific services to individual development teams, which boosted the speed, quality, and manageability of new development.
Facilitated fast scaling by allowing teams to focus only on the services that needed to scale.
Gave Uber the ability to update individual services without disrupting other services.