devopsy.kinsta.cloud

Author: Tony Bradley

  • 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.

  • DevOps by any other name still gets things done

    DevOps by any other name still gets things done

    My version of “A rose by any other name would smell as sweet” is not nearly as eloquent as Shakespeare’s, but the sentiment is the same. Juliet argues in Romeo and Juliet that the name of a thing such as a rose is irrelevant—it’s still a rose no matter what you call it. The same thing is true when it comes to DevOps.

    The term DevOps has achieved industry buzzword status. Most people—at least most people in IT—are familiar with the term even if they don’t have any idea what DevOps is. Even among those who think they know what DevOps is, there may not be consensus on how to define or implement the concept. It is understandable that some people don’t have a clue what DevOps really is.

    The Wikipedia entry for DevOps is a great illustration of the issue. Wikipedia is a crowd-sourced encyclopedia, and as such it is comprised of a variety of contributions. The first few paragraphs of the DevOps Wikipedia entry actually offer up different attempts at a definition. The various explanations don’t necessarily conflict directly with one another, but they also don’t agree completely and reading the Wikipedia entry will leave most people just as confused about what DevOps is or isn’t as they were before they started.

    It’s a “software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.”

    The goal of DevOps is “to maximize the predictability, efficiency, security and maintainability of operational processes. This objective is very often supported by automation.”

    It “targets product delivery, quality testing, feature development and maintenance releases in order to improve reliability and security and faster development and deployment cycles.”

    It “aids in software application release management for a company by standardizing development environments.”

    All of these are true, and yet none of them is necessarily THE definition of DevOps. The simple reality is that it doesn’t really matter.

    DevOps is not a single thing per se. It is a culture, and how that culture is embraced or implemented van vary from one organization to the next without altering the fact that both are employing DevOps. DevOps is not a product or tool–it’s a culture that has evolved organically to meet the needs of a more rapid pace of IT. Many organizations are utilizing DevOps processes or tools, and have no idea what DevOps is.

    If your organization has developers who manage operations, or IT ops staff who do development, or developers and IT operations staff who work closely together to get things done, you might be doing DevOps.

    If your organization uses scripts or other tools to automate the provisioning and/or configuration of servers, virtual servers, or entire virtualized environments, you might be doing DevOps.

    If your organization rapidly develops new iterations of an application, or continuously rolls out new features and tools, you might be doing DevOps.

    If your organization continuously monitors for suspicious activity or potential malicious attacks, you might be doing DevOps.

    If your organization makes extensive use of the cloud in order to be more agile, and be able to scale quickly to meet demand, you might be doing DevOps.

    If your organization lacks rigid structure between departments, and functions more like a startup where everybody does everything, and just does what it takes to get things done, you might be doing DevOps.

    If your organization automates simple tasks and functions with technology rather than wasting valuable man-hours doing everything manually, you might be doing DevOps.

    It doesn’t matter if you understand what DevOps is. It doesn’t matter if you call it DevOps within your organization. All that matters is that you take the elements that make sense for you, and adopt them in order to function more effectively and efficiently, and remain competitive.

  • Clone your entire IT infrastructure in the cloud at the push of a button

    Clone your entire IT infrastructure in the cloud at the push of a button

    Rapid development and deployment is a hallmark of DevOps. The faster pace doesn’t change the need for testing applications before they’re pushed to production, or QA testing the code and infrastructure, though. The tricky part for many organizations is that different groups need access to the same environment, and creating duplicate environments can be tedious.

    There are plenty of tools out there that enable an IT admin to quickly create and provision virtual servers. The virtual servers can even be created from base images that include all of the necessary applications and configuration to match the servers in production. That part is fairly simple.

    Where it starts to become challenging is the rest of the infrastructure. The virtual servers might be identical to the production servers, but unless the switches, routers, connections to other servers and applications, IP addresses, and every other aspect of the production infrastructure match identically, the testing or development done in the secondary environment might not be completely valid.

    In 2011, the core team that introduced the KVM hypervisor—now the standard virtualization technology in Linux—founded Ravello Systems to address and solve this challenge. The Ravello Systems team understood that it’s possible to migrate virtual servers to a new environment, but that doing so introduces other issues, and the resulting environment is not an exact duplicate of the original. They set out to find a way for an entire infrastructure to keep up with the pace of agile development.

    Ravello provides organizations with a way to implement repeatable deployments—complete clones—of complex multi-tier production environments at the push of a button. It’s a concept they call nested virtualization. Ravello saves a blueprint of the environment, and enables IT admins to spin up instances of the complete IT infrastructure, including networking and storage configurations, with a single click or API call.

    One organization that has adopted Ravello for managing rapid development is Deutsche Telekom. Deutsche Telekom (DT)—the fourth largest wireless service provider in the world—maintains a cloud telephony service that is a complex multi-tier application with multiple virtual machines, and network appliances from F5 Networks, Brocade, and Palo Alto Networks. DT uses Chef and Jenkins to automate many aspects of continuous integration and continuous development, but it needed a solution to keep up with capacity needs without the expense and effort involved in expanding the physical datacenter environment.

    “Creating a copy of our production-like environment in Ravello was easy. We simply uploaded our base image, and virtual appliance form factors of our physical appliances, and then used the Chef bootstrapping support that Ravello offers to bootstrap into our existing Chef infrastructure,” said Ram Akuka, director of DevOps at Deutsche Telekom HBS in a statement. “What we are building is a truly large scale system with millions of concurrent users and transactions, so by continuously developing with Ravello we can easily scale to meet our customer’s critical business communication needs twenty-four by seven.”

    The first wave of virtualization made server platforms hardware agnostic. A virtual machine of any server operating system could be deployed and run from virtually any x86 hardware through virtualization. Ravello takes that a step farther by taking the entire virtualized environment, and making it cloud agnostic. The Ravello virtualized infrastructure can be deployed on AWS, Azure, or any other cloud platform.

    Ravello also keeps the pricing and invoicing for the service simple. Ravello charges customers on a per application basis rather than per VM. The Ravello pricing also includes the underlying cloud platform. You get one bill from Ravello, and you don’t need to pay the cloud provider separately.

    If you’re struggling to scale the scope and capacity of your infrastructure to keep up with demand, or you’re having challenges with development or testing in environments that aren’t exact clones of the production environment, you should take a closer look at Ravello and see if it will help you resolve those issues.

  • DevOps doesn’t end at deployment

    DevOps doesn’t end at deployment

    If you ask five IT admins the question “What is DevOps?” you maybe get eight different answers. We’ve attempted to define and explain the term DevOps here on devopsy.kinsta.cloud a few different ways, but a precise definition is still elusive. One thing is certain, though, DevOps is about more than just automating virtual server deployment and configuration.

    At Velocity 2009, John Allspaw and Paul Hammond presented a session titled “10 Deploys Per Day: Dev & Ops Cooperation at Flickr”, which some credit with launching the concept of integrating development and operations—at least to mainstream IT. For many, though—especially those who are still trying to understand what DevOps is, and what it means for their organization—DevOps amounts to tools that simplify the process of implementing tens or hundreds of virtual server instances, and automating the initial configuration.

    Automating IT

    Tools like those offered by Chef and Puppet Labs are useful for automating routine tasks associated with deploying and configuring the IT infrastructure, as well as deploying and updating applications. These vendors can also help monitor and maintain a consistent, stable environment by enforcing a designated configuration.

    To be honest, that sort of automation is more or less table stakes for DevOps. It’s just one small facet of a much larger concept that involves the entire scope of development and operations—agile development and rapid iteration of new versions and features combined with an automated and easily-scalable infrastructure.

    Once the virtual server environment is up and running, though, and once the applications are deployed, the work is really just beginning. Part of merging development and operations, and keeping up with a more rapid pace of IT involves ensuring that everything is running smoothly. With frequent updates and rollouts, it becomes even more important to have tools in place to automate monitoring and alert IT admins when something goes awry.

    DevOps also involves tools like those from Stackify—tools that keep an eye on the apps running in your environment and let you know when things don’t quite seem to be firing on all cylinders. When something goes wrong, you want to know about it in a few seconds, not a few hours or days. Stackify can monitor and trend important metrics like CPU, memory, and disk utilization on your servers, and alert via email or SMS text when problems arise.

    Automating the creation, deployment, and initial configuration of servers is awesome—but you also need tools to address the challenges of maintaining and updating thousands of server instances as well. You need to be able to add or change user privileges, apply patches and updates to the operating systems or applications, change security configurations, enforce compliance policies, and more. When you’re talking about hundreds, thousands, or tens of thousands of servers, it’s imperative that you have tools like JumpCloud to help automate those tasks across the entire environment.

    More than just tools

    As great as all of the various DevOps platforms and tools are, though, DevOps is not just a matter of buying or implementing an array of tools to manage your IT environment. As the name implies, and as Allspaw and Hammond spelled out in 2009, it’s about instilling a culture that breaks down traditional barriers and enables developers and operations to work cooperatively and collaboratively.

    The traditional roles of developers and ops impose unnecessary friction that gets in the way of being effective. Developers blame problems on the implementation or IT infrastructure. Operations personnel blame problems on poorly developed code. Creating an environment where all appropriate parties work together, and where everyone takes responsibility rather than assigning blame creates an entirely different dynamic for productivity.

    When it comes down to it, it’s the culture of DevOps that accelerates the speed of changes and updates that necessitates tools and platforms to automate deployment and infrastructure management. The culture drives the tools, not the other way around.

    So, yes, one of the most visible components of DevOps may be tools that automate the deployment and configuration of servers, but that is just one element of DevOps, and it’s just the beginning. Everything that happens after that to monitor, maintain, and update that environment once it’s deployed, and everything that happens outside of the IT infrastructure to streamline productivity and increase efficiency is all part of DevOps as well.

  • The US Air Force was doing ‘DevOps’ before it was cool

    The US Air Force was doing ‘DevOps’ before it was cool

    One of the pillars of DevOps is the obliteration of traditional silos, and the ability for cross-functional teams to work together to just get things done. While the concept may be new for developers and businesses, the United States Air Force already demonstrated the power of this philosophy during Operation Desert Storm more than 20 years ago.

    “DevOps” – Air Force Style

    The US Air Force is configured primarily in separate units, or silos. Generally, a base or wing is comprised of a single type of aircraft. C-130 transports, KC-135 refueling planes, F-15 fighter jets, A-10 ground engagement aircraft, and F-111 bombers each had their own base of operations, and separate command and control infrastructures. During Desert Storm, though, a new Composite Wing was formed, which included a cross-section of all of these aircraft and Air Force resources tasked to work closely together with one chain of command.

    Air Force Brigadier General Lee Downer wrote about the formation of, and experience with the Composite Wing in an Airpower Journal article in late 1991. In essence, by removing layers of red tape and bureaucracy, and putting all of the required assets and resources under one command, the 7440th Composite Wing was able to operate with unprecedented efficiency and effectiveness.

    Downer concluded with these thoughts: “The 7440th Composite Wing’s achievements are now a part of history. The efforts to get the wing into the war are a special success story that should be told in more detail in the future. As is usually the case, once the decision to go was made, the success of the effort was up to the people who were tasked to make it work. Their accomplishments clearly show that they assumed the challenge with a great deal of enthusiasm and skill. They knew their jobs, did not hesitate to make decisions, and kept improving the operation as they became seasoned and experienced.”

    I can speak personally about the success of the 7440th Composite Wing as well. I was serving in the Air Force at the time, and I was deployed to Incirlik AB as a part of the Composite Wing effort for both Operation Desert Shield and Operation Desert Storm. While my role was traditionally focused on, and restricted to working with F-111 bombers, the exact same technology was also used with other aircraft from other bases.

    During Operation Desert Shield, while working as a part of the 7440th Composite Wing, those barriers were removed and I was given the freedom to do what I did best without regard for the aircraft or what base it originated from. It was a much more logical and effective use of resources—in this case the resource being me.

    Fast Forward 20 Years

    The same concepts and philosophy the US military embraced during Desert Shield form the foundation of the DevOps movement today. The goal is to minimize friction, and empower people to do what they do best with minimal obstacles.

    By removing the barriers between different teams and departments, and allowing people to work together in ways that make sense, organizations are able to get more done, in less time, and get it done more efficiently.

    You don’t have to create a formal merger of assets and resources like the US Air Force did with the Composite Wing. While it did facilitate better integration, and greater effectiveness, defining the resources of the merged team is its own silo in a way, and still puts limitations on what the new team can accomplish.

    You should, however, embrace the essence of the concept—which is to remove obstacles and allow individuals and teams the freedom to share resources, and collaborate together to achieve goals without unnecessary red tape or bureaucracy.

  • Citrix puts DevOps front and center

    Citrix puts DevOps front and center

    I had the privilege of attending Citrix Synergy 2014 in Anaheim at the beginning of May. Citrix unveiled a variety of new and updated products, but one announcement in particular surprised me a little. Citrix talked about new capabilities for automation with a very DevOps-ish approach.

    During a keynote presentation at Citrix Synergy 2014, Sudhakar Ramakrishna, senior vice president and general manager for the enterprise and service provider division at Citrix talked about automatic provisioning through Xen Desktop, and creating blueprints for deployment. He didn’t overtly call it DevOps during the keynote, but it all seemed very similar to what other DevOps tools and services accomplish.

    I followed up with Citrix, and had a conversation with Steve Shah. Shah told me that DevOps is absolutely front and center in the thought process for Citrix when it comes to developing products and services for its customers, as well as for mapping out its future strategies.

    Shah was at one point a bit of a DevOps naysayer. In an article in 2011, Shah questioned the credibility of DevOps and wondered whether it would survive as an actual thing, or if it was really just a flash-in-the-pan buzzword. Three years later and still gaining momentum, I think we can safely say that Shah’s doom and gloom assessment was off base.

    Citrix understands the need and the value for automating routine aspects of provisioning and managing virtual systems. According to Shah, though, one of the things Citrix has noted about the broader landscape is that there is no clear platform for doing DevOps. There are a wide variety of tools and services with a few leaders, but no clear “winner”.

    Shah told me that Citrix is only one part of a much larger solution, and it respects that it has to play nice with a wide variety of other products and services, or customers will find other solutions. There are too many unique, custom applications out there for Citrix to individually address them all, so Citrix has instead focused on creating open APIs that enable vendors or customers to develop their own methods of integrating with Citrix.

    Another area where Citrix has embraced DevOps—whether it is openly called that or not—is through the use of Blueprints. Citrix determined that there are certain deployment scenarios that are very common for customers across all industries. Rather than having each one of them struggle to develop their own solutions, Citrix designed Blueprints of common scenarios that customers can use as a foundation for their own environments—similar in many respects to the Recipes and Cookbooks used with Chef, a popular DevOps platform.

    My revelations from the Citrix Synergy keynote, and my subsequent conversation with Citrix made two things clear. First, many organizations may be embracing elements of DevOps without even realizing or calling it that. There are things that just make sense when managing a large, rapidly evolving environment that naturally lead to implementing aspects of DevOps. Flipping that point upside down, those same needs are more or less the origin of the DevOps movement.

    Second, DevOps is gaining momentum and becoming more mainstream as time goes on. While many still struggle to define DevOps, it shows up in day-to-day operations, and in the platforms and tools organizations use whether they understand it or not, and whether they call it DevOps or not.

  • Simplify and expedite server management

    Simplify and expedite server management

    Deploying, managing, and maintaining servers can be tedious. Deploying, managing, and maintaining thousands, or tens of thousands of server instances is overwhelming—bordering on impossible—without the right tools. Thankfully, the right tools exist.

    The Pain of Doing Things the Hard Way

    I know I am dating myself, but when I was an IT admin for a dot.com startup, I had to deploy servers the old-fashioned way. UPS would show up with a box from Dell. I’d unpack it, and mount it on the rack in the datacenter. Then, I’d begin the process of configuring the operating system, and installing the application software. Each server was essentially a full-day project, and we seemed to constantly be adding new servers, so my full-time role was basically “racking and stacking” for a while.

    Adam Jacob was experiencing similar obstacles when he developed Chef. Working as an IT infrastructure consultant, Jacob was frustrated by the configuration tools that were available, and the lack of a simple, repeatable process. Rather than starting from scratch and reinventing the wheel for each client, he developed Chef to enable IT admins to create modular, reusable “recipes” that automate the process.

    Server management doesn’t end with deployment and initial configuration, though. You also have to maintain the servers, and resolve issues that might occur. When an issue arises, it could mean hours of troubleshooting to identify the root cause, and another few hours to work out and implement a resolution.

    I used to get into philosophical debates with management and other IT personnel because it was my opinion that we should just skip the troubleshooting and rebuild the server from scratch. My theory was that it might be nice to know what caused the problem, but from an operational perspective I knew I could rebuild the server and restore normal operations in a couple hours. Troubleshooting, on the other hand, was an unknown—both in terms of whether or not it would even be successful, as well as how long it would take.

    The Beauty of Doing Things the Easy Way

    Tools that automate configuration and deployment of server instances automatically solve both of these problems. They expedite deployment and configuration, and simplify management and maintenance—freeing IT admins and IT personnel to focus on more important, less mundane tasks.

    Tools like Chef help IT manage complexity. It is great from a DevOps, automation perspective to have a tool that enables you to quickly deploy and configure servers, but the real value comes from the ability to maintain a stable, dependable network with minimal effort.

    Chef nodes “phone home” periodically to ensure the configuration matches the recipe it has been assigned from the Chef server. Any deviations are automatically overwritten—so any changes that may have been made locally on the node are erased, and the server remains configured as it should be.

    In order to implement lasting configuration updates, the changes have to be made to the recipe at the Chef server level. The bonus is that once the recipe is updated, all Chef nodes working from that recipe will be automatically updated.

    When an issue occurs on a server instance, it should ostensibly be corrected automatically when the node communicates with the Chef server and overwrites the configuration. However, even if that doesn’t happen for some reason, the use of DevOps tools like Chef still makes the task of troubleshooting and/or resolving server issues much more efficient.

    With the push of a button, you can just deploy a new server—properly configured and ready to go. You could choose to kill the server experiencing issues and just replace it with the new one, or you could launch a new server to take over the roles and responsibilities of the affected server while you take the time to troubleshoot if you really need to understand what the root cause of the problem was.

    Embrace simplicity

    Apparently, I was an IT admin at the wrong time, and I got out of that career path right when things started to get interesting. Necessity being the mother of invention and all that, Adam Jacob created a platform with Chef that reduces the complexity and tedium of deploying and managing servers.

    Chef isn’t alone. Tools like this form the foundation of DevOps because a culture that combines development and operations, and iterates new releases on a rapid scale needs to have this sort of automated IT infrastructure to keep up.

  • Embracing a culture of continuous incident response

    Embracing a culture of continuous incident response

    In a world of continuous development and rapid iteration combined with being connected online 24/7/365, you are bound to encounter threats. In fact, attackers use automated tools so you are under constant siege from continuous threats. The natural response is to implement some form of continuous incident response.

    The standard development model involves different stages of requirements gathering, writing code, and beta testing, resulting eventually in a defined, periodic software release. That model is being replaced by the DevOps culture of continuous development. Security faces a similar transformation from the pervasive legacy model of the “us vs. them” protect-the-perimeter model to a new system of continuous incident response that addresses the current threat landscape in the real world.

    There is no “us”, and there is no “them”. There is no perimeter. Your authorized users are actually more likely to expose sensitive data, or compromise your systems—whether intentionally or inadvertently—than external bad guys. Your authorized users are also just as likely to be “outside” of the mythic perimeter—connecting from personal smartphones or tablets, or logging in from a Starbucks across town. The traditional security model is simply not equipped to deal with today’s technologies or threats.

    So, what is continuous incident response? I spoke with TK Keanini, CTO of Lancope, who explained, “Some people when thinking about process think of it as a linear model where there is a beginning and end; a better way to model adaptive processes is with a loop and continuous incident response is a loop.”

    He elaborated, “Borrowing from John Boyd’s OODA loop, continuous incident response is where there is an observation, orientation, decision and action cycle that outpaces or runs at a faster tempo than the adversaries.”

    Zane Lackey, director of security engineering for Etsy.com, gave a presentation at the Hacktivity conference on the topic of “Attack-driven Defense”. The concepts he described are essentially the sort of logic and pattern that need to be applied for continuous incident response.

    There are a few key elements organizations need to embrace in order to effectively implement continuous incident response. The first is the loop Keanini described. In order to be “continuous”, you have to continue to cycle through the various phases. There is no “end”.

    One of the crucial components of continuous incident response is continuous monitoring. It isn’t good enough to scan the network once a month, or once a week, or even daily. The threat landscape is constantly changing and evolving, and you have to be continuously monitoring for new vulnerabilities, new attack techniques, and anomalous or suspicious activity that might indicate a security incident is occurring.

    Another important factor is to view continuous incident response as a cross-functional business process. Keanini stated, “I think continuous incident response—when implemented well—touches all critical parts of the business, not just IT. Making it an IT thing is just too narrow and people who experiment in this manner are destined to fail.”

    Companies that have a DevOps mindset, or have adopted DevOps principles will find it easier to relate to the concept of continuous incident response. DevOps organizations are not constricted by the departmental barriers of traditional companies. The hierarchy and red tape of an org chart can get in the way of effective continuous incident response, but DevOps businesses have a more open, fluid organizational structure that makes it much easier to adapt to the dynamics of both operating on, and responding to threats from the Internet.

    Adopting continuous incident response may be easier said than done. It is a different approach to security, which may make it more difficult to get buy-in and support from executive management. You may also encounter resistance from the IT admin and existing security personnel because they’re used to doing things the old-fashioned way, and change is uncomfortable.

    Keanini sums it up well, though. “Just step back and ask yourself how important being connected to the Internet is to your business or customers—and then just consider that continuous incident response is the cost of doing business on the Internet.”

  • 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.

  • DevOps Can Be Your Fountain of Youth

    DevOps Can Be Your Fountain of Youth

    There is a different, almost magical dynamic, at a startup that seems to fade away over time as companies establish themselves. One of the benefits of DevOps, though, is that it creates an environment where that startup magic can continue to thrive. DevOps is like a fountain of youth that lets corporations continue to act like startups where it counts.

    Once upon a time Microsoft consisted of nothing more than Bill Gates and Paul Allen hacking away at a keyboard. Like any successful company, it grew….and grew, and grew, and grew. And, as it grew the culture changed, and departments were created, and bureaucratic policies were implemented. A task or feature that Bill or Paul would have just cranked out on the fly in an afternoon during the early days now must be vetted and approved, and go through a chain of command, and maybe a focus group before it can finally see the light of day.

    Startups are often formed by a few friends over pizza and beer while watching TV. In the beginning, things just get done. There is generally no real hierarchy of control, and everyone just owns what they’re working on and they get it done.

    Startups also remind me of watching Star Trek: The Next Generation. It always seemed like everyone new everyone else’s job—and anybody could fill in for anybody else. If Geordi La Forge—the chief engineer of the USS Enterprise—was captured or incapacitated, Worf—the Klingon chief of security could just step in and manage the warp core in his absence. Although everyone had a designated role, they all understood enough about the other roles to take over in a pinch. That’s how startups are before things grow so big that each person barely has enough time to keep up with their own department and duties, and barely knows what anyone else is doing.

    That brings me back to DevOps. The essence of DevOps requires that individuals take both initiative and responsibility for what they’re working on. The culture of DevOps is more fast-paced, and it doesn’t allow for protracted bureaucracy to drag things down. An organization that embraces the DevOps culture is forced to retain the innovation and agility that defined the startup stage.

    Granted, a large company like Netflix, or IBM still has a management hierarchy. There are policies in place, and different departments for IT, and human resources, and accounting. The IT guy can’t simply cut his own checks, and the accounting person can’t just go rogue and hire people without the knowledge and consent of HR. There are defined roles, and most of them serve a distinct and valuable purpose.

    That corporate structure still exists, but with DevOps you maintain that startup mentality where it counts—where new ideas are being developed and implemented. Of course, it’s also not without its challenges. Balancing the autonomy of DevOps with the policies and bureaucracy of a larger, established corporation can be confusing, and it’s important to have boundaries in place for just how long the DevOps leash is, and where the threshold is at which things need to be escalated up the chain.

    DevOps isn’t about a bunch of rogue employees running around autonomously wreaking havoc on the company, though. Much of DevOps seems to focus on tools and technology—and those are a crucial element of automating routine tasks and facilitating DevOps—but, the power of DevOps from a cultural point of view lies in collaboration. Done right, DevOps fosters an environment that frees employees to work together to find the most effective and efficient solutions.

    You probably won’t be able to recreate a situation like Star Trek: The Next Generation in a larger company. There will be departments, and there will be designated roles that need to be filled. With the right DevOps tools and technology, though, you can automate and speed up routine tasks, and free up time previously spent on those tedious jobs for employees to devote to solving bigger problems. With the right DevOps culture, you will unchain those employees and enable them to think and interact more creatively to come up with innovative ideas that may never have seen the light of day in a traditional corporate bureaucracy.

    DevOps can enable your company to function with the drive and agility of a startup, while still maintaining the wisdom and maturity of an established corporation.