Building stable applications with PHP and 3rd party services
0 likes435 views
The document discusses how to build stable applications using PHP and third-party services, emphasizing the importance of understanding the problems solved, learning from failures, and ensuring testing aligns with expected outcomes. It highlights factors that promote application instability, such as tightly coupled and overly complex code, and offers strategies to enhance stability, including rapid prototyping and careful integration of external services. Finally, it reflects on real-world lessons from companies like Netflix, advocating for designs that expect failure and robust operational practices.
![Frankencode!
_
q[-_-]p
| | “ | |
|| ||
# #](https://image.slidesharecdn.com/phpoz15buildingstableapplicationswithphpand3rdpartyservices-150315175852-conversion-gate01/85/Building-stable-applications-with-PHP-and-3rd-party-services-11-320.jpg)
![Closing thoughts and questions
/ Thanks
_ /
q[-_-]p
| | “ | |
|| ||
# #](https://image.slidesharecdn.com/phpoz15buildingstableapplicationswithphpand3rdpartyservices-150315175852-conversion-gate01/85/Building-stable-applications-with-PHP-and-3rd-party-services-36-320.jpg)
Building stable applications with PHP and 3rd party services
- 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
- 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?
- 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 | | “ | | || || # #