The document discusses Salesforce's approach to infrastructure orchestration, emphasizing the importance of explicit standards and declarative object models to manage complexity and enable rapid implementation changes. It outlines the benefits of measuring success, data analysis, and ensuring security through defined models and interactions. Overall, the focus is on creating a structured framework that enhances customer success and operational efficiency.

1. Orchestration, the conductor’s score
The approach to infrastructure and application scale at Salesforce.
David Lucey
Network Architect
dlucey@salesforce.com
Linkedin: dplucey
Twitter: @dplucey

2. 2013 • 2014 • 2015 2008 • 2009 • 2010
2011 • 2012 • 2013
2014 • 2015
2011 • 2012
2013 • 2014
2015
Most innovative
companies in
the world
20K
FY16 Employees
Salesforce: 4th Largest Enterprise Software Company in
the World This Year
4th largest software company based on
analyst consensus revenue for FY2017.
Salesforce fiscal 2017 guidance provided
November 18, 2015: "revenue for the
company's full fiscal year 2017 is projected
to be approximately $8.0B to $8.1B.”
$ 6.67B
FY16 annual revenue

3. A Complete Platform
for Customer Success
Customer Success
Services
Customer Success
Platform
Complete CRM
Developer Success
Platform
5.5 million apps
Force.com
Heroku Enterprise
AppExchange
Shield
Trailhead
Wave
Thunder
Lightning
Apps
Analytics
Community
Marketing
Service
IoT
Sales
Success
Community
2 million members
MVPs / Events / Community
Salesforce
Success Services
Success
Ecosystem
SI’s / ISV’s
AppExchange
Customer Success Managers
Ignite / Program Architects
Multitenant Cloud

4. Unlimited Transactions at Scale
Further Improving response times
B
70B
140B
210B
280B
Q4FY13 Q2FY14 Q4FY14 Q2FY15 Q4FY15 Q2FY16 Q4FY16
200ms
220ms
240ms
260ms
280ms
Q4FY13 Q2FY14 Q4FY14 Q2FY15 Q4FY15 Q2FY16 Q4FY16
Transactions Per Quarter
270B Transactions in Q4FY16
52% YoY Growth (Q4FY15-Q4FY16)
Average Page Time
211ms Latency in Q4FY16
Flat (Reduction) YoY

5. Orchestration is a tough nut to crack.
Complexity increases with number of interactions, not number of elements.
• Network elements have a good deal more interactions that servers
We focus on object models to constrain and define the complexity.
They shape how we think about the problem, and give us something to compare to.

6. Orchestration is a tough nut to crack.
Complexity increases with number of interactions, not number of elements.
• Network elements have a good deal more interactions that servers
We focus on object models to constrain and define the complexity.
They shape how we think about the problem, and give us something to compare to.
How we think about the problem
gives us the key to solving it.

7. We start with explicit rolling standards
We explicitly standardize and templatize everything
We build each instance with a defined lifespan
Version Everything
A network version is fit for purpose.
We focus on fast-recovery architecture.

8. We start with explicit rolling standards
We explicitly standardize and templatize everything
We build each instance with a defined lifespan
Version Everything
A network version is fit to a purpose.
We focus on recovery-only architecture.
What does this buy us?
• The constraints actually set us free.
• They give us a rock-solid foundation to build upon.
• We can focus our efforts on what really differentiates our platform.

9. It’s all about the declarative object model.
Declarative model
• A structured description of the desired outcome.
• A puppet manifest
Imperative model
• A structured description of exact steps to take to affect a desired outcome.
• A configuration template

10. It’s all about the declarative object model.
Declarative object models are our best friends.
• Everything MUST be modeled, from applications right down to power, cabling, and space.
Declarative models focus on intent, not implementation
• The model is stating what the requester wants, not how they get it.
• This forms an explicit contract, “If I ask for this, I will get something that behaves this way.”
Models can and should be composed of other models.
• Infinite Composability

11. It’s all about the declarative object model

12. It’s all about the declarative object model

13. It’s all about the declarative object model

14. It’s all about the declarative object model

15. It’s all about the declarative object model
These models give us an External Source of Truth
• The routing table is no longer the definition of accuracy.
• We should be able to execute on intent *solely* from the model.

16. Keeping the children in line.
If we do not measure it, we cannot succeed at it.
• This is a guiding principle within Salesforce Infrastructure.
We determine how to measure success before we start, then iterate on it.
Knowledge is power, and data is the key to knowledge
• Grab any data you may possibly need. How long we keep it is a business decision.
Data we have no plans to analyze is not worthless, but data we never analyze is.
• Analyze everything in time-series from failure or degradation
• Need to change - Let each product owner decide what is important and write their own jobs.
How do we know if the infrastructure is adhering to our models?

17. Herding cats is easy when you have food
We now have expected state (intent) and observed state (telemetry).

18. Herding cats is easy when you have food
We now have expected state (intent) and observed state (telemetry).
A controller’s job is to compare the two intelligently
• …and make further statements of intent
• It must be loosely coupled to succeed.

19. Herding cats is easy when you have food
We now have expected state (intent) and observed state (telemetry).
A controller’s job is to compare the two intelligently
• …and make further statements of intent
• It must be loosely coupled to succeed.
Watchdogs (observers) and Robots (actuators)
• Watchdogs are distributed and robots are more centralized.
• Responsibility of their operation and accuracy belongs to the owner.

20. Herding cats is easy when you have food

21. Herding cats is easy when you have food
We loosely couple elements, focusing on intent and interaction.
• This gives each team known inputs and outputs. The middle is their own black box.
• A statement of intent can be broken down into finer grained statements of intent as needed.

22. Herding cats is easy when you have food.
Remember that we model everything? We model configs too.
• A config template is just a tightly coupled type of model.
• We have templates for vendor configs, just like everyone else…but not for long.
We’re getting behind OpenConfig to help push.
• It lets us loosely couple to our network gear – and declare intent.
• We’re working to build OpenConfig models for load-balancing and security as well.
• This shifts the most complicated layer of our orchestration, vendor interaction, over to the vendors.
• This is a huge win for our industry – except for the vendors.

23. Security in a Panopticon World
Security is one of the prime drivers for our declarative model.
• We know where everything is supposed to be.
• We know what everything should be doing.
• We know how it should be doing it.
We’re gathering how things are.
• In the applications
• At the host
• Throughout the network
• At ingress and egress

24. Security in a Panopticon World
Prevention and detection can be elaborated from application models.
Traffic inspection can be compared against the models.
Security Analytics can also be compared against the models.
Response can be signaled from the controller.
We augment that with our Trust Team, to identify
any exploits that static analysis of code,
infrastructure, and our security analytics doesn’t
turn up.

25. What it all looks like.
The application owner defines their model:
• Submit artifacts
• Add configuration templates
• Define interactions
• Define infrastructure needs
• Number of instances of each type
• Fault zones
• Load-balancing and other service needs
• Define metrics and watchdogs

26. What it all looks like.
The application owner defines their model:
• Submit artifacts
• Add configuration templates
• Define interactions
• Define infrastructure needs
• Number of instances of each type
• Fault zones
• Load-balancing and other service needs
• Define metrics and watchdogs
Whether they deploy into our platform or elsewhere, the application model can drive the
deployment.
Network is just another
owner.
The only addition is their
physical needs.

27. Takeaways
Explicit Infrastructure Standards
• Otherwise our automation is 10% engine, 90% exceptions
• Constraint sets us free.

28. Takeaways
Explicit Infrastructure Standards
• Otherwise our automation is 10% engine, 90% exceptions
• Constraint sets us free.
Declarative Object Models
• Anything can be modeled, and everything MUST be modeled.
• Models should be made up of other models, like Lego™ blocks.

29. Takeaways
Explicit Infrastructure Standards
• Otherwise our automation is 10% engine, 90% exceptions
• Constraint sets us free.
Declarative Object Models
• Anything can be modeled, and everything MUST be modeled.
• Models should be made up of other models, like Lego™ blocks.
Measure Everything
• If we do not measure it, we cannot succeed at it.
• We figure out how to measure success before we start, then iterate on it.
• Grab everything. How long we keep it is a business decision.
• Data we have no plans to analyze isn’t worthless, but data we never analyze is.

30. Takeaways
Focus on intent and the interactions, not the implementation
• Loose Coupling and explicit contract versioning allow for more rapid implementation changes,
• Both for component interoperability and for customer interaction.
• This is the heart and soul of ‘Infrastructure as Code’

31. Takeaways
Focus on intent and the interactions, not the implementation
• Loose Coupling and explicit contract versioning allow for more rapid implementation changes,
• Both for component interoperability and for customer interaction.
• This is the heart and soul of ‘Infrastructure as Code’
Security can accrete from the framework
• With explicit standards and explicit contracts owned by our product owners, security models and incident
detection naturally fall out as a result.
• Layered security becomes variations that elaborate from our explicit contracts.
• Security analytics is a further elaboration of our explicit contracts
• predictive analytics can improve those contracts.

32. thank y u