Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Moving From API Design to Deployment


Published on

Designing and building APIs extends far beyond the RESTful interface. It requires thoughtful consideration about how you will draw the lines between capabilities vs optimizations, consume third-party APIs, and implement your cloud deployment strategy. This presentation looks at the API design process, AWS deployment, and moving to a message-oriented architecture

Published in: Technology
  • Be the first to comment

Moving From API Design to Deployment

  1. 1. Moving from API Design to Deployment James Higginbotham CTO, EvoSure @launchany
  2. 2. About EvoSure
  3. 3. Product Architecture Web App Backbone.js JRuby + Rails Only talks to the API Provides API endpoints for UX optimization that are not business capability APIs API JRuby + Sinatra Database Postgres 9.x
  4. 4. Designing APIs
  5. 5. API Implementation Model Capabilities Design and Document Endpoints Acceptance Tests (outside-in) Prototype Payload
  6. 6. Consuming APIs
  7. 7. Internal APIs No SDKs - direct APIs only Timeouts Retries Local storage when appropriate
  8. 8. External APIs No SDKs - direct APIs only Timeouts Retries Fallback behavior with UX focus
  9. 9. Deploying APIs
  10. 10. Monolithic vs. Modular Monolithic = API and Front-end in one app Modular = separation of subsystems into different apps
  11. 11. From Heroku to AWS Originally on Heroku with 2 apps: api and web Support for older browsers prevented this Moved to AWS for elasticity, security, and service offerings S3 CloudFormation RDS (PostgreSQL) Auto Scale Groups (ASGs) Elastic Load Balancer (ELB) Route 53 DNS Chef
  12. 12. Immutable Infrastructure Huh? Actually not that bad Infrastructure is a “promise” When the promise has to change, the stack changes Blue-green deployment model Patch deploys in between stack revisions
  13. 13. How we deploy to AWS CloudFormation templates define a stack Currently two stacks: „dev‟ and „prod‟ Stacks are versioned by name (e.g. dev3, prod3) New stacks started in parallel DNS switch when new stack is ready CNAME with 300 sec TTL
  14. 14. The Move to Messaging Business events are captured Drive behavior Allow for multiple actions from one message Requires eventually consistent view of data
  15. 15. Fluentd: Logging + Messaging
  16. 16. Thank you. @launchany