Modern applications tend to leverage at least one 3rd party service. While application stability can be brought into flux through unexpected challenges, any unexpected challenges related to 3rd party service risk can be devastating. This presentation is aimed at development teams. The goal of this presentation is to help development teams mitigate 3rd party service risk by following a process of questioning. If you are considering usage of a 3rd party service in your application then share this with your team. First presented at #phpoz15 once the videos and live coding demo is available, links will be provided.

1. Building stable applications
with PHP and 3rd
party services

2. What does a stable application look like?

3. Behaviour is in line with expectations:
Mainly unaffected by application environment
Mainly unaffected by infrastructure changes
Service quality is acceptable

4. What promotes application instability?

5. Application instability is promoted when code is:
Tightly coupled and overly complex / simple
Dependent on 3rd
party code / services
Uncoupled but fails to solve problems

6. How can we promote application stability?

7. We can promote application stability by:
Understanding the problems we're solving
Learning from and adapting to failure
Testing against expected outcomes

8. Applications evolve....

9. In the beginning, quickly add new features

10. It started as a blog and now....

11. Frankencode!
_
q[-_-]p
| | “ | |
|| ||
# #

12. A challenge for all of us
Balancing pragmatism and perfectionism

13. Over time we can expect:
Existing bugs found and new bugs introduced
New requirements / enhanced functionality
People will join and leave project teams

14. New requirements and enhancements....

15. We can promote application stability by:
Understanding the problems we're solving
Learning from and adapting to failure
Testing against expected outcomes

16. High level requirement analysis
Who is using this application / feature?
What is the impact of using /not using it?

17. When it comes to the “how to”....
We have to consider our approach:
Develop custom features from the ground up?
Leverage an existing library or service?
A mixture of the above?

18. Additional factors should affect the choice....
Consider:
Cost of implementation / maintenance
Cost of failing to implement / maintain
Specific business rules
Available budget
Timeline

19. Not enough information to make a choice
How can we fill gaps in our understanding?

20. Rapid prototyping

21. We can promote application stability by:
Understanding the problems we're solving
Learning from and adapting to failure
Testing against expected outcomes

22. Make a smaller MVP....
Prove a concept:
Fail fast, review and adapt
Understand challenges
Quick implementation
Remember to stop

23. Remembering to stop
What are we trying to achieve?
What should the specific outcomes be?
Have we met / Can we meet the outcomes?

24. We can promote application stability by:
Understanding the problems we're solving
Learning from and adapting to failure
Testing against expected outcomes

25. Start by writing your test definitions
Live coding demo

26. When we know the implications we can
make better estimates....

27. Choosing to leverage a 3rd
party service?

28. Think carefully and ask questions
Will the application break if the service fails?
What is the impact if the application breaks?
What is the impact if it doesn't break?

29. Good questions, we need to go deeper....

30. 3rd
party service risk questions
What happens if the service provider:
goes out of business?
deprecates the API we're using?
changes arrangements for API access?

31. Don't rush in, design expecting failure....

32. Real world lessons:
Design based on expecting services to fail

33. Netflix infrastructure on AWS
"The best way to avoid failure is to fail constantly"
Source: http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html

34. Netflix contributing to the community
"we are now proud to announce that the source code for
the founding member of the Simian Army, Chaos
Monkey, is available to the community."
Source: http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html

35. Netflix Simian Army
"The Simian Army is a suite of tools for keeping your cloud
operating in top form. Chaos Monkey, the first member, is a
resiliency tool that helps ensure that your applications can
tolerate random instance failures"
https://github.com/Netflix/SimianArmy

36. Closing thoughts and questions
/ Thanks
_ /
q[-_-]p
| | “ | |
|| ||
# #