XenServer, Hyper-V, and ESXi - Architecture, API, and Coding
API Architecture
-
Upload
ryan-kolak -
Category
Technology
-
view
340 -
download
0
Transcript of API Architecture
A short history lesson
Once upon a time, mainframes ruled the world.
Resources were precious and very limited.
A short history lesson
Many companies still rely on these systems today.
Not by choice, but due to heavy investment and commitment.
A short history lesson
Supply of qualified engineers continues to shrink.
Changes involve significant risk.
A short history lesson
Difficult to onboard new engineers.
Technical debt grows over time as fear prevents changes to existing systems.
Things got a little bit better
Rise of desktop computing replaces thin clients.
Client/Server architecture takes over.
Things got a little bit better
Web Browsers became “standard” clients.
HTTP provides a standard communication protocol.
But not really…
Multi-year projects were accepted as the norm.
Post-release updates were painful and very rare.
Waterfall methodology
Once considered state of the art and commonly accepted as a best practice.
Successfully reigned as the gold standard until the Internet came along.
Waterfall methodology1956 - Waterfall development model first presented publicly
1970 - First formal description in a paper by Winston W. Royce, criticizing conventional wisdom and labeling it “non-working”.
1985 - United States Department of Defense mandates waterfall as a standard for contractors (DOD-STD-2167A)
What’s wrong with waterfall anyway?
Early choices locks the project into a design.
Requires foresight into future business needs.
Rigid and not easily adaptable as technology evolves.
Speed to market is severely limited.
Things really get better
1994-2001 Agile Methodology
2002-2005 Web Frameworks (Rails, Spring, Django, Flask, ASP.net, etc.)
2006 Amazon Web Services
Things really get better
A simple prototype or proof of concept could now be built quickly.
Short iteration cycles can add functionality to quickly get to a Minimum Viable Product
Deployed easily without having to procure or configure hardware.
Pitfalls
Technology is a moving target that evolves quickly.
Scaling is hard.
Frameworks often are tightly coupled.
Microservices
Loosely coupled
Lightweight unix-like services
Rise of Docker and AWS services simplifies management
APIs
Business functions are encapsulated within API endpoints.
Easily consumed by client applications, without knowledge of backend implementation.
Allows for Engineers to focus on what they excel at
Architecting for Scale
Predicting growth is hard, overestimate to provide a buffer.
Individual components can scale independently without impacting the rest of the system.
Monitoring smaller parts quickly exposes bottlenecks or other performance issues.
Generative Technology
New platforms can consume the same API endpoints.
External partners can use your API and grow your business.
Public APIs will produce new and unimagined applications.
Twitter exampleTwitter began on Rails with a focus on SMS messaging.
Quickly outgrew their architecture.
Slowly replaced every portion of their architecture.
Invented new solutions to emerging problems.
Twitter API accelerated adoption
http://www.slideshare.net/RyanK/api-architecture
Twitter: @RyanK
http://elelsee.com