CFEngine are sponsoring DockerCon14. We’re excited to be able to show you how CFEngine and Docker can be used together to help manage your docker containers and make sure that you don’t go back down the path of golden images! If that isn’t enough to get your excited our very own Diego Zamboni is flying in from Mexico from the event. Stop by and have a chat with Diego about CFEngine, security or anything else. Diego will also be signing copies of Learning CFEngine 3. We look forward to seeing you there.
DevOpsDays events in Pittsburgh and Austin have both been awesome. It’s great to see the events maturing over time. While it was the first DevOpsDays event in Pittsburgh the organizers were familiar with DevOpsDays events and made sure that they built on top of other successes. The lack of “Idol worshipping” aka “we love Amazon, Etsy, Facebook, Netflix” was refreshing! We were treated to excellent sessions covering culture, PaaS, docker and other great topics. As long as you are in tech I’m certain there was plenty to interest you. The ignite sessions again were fun as always. There were some fun moments and some awkward moments! I presented my ignite session from DevOpsDays Austin on why DevOpsDays is failing horses and unicorns. Eventually I’ll track down a video of it and link to it, but it was well received. The awkward moment was that I presented after Nathan Harvey of Chef. He preached the familiar unicorn cry of “if you aren’t happy quit your job”. My ignite session has a slide that made fun of unicorns telling horses to quit their jobs and go work with unicorns because it really isn’t helpful at all. There was a great open space session on diversity in tech which could have gone on for hours. It was constructive and we all realize there is a problem. While DevOpsDays PGH wasn’t incredibly diverse it was heartening to see a significant number of women attending and presenting. In particular I’m looking forward to seeing Bridget Kromhout (@bridgetkromhout) and Cornelia Davis (@cdavisafc) present again. Awareness of CFEngine is growing, and we are getting recognition in presentations once again. People really seem pleased that we are still around and doing some awesome things. I can’t wait until DevOpsDays Silicon Valley when we can talk about some really cool stuff we have coming! June will be a very busy month for CFEngine. We’ll be at DockerCon, Velocity Santa Clara and DevOpsDays Silicon Valley.
This is a term often used today to acknowledge the extraordinary growth of the major web companies over a decade (social media, retailing, games, cloud etc) from handfuls of machines to the largest installations on the planet. The major web players today have datacenters with 10,000, 100,000 and even 1,000,000 computers serving their operations. Of course, this kind of growth is not appropriate for everyone. WebScale often goes together with quite singular or focused applications, by contrast with very complex industries that have to support thousands of applications for different lines of business. There is also a link to ideas of cloud computing. WebScale operations do not necessarily involve virtualisation, but typically there is a correlation between ideas of cloud computing and web scale. Some of the issues at web scale include:
We’ve already had fear-mongering about DevOps potentially killing off operations positions (thanks NoOps) and now it’s the turn of articles about DevOps killing off the developer. Terms like full stack developer are thrown around and other un-helpful terms that recruiters seem to love. Let me make one thing perfectly clear. I don’t believe DevOps is about training people so that people can do each other’s jobs equally well. That doesn’t make sense. There always needs to be specialists. The cultural changes encouraged by the DevOps movement should result in people in Dev and Ops having an appreciation of what the other groups do and the kind of decisions they have to make and why. All too often I have witnessed developers putting technology X into a product because it is new and hot and they want to use it, no matter what the consequences to QA, operations and so on. Dev and Ops should work together. Sure, that might mean that someone from operations spends some time in code working with developers getting an understanding of what’s going on and why, especially when it affects infrastructure design. The same goes for developers, spending some time doing some basic administration and maintenance of systems that traditionally fall outside of the developer role is a good thing. That said, having spent most of my time on the development side of the house and working very closely with operations I believe that developers should be involved in the consequences of their decisions. In fact the best developers I have worked with have cared about this and were extremely happy to work with operations teams if given the chance. Of course there has to be balance. If as a developer you are spending less time developing and more time playing with databases, infrastructure of whatever else you blame DevOps for I would guess there might be a couple of things going on: 1. The development team put something together than is hard to maintain once it is out of the hands of development and you are now being held accountable, or 2. You have a management problem. Either way I would say it’s not something DevOps should take the blame for. Perhaps this sounds like I am bashing developers! What I have said applies to Ops too. I’ve witnessed Ops being so resistant to change that developers feel like they are working with one or even both arms tied behind their backs due to constraints imposed on them. So no, DevOps isn’t killing off the developer, it’s not killing off operations or anyone else. It should be helping you collaborate and work effectively which will ultimately let you spend more time doing what you do best.
I’m really looking forward to DevOpsDays Pittsburgh this week. The first DevOpsDays event in a city is always special. I’m not sure what to expect, but I think it’s going to be great and at the very least I’ll get to have some great conversations about DevOps, configuration management and play some werewolf! I’m due to present an ignite session too, I have one lined up already but theres a good chance I might come up with something new based on conversations and presentations on the first day of the event. I’ll be at the event with Adi Aloni, so stop by and talk to us about CFEngine and some of the exciting things we are working on.
Introduction CFEngine users version their policies. It’s a reasonable, easy thing to do: you just put /var/cfengine/masterfiles under version control and… you’re done?
What do you think? How do you version your own infrastructure?
Problem statement It turns out everyone likes convenience and writing the versioning machinery is hard. So for CFEngine Enterprise 3.6.0 we set out to provide version control integration with Git out of the box, disabled by default. This allows users to use branches for separate hubs (which enables a policy release pipeline) and enables Design Center integration.
I had a thought-provoking article by Rachel Shannon-Solomon forwarded to me. Essentially the article states that while DevOps is great for startups the enterprise isn’t ready for it yet. I’ve read/heard people disagreeing with this but I think the article raises some great points. At DevOpsDays Austin I presented a session on why it isn’t realistic to expect enterprises to become just like startups when adopting DevOps. There’s a lot of technological and cultural complexity present in legacy enterprises that just aren’t an issue in startups. DevOps practitioners from startups don’t seem to have an answer either, quit your job and move to a startup might be a solution for an individual but it certainly doesn’t help with DevOps adoption in the enterprise. Setting aside the cultural difficulties of doing DevOps in the enterprise there’s the not so small issue that a lot of the tools available are suitable for startups but unproven and dare I say often unsuitable for the enterprise. Some vendors have been extremely skilled at attaching themselves to DevOps and trying to morph DevOps into something that helps them sell products. Unfortunately this doesn’t change the fact that software isn’t going to solve your DevOps adoption problem, in fact I would say some of the solutions I have seen presented can make matters worse. I’ve heard multiple times that being a Director of DevOps or a having similar title isn’t ideal because it implies that the person is responsible for the success or failure of DevOps in an organization. I agree with that in any type of organization. The problems DevOps is trying to address span multiple organizational units and it takes much more than one person with a fancy job title and a mandate to “do DevOps” to make changes in the enterprise. Those of us who believe that the DevOps movement can make a difference in the enterprise have a responsibility to recognize challenges faced. Let’s stop pointing out how awesome DevOps works in startups and get together to bring DevOps to the enterprise. Perhaps it is the DevOps movement that isn’t quite ready for the enterprise. The good news is that there are people who passionately believe in helping bring DevOps to the enterprise. I believe their work will help transform the DevOps movement into something more enterprise friendly while still keeping the spirit of DevOps.
Companies of all sizes are under pressure to succeed in competitive environments requiring them to move faster with expectations of always-on service from their IT organization. However, these same IT groups are faced with significant challenges from manual processes, homegrown patchwork solutions, disparate systems, and other legacy problems. In order to overcome these issues, companies need to automate their infrastructure in an intelligent way to keep up with the pace of the business while at the same time providing a secure and stable environment to deploy complex multi-tier applications to local or cloud infrastructure. By implementing a solution that enables continuous operations, companies can gain complete visibility and alert capabilities that can automate compliance checks, audits, and remediation using a policy-based approach. Join us for a discussion on Thursday June 19th at 10am PT / 1pm ET / 6pm GMT featuring guest speaker, Forrester Research, Inc. Vice President and Research Director Glenn O’Donnell **** and CFEngine Co-Founder and CTO Mark Burgess as they talk about the principles of continuous operations and how complete visibility combined with phased deployment rollouts can minimize risk and maximize uptime. Most importantly, you’ll also learn about how you can get started on implementing continuous operations within your organization. We hope to see you there! CLICK HERE TO REGISTER TODAY Speakers: Glenn O’Donnell, VP and Research Director Serving Infrastructure & Operations at Forrester Research Glenn serves Infrastructure & Operations Professionals. He is widely regarded as a top thought leader in IT service management, IT operations, and the broader social implications of technology evolution. Glenn’s specialties are in data center automation and operational excellence. He is the co-author of The CMDB Imperative, a book on CMDB best practices. Mark Burgess, Founder and CTO at CFEngine Mark Burgess is the creator and main technical architect of the popular CFEngine open source IT automation software. He was the first person internationally to hold the title of ‘Professor of Network and System Administration’, at Oslo University College. He now leads the research and development of the CFEngine software full time.
Once again DevOpsDays Austin was a fantastic event. This was the DevOpsDays event that I have been to that had two tracks. One track for what I would call traditional DevOpsDays sessions that focused on culture and organizational change, the other with more practical advice on how to get things done. I took the opportunity to get something off my chest that has been bothering me a bit about DevOpsDays and other DevOps events in general. I presented an ignite session titled “Why DevOpsDays (and other DevOps events) is failing both horses and unicorns”. Essentially I proposed that focusing on Amazon, Etsy, Facebook and Netflix so much wasn’t really helping the horses (aka the enterprise). Essentially there was a proposal and a reminder in the ignite: 1. Let’s stop using the regular DevOps idols as examples and replace them with stories from other companies. If there aren’t any other success stories then are we really making a difference at DevOpsDays events? 2. For the unicorns presenting always think about how what you are presenting applies to people in more traditional companies. Don’t just say “if you can’t do awesome in your current company quit your job and come work with us”. That’s not particularly helpful I didn’t really expect a positive reaction to the session but was pleased that it resonated with people. If the evolution of DevOpsDays Austin over the past few years is anything to go by I’m really looking forward to seeing how other DevOpsDays events will evolve over the source of the year. Next up is DevOpsDays Pittsburgh. CFEngine is sponsoring and I’ll be there to spread the word about CFEngine! Hope to see you in Pittsburgh!
Yesterday, I had an amazing opportunity to participate in the inaugural Internet of Things (IoT) Expo held at Fisherman’s Wharf in San Francisco. The event was conceived by Jeremy Geelan who is also behind the highly successful Cloud Expo events. The IoT Expo was well attended with many excellent keynotes and product demonstrations. Among others, industry leaders such as Tony Shakib (VP, IoT vertical at Cisco), Omri Lachman (Co-Founder and CEO Humavox), and Joe Speed (Director of IoT at the Linux Foundation) gave us very compelling insights into what IoT can achieve, its potential, as well as issues that still need to be solved for. Later in the day, I participated in a panel discussion with Peter Moskovits (Kaazing) and David Nielsen (Cloud Computing Evangelist and Consultant) around the following questions:
