March 5th, 2014

2014 Thoughtworks Tech Radar

My summary notes from the 2014 Thoughtworks Technology Radar Hangout

— Matthew Fellows —

Thanks to Scott Shaw, Evan Bottcher and Sam Newman from Thoughtworks for giving their time in today’s Hangout. As always, great material and insight from all parties.

My Crude, Unopinionated Notes

  • Micro Services (Sam newman)
    • Avoid large, monolithic systems which are heavy, hard to scale, slow to deploy
    • Embrace SOA with new technology, processes
    • Many fine-grained, small services
    • Model based on Web
    • Benefits:
      • Different ways to scale, deploy
      • Opportunities to explore new technologies
      • Avoids the need for gigantic rewrite
      • Optimised for replaceability rather than re-use
    • Question: “Examples of Java container that support “micro service” deployment
      • Really want to run each service independently
      • Favour embedded (e.g. Jetty)
        • DropWizard good example
          • Extra functionality like metrics/monitoring comes for free
      • Go-lang good example for micro-services – great HTTP library – and small binaries
    • Question: “What are the disadvantages of micro-services in real world?”
      • Biggest challenge is having many services
      • With monolithic system, things like monitoring is in one place
      • Many systems = more places to look
      • Recommend moving slowly from single -> many
  • Enterprise Data Warehousing (Evan Bottcher)
    • Challenge view that projects need to be upfront in nature
    • Avoid ‘data fortress’
    • Recommend
      • De-centralisation
      • Frequent release
      • Supported by micro-services which provide key intelligence in different areas
  • Internet of Things (Scott Shaw)
    • We’re on the path to an explosion of smart devices connected to the Internet
    • Low cost robotics
    • Lot’s to learn, we don’t know where it’s going but it’s going to be interesting & a challenge
  • Cloud (Sam)
    • People ‘electrocuting’ themselves – Amazon\Cloud is not a silver bullet and people still ‘blame’ Amazon when things go wrong.
    • Failure rates can be higher than internal DC, and coping mechanisms (such as physical access to the server) disappear
      • Design for failure
    • SLAs provided for AZ, not per node
    • Moving applications as-is (lift and shift) to a cloud based environment is not going to work
    • Moving toward self-service models, much like Amazon did with its own services
      • Teams structuring around the ‘product’ who can be entirely self-sufficient, and provide interfaces to other groups
      • Micro-services applied to people?
    • Recommend:
      • One application at a time
      • Keep options open with cloud provider
      • Invest in automation
      • Source control All-the-things
  • JavaScript (Scott Shaw)
    • JS growth, adoption rate, community and platform is massive and very rich
    • People learning how to use it in a good way (there are many bad things)
    • Dependency management
      • Desperate need, and no real approach that works universally
    • MVC frameworks bring better practices to the community
      • Angular, Knockout, Node.js
  • Continuous Delivery
    • Hudson, Jenkins etc. OK for a build server, but lack the concept of a ‘build pipeline’ which is key to success in DevOps/Continuous Delivery.
    • Thoughtworks have a Product ‘Go’
  • Where does Testing fit in?
    • Testing embedded in the team works best
    • Offshoring testing is missing the point of Test automation – it’s not just about efficiency, it’s about software quality and design
    • It effects the design of the software in a negative way as it doesn’t emphasise all of the positive principles in TDD/BDD etc.
  • http://maidment.org James

    Great notes!