Rahul Singh rsingh@distelli.com

1. Build & Deploy Infrastructure for Startups Rahul Singh rsingh@distelli.com

2. Conventional Wisdom • Repeatable Business Model • Product Market Fit • Customer Development • Lean Startup / MVP • Build a Prototype • Do things that don’t scale

3. Conventional Wisdom is Correct • They’re all correct • Focus on building a product that someone will pay for • Most startups fail • Avoid Failure • What happens if you succeed?

4. Mt Gox • First major bitcoin exchange • Started out as Trading cards • Millions of Customers • Millions in Revenue • Lost $22 Million • Lost $400 Million • Mt Gox is Dead!!

5. Mt Gox • Software wasn’t built for Financial Transactions • Growth outpaced Technical Debt • Another Example: Twitter • Question: If things go well, will you be able to keep up? • Question: If things don’t go well will you be able to keep up?

6. Rate of Innovation • Tech startups must innovate • Tech startups must iterate • Lean Startup = MVP • Product Market Fit = Iterate fast • Your success is tied to how fast you can innovate and iterate on your product

7. Technical Debt Wikipedia: Technical debt is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

8. Technical Debt • Reduces rate of innovation • Reduces rate of iteration • How fast can you respond to Issues? • How fast can you add new features? • Focus on Product Market Fit but avoid technical debt from day one!

9. Do it Right the First Time • Do it right the first time • Modular code • Good build systems • Auditability • Accountability • Good Deployment System

10. Don’t Reinvent the Wheel • Reuse well known platform • Leverage open source • Use well known patterns • Avoid doing anything special • Let others handle the muck • Buy vs Build

11. Source Control • Use Source Control • Git • Mercurial • No reason to use SVN today • Hosted Source control: • GitHub: Popular • Bitbucket: Cheaper • Don’t host your own source control server

12. Lots of Repositories • Break code into modules • One Source Repository per Module • To work on a module: • git clone github.com/distelli/MyModule.git • make code changes • git commit • Rebuild all downstream dependencies

13. Dependencies • Common Pattern: • All code is in a single directory • No dependencies • Check out the world • Every change needs to rebuild the world • Module Dependencies • Java: Maven • Python: Pip • Ruby: Gems • NodeJS: NPM

14. Version each Module • Use Module Versions • Each module has a well defined name • Each module has a well defined version • Examples: • Java: HttpClient-1.4 • Ruby: Nokogiri-1.1 • Python: Requests-1.0

15. Build System • Let the build system track dependencies • Always know what all the dependencies are for each application • Java: Maven Pom.xml • Python: Distutils / Setuptools / Distribute • Ruby: Gemfiles

16. Build Artifacts / Releases • A compiled binary or frozen snapshot of your code with all its dependencies that work together • Also known as a Release • Build system produces an internally consistent release • Tag the release in your source control • Use an artifact repository: • Stores tagged releases • Eg: Nexus, Pypi, rubygems.org

17. Deploy Releases • Build System produces Releases • Releases are deployed to Servers • Deployment System deploys releases • Releases can be Tagged • Deploy to a staging environment • Promote to Production • Always track who deployed what to which server • When did they do it • Rollbacks if things break in production

18. Deployment System • Most Common: • Home grown scripts • SSH, SCP, RSYNC • Git post receive hooks • Everyone builds their own deployment scripts • Deployments are hard • Don’t build your own deployment scripts

19. Deploying Code is Hard • What version of the software is running? • Who deployed it? • When was it deployed? • How many servers are running? • How do we add instances (scale up)? • How do we remove instances (scale down)? • How to we handle server failures?

20. Deploying Code is Hard • How do we push a bugfix to all servers? • How do we rollback to a known good version? • What version of HttpClient is my app using? • What changed in this latest deployment? • Efficiency / Cost - Can we run multiple apps on a single Server? • Heroku is awesome… but... • Too Expensive • Enterprises don’t want to push code outside the organization

21. A New Way • distelli.com is a platform that makes it easy to deploy any application to any server • Easy & Secure • No SSH access required • No Code changes required • Code doesn’t leave your organization • Audit trails & History • Teams and Collaborative features • Works well with other tools

22. A New Way • Make deployments a part of the developer workflow • code -> build -> unit-test -> deploy to test stage • De-couple production deployments from development • Developers produce deployable code • Operations team deploys from test stage to prod

23. Interactive Q & A • Questions • Example Code • Talk to me if you need help