Mastering the cloud by building "boring", stable software solutions
Rainer Stropek | @rstropek
Smart
Innovative
Creative
Visionary
Ground-Breaking
Clever
Ingenious
Resourceful
Types of Complexity
Inherent complexity
- Arises from the problem domain
- Part of the requirements for a system
- Cannot be eliminated easily
- Only by reconsidering requirements
Artificially added complexity
- Added by DevSecOps teams
- Intentionally or unintentionally
- Different reasons
- Design decisions
- Implementation choices
- Anticipation of future requirements
- Habits
- Adopting "best practices"
Simple does not
mean naive!
Simple is boring...
...but boring can be smart
What Does "Simple" Mean?
Keep it simple
- Avoid artificially added complexity
- ⚠️ Anticipating vague, future requirements
- Prioritize features driving inherent complexity correctly
- Question every component of your software architecture
- If you cannot answer the "why?" question, YAGNI!
- Do you really test and use what you built?
- Don't let aiming for "perfection" get in your way
- Iterative development rules!
- Avoid fragmentation
- Loosely coupling has its advantages, but also its downsides
- Ask "why" again and be critical about vague answers
What Does "Simple" Mean?
Avoid toil
- Regular, manual work are an alarm signal
- Eliminate or automate
- Have a focus on maintenance efforts
- Use managed services
- Serverless or SaaS if possible
- PaaS when finer control is required
- ⚠️ Avoid IaaS and custom container images
- Automate to eliminate toil
- ⚠️ Avoid over-automation
- Focus on real, not potential toil
- Use alerts and automated anomaly detection
What Does "Simple" Mean?
Using what many others are using
- Standing on the shoulders of giants
- Battle-tested services/libraries
- Available documentation and learning resources
- AIs know a lot about the technology
- Adjust architecture to what's available (PaaS)
- Use niche solutions only if really necessary
- Consider cost-driven design
- Beware of abandoned services/frameworks/libraries
- Prefer widely used, established services/frameworks/libraries
- ⚠️ Question "best practices" that add a lot of complexity
- Do they offer enough added value to justify complexity?
Challenges
Challenges
Lock-in Effect
- Simple, integrated solutions are often cloud vendor-specific
- Simplicity vs. lock-in
- Avoid investing in portable code if portability isn't a requirement
- Change code when moving becomes necessary
- Consider using abstractions in code to isolate dependencies
- Make additional costs for building portable solutions visible
- ⚠️ Missing innovative solutions by always following the same path?
- Strategies for bursting ones "bubble" are required (more later)
Challenges
Security requirements raise the complexity
- Reducing complexity can enhance security
- Free resources can be invested in security
- Fewer components lead to smaller attack surface
- Simple architectures are easier to understand and maintain
- Complex systems become insecure under time pressure
- Developers struggle and take shortcuts
- Externally imposed security requirements
- Use built-in security mechanisms as much as possible
- ⚠️ Established practices might not translate well
Challenges
Personal preferences, beliefs, and habits
- People want to follow their preferences and beliefs
- You want people to take responsibility
- Simplification sometimes requires fundamental changes
- Value of simplification vs. costs of changing status quo
- Gain flexibility to try things with a Microservice approach
- ⚠️ Loosely coupled components raise complexity
- Don't let technology landscape diverge too much
- Lead by example
Establish the right team culture
Team Culture
Value simple, stable solutions
- Make the importance of simplicity a shared value
- Showcase not just innovative, complex solutions
- Celebrate simple solutions with high developer productivity
- Don't punish accidental over-simplification
- It is ok to re-introduce complexity after having removed it
- Don't punish complexity reduction
- It is ok to admit mistakes
- Value stability
- Leading-edge vs. "bleading" edge
- ⚠️ But: Avoid letting components get outdated
Team Culture
Focus on the customer
- Customers want features, not self-purposed, fancy tech
- Focus is added value from the customer's viewpoint
- Implement regular feedback and retrospectives
- Involve customers
- Make hidden maintenance costs visible
- How much time do we spend adding value vs. keeping system up?
- ⚠️ But: Demand clear and concrete requirements
- Unclear requirements lead to over-engineering
- Flexibility and config options have to be a requirement
Don't mistake being busy for being productive
Team Culture
Repeat what's working
- If something works, stick to it
- ⚠️ Don't let conformity prevent innovation
- Make working solutions sharable and repeatable
- Be very specific about responsibilities and maintenance
- ⚠️ Prefer copying code over immature services/libraries
- Make small steps to improve patterns, practices, and principles
- Continuous improvement
- Continuous updates
Team Culture
Break out of the bubble
- Collaborate with others
- Inside/outside of the organization
- Listen to newcomers
- ⚠️ Value existing knowledge and experience of colleagues
- Regular prototypes/studies of new tech/approaches
- Company-specific "technology radar"
Team Culture
Allow new approaches
- Distinguish between prototypes/feasibility studies and production code
- ⚠️ Never put prototypes into production
- Time/effort-boxed approach
- E.g. Hackathons
- E.g. Isolated, low-risk experiments
- Benchmark early against existing patterns, practices, and principles
- ⚠️ Avoid the sunk cost fallacy
- Stay appreciative regarding legacy code
- Legacy code is code that earns money
- Have a path forward for legacy code to avoid obsolescence
Be smart by
being boring 😉
Mastering the cloud by building "boring", stable software solutions Rainer Stropek | @rstropek
Master the cloud by building boring, stable solutions
By Rainer Stropek
Master the cloud by building boring, stable solutions
- 468
