staging-devopsy.kinsta.cloud

Tag: microsoft

  • Creatures of Habit, Snowflakes and Integration Tax

    Creatures of Habit, Snowflakes and Integration Tax

    Donovan Brown of Microsoft, in conversation with Matt Hilbert of Redgate Software, discusses database DevOps’ biggest challenges

    When DevOps was first talked about in Flickr’s seminal “10 deploys per day” Velocity presentation in 2009, it was regarded by some as strange and alien to corporate culture. It was the antithesis to the accepted way of doing things, a threat to established and proven processes—it was downright dangerous.

    Times have changed. Unicorns such as Uber, Airbnb, Spotify and GitHub couldn’t live without it. Microsoft has embraced it and actively promotes it. It’s become the key to gaining competitive advantage in a technology marketplace that is moving faster and changing quicker than it ever has before.

    But what about the database? Why are practices such as version control, continuous integration and automated deployment being introduced to application development but left on the shelf when it comes to the database? The 2017 “State of Database DevOps survey,” for example, found that continuous integration was in place for 39 percent of applications, but fell to 20 percent for databases. What’s going on?

    In search of some answers, we spoke to Donovan Brown, Principal DevOps Manager at Microsoft and DevOps advocate. Also known as The Man in the Black Shirt, his unofficial tagline is #RubDevOpsOnIt. He lives DevOps. In fact, you can’t stop him talking about it and enthusing about its advantages.

    He describes DevOps as “the union of people, process, and products to enable continuous delivery of value to our end users.” The most important of those three, according to Donovan, is people. It’s also, conversely, the most difficult to fix.

    ‘People are Creatures of Habit.’

    “If you’ve been doing something the same way for 30 years,” he said, “why would you fix it? We all resist change, even if change is for the better, and DevOps requires a lot of change.”

    A large part of that needs to come from the Ops side of the equation because, while processes including version control and continuous integration have become second nature to developers, Ops teams traditionally don’t do them on a daily basis. In fact, Ops are often seen as the opponents of change.

    Donovan does, however, hold his hand up as being partly responsible for the division. “Historically,” he said, “they’ve had to become the gatekeeper because developers like me 20 years ago were wreaking havoc on production servers, running on there with admin credentials. Their job in my opinion has never been to deploy software for us. Their job is to protect and manage the infrastructure, to make sure it runs as efficiently as it can. That history, though, stays with us because there is so much regulation and red tape to get code from the fingers of developers to the hands of users.”

    He sees DevOps as the solution to the problem. “What I’m hoping is that DevOps will help automate what we’re forcing them to do, which was never their job, and rebuild the trust between Dev and Ops. We really need to help Ops people realize that we’re not trying to replace them, we’re trying to empower and enable them to allow us to continuously deliver value.”

    It’s not down to Ops teams on their own, however. C-level executives also have a part to play because they often favor a traditional approach to software development, with targets and long term strategies standing in the way of DevOps.

    “What I’ve noticed in a lot of companies that are struggling to adopt DevOps is that they’re not getting the backing from the executive level,” Donovan saids. “You have this waterfall mentality from the top that still wants GANT charts and milestones, and things that just do not line up with agile thinking at all. I’ve had the best success implementing DevOps in organizations where the C-level executive got it. When you have a grassroots team who get it, but no one else does, they usually get snuffed out by tradition.”

    The database is not separate from Donovan’s goal of people, process and products coming together. Prior to joining Microsoft, he was a Process Consultant and Scrum Master, helping a range of companies introduce DevOps to their development practices. He made sure the database was part of that.

    Then, as now, including the database was a challenge, but Donovan worked around it, using the technologies available to allow customers to treat the database just like every other element in their DevOps solution.

    He does, however, admit it was hard work. “It’s actually the most difficult part of the pipeline to automate because of the risk of failure,” he said. “You can easily roll back a front end; you can’t do the same for your database because any transactions that have occurred during the deployment could potentially be lost. So, it’s a crucial, integral part of your DevOps pipeline and I challenge any company that claims to be doing DevOps that only does it for the front-end but their back-end is still done manually. To me, they’re faking it.”

    ‘Infrastructure as code should not be a special snowflake. It’s just part of your solution.’

    The key is to remember that the code written to make changes to a database is just that: code. Traditionally, it has been managed outside of and separate to application code, with database changes often managed on-the-fly, at the last minute. Consequently, deployments have become worrying at best, with teams on hand for the expected firefight against downtime.

    Include it in version control, however—and continuous integration and automated deployments—and the database can be developed in parallel with applications. Problems are then picked up earlier, deployments become predictable and reliable, downtime and rollbacks are a thing of the past.

    What has made this even more appealing is the tooling now available—software that in Donovan’s days as a consultant was only just emerging. As he admitted: “The tooling had to mature to allow us to get over a lot of the hurdles that are unique to database deployments so that we can have everyone incorporated into the DevOps pipeline, not just the unicorns. Everyone should have the power available to them to be able to take their databases and incorporate them as part of their DevOps pipeline. Until you do, you still have that being the bottleneck.”

    There is a price to pay, however, if by introducing tools to bring DevOps to the database, companies get bogged down by what Donovan calls “the vendor explosion.”

    ‘Every vendor you add to your pipeline also adds integration tax.’

    Integration tax is the cost to companies, in terms of training and introducing unfamiliar ways of working, to use a new piece of software that resolves a piece of the DevOps puzzle. If that cost is too high by, for example, moving people out of the development environment they’re comfortable with, it betrays the ideals of DevOps. One onerous way of working is simply replaced by another.

    Donovan is keen to remove that tax by encouraging companies to work with as few vendors as possible—and preferably those vendors who have already paid the integration tax in advance. By, for example, introducing tools that work inside or alongside existing software, thereby reducing the time it takes to become familiar with them, and making the most of the current infrastructure rather than adding to it.

    Otherwise, Donovan concluded, “You’re paying tax for that integration. When we at Microsoft have partners who create extensions for our products, it’s the vendor and Microsoft who pay the tax in advance.”

    Finally, I asked Donovan what the biggest challenge was for companies who adopt DevOps for the database. His answer was the most telling.

    “If you’re doing DevOps differently for your database and the rest of your system, to me there’s something wrong there. When I think of DevOps, the database is part of that. I don’t need a separate conversation about it.”

    About the Author/Matt Hilbert

    Matt Hilbert is a technology writer at Redgate Software with 20 years’ experience working for lots of the world’s biggest tech companies – and many of the smallest. He has a particular fascination for emerging technologies and is on a continuing mission to decompile, untangle, and explain techspeak to a wider audience, and excite people about the endless possibilities technology offers.

     

  • DevOps Chat: 7 habits of successful DevOps

    DevOps Chat: 7 habits of successful DevOps

    I recently had a chance to speak again with Sam Guckenheimer of Microsoft about his experience in leading the transition for Microsoft Visual Studio to Visual Studio online. In doing so, Sam and his team developed the 7 habits of successful DevOps.  You can listen to my interview below or read along below that. Also if you want to download the Microsoft paper on the 7 habits of successful DevOps you can do so here.
    [soundcloud url=”https://api.soundcloud.com/tracks/234949072″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

    Hi, everyone—Alan Shimel, staging-devopsy.kinsta.cloud, here for another DevOps Leadership Chat, and I’m joined today by Sam Guckenheimer of Microsoft. Sam, welcome.

    Interviewee:                 Hey, Alan. How are you doing?

    Interviewer:                 I’m doing well. It’s good to speak to you again. The last time we spoke was at the DevOps Enterprise Summit out in San Francisco.

    Interviewee:                 Yep, that was a lot of fun. That was a great conference.

    Interviewer:                 Yes, and you know what? I think—well, you contributed to making it great, Sam. It was a great presentation you made, talking about, kind of documenting the journey of Visual Studio from a COTS, you know, traditional kind of software model to a SaaS based program, Visual Studio Online. And, you know, I think that’s something that a lot of our listeners may be interested in, and how do they turn their current software offerings into SaaS based. And along the way, of course, you’ve come up with a, I guess you call it the Seven Successful Habits of DevOps?

    Interviewee:                 Yeah, so we think about the seven habits that we’ve applied as we’ve done our transformation. We started around 2010, we were in the, if you will, the pinnacle or the leader’s quadrants on all the analyst assessments as a provider of software for on-prem use in what was then called ALM—application life cycle management. And we said, “Hey, we need to become a great SaaS provider as well.”

    So we think of things in terms of these seven habits that we need to provide. Three of them you can think of as sort of Agile on steroids or second decade Agile. That’s team autonomy and enterprise alignment, is number one. We work in scrum teams or feature crews, think about 8 to 10 engineers and a product owner. They autonomously pull items from a common product backlog, and at the same time, they align to enterprise goals on a six month planning cycle, we call this a semester or a season, where we know, in that time frame, what are the needles we’re trying to move for the business? What are the things we’re trying to do at the epic level that count, and Sprintly we measure, how are we doing against that, and the things that each feature crew is doing are counting against that. They may move forward, they may move backward, they may decide, based on the data they’re collecting to do more or do something else. But you know, that’s in their control based on the things we’ve agreed for the six months.

    The second habit we have is a rigorous management of technical debt. We’ve known about technical debt for a long time, but when you’re running a service, you really can’t afford to let any debt creep in, and you have to stay clean all the time. So we make sure that we’re constantly monitoring both what’s happening in the production service and what’s happening in the development process. So if, for example, there is anything on the live site going wrong, we attend to it immediately. If there’s anything happening in the development process, like a feature crew is letting its bug count start to ride up, they have to stop immediately, fix the bugs, and can’t do any new work until they get them down to zero, so we stay clean on tech debt as we’re going.

    The third habit is a focus on the flow of customer value. We’ve talked about this since early days of Agile. Now, with SaaS, we can measure it. So we have great telemetry in the service, and we look at how people use our software, both quantitatively as we’re going forward; that is, we actually observe what gets used, what doesn’t get used, what the scenarios are, and we reach out to customers qualitatively, where we engage with the high usage accounts and we say, you know, “Let’s talk to them.” And we encourage our engineers to buddy up and reach out and say, you know, what’s gone well, what’s gone not so well, what would you like us to do that you don’t see? Are there things you wish for that we could be doing for you, and so on.

    So we reach out to customers, we listen to them through things like UserVoice and we observe their behavior through telemetry on a continual basis. That’s all kind of Agile on steroids.

    Interviewer:                 Mm-hmm.

    Interviewee:                 You know, those are the first three. Then you get to the stuff that’s really new with devops. The first is, of those, number four is what I’d call hypothesis driven development or a backlog that gets groomed with learning. This is what Eric Ries, in Lean Startup, calls “build, measure, learn.” So, in other words, the idea is that the backlog, instead of being the just, you know, what an omniscient product owner things is right, it’s—we recognize that it’s a set of hypotheses or beliefs. We think that these things will improve our service, but we’re gonna treat them as hypotheses and we’re gonna turn those hypotheses into experiments, and we’re gonna collect data against those experiments so that we can substantiate or diminish the hypothesis, and that data will be evidence gathered in production. That’s the fifth practice—everything is evidence that we need in order to build up or draw down against those hypotheses. We look, we use instrumentation on everything, we use telemetry on everything, and we measure it against what’s important.

    So, for example, if we think something’s gonna be a better sign of experience, we will run the new against the old in parallel, and we may, if we have multiple front doors, like in our case we have a web experience and an experience through the IDE, the integrated development environment, we’ll run those in parallel. So that would be a four cell test, you know? New and old, web and IDE, and we’ll see what the evidence shows us about how much better the new is than the old, and hopefully the new is better; it might not be. Hopefully we’re right, but sometimes we’re wrong. In any event, it’s the data that will tell us, and it’s a “bring your data” world.

    So, evidence gathered in production is our fifth habit, and that is made possible by our sixth, which is what we call a production first mindset, or what Satya, our CEO, calls a live site culture. The idea of a live site culture is that the site status is always first priority, and with site status, you have two goals. If there is a live site incident, you want to, as quickly as possible, remediate so that customers aren’t affected, and you want to drive to a root cause analysis. Practice the 5 Whys like Toyota, get to the root cause, and identify the actions that you need to take in order to prevent a recurrence of such an incident or something similar, and those root cause actions that you take, you need to complete in one or two sprints so that you’re hardening the service as you go learning from the live site incidents so that you’re always getting better.

    That’s number six, and finally, number seven is that we manage infrastructure as a flexible resource. We can do this because we use the public cloud—of course, in our case, that’s Azure. We work as a customer of Azure just like our external customers would. We take things a little earlier, but otherwise, we’re a customer when we need more resources for development or for load testing or to spin up more labs, we just do it.

    And we continue to expand the number of data centers we run, and we now run our Visual Studio Team Services in eight data centers around the world; that’s out of 24 regions that are currently active in Azure, and we fully automate the deployment, but we start each Sprintly deployment with a canary instance, which is where we work. It’s our own one of those stamps, and the one where our closest early adopter customers are so that we know from the canary if there’s anything wrong with the deployment, and if there is, we then restart at the canary before we roll out to the subsequent deployment rings. And that practice of canary-ing, going big with load testing is part of the deployment pipeline, and then using the automation to roll out in subsequent rings is something that we’ve used to harden the service and let us get to a global scale on a regular basis.

    Interviewer:                 Got it. So, Sam, these are obviously lessons learned the hard way, right, [Laughter] by doing and paying the idiot tax and doing that.

    Interviewee:                 Yes.

    Interviewer:                 For our leaders who are listening to you now, where to begin? Where to start? Obviously you can’t do all seven at once. Some of them are dependent on others. Where do they begin?

    Interviewee:                 Well, I think that the first thing is to make sure you have Agility down. I think you cannot do this if you are a command and control organization that doesn’t really let teams learn, and to recognize that you do need to measure your time to learning along with your other measurements, you also need to totally automate your release pipeline.

    So, the notion that you can have manual steps somehow between a development pushing code or checking in and the release of that is a thing of the past. You know, start with continuous integration and then quickly go to continuous deployment and put the telemetry in place so that you can see the evidence from production that gives you the feedback on everything that’s getting deployed.

                                        If you don’t have those things in place, the rest will crumble.

    Interviewer:                 Yeah, agreed.

    Interviewee:                 Sam, we unfortunately are coming up near the end of our time. I want to ask one more question of you, though, and it’s along the same vein. So, you’ve laid out the steps here for us. How did you get your team’s buy-in on this—or did you?

    Interviewer:                 Well, we certainly did. I don’t think it was very hard. I think that we all wanted to move to this world. I think that there was a broad recognition that we needed to become a first class SaaS provider. I think that there were some additional quirks in our case of being a great SaaS provider while we continue to be a great provider on-prem software, and maintaining that engineering discipline.

    The teams were all for it. I think the leadership needed to recognize that we were investing in new practices and that we needed to maintain the investment in engineering systems and engineering practices so we have a rule of thumb that about 20 percent of our investment goes toward non-customer visible engineering, things like live site work, and we don’t quarrel about that. If we need to do live site improvements, we do them.

    So I would say there was a little bit more work on management to accept the change in practices than there was on the ground with the engineering teams who were sort of chomping at the bit to get going.

    Interviewer:                 Well, there often is in devops, right? You have that “from the bottom up” and getting true top down sponsorship and cover is a problem, right? Not a problem that cannot be overcome, but an issue that we’ve explored previously in our leadership suite here.

    Interviewee:                 Yeah. Yeah, it helps that our, right now, our CEO comes from this world, Satya Nadella, so he is pushing everyone in the company to make the change and to learn the new practices. There were some folks in the middle who were not comfortable, necessary, but you know, they’ve come around.

    Interviewer:                 As they often do.

     

    Interviewer:                 Sam, anyway, we are probably over our time and I apologize, but thank you very much for sharing your Seven Habits for Successful DevOps. Continued success with your Microsoft Visual Online and the rest of your endeavors at Microsoft, and we hope to have you on again some time in the future and we can talk more about leading the transformation at companies around the globe with these new ways of doing things.

    Interviewee:                 Thanks, Alan. I’ll do one commercial, which, which is that there’s a URL, microsoft.com/devops, where you can download an e-book about our journey and a devops self-assessment if you want to read more.

    Interviewer:                 You know what, we’ll include that link in the article, too, in the transcript so people can get that. Sam Guckenheimer, Microsoft—thank you so much for being our guest today.

    Interviewee:                 Thank you very much, Alan.

    Interviewer:                 Okay, this is Alan Shimel for staging-devopsy.kinsta.cloud. Thanks, and have a great day.

  • Hyper-V Containers combine virtualization with containerization

    Hyper-V Containers combine virtualization with containerization

    Containers are all the rage these days. You’re just not cool if you’re not using Docker or some other container technology to build and deploy your IT infrastructure. Traditional containers, however, lack sufficient security for some industries and companies, so Microsoft developed Hyper-V Containers.

    Container platforms like Docker and Rocket have significant momentum and have quickly become established as a de facto way of developing and deploying applications. Microsoft already entered into an arrangement to bring native Docker container support to Windows Server, but now it is going a step farther by creating Hyper-V Containers that combine the agility of containers with the security of virtualization.

    Hyper-V Containers ensure that code running in one container object remains completely isolated. The Hyper-V Container object cannot impact other container objects or the host operating system, or vice versa, because it is a separate virtualized container. Mike Neil, general manager of Windows Server for Microsoft, explained in a blog post, “Leveraging our deep virtualization experience, Microsoft will now offer containers with a new level of isolation previously reserved only for fully dedicated physical or virtual machines, while maintaining an agile and efficient experience with full Docker cross-platform integration.”

    IT admins will appreciate the fact that Hyper-V Containers can be created and deployed using the same development and management tools used for traditional Windows Server Containers and that they integrate with Docker for cross-platform deployment. Neil points out that applications developed as Windows Server Containers can easily be deployed as Hyper-V Containers without any modification—enabling organizations to take existing containerized apps and re-deploy them in a more secure manner.

    It seems like security is always an afterthought to any new technology concept, and containers is no exception. It started out as a good idea that caught fire, but it wasn’t until it hit critical mass and achieved mainstream adoption that security became a factor. As larger companies, or organizations in highly-regulated industries look at jumping on the container bandwagon, though, security becomes a mandatory component.

    Virtualization has been used in hosted environments for years as a means of isolating different systems running on the same physical hardware or network. Microsoft’s Hyper-V Containers take those same principles and apply them at the container app level so that security-conscious organizations can have some peace of mind and remain compliant with security mandates as they embrace containerization.

    Microsoft’s strategy of integrating Windows Server Containers and native Docker support in Windows Server and Azure was a big step in the right direction. Adding the security of Hyper-V Containers is brilliant. Microsoft is doing an excellent job of pivoting its business model and not just embracing cloud and DevOps technologies, but raising the bar and taking the lead.

    As a side note Microsoft also announced Nano Server—a new minimal footprint implementation of Windows Server optimized for cloud hosting and container technologies. The Nano Server installation includes the bare minimum components necessary. Microsoft claims the result is smaller server images, faster deployment times, decreased network bandwidth consumption, and reduced administrative overhead. In other words a Nano Server installation of Windows Server will just do what it’s supposed to do with minimal interaction or oversight so IT personnel can focus on more important things like the Hyper-V Container apps running on it.

  • Microsoft strives to embrace open source culture

    Microsoft strives to embrace open source culture

    In many ways Microsoft is going through the corporate equivalent of a mid-life crisis—it has reached a stage where it longs to drop a few pounds, and turn back the clock a few years. After years of tremendous success, it’s now starting to show its age, and it is struggling to adapt to the new tech landscape and compete with younger, leaner, more innovative competitors.

    The shift began under ex-CEO Steve Ballmer. Ballmer’s approach, though, was misguided. Ballmer’s Microsoft suffered from hubris, and ignored the seismic shift in technology until it was too late. When Ballmer finally recognized the existential threat, and tried to turn the ship around, it was done from within the established bloated corporate culture. There was an effort to rearrange the chairs on the deck with a management reorganization, but it simply wasn’t enough.

    Then Satya Nadella took over. Nadella has a more aggressive vision. It’s still not an easy job, nor a goal that can be accomplished overnight with a behemoth the size of Microsoft, but Nadella has dramatically changed the culture, and the vision for where Microsoft is heading.

    Part of the new and improved Microsoft includes embracing communities that Microsoft has long ignored or alienated, and shifting the way things get done at Microsoft so the company can be more agile. It is evident in how Microsoft partnered with Chef and Puppet Labs to integrate popular DevOps tools into the Azure cloud platform, and it can be seen in how Microsoft is adopting open source.

    “Recent articles have shown that Microsoft is “open sourcing” code to their internal teams. The fact that that is advertised as innovation is telling,” declared Michael LaVista, CEO and Founder of Caxy. “That’s what smart organizations have always done. In fact, Microsoft has somehow found itself the underdog in this sense and probably needs to do things like this to attract talent.”

    Leveraging open source concepts internally isn’t quite the same thing, though, as actually making Microsoft code open source. Open source projects like Apache, Project Libre, or Docker share source code with the general public, and anyone can review the code, and submit changes to improve or fix the code. Open source communities collaborate to continuously enhance the code. Microsoft appears to be doing something similar, but without exposing its source code to the general public.

    LaVista suggests that Microsoft should take that next step, though, and work collaboratively with the open source community outside of Microsoft’s walls. If it does so, Microsoft will some issues to address. Will it accept code fixes from a 14-year old on the other side of the world? Will exposing source code for the Windows operating system, Microsoft Office, or other popular Microsoft applications open up a Pandora’s Box of security concerns?

    “They will have to embrace what happens to code when it is open sourced. Once the code is out there, everyone can see the flaws,” explains LaVista. “The benefit of the model is that you have so many more eyes looking at it from more perspectives. If Microsoft is used to running their own software and making their own decisions about what to work on and fix, this could pose problem.”

    Perhaps. LaVista makes good points about concerns Microsoft would face, but in and of themselves they’re not a reason not to adapt and evolve. Yes, exposing Microsoft source code to the general public would probably result in a spike in security concerns, but once the dust settles the collaborative approach of an open source community addressing those issues could result in quicker patch releases, and make the software more secure.

    LaVista recommends that Microsoft use companies like Red Hat, IBM, and HP as examples of how a larger corporation can be successful in an open source culture. Only time will tell. We’ll have to wait and see to what extent Microsoft makes the shift to open source, and we’ll have to wait and see how Nadella’s Microsoft adapts, and whether Microsoft can successfully reinvent itself to remain competitive in this new tech landscape.

  • Microsoft bridges the gap between Azure and DevOps

    Microsoft bridges the gap between Azure and DevOps

    DevOps can be easy for a startup. Many of the concepts and principles of DevOps come quite naturally to a fresh company just getting started. It’s a different story, however, for large, established enterprises trying to wrap their arms around this DevOps thing. For IT admins working in Microsoft’s Azure cloud platform, though, things just got a lot easier thanks to the integration of Chef and Puppet Labs.

    Many organizations are heavily invested in the Microsoft ecosystem. IT teams and administrators are familiar with Windows domains, Active Directory, Hyper-V, and Azure. They know how to write scripts and leverage PowerShell to get things done, but they’re much less familiar with the core principles of DevOps, or common DevOps automation tools like Chef and Puppet Labs.

    One of the driving forces of DevOps is the ability—or perhaps necessity—to automate those tasks that can be automated so IT resources are freed up to focus on more important tasks. Deploying and configuring virtual servers and applications is necessary, but it can also be tedious, and it is a task that can be easily automated using DevOps tools.

    The arrangement also works the other way. Smaller companies that are already familiar with, and invested in DevOps may need to scale to a platform like Azure. They should be able to build on what they’ve started, and continue to use the tools they’re familiar with as the company migrates to Microsoft’s Azure.

    One of the main attractions of Microsoft Azure is the degree of flexibility, choice and control it gives customers. Microsoft Azure’s partnership with Puppet and Chef allows customers to choose from an array of existing technologies and communities to easily deploy, configure, automate and manage their VMs.

    According to a Microsoft spokesperson Puppet Labs and Chef complement and extend Microsoft technologies such as Resource Groups and PowerShell Desired State Configuration (DSC) to offer more options for customers to migrate existing or deploy new applications to the cloud. The partnership offers Microsoft the ability to support Linux and UNIX environments, and also alleviates the concerns that organizations already using Puppet or Chef will have about abandoning their investment. Now, they can continue to use their Puppet modules or Chef recipes in Azure.

    Luke Kanies, CEO of Puppet Labs believes the integration of Puppet Labs and Azure will help Microsoft IT admins by making it easier to deploy applications across any platform or cloud environment. Kanies explained in a press release, “Our goal is to help you automate the configuration and ongoing management of your machines and the software running on them, so you spend less of your time firefighting and running simple scripts across a thousand machines, and more time getting great software in front of your users.”

    I spoke with Kanies about the difference in dynamics between a small company and a large enterprise. He told me that in a small company it’s much easier to communicate and coordinate resources, and the cost of failure of any particular project is much lower. For a large, established enterprise, however, there is assumedly a large base of existing customers, and there is more fear and worry about possibly disrupting normal operations.

    I also had a chat with Ken Cheney, VP of business development for Chef. His philosophy mirrors a lot of what Kanies described. Cheney told me that emerging companies have the luxury of starting from ground zero with a clean slate. There aren’t yet any established processes to navigate. The challenge is trying to transform an organization with established processes, and a team of existing developers over to a DevOps mentality. Integrating DevOps into Azure helps organizations to meet that challenge.

    DevOps adds an element of speed and simplicity that makes it easier for larger enterprises to be more agile. Using tools like Puppet Labs and Chef enables IT admins to add speed as a core requirement for infrastructure projects without disrupting or conflicting with other requirements—like security and stability.

    Ultimately, the new alliance illustrates Microsoft’s commitment to empower Azure customers with the best-in-class configuration and automation tools by embracing the technologies, communities and ecosystems that developers know and love. Combining Azure with powerful and popular platforms like Chef and Puppet Labs bridges the gap between traditional IT and DevOps—enabling old school IT admins to embrace DevOps, and DevOps startups to mature and evolve into larger enterprises.