2. Scaling is the Developer's Job
Was:
• Write code, make it work
• If it get slow, buy:
• Bigger server
• Bigger database
• "Enterprise" software support
3. Needs Harmony Between
• Software
• Data Tier
• Development Infrastructure
• Deployment Infrastructure
• Team
• Ability to manage it all
4. Needs Harmony Between
• Software
• Data Tier
• Development Infrastructure
• Deployment Infrastructure
• Team
• Ability to manage it Best Achieved
all
with Good
Architecture
6. Common Mistakes…
• "Let's organize by horizontal!"
• "Back end shouldn't care what front end
does!"
• "Just get it launched and we'll scale with
hardware"
• "You can scale transparently with
technology X"
• "Get an Oracle consultant to speed things
up"
7. Common Problems
• Overly complicated interfaces
• Abstracted too many times
• "We can switch out entities with a simple
configuration!"
• Over-abstracted
• "We might need to change database vendors so
abstract the SQL layer"
• Over designed
• "We don't know how the client will call, so support
all possible calls!"
9. Directionally Speaking
• Go Vertical!
• Ability to understand full lifecycle
• APIs as the communication of choice
• General convergence on developers
• Databases (MongoDB, Cassandra, Dynamo)
• API frameworks
• IT & QA are disappearing
• Wordnik currently has *none*
• Team, infrastructure, discipline *win*
10. Directionally Speaking
• Go Vertical!
• Ability to understand full lifecycle
• APIs as the communication of choice
• General convergence on developers
Still Room
• Databases (MongoDB, Cassandra, Dynamo)
to specialize
• API frameworks
• IT & QA are disappearing
• Wordnik currently has *none*
• Team, infrastructure, discipline *win*
11. Vertical, Explained
• Big application => micro services
Monolithic
application
"Isn't this
just
SOA?"
12. Not SOA
• This is different
• No proprietary message bus
• Decoupled objects
• Dedicated storage***
• Speak REST
• Develop your services in…
• Java
• Scala
• Ruby
• Php
13. Speak REST?
• Sounds good but…
• REST semantics vary wildly
• HATEOAS vs. practical REST?
/api/pet.json/1?delete (GET)
/api/pet.json/1 (DELETE) All
/api/pet.json/1 (POST empty) valid!
So…
14. Speak REST?
• Sounds good but…
• REST semantics vary wildly
• HATEOAS vs. practical REST?
/api/pet.json/1?delete (GET)
Peer All
/api/pet.json/1 (DELETE)
Review! valid!
/api/pet.json/1 (POST empty)
Better
Docs!
So…
API
API Styleguide
Council! !
15. Hello, Swagger
• Swagger is…
• Spec for declaring an API schema
• A framework for auto-generating the spec
• A library for client library generation
• A JSON-based test framework
16. What is this Resource Declaration?
• Listing of all available APIs
http://petstore.swagger.wordnik.com/api/resources.json
“It’s like a
sitemap for
your API!”
17. What is this Resource Declaration?
• “But I don’t want it all exposed!”
• Swagger can filter APIs by permissions
Header,
Api key, URL,
Cookies, Method
OAuth
18. What is this Resource Declaration?
• Each api is documented
http://petstore.swagger.wordnik.com/api/pet.json
25. How does this help?
• Generate client libs
• Invoke methods not URLs
• Pass arguments, not query params
• Don't care about how service is developed
• Different versions of java?
• Different REST frameworks?
26. How does this help?
• Generate client libs
• Invoke methods not URLs
• Pass arguments, not query params
• Don'tRESTler? how service is developed
care about JAX-RS
• Different versions of java?
• Different REST frameworks?
Client
Play! Scalatra
doesn't
care
29. But What about Speed?
• Yes! REST over HTTP is slow
• Connection overhead
• Marshaling & Unmarshaling overhead
• Chatter
• JSON/XML need to diet
• It's also…
• Synchronous
• GET/POST/PUT/DELETE don't cut it
30. But What about Speed?
• Yes! REST over HTTP is slow
• Connection overhead
• Your
Marshaling & Unmarshaling overhead prod
• Chatter Database
• JSON/XML need to diet isn't doing
• It's also… REST
• Synchronous
• GET/POST/PUT/DELETE don't cut it
31. Websockets to the Rescue!
• It's…
• Full Duplex
• Persistent connections
• Completely Async
• But…
• Very finicky
• Wildly inconsistent server support
• Still in draft
32. Websockets to the Rescue!
• It's…
• Full Duplex
• Persistent connections
• Completely Async
• But…
• Very finicky
• Wildly inconsistent server support
• Still in draft
35. Swagger + Websockets
• Swagger sockets
• Same discovery interface
• Same client interface
• Same codegen
• But…
• Multiplexed connections
• Support for binary protocol
• Full Async
• Adding "subscribe" to GET/POST/PUT/DELETE
36. Swagger Sockets
• Live now on smartmoney.com
• Fully OSS
• Wire-protocol speed
• Format-agnostic
• JSON
• Binary
37. Summary
• Smaller, dedicated units of work
• Micro services => micro teams
• Full service knowledge
• Swagger is the Fabric for your Services
• Swagger sockets are like Fiber for your
grid's connectivity