The document discusses the evolution and challenges of serverless computing from the perspective of backend developers, emphasizing the need for unlearning traditional practices. It addresses the organizational and individual barriers to adopting serverless architectures and suggests strategies for effective learning and adaptation. Key points include the importance of a knowledge strategy, the role of organizational identity in resistance to change, and the necessity of structured learning processes.

1. Serverless vs. (Backend)
Developers
AWS Loft Berlin
By Soenke Ruempler (@s0enke)
Co-founder of superluminar (@superluminario)

2. Hi.

3. I’m Soenke.

4. Twitter: @s0enke

5. Co-founder of superluminar.io
Based in Hamburg.

6. Focussing on Public Cloud, AWS and
Serverless.

7. And people.

8. Feb 15th 2019
hamburg.serverlessdays.io

9. Agenda
1. What’s Serverless
2. The Evolution of (Backend) Programming
3. What Developers will have to (un)learn with Serverless
4. Why is (un)learning so hard.
5. Generic strategies to amplify (un)learning and to overcome
resistance

10. Wikipedia says ...

11. “Serverless computing is a cloud-
computing execution model in which
the cloud provider acts as the server,
dynamically managing the allocation of
machine resources.”

12. “… Pricing is based on the actual
amount of resources consumed by an
application, rather than on pre-
purchased units of capacity”

13. “A Serverless solution is one that costs you
nothing to run if nobody is using it
(excluding data storage)” - @PaulDJohnston
Serverless - A definition

14. Serverless != Function-as-a-Service

15. Serverless == Serviceful

17. Evolution

18. How do things evolve?

19. Genesis
Faraday disk
Evolution of Electrical Power
Custom Built Product
Siemens
dynamo
Commodity

20. CommodityProductCustom Built
Evolution of “Compute”
Genesis

21. Everything evolves!
(to commodity)

22. A typical web-app backend Customer/User-Need
Genesis Custom Built Product Commodity
App
Runtime Execution
Event-System
Login/User
Management
Database
Storage
Power
API-Endpoint
Compute

23. What happened to Ops? Customer/User-Need
Genesis Custom Built Product Commodity
App
Runtime Execution
Event-System
Login/User
Management
Database
Storage
Power
API-Endpoint
Compute
API
Your Ops Team
Cloud Provider

24. Customer/User-Need
Genesis Custom Built Product Commodity
App
Runtime Execution
Event-System
Login/User
Management
Database
Storage
Power
API-Endpoint
Compute

25. Customer/User-Need
Genesis Custom Built Product Commodity
App
Runtime Execution
Event-System
Login/User
Management
Database
Storage
Power
API-Endpoint
Compute
API
Developer Duty
Cloud Provider Duty

26. What does Serverless “take away” from developers?
Library / Self-Hosted AWS Service(s) Google
Messaging Kafka, RabbitMQ,
Resque, ...
Kinesis/SQS/SNS/Batch Pub/Sub, Dataflow
Middleware Nginx/Rack/Express/Sil
ex...
API Gateway / ALB +
Authorizers
GLB, Cloud Endpoint
Databases MongoDB/CouchDB... DynamoDB Datastore
Identity/Login Keycloack/Hydra/…. Cognito Firebase
API Managment Express-graphql, .. AppSync ?
SSL Management OpenSSL Certificate Manager ?
Data Analysis Hadoop Kinesis/Athena BigQuery, DATAPROC
Logging ELK Stack ElasticSearch-Kinesis-
Kibana, CW Logs
StackDriver

27. The serverful vs. serverless developer

28. Stereotype: The “serverful” vs the “serverless” dev
“Serverful” Serverless / Serviceful
Products/Libraries Services
Not-Invented-here Proudly found elsewhere
“Favorite tech” Usage of cloud building blocks
Single Tech Expert Cloud Provider Expert / Generalist
Developing with Stubs / Fakes Developing “in the Cloud”
No direct feedback loop on costs High visibility and traceability of cost
Worth based development
Long running tasks Small batches
12 factor maybe 12 factor enforced

29. Products/Libraries => Services

30. Ok, so what?

31. Hypothesis: “Serverful” folks will get
into trouble!

32. How do organizations learn?

33. Organization
==
Organized resistance to learn

34. WAT.

35. Depending on “learning resistance”
to do the daily work.

36. Stable
Old “Business
as Usual”
Stable
New “Business
as Usual”
Destabilization
Learning
Restabilization
Unlearning
How do organizations learn?
Learning new
habits, routines
and reactions

37. Ok, sounds easy.

38. Really?

39. Knowledge is a part of
[human/group] identity.

40. Example: RabbitMQ => SQS

41. "The acceptance and valuation of external knowledge can
be perceived by insiders as a degradation of the own
achievements, expertise and competence of the in-
group.”

42. “In consequence, individuals tend to
reject external ideas to defend their
group identity"

44. Unlearning can be a painful
experience!

45. Organizational learning is a conflict
with unknown outcome (!).

46. Conflicts can arise
because of the timing and/or
magnitude of change.

47. Good timing for
“hey let’s try X”?
https://de.wikipedia.org/wiki/Operation_(Medizin)#/media/File:Operation_Medizin.jpg

48. “We've always done it this way”
is a
Defensive (survival) reflex of an
organization.

49. Active learning is only possible
if folks can control what they engage
with.

50. “Suffering” from “Passive Learning”.

51. Many barriers to learning and
unlearning

52. Individual Group / Team / Organizational
● Not-invented-here syndrome
● Routine blindness
● Illusory superiority / Dunning-Kruger effect
● Lack of social meta knowledge
● Lack of time
● Information overload
● Knowledge-is-power thinking
● Poor understanding
● Antipathy
● Reduction of cognitive dissonance
● Lack of Self-efficacy
● ...
● Hierarchy
● Formalism and bureaucratism
● Micropolitics
● Silo thinking
● Groupthink
● Separation of information collection/using
and decisions
● Lack of a knowledge strategy
● No support from management
● Leaders/managers acting as bad examples
● Top-down procedures
● Missing or dysfunctional incentives
● Focus on IT for “knowledge sharing”
● ...
“Knowledge barriers” / “information pathologies”

53. Organized (un-)learning

54. In order to learn we need a
“Routine to cancel routines”

55. Ok, but what can we do?

56. Possible solutions

57. Possible solutions - So what do the books say?
◉Have a Knowledge Strategy
○ Focus on core competences and user needs
○ Know what to (un)learn
◉Experiments / Small Wins
◉Right incentives
◉Team and personnel development
○ Training “Letting Go”
○ Seeking “Positive ignorance”

58. A competent organization knows
when and what to (un-)learn.

59. Knowledge Strategy

60. General questions

61. Why do I need which knowledge?

62. What organizational value can be
created through which new, revised
knowledge?

63. What future capability do we acquire
through which organizational
expertise?

64. So let’s look back to our Wardley Map
...

65. Customer/User-Need
Genesis Custom Built Product Commodity
App
Runtime Execution
Event-System
Login/User
Management
Database
Storage
Power
API-Endpoint
Compute
API
● “Positive Ignorance” (“Don’t need to
know”)
● Unlearn details, learn usage of
commodity building blocks
● Vendor Lock-in as “feature”, Cloud
Provider as “strategic partner”
FOCUS here

66. Universally applicable knowledge
Doesn’t go away even with serverless
◉ Ports and adapters, hexagonal architecture
◉ Test pyramid
◉ Domain driven design
◉ Design patterns
◉ (Unit) tests
◉ CAP theorem
◉ Fallacies of distributed computing
◉ SQL injection (aka not preparing data for subsystem)
◉ ...

67. Ok, but how can we change without
“destabilizing” too much?

68. How could a
“Routine to cancel routines”
Look like?

69. Disciplined Learning and
Experimenting.

70. Toyota Kata

72. Vision / Challenge 100% value-add (Focus on customer
needs).
Next Target Condition 50% value-add work
Current Condition 30% value-add work (bugs, incidents,
outages, ...)
Current Obstacle Our login system causes 80% of the bugs
and outages.
Next Experiment Look for managed alternatives for login /
user management
Learned Our Cloud Provider AWS offers a service
called “Cognito Userpools”. We could start
a Proof of Concept
(Made up) Toyota Kata Example

73. “Serverless” itself is not a “target
condition”

74. Toyota Kata Recap
◉ Directed, structured, disciplined way of learning
◉ Giving the direction, not the implementation
◉ “Routine to cancel routines”: Improvement work
gets a habit
◉ Experiments > Opinions

75. Incentives

76. Idea: “Serverless First”

77. “The "total cost of ownership" userstory”

78. Team and personnel development

79. Ideas for Team and personnel
development
◉ Team/Personal Coaching
○ Training “Letting Go”
◉ Giving people and teams autonomy, mastery and
purpose
◉ From “Special Tech Expert” to “Function Master”
○ Example: from “RabbitMQ Expert” to “Messaging
Master”
◉ Again: Right incentives

80. Recap
◉ Serverless means Serviceful: Caring about your
customer needs and the core product.
◉ Knowledge is identity, Unlearning can be a painful
experience.
◉ Prerequisites for (Un)learning:
○ Knowledge vision / strategy (e.g. Wardley Map)
○ A process for structured learning (e.g. Toyota Kata)
◉ Team and personnel dev / The right incentives
○ Foster “generic” knowledge, unlearn “special” knowledge

81. Standing on the shoulders of giants / Proudly
found elsewhere:
- Systemic Knowledge Management / Ignorance
Management (Ursula Schneider, Helmut Willke,
Dirk Baecker)
- Wardley Mapping (Simon Wardley)
- Organizational Psychology (Susanne Hopf)
- Learning Organizations (Argyris & Schoen)
- Systems thinking (Peter Senge, Deming)
- Toyota Kata (Mike Rother)
- Defensive Routines (Argyris)