Articles, tagged with Microservices, providing techniques, guidance, and best practices for how to build web applications that scale to significant traffic volumes.
It’s simple, really — services call other services and they take actions based on the responses from those services. Sometimes, that action is a success, sometimes it’s a failure. But whether it is a success or a failure depends on if the interaction meets certain requirements. In particular, the response must be predictable, understandable and reasonable for the given situation. This is important so that the service reading the response can make appropriate decisions and not propagate garbage results. When a service gets a response it does not understand, it can take actions based on the garbage response and those actions can have dangerous side effects to your service and your application.
Bringing down an entire application is easy. All it takes is the failure of a single service and the entire set of services that make up the application can come crashing down like a house of cards. Just one minor error from a non-critical service can be disastrous to the entire application. There are, of course, many ways to prevent dependent services from failing. However, adding extra resiliency in non-critical services also adds complexity and cost, and sometimes it is not needed. Read the entire article today in The New Stack.
Microservices is a hot topic in software development circles these days. And for some very good reasons. Put simply, the traditional way of building enterprise applications—using a monolithic approach—has become problematic as applications get larger and more complex. So developers are turning to a microservices software development architecture, in which applications are structured as collections of loosely coupled services. This makes them easier to build, and—more importantly—much easier to expand and scale. Let’s take a closer look at how a microservices approach differs from a monolithic one, and examine their relative strengths and weaknesses.