4. Let’s get right into the following
● Couple of real-world examples
● The abstract of software decisions
5. Click to edit Master title styleClick to edit Master title styleClick to edit Master title style
We need to make some decisions
6. Lets build the second application
● RubyOnRails
○ it fits the team
○ matches what we’ve built before
○ can we deliver fast
● Mongo
○ Fits the features of the app
7. Lets build an app number xx
● NodeJS
○ Fits the features
○ Performs well
○ Encourages modular approaches
● DynamoDB
○ Easy to scale
○ Performance
8. Differences
● Old app is easy to kill and compicated to recover
● New app is happily serving 2000 request/second
10. RabbitMq - A message queue
● Asynchronous communication
● Event based communication
● Persistent communication
● Configurability for future
● Proven track record
● Clients for several languages
11. We chose Java over Ruby
● Can it fit on a cheapest amazon node
● Can it provide fast response time
● Is the ecosystem mature
● Can we build apis in it
● Is it evolving or revolutionary
12. ● JVM - predictable, performant
● Fundamentals - threads, objects, annotations
● Tooling - IDE, javadoc, debugging, code generation
● Lightweight enough (jetty)
● Easy to abstract and extract libraries
● Load tests are good enough
13. Click to edit Master title styleClick to edit Master title styleClick to edit Master title style
The evolution
14. Less building more maintaining
● Scaling
● Maintaining infrastructure
● Reworking previous features
● Working around past mistakes
15. Click to edit Master title styleClick to edit Master title styleClick to edit Master title style
Conway’s law
16. Click to edit Master title styleClick to edit Master title styleClick to edit Master title style
Application continuum
17. Conclusion
● App evolves with the company
● Rewriting and maintaining things takes time
● Day to day environment influences applications
more than features