I’m a newcomer to the DevOps movement. I only started paying attention when I joined ZeroTurnaround and the LiveRebel development team.
Initially, all I heard about and focused on were the tools and the technology that would allow me to ‘implement DevOps’ and ‘become more productive’. At hindsight, this is exactly the opposite of what I was supposed to do. Local optimums (ie. individually enhanced islands) are the enemy of DevOps as they will most certainly interrupt the global flow of the organization. Adopting Vagrant or Chef are details that are very specific to individual organizations, maybe the best tool for your teams is a whiteboard with post-it notes or maybe it is a fluffy pink llama doll.
When I was at DevOps Days Austin two weeks ago, I wondered why so many of the talks hammered on about the cultural aspect of DevOps, but it was only after reading The Phoenix Project and The Goal that I realized why culture is so important.
DevOps Days Austin 2013 included demonstrations of the awesome power of LiveRebel for automating your application deployments, talks on productivity comparing DevOps vs. traditional IT Ops, hippie hackers (see pic) and a good old swag giveaway as well. Up next: DevOps Days Berlin and DevOps Days Mountain View.
Introduction to DevOps, Virtualization and Provisioning
DevOps has become more than just a buzzword among the innovators in software development and IT operations today. It’s as hot a topic as agile was a decade ago. Just like agile, no one was able to really lock down a good enough definition, or figure out the context in which the definition of agile actually existed (at first)…
“Devops is intersection of lover of cloud and hater of wake up at 3 in morning.” @DEVOPS_BORAT
Yep, we’re talking about DevOps. We made a report on why it’s better. And yes, it IS better than what we’ve termed “traditional IT Ops”. We have statistics on that, and we’ll argue it all day.
DevOps is better because it carries forward the same, proven methodologies that brought Agile into the limelight for software development.
So why do we need to apply those concepts to operations? To that we have 3 bullet points:
Traditionally siloed team structures don’t scale
Developers and Operations have opposing philosophies
Technology continues to evolve and the same old processes cannot handle newer paradigms
Together, Dev and Ops can focus on what’s most important – the end user experience. They produce high quality software with high availability and a full understanding of each other’s limitations that can be addressed well ahead of time. As a result, much of what is considered “operations” is written and packaged as code, both in and out of the app. This brings forth smarter apps and environments that can adapt to changes in user requirements faster.
We have about 35 pages for you in the full report, but also wanted to let as many people see the real meat of the results as quickly as possible. So you can get the full report from Rebel Labs, or keep reading to see lots of shiny graphs and serious numbers…
Introduction to Chef
In previous posts we discussed the benefits of having automated environment provisioning & virtualization and how to get started with Vagrant. We also mentioned how this topic relates deeply to the technoculture of DevOps, which focuses heavily on automation, reusability and iterative improvement with regards to building and releasing software.
So let’s get started with Chef, which helps you turn environment provisioning into an automated process, making it not only more reliable and error-proof, but saving loads of time and headaches.
After reading through our previous introductory article on Pragmatic DevOps, you most certainly want to dive right in and try Vagrant out for yourself. No need to hunt around the web to collect the instructions, just follow the few simple steps below and you’ll get a taste of Vagrant in no time.
Ah, DevOps, the biggest WTF buzzword among the innovators in software development and deployment today. It’s as hot a topic as agile was a decade ago, but just like agile, no one was able to really lock down a good enough definition, or figure out the context in which the definition of Agile actually existed (at first).Read more
London was rainy and cold, but inside the Mary Ward House, there was heat billowing from 200 devs and operations folks eager to hear about new processes and tools. It got even warmer when we started giving away free JRebel trial licences, Guinness beer and our famous bloody t-shirts!
About a month ago, we launched our IT Productivity survey (take it if you haven’t already done so!) about a month ago in order to gain insight into the day-to-day lives of IT folks, their processes and tools of choice that help improve productivity. Thus far, we’ve have some interesting insights and I’d like to share one with you. But you’d better sit down for this, because once you actually figure out how much money you lose EVERY TIME you have a production application failure, you’ll get weak in the knees!