Independently Deployable By breaking an application up into microservices, your teams can develop and release each service independent of another. This is a big deal when it comes to product or feature roll-outs. Teams no longer have to treat the software system as an unwieldy whole whenever they want to roll out a new feature. In the risk field, this notion behaves the same way. A data scientist interacts with a risk model in the same way a developer might change a login service. The data scientist can make changes to models or business logic, and those changes are validated, tested, and pushed back into the application. If you’re starting to get the idea that microservices also means organizational change that more closely aligns your development teams with your operational teams, you’re right. We will touch on that in the aptly named ‘DevOps’ section. Resilient Because a microservice is autonomous and loosely coupled, the failure of one service tends to happen in isolation of the rest of the system. The logic goes something like this: In a monolith, everything exists on one “circuit” (think of it as a string of those old fairy lights). If something fails, the entire system goes down. However, microservices exist like independent, battery-operated light bulbs. If one goes out, it has no impact on the remaining lights. This concept of fault tolerance is a huge driver in financial services, where downtime can have detrimental reputational and regulatory consequences. Consider this in a banking application, where a mission critical piece of functionality like payment processing would continue to function, even if something unrelated like a credit check microservice failed. Traffic can then be routed to a new instance because microservices tend to be stateless by design.
By breaking an application up into microservices, your teams can develop and release each service independent of another.
© 2017 PROVENIR ALL RIGHTS RESERVED
Made with FlippingBook Digital Publishing Software