Have you ever wondered what are Microservices? Your quest for the truth ends here. Throughout this piece, we’ll make it a point to answer the same in utmost detail and precision.
There’s a specific reason we’re compiling this piece today. When we searched for the term “What are Microservices?” on the web, the results were pretty confusing. They were written from a technical POV, or just too complex to understand.
Not everyone understands APIs, REST, Containers etc. So, we’ll scribble this piece down in a way that a 5th grader can understand it. Sure there may be terms you do not understand, but you’d still get a solid idea of what Microservices are.
What are Microservices?
Micro-Services- meaning small services. Microservices are a new way of developing programs and applications in which the application is broken down into multiple smaller parts.
These parts are then individually developed, maintained and progressed. The sum of all these smaller applications is what makes up the parent application as a whole. These smaller parts are called Microservices.
They still communicate to one another via various modes, such as APIs, HTTP etc. This makes sure there’s coherence between different parts of the applications. Yet, they aren’t completely dependent on each other.
It’s like developing multiple small applications/features and then bringing them all together to form the larger application. This allows the creation of different teams to handle the different Microservices. Each team may have its own preferred coding language as well.
(Image credits: Rising Stack).
Microservices have the capability to maintain their own databases. So there’s no single database for the entire application, rather independent databases for each Microservice.
Microservices can even employ “Polyglot Persistence”, meaning a variation in database types. So not all services need to have the exact same DB type and they’ll still function normally.
A real-life example can be best seen at E-commerce sites. When using the E-commerce portal, we see multiple features such as search, compare, add to cart, recommendations etc.
All of these are separate services, which can be (and are) developed as Microservices. The user doesn’t feel a difference, but because these are independent they do not influence the parent application negatively.
So in case the search functionality of a website fails, and if it was developed as a Microservice, it won’t bring down the entire website. Rather, the search-functionality can be fixed independently.
But in order to understand Microservices, it would help if you know what was used before Microservices came around.
What is Monolithic Architecture?
Monolithic applications are basically the opposite of Microservices. They do not have multiple parts.
The entire application depends on one, single, monolithic architecture. The primary problem in this case is dependency. If one function fails, the entire program/app/website fails.
The programs aren’t loosely coupled as is the case with Micro services. Hence, each of the components must be available and functioning in order for the program to work as a whole.
Also, any change in any process of the application would mean the entire program would need to be changed.
Although it’s not completely without its advantages, let’s look at some of them:
- Simpler development process.
- Easier deployment.
- Simpler testing environments and debugging. (Fewer elements = fewer problems).
Problems with Monolithic Architecture
While the benefits seem alluring for small programs/projects, it’s not adequate for larger organizations. The downsides of Monolithic architecture far outweigh its advantages.
- Single point of failure. One process fails, the entire projects shuts down.
- Making changes to Monolithic Architecture is much more time-consuming.
- Almost all the functions/processes depend on each other heavily.
- Development has to be horizontal. Independent sections can’t be developed/changed without effecting the rest of the program.
- Not era-friendly. When there’s a technological upgrade, Monolithic programs can’t make the shift as easily as programs built using Microservices.
Now these are some of the problems which made companies shift from Monolithic to Microservice developments.
What are the Microservice Benefits?
You should have a decent idea by now of what Microservices are. But what are the direct benefits of employing Microservices? I mean they’re smaller programs/functions, so what? How does that benefit a project or a company?
For starters, the independence that each Microservice holds from its parent application and other services is liberating. Teams can develop each function independently, in their own language and database preferences. This provides for more freedom both creative and others.
Then again, you can make independent changes to each Micro Service. There’s no risk of the changes seeping into the larger program and causing unwarranted problems.
Smaller services can be more precise and accurate. The team for each service only focuses on that specific service, hence resulting in much better outputs.
Scalability is another major advantage of Microservices. Companies can scale each Microservice independently, without having to involve the other services or the parent application. These also can be integrated with other third-party services more easily because these services are independent.
Understanding and developing the program as a whole becomes a lot easier. Then there’s reusability. The same Microservice maybe used for different instances of the program, or even with completely different programs with minor tweaks. This makes Microservices into an asset rather than just programs and functions.
Ability to use containers (such as Docker) is another one of the advantages. Containers basically help developers use completely different environments, without causing conflict. These are basically Virtual Machines of sort, just for apps. Each app runs in its own environment, isolated and separate from the parent environment.
Continuous deployment is possible for Micro Services. They even can be automated using tools like Jenkins which isn’t possible with Monolithic architectures.
Bottomline, Micro Services are the current trend, and requirement.
Problems with Micro Services
We vowed to answer the question –“What are Microservices?”. And it can’t be fully honest without the complete truth.
Sure Microservices are great, but it’s not all rainbows and sunshine. It has its own set of challenges as well. For e.g. here’s an excerpt from Martin Fowler’s blog:
Martin helped conceptualize Microservices and hence his views sure count. Then, Segment (a data analytics company) told a website (Computer World) that making small changes frequently, maintenance and deployment was a headache once they shifted to Microservices.
Testing Microservices with perfection isn’t always
possible as well. Developers can’t always create all the interaction scenarios
for their specific Microservices.
And finally, deploying Microservices is another downer as compared to deploying Monoliths. With Monoliths, the program can be deployed with identical servers and load balancers. While with Microservices, you’ve got to take care of multiple runtime instances.
Types of Micro Services
Microservices have two primary types (other loose categorizations may exist):
- Stateless Microservices.
- And Stateful Microservices.
Stateless Microservices simply are void of any “session state” maintenance. Or in other words, individual service instances do not effect the entire service as a whole.
Stateful Microservices on the other hand do maintain session information. Not the most ideal case, but it has its own applications as well.
Current Micro Service Usage
We’ve been singing praise-songs for Micro Services. But what about real-world acceptance and use? Well let’s talk briefly about some of the companies that implemented microservices, and how it made a difference.
Walmart, one of the biggest retail companies on the planet skyrocketed its conversions by 20% and mobile orders by 98%. It also was able to achieve 0-downtime sessions even on mega sale-days such as Black Friday. (Source: Risingstack).
Today, Amazon the largest online retail makes over 50 Million deployments a year solely because of its Microservices. And this is just the tip of the iceberg. Nearly all the big companies are already making the switch!
Final Words on What are Microservices?
Wrapping this up, all I can say is Microservices are independent pieces of a program, which make the parent program function at its best.
Are they the future? That’s debatable. Companies like Segment have reverted back to Monolithic development indicating not an universal acceptance of Microservices. Yet, the advantages are clearly recognized as well as accepted by majority of the world.
So well, it’s all a game of balance. If your enterprise is big enough and the cons can be managed, the Pros of Microservices sure are more than rewarding. I’d love to know if this piece gave you atleast some idea regarding Microservices and their use? Make use of the commentbox to voice your opinions, questions or suggestions
