At National Instruments, we have developed an automation and provisioning framework called PIE (Programmable Infrastructure Environment) that we use daily on our devops team. Similar tools are available such as chef or puppet, but what makes PIE unique is its ability to work in multi-cloud deployments (Azure and AWS) along with multiple node OS types (linux and windows). It uses zookeeper to keep state and track dependencies across nodes and services. When building PIE we actively considered how to implement it in a Rugged way for a DevOps team. As noted in the deck on slide 68, we are Rugged by Design and Devops by Culture. We see these as intersecting domains that have the ability to impact each other. For more info see ruggeddevops.org

1. Coding Secure
Infrastructure in the Cloud
using the PIE framework
Peco Karayanev
James Wickett

2. @wickett
• Operations and Security for software
delivered on the cloud
• National Instruments, R&D
• Certs: CISSP, GSEC, GCFW, CCSK
• Tags: OWASP, Cloud, DevOps, Ruby
• Blogger at theagileadmin.com
• I do stuff for LASCON (http://lascon.org)
• Twitter: @wickett

3. @bproverb
• Peco Karayanev
• OpNet, Senior Applications Engineer
• Tags: APM, Java, DevOps, Big Data
• Blogger at theagileadmin.com
• Twitter: @bproverb

4. About OPNET Technologies, Inc.
Corporate Overview
• Founded in 1986
• Publicly traded (NASDAQ: OPNT)
• HQ in Bethesda, MD
• 600 employees
• Worldwide presence through direct offices and
channel partners
Best-in-Class Solutions and Services
• Application Performance Management
• Network Performance Management
Strong Financial Track Record
• Long history of profitability
• Annual revenue: $140M
• 25% of revenue re-invested in R&D
test
Broad Customer Base
• Corporate Enterprises
• Government Agencies
• Network Service Providers
OPNET Confidential – Not for release to third parties
4 © 2011 OPNET Technologies, Inc. All rights reserved. OPNET and OPNET product names are trademarks of OPNET Technologies, Inc.
Rev. 04-01-2011

5. National Instruments
• 30 years old; 5000+ employees
around the world, half in Austin,
mostly engineers; $873M in
2010
• Hardware and software for data
acquisition, embedded design,
instrument control, and test
• LabVIEW is our graphical
dataflow programming language
used by scientists and engineers
in many fields

6. From toys to black holes

7. Cloud @ NI
We built a DevOps team to rapidly deliver
new SaaS products and product functionality
using cloud hosting and services (IaaS, PaaS,
SaaS) as the platform and operations, using
model driven automation, as a key
differentiating element.
With this approach we have delivered
multiple major products to market quickly
with a very small staffing and financial outlay.

8. NI’s Cloud Products
• LabVIEW Web UI Builder
• FPGA Compile Cloud
• more to come...

9. ni.com/uibuilder

11. FPGA Compile Cloud
• LabVIEW FPGA compiles take hours and
consume extensive system resources;
compilers are getting larger and more
complex
• Implemented on Amazon - EC2,
Java/Linux,C#/.NET/Windows,
and LabVIEW FPGA
• Also an on premise product,
the “Compile Farm”

12. Our design tools are primitive

13. Our operation tools
are primitive

14. Our system engineering
challenges are greater
< year 2000
the modern era

15. If you want to build a ship, don't
drum up people together to collect
wood and don't assign them tasks
and work, but rather teach them to
long for the endless immensity of
the sea
- Antoine Jean-Baptiste Marie Roger de Saint Exupéry

16. The vision

17. What is Rugged?

18. Adversity fueled
innovation
• NASA in Space
• Military hard drives
• ATMs in Europe

19. The Internets is Mean
• Latency
• Distribution
• Anonymity
• Varied protocols
• People

20. Systems are complex
• “How Complex Systems Fail”
• Failure at multiple layers
• Synonyms in other industries
• Defense in Depth

21. Software needs to
meet adversity

22. Intro to Rugged
by analogy

23. Current Software

24. Rugged Software

25. Current Software

26. Rugged Software

27. Current Software

28. Rugged Software

29. Current Software

30. Rugged Software

31. Current Software

32. Rugged Software

33. Current Software

34. Rugged Software

36. Rugged Software
Manifesto

37. I am rugged... and more importantly,
my code is rugged.

38. I recognize that software has become
a foundation of our modern world.

39. I recognize the awesome
responsibility that comes with this
foundational role.

40. I recognize that my code will be used
in ways I cannot anticipate, in ways it
was not designed, and for longer
than it was ever intended.

41. I recognize that my code will be
attacked by talented and persistent
adversaries who threaten our
physical, economic, and national
security.

42. I recognize these things - and I
choose to be rugged.

43. I am rugged because I refuse to be a
source of vulnerability or weakness.

44. I am rugged because I assure my
code will support its mission.

45. I am rugged because my code can
face these challenges and persist in
spite of them.

46. I am rugged, not because it is easy,
but because it is necessary... and I
am up for the challenge.

47. Qualities of Rugged
Software
• Availability - Speed and performance
• Longevity, Long-standing, persistent - Time
• Scalable, Portable
• Maintainable and Defensible - Topology Map
• Resilient in the face of failures
• Reliable - Time, Load

48. Security vs. Rugged
• Absence of • Verification of
Events quality
• Cost • Benefit
• Negative • Positive
• FUD • Known values
• Toxic • Affirming

49. DevOps

50. It’s not our problem anymore

51. DevOps is not just
making the wall shorter
before after

52. -Alex Honor, dev2ops

53. Programmable
Infrastructure
Environment

54. The PIE vision

55. People that built PIE
Peco Karayanev crazy to dream up PIE and foolish to try to build it
Ernest Mueller godfather and proponent of DevOps in PIE
James Wickett chief evangelist of PIE
Michael Truchard ensuring PIE is as much for dev as it is for ops
William Hackett evolving PIE from hackery to legit software.
Karthik Gaekwad reminding PIE to KISS
Kar Meng Chow ensuring PIE is a tool for daily ops
Mohd Hafiz Ramly boldly taking PIE to new heights
John Hill herding the PIE cats

56. What is PIE?
• a a framework to define, provision,
monitor, and control cloud-based systems
• written in Java, uses SSH as transport,
currently supports Amazon AWS (Linux
and Windows) and MS Azure
• takes an XML-based model from source
control and creates a full running system
• to define, provision, monitor, and control
cloud-based systems

57. What do we like about PIE?
• Collaborative system design
and development
• Automation for building,
provisioning and controlling
cloud systems
• From source to running multi-
tier cloud system in minutes
• Infrastructure as code

58. What do we use PIE for
• Provisioning cloud instances
• Creating new environments
• Deploying & configuring software
• Deploying & configuring applications
• Backups
• Log aggregation
• Auto-scaling roles based on demand
• Running tests
• Continuous integration
• Release workflows
• Auditing cloud resource usage
• Integrating with revision control & software build

59. can we do better?

60. Security features and use cases
• Increase the visibility and auditability of the system
• Track dependencies and what code is deployed where
• Diff versions of the system and see changes
• Role based auth for operators
• No manual steps
• Passwords able to be changed with a few PIE commands
• Keys out of the model
• Ports and user/pass changes
• App Config
• Audit / Running state vs. model diff

61. Architecture
o Document based Architecture Definition Language
o Command orchestration,dispatch and execution engine
o Runtime Registry
o Command Line Interface

62. ADL (Architecture Definition Language)
• Structural model of the system described in XML
documents.
• 4 Level Hierarchy - System,SubSystem,Role,Service

63. ADL (continued)
Each entity is defined in XML and holds meta-data about
resources and commands.

64. Command Execution & Orchestration
• The execution engine can dispatch and execute
commands to remote machines.
• More complex workflows can be created from
simple commands.
• Commands can be overloaded in different model
components.

65. Runtime Registry & Name Service
• The Runtime registry tracks the state and
dependencies
• The Name service keeps a namespace for
instances.

66. Command Line Interface
Example full command line invocation:
Target Query string explained:

67. Demo
• On Azure
o Provision an environment.
o Deploy an app and test.
o Update the model and turn off port 80.
o Redeploy and test the app.
o De-provision the environment.

68. Rugged DevOps
Results
• repeatable – no manual errors
• reviewable – model in source control
• rapid – bring up, install, configure, and test
dozens of systems in a morning
• resilient – automated reconfiguration to
swap servers (throw away infrastructure)
• rugged by design devops by culture

69. Roadmap
• Open Source
• More security workflows
• Azure data management workflows
• Add support for external keystores
• ADL and model usability features
• Port AWS functionality to 2.0 version
• New shiny distributed orchestration engine
• Add user auth through LDAP or other repos
• IDE to simplify design
• More powerful script engine

70. PIE now and future
(now) (28 years later)

71. Recommended Reading

72. Want the slides?
send me a tweet @wickett