Building intermicroservice communication over the network is one of the hardest things in building microservices. The resiliency of microservice-based applications heavily depends on how well they handle interservice communication over an unreliable network. To make microservices resilient, the developers have to apply numerous resiliency patterns such as timeout, retry, circuit breaker, fail-fast, bulkhead, transactions, and failover/load balancing. Most of these patterns are implemented as part of the service logic, and microservice development technologies have to cater to such requirements. On the other hand, service meshes try to offer such commodity features as part of a shared communication infrastructure.
Kasun Indrasiri explores the importance of microservice resiliency; details resilience patterns for interservice communication, including timeout, retry, circuit breaker, fail-fast, bulkhead, transactions, and failover/load balancing; dives into transactions resiliency; discusses technologies for building resilient microservices; and outlines the role service meshes play in building resilient microservices communication.
Kasun Indrasiri is the director of integration architecture at WSO2 and an architect with over nine years of experience in enterprise integration and microservices. He’s an author and an evangelist on microservices architecture; his books include Microservices for Enterprise (Apress) and Beginning WSO2 ESB (Apress). Previously, he was an architect and the product lead of WSO2 ESB and a committer and PMC member of the Apache Software Foundation. He founded the Silicon Valley Microservice, APIs, and Integration Meetup, a vendor-neutral microservices meetup in the San Francisco Bay area. He’s a regular speaker at most WSO2 conferences and has conducted talks on microservices topics in most of the Bay Area meetups.
©2019, O'Reilly Media, Inc. • (800) 889-8969 or (707) 827-7019 • Monday-Friday 7:30am-5pm PT • All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. • firstname.lastname@example.org