What is Microservices?

Microservices are both architecture and an approach to writing software. With microservices, applications are broken down into their smallest components, independent from each other. Instead of a traditional, monolithic, approach to apps, where everything is built into a single piece, microservices are all separated and work together to accomplish the same tasks. Each of these components, or processes, is a microservice. This approach to software development values granularity, being lightweight, and the ability to share similar processes across multiple apps.

Microservice architectures enable faster feature delivery and scaling for large applications

The core idea of microservices is to split the large system into loosely coupled services that can be deployed independently. That’s it.

What are the benefits of a microservices architecture?

Microservices give your teams and routines a boost through distributed development. You can also develop multiple microservices concurrently. This means more developers working on the same app, at the same time, which results in less time spent in development.

Ready for market faster

Since development cycles are shortened, a microservices architecture supports more agile deployment and updates.

Highly scalable

As demand for certain services grows, you can deploy across multiple servers, and infrastructures, to meet your needs.

Resilient

These independent services, when constructed properly, do not impact one another. This means that if one piece fails, the whole app doesn’t go down, unlike the monolithic app model.

Easy to deploy

Because your microservice-based apps are more modular and smaller than traditional, monolithic apps, the worries that came with those deployments are negated. This requires more coordination, which a service mesh layer can help with, but the payoffs can be huge.

When change is required in a certain part of the application, only the related service can be modified and redeployed—no need to modify and redeploy the entire application

Accessible

Because the larger app is broken down into smaller pieces, developers can more easily understand, update, and enhance those pieces, resulting in faster development cycles, especially when combined with agile development methodologies.

More open

Due to the use of polyglot APIs, developers have the freedom to choose the best language and technology for the necessary function.

Also easy to understand and modify for developers, thus can help a new team member become productive quickly

Better fault isolation: 

if one microservice fails, the other will continue to work

What are the Microservice architecture challenges?

complexity and efficiency are two major challenges of a microservice-based architecture.

1. 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. You also need to consider the effects that microservices have on your data.
2. Testing: Integration testing, as well as end-to-end testing, can become more difficult, and more important than ever. Know that a failure in one part of the architecture could cause something a few hops away to fail, depending on how you’ve architected your services to support one another.
3. 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. Alternatively, you could stand up multiple live versions for different clients, but that can be more complex in maintenance and management.
4. 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. 
5. Logging: With distributed systems, you need centralized logs to bring everything together. Otherwise, the scale is impossible to manage.
6. Monitoring: It’s critical to have a centralized view of the system to pinpoint sources of problems.
7. Debugging: Remote debugging through your local integrated development environment isn’t an option and it won’t work across dozens or hundreds of services. Unfortunately, there’s no single answer to how to debug at this time.
8. Connectivity: Consider service discovery, whether centralized or integrated.

When to Use Microservices

As a good starting point, these would be some of the ideal situations you can prefer microservices over their monolithic counterparts.

• When you want your monolithic application to accommodate scalability, agility, manageability and delivery speed
• When you have to rewrite legacy applications in today’s programming languages or tech stacks to keep up with modern-day business requirements and solutions
• When you have standalone business applications or modules that have to be reused across diverse channels—some good examples would be login services, search options, authentication facilities and more
• If you’re building a highly agile application (product or service) that demands swift speed of delivery, innovation and more

When Not to Use Microservices

As a starting point, here are some factors.

• Microservices are solutions to complex concerns and if your business doesn’t have complex issues, understand that you don’t have a system in place to handle the complexities of microservices.
• Using microservices can prove to offer contrary consequences if you don’t have a team size that cannot handle the tasks involved. This will only result in the delay of delivery.
• Implementing microservices for the sake of it can be hampered as well. If your application does not require to be broken down into microservices, you don’t need this. There is no absolute necessity that all applications should be broken down into microservices. There are those that are simple by their nature and functionality.