Download to read offline
The-steps-to-make-technical-deicisons.pptx
- 2. Examples Docker swarm Kubernetes MongoDBMySQL implement reuse Maven Gradle
- 3. your WORST technicaldecision here
- 4. … let mehelp own persistency layer in PHP merge two non-compatible libraries ~ 300 dependencies each
- 5. We all havewar stories
- 7. STICKY COGNITIVE NOISE TECHNICALDEBT ACCIDENTAL COMPLEXITY
- 9. SOLVES THE RIGHTPROBLEM
- 10.
- 11. EASY TO USEMAINTAINABLE FAST NO SURPRISES
- 12. • Could takeweeks • Expertise to do it rapidly Quality Attributes & Metrics • Prioritization! • Just enough depth of field
- 13.
- 14.
- 15.
- 16.
- 17.
- 18. Design maturity API feature richness interfacing (replaceable) simplicity Learning Curve quality docs usability fast feedback team expertise Runtimeno SPOF stability performance technical constraints security Support debugging logging exceptions no snowflakes monitoring testing
- 20.
- 21.
- 22. Technical Constraints &Feature Richness
- 23. Design & Simplicity& API & Stability
- 24.
- 25.
- 26.
- 27.
- 28. version: '3' services: toxiproxy: image: "shopify/toxiproxy" redis-master: image:"redis:alpine" redis-slave: image: "redis:alpine" mysql: image: mysql:5.6 … apiVersion: apps/v1 kind: Deployment … spec: … template: spec: containers: - name: … … --- apiVersion: v1 kind: Service metadata: name: mysql …
- 29. Design maturity API feature richness interfacing (replaceable) simplicity Learning Curve quality docs usability fast feedback team expertise Runtimeno SPOF stability performance technical constraints security Support debugging logging exceptions no snowflakes monitoring testing
- 30.
- 31.
- 32. Capacity Planning • model-based •existing measurements • check SLAs • check latencies • check costs • check limits and quotas!
- 33.
- 34.
- 35.
- 36.
- 38.
- 39.
- 40. Last Responsible Moment •parallel dependencies • interfaces & abstractions • feature toggles • deprecation
- 41.
- 43. Decision Making • Workas a team! • Use your intuition wisely • Remember: breadth-first • Be CALM & COLLABORATIVE
- 45.
- 46.
- 47.
- 48. Thank You! OresztészMargaritisz @gitaroktato https://www.linkedin.com/in/oresztesz gitaroktato
- 49. References • How wedecide (book summary) • Choose Boring Technology • Set-based design • How to make technical decisions given very little time? • Stackoverflow Insights • CVE Details • Analyzing code with SonarQube in Docker • Google Trends • Software Engineering Wisdom • Lean Tools: Making Decisions • Lean Tools: Options Thinking • Emotional Intelligence • Microsoft – Quality Attributes and Metrics • EPAM – Technology Radar • InfoQ – Technology Trends • Thoughtworks – Build Your Own Technology Radar
- 50. References • AWS Latencies#1 • AWS Latencies #2 • ADR Tools GitHub • Michael Nygard – Documenting Architecture Decisions • AWS Pricing Calculator • AWS SLA searck • AWS Reliability Pillar – Example implementation of availability goals • AWS Reliability Pillar – Definition of availability • gitaroktato – Microservices availability simulator • gitaroktato – Queue model in Python • TechEmpower – Web framework benchmarks
Editor's Notes
- #3 TODO: Under 1 minutes
- #7 COST OF A BAD DECISION
- #8 Cognitive Noise OWN STORY: 3 syntactic sugar libraries for same purpose (commons, guava) TODO: 1:30 (PAUSE)
- #11 POLL!!!
- #23 “how to position your technology stack in the given job market”
- #29 3 seconds and 30 seconds make a difference
- #37 POLL!!!
- #41 Set-based design: “Deliver as fast as possible” Last responsible moment: “Decide as late as possible”
- #43 Get me the …. (fastest, cheapest, easiest) Branch Combine TODO: 1:30 OWN STORY: Workaround & Parallel in the last day of sprint.
- #44 OWN STORY: 3 DB implementation. Remove deprecated. DevOps => sync up for solution. OPS side difficult / easy on DEV side
- #47 OWN STORY: 3 DB implementation. Remove deprecated. TODO: 2:00
- #48 TODO: 3:30