Increasing velocity via serless semantics
0 likes245 views
1) The document discusses increasing developer productivity in microservices architectures through adopting serverless semantics. 2) It notes that existing productivity libraries and code generation approaches become too complex and create maintenance issues over time. 3) The speaker advocates adopting a serverless approach that exposes runtime as a service, simplifies deployment and configuration, and focuses developers on business logic through a simple API. This avoids problems of "distributed monoliths" caused by compile-time wiring of runtimes.
![module.exports = functionsBuilder =>
functionsBuilder
.withContextPath('conferneces-locator')
.addWebFunction('GET', '/confernces-list', async (ctx, req) =>{
return [
'geektime code',
'serverless days',
'Reversim'
]
});
http://serverless.wix.com/conferences-locator/conferences-list
Defining the API](https://image.slidesharecdn.com/increasingvelocity-geektime-190603200515/85/Increasing-velocity-via-serless-semantics-33-320.jpg)
Increasing velocity via serless semantics
- 1. Increasing velocity via serverless semantics Kfir Bloch kfirb@wix.com @kfirondev The path to productivity in Microservices ecosystem
- 2. ● Developer 20 years ● Cook Since I remember myself ● Photographer 1 year ● Manager 15 years This is me Just a normal result driven developer
- 3. By the end of this talk you will Think more about productivity Get more ideas about speeding up velocity Hopefully will adopt serverless semantics
- 4. The scale we are currently facing ~1000 Microservices ~700 Developers
- 6. In order to have many Microservices by many teams you need to standardize the infra
- 7. Productivity Libraries Kafka Abstraction RPC server RPC client Configuration Logging HTTP controllers Secret keys Auth & cookies Containers Caching policy BI reporting ORM support And many more...
- 8. Supporting web tools And many more... Deployment settings portal Build settings portal
- 9. ...and some “non-functional” Health tests Monitoring Metrics Graceful shutdown Headers propagation Error handling Security Plugins support
- 10. It worked for us!
- 11. It worked for us! But not good enough!
- 16. Infra developer is the worst person to define abstraction Rule #1
- 17. Infra developer is the worst person to define abstraction The only person that can define great abstraction is the developer that uses the library Rule #1
- 18. So let’s generate the code based on wizard with questions! Yeoman to the rescue
- 19. Yoshi tool
- 20. Still not good enough... ▪ Code generation does not get new updates ▪ Runtime injected in compile time ▪ We generate the code with the problem instead of hiding the problem ▪ Code generate still has maintenance cost ▪ Project got bigger, it is hard know know what it does because of the code generation
- 21. The secret of productivity library that no one tells you Productivity library is what makes you productive in the beginning Then it becomes frameworks with 40 pages docs...
- 22. Check your productivity library and you’ll find out that 80% of the projects uses only 20% of the features Rule #2
- 23. ▪ Still need to use/know so many tools ▪ Microservice tend to become mini-monolith ▪ “distributed monolith” due to compile time wiring of the runtime ▪ Slow onboarding
- 24. ▪ Runtime as a service ▪ Simplify deployment & configuration ▪ Let developer focus on the logic ▪ Simple API ▪ 20% of the interfaces from the productivity libraries to support 80% of the applications ▪ Still need to use/know so many tools ▪ Microservice tend to become mini-monolith ▪ “distributed monolith” due to compile time wiring of the runtime ▪ Slow onboarding So we need
- 25. ▪ Runtime as a service ▪ Simplify deployment & configuration ▪ Let developer focus on the logic ▪ Simple API ▪ 20% of the interfaces from the productivity libraries to support 80% of the applications ▪ Still need to use/know so many tools ▪ Microservice tend to become mini-monolith ▪ “distributed monolith” due to compile time wiring of the runtime ▪ Slow onboarding So we need Serverless to the rescue
- 26. Also takes us to better engineering 1. Passes the tests 2. Reveals intention 3. No duplication 4. Small parts Kent Beck’s Four Rules of Software Design AKA “Simple Design”
- 27. The fundamental of software engineering If you have complex problem, you should break it to smaller mini problems
- 28. Real life metaphor - fine granular approach Action: Clean the house Test: is the house clean Action: wipe the dust Test: do we have dust Action: wash the dishes Test: is the dishes clean Action: Clean the floor with water Test: Is the floor clean? Action: Do the laundry Test: Is the laundry clean? Service Function
- 29. Why Amazon lambda is not good for us? ▪ Cold start problem ▪ Instantiating singletons ▪ Nearby our servers/databases to reduce the I/O ▪ Integration to the rest of the Microservices ecosystem ▪ AWS is optimized for multi tenancy. This does not fit our scale.
- 30. So let’s build our own lambda based on the node.js platform we already have
- 31. Requirements Zero boilerplate Zero configuration - code only Add only features that are good to 80% of the projects CLI tool Hide deployment and runtime complexity Documentation must be one page only!
- 32. We started with API first approach! Developers feedback before developing the platform
- 33. module.exports = functionsBuilder => functionsBuilder .withContextPath('conferneces-locator') .addWebFunction('GET', '/confernces-list', async (ctx, req) =>{ return [ 'geektime code', 'serverless days', 'Reversim' ] }); http://serverless.wix.com/conferences-locator/conferences-list Defining the API
- 34. module.exports = functionsBuilder => functionsBuilder .withContextPath('foo') .addWebFunction('GET', '/bar', async (ctx, req) => { ctx.database.insert({id: 'bla'}) ctx.abTesting.conduct('my-experiment',doSomthing) ctx.kafka.produce('my-topic',{msg: 'message'}) ctx.secretStore.getKey('google-token') return {baz: 'dar'} }); ctx to access productivity libraries
- 35. Multi repo - by conventions http://github.com/wix-private/serverless/my-scope/serverless.js Code should be in any repo in a folder with convention Org scope Entry file http://github.com/wix-private/serverless/my-scope/serverless.ts Org scope Entry file
- 36. What is proper replacement for deployment and configuration portal? CLI tool
- 37. Why CLI tool? ▪ The best DSL for the developer ▪ We can be really fast by just using the CLI ▪ Github - we use CLI mostly, but only for advance we go to the web ▪ Only code and CLI approach - no config
- 38. CLI interface ~> wix-serverless deploy my-scope ~> wix-serverless rollback my-scope ~> wix-serverless define-db-schema my-scope ~> wix-serverless traffic-info my-scope
- 39. To keep it simple, we are exposing only interface which is good for 80% of the projects
- 40. To keep it simple, we are exposing only interface which is good for 80% of the projects ~> wix-serverless eject But i need to have low level access
- 41. It is great approach to expose 2 types of API always for any library 1. Full blown features 2. Most used features Tip
- 42. Architecture
- 43. But most of us does not have the capacity to develop such platform Start by exposing reduced API from your current platform You will solve most of the problems
- 44. Serverless semantics is a good start
- 45. Serverless semantics is a good start Takeaways ▪ Think of your target audience when exposing APIs ▪ Avoid abstraction with too much information ▪ Function is smaller, smaller is better ▪ Go serverless - Amazon lambda is also a good choice ▪ Make 2 types of APIs, make them separately ▪ Make your developers focus on business logic mostly ▪ API first - don’t think on the engine in the beginning ▪ Junior developer must be able to write his first service on his first week
- 46. Thank you & Q&A kfirb@wix.com @kfirondev