Date post: | 04-Dec-2014 |
Category: |
Technology |
Upload: | bhavin-javia |
View: | 648 times |
Download: | 3 times |
Text
12 Steps to DevOps NirvanaBhavin Javia @bhavinjavia Founder @
!=
+
What ismethodology to build SaaS apps
triangulation of best practices
development, deployment, scaling of 100,000s of apps
organic growth, collaboration, avoid software erosion
awareness, shared vocabulary, conceptual solutions
Who should read ?Devs building SaaS apps
Ops engineers managing SaaS apps
Apps written in any programming language
Apps deployed on the cloud
I. CodebaseTracked in version control
One codebase per app
Many deploys
Same codebase, different versions
Mutiple apps == Multiple Codebases (and Apps)
Extract Libraries to share code
II. DependenciesNever rely on system-wide packages
Dependency declaration & Dependency isolation
Use tools for both
Simplifies setup for new devs
Vendored system tools (controversial)
III. ConfigAnything that varies across deployments
Except internal app config
Strictly separate config from code
Litmus Test: Can you open source it RIGHT NOW ?
Store config in Files (good) or ENV vars (better)
Grouping of ENV vars (does not scale)
IV. Backing ServicesAny services consumed over the network
Attached resources
No distinction b/w
Local & Third Party services
Service == Resource
Resources attached or detached at will
V. Build, release, runStrictly separate stages
1. Build Convert code to executable ‘build’ Can be complex
2. Release Combine build
& config Immutable
3. Run run the release keep it simple
VI. ProcessesOne or more processes
Stateless and share-nothing
Process Memory/FS == transactional cache
Store persistent data in stateful backing storage
No sticky sessions (controversial)
VII. Port bindingExport services via port binding
App binds to HTTP port
Most server software can use port binding
One app == backing service for another
VIII. ConcurrencyScale out via process model
Scale == Running Processes
Workload Diversity = Process Types
Does not exclude internal threads, evented model
Adding concurrency is simple and reliable
Never daemonize and use a Process Manager
IX. DisposabilityProcesses are disposable
Minimize startup time
Shut down gracefully
Should handle hardware failure
Return jobs back to the queue on failures
X. Dev/prod parity
Keep Dev, Staging, Production similar
Reduce gaps in Time, Personnel and Tools
Design for Continuous Deployment
Mind parity issues in Backing Services
Lightweight, local services less compelling
Use same type & version of backing services
XI. LogsLogs == Event streams
Provide visibility into running app
App not concerned about routing/storage
Route all logs to single destination
Index and analyse logs for
Find past events
Graphing of trends
Alerting
XII. Admin processesRun admin tasks as one-off processes
DB migrations
REPL shell
One-time scripts
Run Admin process in identical env
Run against same release
Ship admin code with app code
Is it for me ?These are broad, conceptual guidelines
You might have
Env specific differences
Organizational constraints
Infrastructural constraints
YMMV
See what works
Thank You@bhavinjavia
[email protected]://speakerdeck.com/bhavinjavia http://www.slideshare.net/bhavinjavia