Weeks ago, ThoughtWorks published a new issue of Technology Radar compiled by its senior tech leaders. It has done a great job to track latest technology and market trends since 2010 (for archives, scroll to the bottom of this page).
Given the company’s business and the authors’ expertise in customized software consulting, the focus is around the software development in four different areas: techniques, tools, platforms, languages. For each area, it categorizes various technologies into four rings from inner to outer: adopt, trial, assess, and hold. So you can clearly see what actions should be taken for a particular technology. I don’t necessarily agree on everything it recommends, but definitely find the Technology Radar well worth reading.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
I think the most interesting part for virtualization and cloud community is the platforms area, which tracks 29 technology points. Among them, 6 technologies are recommended to adopt: ATOM, AWS, care about hardware, communication between those responsible for hardware and software, KVM, mobile Web.
While talking about virtualization, the Technology Radar warns,
“While virtualization is on the rise, some organizations are treating virtual machines like physical infrastructure. We frown on doing a full operating system install for each VM or using VMs for load testing. Virtual machines can be cloned, snapshotted, and manipulated in ways physical machines cannot, and also have vastly different performance characteristics than physical hardware. VMs should be used with full understanding of their benefits and limitations, otherwise you can really get into trouble with them.”
Well said! Like everything else, you can better use virtualization if you understand it.
I also like the discussion on the gap between software team and infrastructure team:
“One of the principal mechanisms that allows agile software development to work is feedback loops. One common yet expensive broken feedback loop we have observed is the lack of communication between those responsible for hardware and software. The end result creates cost but not worth. You must view architecture holistically; neither hardware nor software has a full enough perspective to be successful alone.”
It explains the rise of devops movement. I also think for a really successful project, at least one person, ideally software architect, should understand both software and hardware. Communication definitely helps, but never to the same result as both perspectives in one brain.