 |
| DevOps related books I have in my library currently |
Software development methodologies and practices have evolved a lot since then. It's been a challenge to keep up. I'm a pragmatic guy, and I thought one could get pretty much all the functionality needed for an automated build and deployment stack just using Ant, CruiseControl, Kickstart, VMWare, and some helpful API's. Clearly I was wrong.
Cause for Pause
Without a doubt, the DevOps movement has captured the imagination of many a software developer. Just look at all the tools out there now! Chef, Puppet, Bamboo, RunDeck, Octopus, Docker, TeamCity, Jenkins, RubiconRed, Ansible, Vagrant, Gradle, Grails, AWS... I could go on. I'm beginning to question whether or not the polarization and proliferation of these tools has been helpful. I find many companies looking to fill a Devops role are asking for resources who have experience with the specific tool stack they are using. That must make human resource managers pull their hair out. Even personally, I'm concerned about hitching my wagon to the wrong horse. If I decide to accept a position with a company who is using a Chef/Docker stack (for example), but the industry decides that Ansible/Bamboo is the holy grail, have I committed professional suicide? Probably not, but it does make one consider job opportunities carefully.
Looking Forward
This P and P (proliferation and polarization) of DevOps tools makes me wonder what the future is going to look like for the DevOps movement. Consider what Microsoft did with C#. Instead of continuing to diverge and go their own way with the replacement for VB, they created a language with a syntax that essentially brought the software development industry back together (in a way). Brilliant move. Java developers quickly ported their favourite tools/frameworks over to C# and suddenly developing with Microsoft tools was cool again. It would sure be nice if something like that happened with the DevOps tools.
Something else to consider for the future... so far in my experience with overseas, outsourced teams, they have not yet embraced the DevOps movement. As a result, they aren't as efficient or as competitive as they could be. When they do jump on the DevOps bandwagon and truly tap into it's potential, it could be a game changer for people like me....
Tools to Watch
- Perhaps Amazon is the 'new Microsoft' with its expansive and ever expanding AWS tool stack? There's definitely some momentum and smart thinking going on there. They appear to have automated provisioning all wrapped up in a bow.
- Atlassian is another company (I didn't realize they were based out of Australia) that is putting together DevOps tools that have a lot of momentum in the industry. Their niche is collaboration tools.
- Puppet and Chef both have a strong foothold in the DevOps community. Both of them are adding new features all the time, enabling them to automate the deployment and provisioning of more products and systems. Many people use Puppet and Chef in conjunction with RunDeck or Docker to get all the automation they are looking for.
1 comment:
Just saw this older post from you, and realized I was part of that 'team' that built that DevOps environment long before DevOps existed as a IT term.
I think when you look closer at what we accomplished, it was FAR more about the 4-5 of us in Release Management, Development, and Operation that said 'there has got to be a better way to do releases and environment builds than spending hours manually entering parameters'. The tools available (kickstart, Ant, and the PHP/MySql web UI) at the time were primitive compared to now, but we leveraged them well and created a VERY cohesive release environment capable of installing a fresh OS to a VM, the app stack, and a specific branch/tag.
Since I left that contract and moved onto other customer sites, I tried to explain and 'sell' to people how much better managing Development, QA, and Prod environments could be with some front end effort into the automation. Nobody seemed to understand, listen, or care. The exception to this was working for along side some other bright people at Redfall. Other than Redfall, I've seen organization after organization be oblivious to the possibilities of automation and devops.
Why?
Tools are, in my opinion, secondary or even tertiary to the people chosen for a team. It was the team of Derek, Ka-Wai, Bernie, you and to a lesser degree myself that created that environment (I hope I didnt miss anyone). There was no top down corporate strategy designed or chosen by a 'Architect'. It was us sitting there discussing the problems and how to resolve them.
I think its important enough to say it again;
People make the difference, not tools or methodologies.
Post a Comment