Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Serverless vs. Developers – the real crash

48 Aufrufe

Veröffentlicht am

With serverless things are getting really different. Commodity building blocks from our cloud providers, functional billing, serverless marketplaces etc. are going to hit the usual “Not invented here”3 syndrome in organizations.
Many beloved things have to be un- or re-learned by software developers. How can we prepare our organizations and people for unlearning old patterns and behaviours? Let’s have a look from a knowledge management perspective.

Objective of the talk:
Intro into systemic knowledge management

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Serverless vs. Developers – the real crash

  1. 1. Serverless vs. (Backend) Developers AWS Loft Berlin By Soenke Ruempler (@s0enke) Co-founder of superluminar (@superluminario)
  2. 2. Hi.
  3. 3. I’m Soenke.
  4. 4. Twitter: @s0enke
  5. 5. Co-founder of superluminar.io Based in Hamburg.
  6. 6. Focussing on Public Cloud, AWS and Serverless.
  7. 7. And people.
  8. 8. Feb 15th 2019 hamburg.serverlessdays.io
  9. 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. 10. Wikipedia says ...
  11. 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. 12. “… Pricing is based on the actual amount of resources consumed by an application, rather than on pre- purchased units of capacity”
  13. 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. 14. Serverless != Function-as-a-Service
  15. 15. Serverless == Serviceful
  16. 16. Evolution
  17. 17. How do things evolve?
  18. 18. Genesis Faraday disk Evolution of Electrical Power Custom Built Product Siemens dynamo Commodity
  19. 19. CommodityProductCustom Built Evolution of “Compute” Genesis
  20. 20. Everything evolves! (to commodity)
  21. 21. 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
  22. 22. 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
  23. 23. Customer/User-Need Genesis Custom Built Product Commodity App Runtime Execution Event-System Login/User Management Database Storage Power API-Endpoint Compute
  24. 24. 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
  25. 25. 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
  26. 26. The serverful vs. serverless developer
  27. 27. 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
  28. 28. Products/Libraries => Services
  29. 29. Ok, so what?
  30. 30. Hypothesis: “Serverful” folks will get into trouble!
  31. 31. How do organizations learn?
  32. 32. Organization == Organized resistance to learn
  33. 33. WAT.
  34. 34. Depending on “learning resistance” to do the daily work.
  35. 35. Stable Old “Business as Usual” Stable New “Business as Usual” Destabilization Learning Restabilization Unlearning How do organizations learn? Learning new habits, routines and reactions
  36. 36. Ok, sounds easy.
  37. 37. Really?
  38. 38. Knowledge is a part of [human/group] identity.
  39. 39. Example: RabbitMQ => SQS
  40. 40. "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.”
  41. 41. “In consequence, individuals tend to reject external ideas to defend their group identity"
  42. 42. Unlearning can be a painful experience!
  43. 43. Organizational learning is a conflict with unknown outcome (!).
  44. 44. Conflicts can arise because of the timing and/or magnitude of change.
  45. 45. Good timing for “hey let’s try X”? https://de.wikipedia.org/wiki/Operation_(Medizin)#/media/File:Operation_Medizin.jpg
  46. 46. “We've always done it this way” is a Defensive (survival) reflex of an organization.
  47. 47. Active learning is only possible if folks can control what they engage with.
  48. 48. “Suffering” from “Passive Learning”.
  49. 49. Many barriers to learning and unlearning
  50. 50. 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”
  51. 51. Organized (un-)learning
  52. 52. In order to learn we need a “Routine to cancel routines”
  53. 53. Ok, but what can we do?
  54. 54. Possible solutions
  55. 55. 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”
  56. 56. A competent organization knows when and what to (un-)learn.
  57. 57. Knowledge Strategy
  58. 58. General questions
  59. 59. Why do I need which knowledge?
  60. 60. What organizational value can be created through which new, revised knowledge?
  61. 61. What future capability do we acquire through which organizational expertise?
  62. 62. So let’s look back to our Wardley Map ...
  63. 63. 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
  64. 64. 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) ◉ ...
  65. 65. Ok, but how can we change without “destabilizing” too much?
  66. 66. How could a “Routine to cancel routines” Look like?
  67. 67. Disciplined Learning and Experimenting.
  68. 68. Toyota Kata
  69. 69. 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
  70. 70. “Serverless” itself is not a “target condition”
  71. 71. 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
  72. 72. Incentives
  73. 73. Idea: “Serverless First”
  74. 74. “The "total cost of ownership" userstory”
  75. 75. Team and personnel development
  76. 76. 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
  77. 77. 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
  78. 78. 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)

×