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.
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