austin scales - ostrich (lightweight soa framework)
DESCRIPTION
Brandon Beck talks about Ostrich, Bazaarvoice's service oriented architecture library that enables easy deployment and maintenance of loosely coupled services in the cloud.TRANSCRIPT
OstrichBrandon Beck, Engineering Lead
Why SOA?
What is a Service Oriented Architecture?
http://en.wikipedia.org/wiki/File:SOA_Metamodel.svg
What is a Service Oriented Architecture?
SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications.
These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.
● Decoupled software
● Decoupled teams
● Decoupled deployment
Why SOA?
Ostrich
● Bazaarvoice authored library to help build service oriented architectures
● Lots of services at BV using it in production
● JVM based
● Open source
Use Cases
● Automatically adapt to maintenance and outages
● Minimize manual configuration needed to interact with a service
● Focus on server to server communication within a single data center
Concepts
● Registry/Discovery○ Who is out there? How do I tell others about me?
● Load Balancing○ Which one should I use?
● Error Recovery○ I really did need that answer...
● Client Libraries○ How do we communicate?
Best Practices
Registration and Discovery
● Use a live, automatically updating view of the world
● Including updates when processes crash
● We use ZooKeeper ephemeral nodes for this
Error Handling and Retries
● Wrap every call to a service in an error handling/retry loop
● Expect failures to happen and distinguish between transient failures and systemic ones. Make all operations idempotent!!!
● In Ostrich we made it so that all remote operations require error handling
Health Checks
● Require services to be able to make a declaration of whether or not they're healthy
● Otherwise after a failure you have no idea when you can start using a previously unhealthy service again
● Ostrich requires that all service providers implement an "is healthy" method
Client Libraries
● Make your service authors also provide a client library for communicating with their service
● Produces better quality and standardized integrations
Examples
CalculatorService
Retry Loops
Service Factory
Client Library
Other Cool Things
● Dynamic Proxies
● Yammer Metrics
● Consistent Hashing
● Configurable EndPoint Caching/Pooling
● Async Operations
Questions?
● GitHub project pagehttp://github.com/bazaarvoice/ostrich
● Maven artifacts<dependency> <groupId>com.bazaarvoice.ostrich</groupId> <artifactId>ostrich-core</artifactId> <version>1.5.0</version></dependency>