Karthik Gaekwad is a member of the cloud team at National Instruments who owns the Canopy user management and licensing platform. He discusses National Instrument's approach to cloud development which includes short monthly iterations to incrementally develop and deploy new features. Key aspects of their approach include modeling the end-to-end system, designing features to be reusable across platforms, extensive testing and monitoring, and getting early user feedback through demos.

1. Karthik Gaekwad
@iteration1

2.  Member of the Cloud Team @NI
 I’m the dude that plays the dude that designs
and implements REST Services and Web
Apps.
 Platform Owner- “Canopy”- User
Management and licensing for NI Cloud
products.

3.  Typically, NI has a yearly product releases
 Waterfalley
 Cloud Iterations: monthly
 Feature by Feature
 Features ready for production deployment at the
end of an iteration

4.  Few features at a time.
 Design->Implement->Test->Deploy

5.  We listen!
 Know what we are really trying to
accomplish.
 Who is my end user?
 Interact with the end customer.
 Do I understand the feature?

6.  Create ‘Research Item’ tasks
 Don’t have enough information upfront
 need to investigate an approach.
 Make this time bound.
 Goal: Know what a prototype would look like,
and how it may function.

7.  Create the Cloudlet Model
 Describes the end to end system.
 Dev and Ops communicate effectively.
 Core belief:
 Model Driven Automation.

8.  Design the feature
 Core belief:
 Build platforms, not applications
 Reuse existing platforms

9.  Proactive stance with @wickett on the team
 @wickett- CISSP, GWAPT

10.  Best practice:
 Don’t write crappy code
 Make it robust & resilient
 Fix bugs as soon as you can
 Get it reviewed
 Never release with known
bugs.

11.  Not Ctrl+S
 Source Control!
 We use Perforce/TFS
“If it’s not in source control, it won’t be
deployed”

12.  Unit Tests to test out individual methods
 Integration Tests to test out system
 Production Ready?
 Load Test
 Monitors that can execute
custom workflow checks
Worst advice ever

13.  PIE Time- Our homegrown DevOps tool.
 Create the PIE recipe (System Model Files)
 Deploy to the environment of our choice-
typically Dev/Test

14. People “get it” when they see it.
 End of Iteration demos
 Demos to the end users
 Iterate based on feedback

15.  Push to production
 Pushed by the Operation Team
 The act of pushing files to production
SHOULD NOT be a big deal.
 If it is, the process has holes.

16.  Cultivate an open culture
 Easier to track what happened with frequent
releases
 Internal Users can read at their own
convenience

17.  Don’t freak out.
 Figure out what (really) broke.
 Figure out why it broke.
 Accept that it happened.
 Fix the code!
 Write a new integration tests/ monitors for
this

18.  Know your end user.
 The customer is your biggest ally
 Agile is a process.
 Tweak it, to make it work for you
 Release Early, Release Often.
 Bigger the release, more stuff that will go wrong
 Harder to rollback
 Create integration tests that can be executed by
the whole team.
 Great when you are on vacation!

19.  Keep system designs simple.
 Complex cloud designs are brittle and hard to
scale
 Log like a champion!
 But not sensitive data
 Create APIs to measure metrics.
 Even more important in the cloud
 If you do something awesome, tell people.
 Others are solving similar issues #DevOpsCulture

20.  Questions?
 Find me here or on twitter @iteration1