Author: Tony Bradley

  • Streamlining no matter how many speeds your IT operates at

    Streamlining no matter how many speeds your IT operates at

    IBM InterConnect 2015 took over the Mandalay Bay and MGM Grand conference centers this week with an estimated audience of more than 20,000 attendees. The event is filled with DevOps evangelists, hybrid cloud experts, and IBM customers converging to share information in presentations and panel discussions.

    On Monday I had an opportunity to attend one such panel discussion titled Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record. Yeah, the title doesn’t exactly “pop” but I didn’t let that dissuade me. The panel included a number of respected names in DevOps such as Carmen DeArdo from Nationwide Insurance, and Rosalind Radcliffe and Sanjeev Sharma from IBM.

    In spite of the title of the panel discussion most of the conversation revolved around the concept of two-speed IT. In any organization—no matter how streamlined—there are going to be different processes or teams that function at different speeds. Applying the Pareto Principle, even if the organization figured out a way to operate more efficiently there would still be 20 percent doing 80 percent of the work and 80 percent doing the other 20. It would just be a matter of degree.

    The problem is that if the speeds are too different problems arise. First, it’s just a waste of resources to have skilled workers sitting idle waiting for a different group or process to catch up. Second, those workers will often get antsy and go rogue—writing code and introducing features that weren’t part of the initial requirements and aren’t part of the planned testing. Now you’re just adding chaos that disrupts the workflow even further.

    According to the esteemed panel the goal is to find ways for those processes and teams to function at their own pace without it impeding the overall efficiency —hence two-speed IT. Rather than trying to force a square peg into a round hole, or getting frustrated that the square peg can’t just be round in the first place, you have to find ways to maximize efficiency with the teams and processes you have.

    Carmen DeArdo from Nationwide Insurance applies another term as well: variable-speed DevOps. In essence two-speed IT frames the challenge, and variable-speed DevOps is the set of processes and tools organizations can utilize to address the challenge. Removing some of the friction between different groups and enabling the organization to function more effectively is one of the primary benefits of DevOps.

    When I spoke to Rosalind a couple weeks ago she stressed repeatedly that the foundation of effective DevOps is breaking down silos and finding common ground. That doesn’t mean all the teams have to be restructured under one organizational unit, or even that everyone has to adopt the exact same tools and processes. It means figuring out how they’re different and how they’re alike, and determining ways to make the most effective use of the common ground where their similarities overlap. It provides a starting point to get the ball rolling, and then things can mature and evolve from there.

    In the session at IBM InterConnect Rosalind agreed that variable-speed DevOps is a great approach, but cautioned attendees regarding how it’s used. She told the audience that variable-speed IT should be driven by business needs, not by tools or processes. In other words, you have to stay focused on the business requirements and the need to achieve business goals and then find ways to do that. You can’t try to shrink or adapt the business requirements and goals to fit the processes and tools you already have.

    DevOps tools and processes can—and in most cases should—speed processes and teams up. One of the hallmarks of DevOps is speed. Even as organizations embrace DevOps and introduce more automation, there will still be different teams and processes functioning at different speeds—and a need to implement variable-speed DevOps to enable those different speeds to exist in harmony.

  • Inside the mind of a true DevOps evangelist

    Inside the mind of a true DevOps evangelist

    IBM InterConnect is imminent. Next week more than 20,000 people will descend on Las Vegas and take over the north end of the strip for IBM’s massive event. One of the primary topics attendees will be focusing on is DevOps. IBM’s Rosalind Radcliffe—a respected evangelist for DevOps—will be there to share her passion and knowledge as well.

    Rosalind Radcliffe is a Distinguished Engineer, in Rational currently responsible for the driving the System z and Power Systems aspects for the Jazz foundation and Jazz foundation based products—or so her LinkedIn profile indicates. Really she’s just a very smart person who loves to help customers solve problems.

    At InterConnect Radcliffe will be talking about DevOps. She is hosting a number of workshops for DevOps for enterprise systems. She will also be engaging in panel discussions with clients to discuss things like how an organization can transform its current environment and the part that DevOps plays.

    I had an opportunity to speak with Rosalind recently, and gain some insight into her perspective on DevOps and what it means for IBM enterprise customers. Two themes seemed to come up repeatedly: breaking down silos, and finding a common ground.

    Radcliffe stressed that top-down support from executive management is crucial to a smooth transition. “At a business level [executives] understand DevOps is necessary. They know the value and they want to do it,” she explained. The challenge is how to adapt and make that transformation without disrupting business.

    Where do you begin? If you’re Rosalind Radcliffe you start by finding common ground. All the way from the business perspective to deployment and across all platforms it’s important for all parties to see the same point of view and work toward a common goal.

    That’s not always easy to do when you’re dealing with different teams using different tools and platforms, and with separate political agendas. The first step is breaking down silos. Rosalind told me, “Everyone says that, but that’s really what has to happen.”

    She explained that customers don’t have to throw out the organizations structure or retool the teams themselves necessarily. It’s about redefining how the teams interact and work together, not about reorganizing the teams.

    Radcliffe is passionate about DevOps, but her real drive is helping customers achieve their goals. DevOps is hot now, but it’s just an evolution of the tools and processes businesses use to find a competitive advantage. DevOps may pass, but the need to streamline processes and accelerate delivery will live on.

    “A few years from now we won’t be using the word DevOps,” said Radcliffe. She told me that DevOps is just the Agile principle taken to the full enterprise. It provides a more comprehensive end-to-end perspective that enables enterprise-scale transformation.

    The reality, according to Radcliffe, is that customers need to come up with an enterprise strategy, but it helps to start small. She works with customers to find those initial baby steps that help them gain momentum that eventually allows them to make the bigger transformation.

    Vegas isn’t really her scene, but she’ll be there next week for IBM InterConnect. She can do without the flashing and dinging of the slot machines or the Vegas shows. But, she’s driven to engage with and help enterprise customers, so she’ll brave the busy Vegas environment to share her passion for DevOps.

  • Healthcare information provider streamlines deployment with DevOps

    Healthcare information provider streamlines deployment with DevOps

    Streaming music and online shopping are just two of the ways technology and the Internet have changed our way of life. One of the other major shifts in culture has been the ability to research symptoms and self-diagnose medical conditions. One online healthcare information provider recently teamed up with IBM and embraced DevOps to streamline development and deployment of features and information for customers.

    In a case study titled A healthcare information provider cuts deployment time down to minutes, IBM details how this healthcare information provider—which remains anonymous—used IBM UrbanCode Deploy to get products to market faster. While the name of the company is not disclosed, IBM does reveal that it is a United States company that employs approximately 1,500 people, and develops and maintains more than 200 applications.

    The case study describes a scenario that is probably common across many companies regardless of industry:

    The organization’s existing deployment solution combined tools designed for other purposes, such as administration or content management, and strung them together with custom scripts. The process also involved many manual steps, which introduced the potential for human error. Developers and quality assurance (QA) teams were bogged down with the numerous administrative steps required to request a new deployment. And the company’s web operations team was spending much of its time deploying production and QA environments.

    “In many ways they are a classic DevOps story for a mid-sized organization (1,500 people) with a heavy tech component,” stated Eric Minick, DevOps evangelist for IBM. Minick explained that development at the organization had shifted to agile, and that applied pressure downstream on operations. The natural evolution from there to keep up with development and continue to meet business needs was to automate aggressively and improve collaboration between developers and IT operations. In other words: embrace DevOps.

    Minick told me, “The medical element almost doesn’t matter here—except that this is a place where I would go to get health information to make decisions that impact the well-being of my kids. They trade in trust.”

    An outage would have financial consequences as it would for any company that engages with customers over the Web, but the more crucial issue for this company is its reputation—and the need to earn and maintain the trust of its customers. “In a lot of ways, this is the same fundamental challenge that banks have. You have to be consumer facing, compete with new money transfer startups that move fast, but if people can’t deposit their paycheck in time to make rent, you lose customers quickly,” said Minick.

    For US Health insurers, the past couple years have been very interesting. The Affordable Care Act has forced the health industry to shift from thinking of the insured as a secondary customer (the employer being the primary) to really shifting into a business-to-consumer (B2C) business model. The change in perspective makes their systems of engagement more critical to the business, and being able to experiment and rapidly deliver has become more important.

    Minick stressed, “At the same time, they have significant regulatory burdens requiring them to have strict controls, and security protections. Meanwhile, operating efficiency has become even more important as overhead / profit is capped as a percentage of premiums. This nets out to a requirement to be able to change more quickly, without additional risk or cost.”

    A vice president from the healthcare information provider shared some thoughts on the benefits of working with IBM and embracing DevOps. “The fact that we had development, QA and ops engineers all in the same room choosing the tool, that process and the standards really created a sense of collaboration and let everyone walk in the other person’s shoes, understanding the challenges others face. To me that’s what the DevOps culture is about: breaking down the walls and letting staff understand everyone’s challenges. Everyone benefits from using tools and processes like this.”

  • Does DevOps drive agility, or does agility result in DevOps?

    Does DevOps drive agility, or does agility result in DevOps?

    DevOps is a hot topic. Hell, I’m writing this on a site dedicated specifically to DevOps and you’re reading it, so it seems safe to assume we agree on the general premise that DevOps is an important trend for both business and IT. I question however, giving all of the credit for cost cutting, or for more agile and effective organizations to DevOps.

    A recent survey commissioned by CA Technologies titled DevOps: The Worst-Kept Secret to Winning in the Application Economy makes the claim that 88 percent of IT professionals surveyed have already implemented DevOps or plan to within the next five years. It also notes that companies that have already adopted DevOps have experienced 14 to 21 percent improvement in quality and performance of applications and/or faster time-to-market. Clearly DevOps is virtually ubiquitous, and companies that embrace DevOps are all but guaranteed to be more effective and efficient.

    Well, no. Not really. I’m a huge fan of DevOps, and I think there is a very good chance that organizations that adopt DevOps are likely to experience tangible, measurable benefits. However, one does not necessarily lead directly to the other and, in fact, it may be the other way around. Perhaps organizations that are doing the right things to yield improvements that result in more efficient and effective operations are also the organizations that are likely to embrace DevOps. I call this “Does DevOps drive agility, or does agility result in DevOps?”

    For starters, we still can’t even narrow down a concise explanation or definition of DevOps we can all agree on. So when we say that an organization’s success is the result of DevOps, what do we mean? Is it because the company broke down barriers between teams and enabled workers to collaborate together more efficiently? Is it because the company moved its infrastructure to the cloud and automated deployment of virtual servers and applications? Or is it because the company embraced specific tools or platforms like Chef, or Docker?

    There is an argument to be made that much of what comprises the strategic side of DevOps is just a natural, cyclical occurrence in business. There’s always some new management philosophy or business model du jour with a catchy buzzword, and right now it’s DevOps. Part of the reason that DevOps remains such an ethereal concept is that most of the organizations employing DevOps don’t realize they’re using DevOps, and they don’t call it that. Those organizations are just responding to the realities of competing today in the best way they can. That effort seems to lead invariably to embracing philosophies and strategies that have been collectively dubbed part of the DevOps culture.

    The organizations that started it all didn’t sit down and say “OK. We should start by adopting DevOps tools and strategies.” Companies like Netflix didn’t “embrace” DevOps—they created it from scratch, organically, and developed the tools and strategies that form the foundation of the DevOps movement. Everything that follows is an attempt to mimic the success of those organizations.

    If it’s a question of which came first, the chicken or the egg, it seems clear to me that DevOps is the outcome of a culture shift more than the engine or catalyst of the culture shift. To be fair, DevOps has matured, and is evolving into a culture all its own, and the tools and philosophies that make up DevOps are more clearly defined as time goes on. A company looking at it today can explore successful tools like Chef and Docker, and study examples of other organizations that have achieved success through DevOps principles.

    We still need to be careful, though, when breaking down statistics like those in the CA survey. Companies that are more agile, and deliver better quality products more quickly may also have adopted DevOps tools and strategies, but it doesn’t necessarily imply a direct cause and effect between the two. Perhaps as DevOps matures and the definition of the strategies and tools that comprise it becomes more consistent it will be easier to state clearly whether or not an organization has “adopted DevOps” and apply metrics that directly measure the effects of DevOps unique from the metrics the company would achieve anyway with or without DevOps.

  • Why DevOps is like fitness or religion

    Why DevOps is like fitness or religion

    What is DevOps?

    I noted in a blog post last summer that limiting DevOps to a single definition is challenging. The Wikipedia entry for DevOps contains a variety of possible explanations that seem to disagree in some ways:

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

    A recent ZDNet post titled Why there will never be one do-it-all DevOps tool proclaims, “There is really no such thing as a specific DevOps “tool”—and don’t buy into the “DevOps” labeling many vendors are attaching to their solutions. Successful DevOps depends upon a multitude of tools and methodologies that can help organizations better align their software development and release cycles.”

    The question, “What is DevOps?” isn’t like asking, “What’s the temperature today in Phoenix, AZ?” or, “What’s the fastest land animal?” Those questions have precise answers that are based on measurable, irrefutable metrics. The answer is the answer and it isn’t really open to debate.

    “What is DevOps?” is more like asking, “What is the best fitness program?” or, “Which religious belief system should I subscribe to?” There is a vast array of answers and passionate beliefs on all sides. But, there really isn’t so much a “right answer” as a “right answer for you”.

    When it comes to fitness, there seems to be as many diet and exercise programs as there are people trying to get fit. Books, magazines, and infomercials are filled with extraordinary examples that “prove” that a given fitness program or philosophy works…at least for the subject of the story. There are some elements that are universal truths like exercise is better than being sedentary, and making healthy eating choices is better than eating an entire cheesecake for dinner. Almost everything else is subjective. There are too many variables involved that make people, and how they respond to different diet and exercise programs, different.

    DevOps is also like religion. Most people don’t choose their faith. They’re raised from birth to follow in the footsteps of their parents, and their religion is more or less predetermined. Religion is also personal. While some will insist that there is only one true faith and that theirs is the only real religion, most people recognize that religious faith is very subjective and it’s a function of finding the belief system that makes sense to you.

    DevOps is like fitness and religion in that what it means to an organization, and how it is first implemented, is influenced by the existing culture and infrastructure—the IT the company was “raised on”. DevOps is also like fitness and religion because there is no “one-size-fits-all” answer to the question “What is DevOps?”

    It isn’t a defined process—it’s more of a concept or philosophy. It isn’t a product or service that can be packaged and sold—it’s more a collection of the products and services that enable you to embrace the concept or philosophy. To some extent, DevOps is whatever works for your organization to automate routine tasks, reduce redundant effort, streamline operations, and remove unnecessary obstacles so people can get things done as efficiently as possible.

  • When the bad guys use DevOps, you need DevOps to defend yourself

    When the bad guys use DevOps, you need DevOps to defend yourself

    I came across an intriguing headline the other day: Malware coders adopt DevOps to target smut sites. The article, unfortunately, is fairly vague about what exactly that means, but it got me thinking about the potential implications.

    It’s all just a function of rivals competing. Just as Company A has to find a way to work more efficiently and bring better products and services to market faster than Company B, malware developers need to be faster and more agile than their targets. In either scenario DevOps can give one or both parties a competitive boost.

    Although the article in question simply says malware developers are “now engaged in DevOps,” and claims it’s the first time that behavior has been seen from the dark side, the reality is that malware developers—even those in organized cybercrime groups—have always had an element of DevOps to them. By their very nature they’re more inclined to have shared responsibilities and to exhibit the sort of jack-of-all-trades cross-functionality that we expect to find in young startups.

    “It has always been the case that most attackers embrace much more of a DevOps pattern than defenders. Most of these folks were born of the Internet way of thinking and nowhere in their playbook do they have the traditional data center change controls or any other big enterprise methodology,” declared TK Keanini, CTO of Lancope.

    The problem that many organizations face when it comes to mounting an effective defense is a lack of situational awareness of their own environment. In many cases the attackers actually know more about the organization’s network, and the assets connected to it than the organization itself.

    Effective defense also requires agility. Companies need to be able to adapt quickly and implement changes without impacting business continuity. Keanini says, “DevOps is one way to do this and something like the Rugged Manifesto does a great job of capturing the essence of what it will take to battle this threat day in and day out.”:

    The Rugged Manifesto

    I am rugged and, more importantly, my code is rugged.

    I recognize that software has become a foundation of our modern world.

    I recognize the awesome responsibility that comes with this foundational role.

    I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.

    I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security.

    I recognize these things – and I choose to be rugged.

    I am rugged because I refuse to be a source of vulnerability or weakness.

    I am rugged because I assure my code will support its mission.

    I am rugged because my code can face these challenges and persist in spite of them.

    I am rugged, not because it is easy, but because it is necessary and I am up for the challenge.

    The question is, “How?”

    Keanini—ever the strategist—references the OODA loop, conceived by USAF Colonel John Boyd. OODA is an acronym for Observe, Orient, Decide, and Act. The concept was originally designed for military combat operations but can also be applied quite effectively in many areas of business. Applying it to network or endpoint security, the idea is to at least raise the cost of observation and orientation for the opponent—in this case the malware developers.

    “DevOps can deliver this because change can be implemented as a defense whereby the adversary never has time enough to make enough of an observation, or orientation accurate enough for effective decision and action,” clarified Keanini.

    There are a few different elements involved here. Continuous monitoring and continuous incident response are both applications of a DevOps mentality that can help organizations mount a more effective defense against sophisticated attacks. The OODA loop Keanini refers to is less about response, and more about applying DevOps philosophies to take away the strategic initiative from the attackers in the first place.

    One thing is certain, if the malware developers implement policies that enable them to craft and deploy attacks faster, businesses will have no choice but to figure out some way to adapt and defend more quickly as well.

  • Enter at your own risk: DevOps isn’t for everybody

    Enter at your own risk: DevOps isn’t for everybody

    There’s always a sexy new tech buzzword flying around, and it’s easy to fall into the trap of assuming that if a concept or technology is hot you need to hurry up and jump on board so you don’t miss anything. DevOps is hot, and seems to be almost ubiquitous these days. But that doesn’t mean that every organization should rush out and embrace DevOps.

    Defining what it is exactly that you think you’re embracing can be a challenge. The concept of DevOps is a bit broad and ethereal in the first place. The number of vendors calling their products or services “DevOps” just because it’s sexy marketing muddies the waters and makes it more difficult to figure out what DevOps is, and how it’s supposed to benefit your organization.

    Even if you think you have a fair grasp on what DevOps is, though, it still isn’t necessarily right for every organization. It CAN be right for most organizations, but there’s some introspection, and due diligence that has to come up front. More precisely, it isn’t necessarily right for every organization without a solid foundation of the right skills and resources, and an understanding of what you hope to accomplish, and how you plan to get there.

    Nathen Harvey, community director at Chef, shared some insight on this topic. “Through immense feedback from our community, customers and contributors we’ve learned a lot about how and when an organization should begin a DevOps transition. In short, everyone should not immediately jump on the DevOps bandwagon.”

    Harvey added, “DevOps is full of big ideas and big changes and therefore development and operations teams need to be prepared to work together through challenges and to collaborate toward a common goal.”

    James Bottomley, CTO of server virtualization at Parallels, cautions, “DevOps processes are supposed to be accessible to anyone. However, since current DevOps lifecycles are based on virtual machines, they are really only accessible to those with the skills to manage virtual images and, to make use of the live VM, administer base systems and platforms.”

    Bottomley explains that larger organizations often have the necessary skills available, and just have to marshal them toward a DevOps strategy. Small and medium businesses, on the other hand, often lack the appropriate resources.

    “If you are a SMB you should consider carefully whether you have the necessary Ops skills in-house and if not, how you are going to obtain them (whether from a [service provider] or other form of management). Ongoing Ops skills are vital to proper VM maintenance (fixing security issues and the like), so you have to make sure you have an ongoing Ops capability, not just a one-time one when the virtual system was created.”

    According to Chef’s Harvey, there are three specific areas organizations need to consider before embarking on a journey to embrace DevOps. They are the “Three C’s”: Character, Communications, and Community.

    · Character requires trust, respect, empathy, learning and perseverance.

    · Communication is meant to align objectives—such as setting metrics for everyone, and sitting close enough to easily collaborate with one another.

    · Community can take many forms, whether engaging in podcasts, conferences, sharing code and more.

    Don’t make the mistake of jumping on the DevOps bandwagon prematurely just for the sake of jumping on the DevOps bandwagon. It will be a frustrating experience almost doomed to fail and leave a bad taste in your mouth. Instead, take the time necessary to understand what DevOps means to you, figure out what you hope to accomplish by embracing DevOps, consider whether or not you actually have the skills and resources to make it happen, and develop a plan that includes the “Three C’s” so your DevOps journey can be a successful one.

  • Optimize app performance with the help of real-time monitoring and analytics

    Optimize app performance with the help of real-time monitoring and analytics

    Back in 1980 there was a movie called Nine to Five—referring to the commonly held perception of a standard work day. Of course, that work day evolved to be more like eight to six (or seven), and now it seems like the concept of a work day—or work hours at all—is a distant memory. In order to keep up with the instantaneous, always-on, connected 24/7 pace of today, companies need to be able to understand how their apps are used, and proactively address issues in real-time.

    That’s where companies like MixPanel come in. MixPanel offers an advanced analytics platform for Web and mobile apps so that developers can keep tabs on when, where, and how apps are used, and any problems that might arise.

    I spoke with Tim Trefren, co-founder of MixPanel. He proclaimed, “It’s easy to build a product. What’s hard is building a good product.” I assume that wisdom applies both to MixPanel itself, as well as to the customers that employ MixPanel to monitor and improve their own products.

    Trefren told me that MixPanel provides a very flexible system that enables customers to track and monitor the metrics that matter most to them. It allows for custom metrics, so companies can choose to monitor elements of apps and app functionality that are completely unique. Customers can also implement A/B alternatives and compare metrics between the two to determine which is most effective.

    Monitoring performance metrics, and analyzing that data to fix or improve apps fits into the broader concept of agile development, and rapid iteration that define DevOps. Trefren explained that some customers also employ MixPanel in an innovative way that also applies to DevOps—to actually monitor operational data.

    Trefren says MixPanel may not be the ideal tool for monitoring operations, but it does enable admins to monitor everything from a single display, and it can be used to alert IT personnel when issues arise. For example, if MixPanel starts logging metrics that show an app is not being used at all, that could indicate that a server is offline.

    MixPanel also recognized that it was in a position to do a little more. It offers a service that analyzes captured metrics data, and enables MixPanel to help companies understand who their customers are. Understanding the audience, and the actions they take (or don’t take) with an app provides valuable demographic data that companies can use to target marketing efforts with greater precision.

    Trefren also told me that he is exceptionally proud of the engineering team at MixPanel. While the volume of data being analyzed has tripled in each of the last two years, the engineering team has only doubled over those same periods. That means that the MixPanel engineering team is working more efficiently, and getting exponentially more done in order to keep up with demand, but that’s another story for another day.

    “The combination of power, flexibility, and performance set MixPanel apart from competitors. We’re able to do more, and do it more quickly,” said Trefren.

    That may be true, but MixPanel isn’t alone. I wrote a while back about similar services from AppDynamics, including its DevOps War Room feature. Clearly, the rapid pace of development, and the sheer volume of apps have created a market for being able to monitor metrics, and measure the performance of those apps in real-time.

    MixPanel offers its analytics as a freemium service. Paying customers are billed for metrics per data point, so the overall cost ends up being a reflection of the volume of data being analyzed.

  • Deliver faster, but don’t sacrifice quality

    Deliver faster, but don’t sacrifice quality

    Developing applications, and deploying servers faster are great goals. Being agile and streamlined can give an organization a clear competitive advantage. However, faster does not equal better, and being speedy for the sake of being speedy can lead to avoidable mistakes. Faster is only better if you can achieve greater speed without sacrificing quality.

    At the same time companies are racing to be faster than their rivals, they’re also dealing with an increasingly complex IT infrastructure. IT environments are becoming highly heterogeneous—merging physical, virtual, and cloud platforms, and combining legacy systems with cutting edge technologies. The challenges of managing such a diverse IT infrastructure simply add to the potential issues that can arise as organizations try to work faster.

    That is where DevOps plays an important role. DevOps tools and technologies establish a process chain between development and deployment. It enables organizations and IT admins to reliably track and understand the components in use, and any changes or updates that occur. In order to achieve speed without sacrificing quality, it’s important to maintain as consistent an environment as possible, and to know exactly what has been changed.

    “For hypervisor based virtual images, this depends on the strict process around handling the images, but for container based virtual images depending on a cascading snapshot mount namespace, where there are layers of images built one on top of the other, strict handling becomes unnecessary because everyone can see transparently (via the image cascade) what changes at each stage of the process,” explained James Bottomley, CTO of server virtualization for Parallels. “This gives everyone in the DevOps chain the ability to verify each step and see the changes for themselves, leading to much higher assurance that the resulting deployment is correctly tested and released.”

    Ken Cheney, VP of business development for Chef, describes another way that DevOps helps boost speed without affecting quality. “Automation turns infrastructure into code. For example, Chef recipes automate all facets of management and orchestration—from provisioning bare-metal and cloud servers to automated configuration and application deployment. You can replace manual, slow, error-prone procedures with code that is versionable, testable and repeatable.”

    “When infrastructure is code you can test it just as you would applications—using automated tests that find problems early, before you release to production,” added Cheney.

    In its 2014 State of DevOps Report, Puppet Labs drew an interesting correlation between speed and quality. Essentially, Puppet Labs found that speed and quality become a self-feeding circle.

    “There’s a virtuous circle at work here: As stability improves, IT performance improves. This improved performance helps to create a better-functioning business that can pay attention to the communications and processes that enhance and improve stability.”

    The converse is also true. Poor quality results in issues, and necessitates allocating resources to troubleshoot and resolve problems, which impedes the speed at which an organization can function.

    DevOps tools and technologies enable organizations to streamline development, and work more efficiently without sacrificing quality. Businesses that attempt to work faster, without also working smarter by using DevOps are putting themselves at a disadvantage.

  • Equalizing IT infrastructure with DevOps

    Equalizing IT infrastructure with DevOps

    IT is getting more complex. Managing on-premise servers, cloud servers, and hybrid environments that span various operating systems and standards creates challenges for IT admins. DevOps technologies and platforms, however, can be an equalizing force among the cloud chaos—making it easier for organizations to deploy servers and applications quickly and consistently regardless of platform or environment.

    Once upon a time most organizations were fairly standardized. Servers were located on-premise in some sort of closet or data center, and IT admins knew exactly what operating system they were working with. Now, those servers may be physical or virtual, on-premise or in the cloud, Windows or Linux, Azure or Amazon, and in many cases IT admins are dealing with an infrastructure that amounts to an all-of-the-above approach.

    As the name implies, the core of the DevOps movement is to remove the barriers between developers and operations. Many of the tools and technologies that comprise the DevOps movement, however, also have the added benefit of providing a consistent, modular approach to developing and deploying applications and infrastructure. Those technologies also reduce friction between on-premise and cloud environments, and allow organizations to streamline operations across different platforms and operating systems.

    “One of the biggest reasons for the increased interest in DevOps tools and practices is because businesses have to move and iterate faster today than at any other time in history,” declared Tim Zonca, director of product marketing for Puppet Labs. “So IT teams are pursuing DevOps flows, where development and operations practices, systems, and tools work in lockstep.”

    As IT infrastructures become more complex, DevOps becomes more crucial. Expansion of IT across physical, virtual, and cloud environments make even minor inconsistencies into critical issues as organizations grow, and brings additional burden to address those problems.

    Many DevOps technologies revolve around using virtualization to deploy applications inside pre-built environments, or modular blocks that can be deployed and re-used across various platforms and environments. These tools remove most of the chaos, and enable organizations to simplify deployment across virtually any infrastructure.

    Docker is a great example of the impact DevOps is having. Docker containers enable developers to package an application, and transport it anywhere Docker containers are supported without modification to the virtual environment. As Docker continues to spread influence across Azure, Parallels, and other cloud and virtual platforms, it is asserting itself as an equalizing force that eliminates the need to even care what the underlying infrastructure or operating systems are.

    Puppet Labs is another illustration of the equalizing force of DevOps. Zonca explained, “Puppet makes it easy to standardize and add consistency to your infrastructure so you can make fast, repeatable changes across physical and virtual machines, on premises or in the cloud. Because these tools create a predictable environment, you don’t have to worry about a simple update taking down an entire system your business relies on.”

    James Bottomley, CTO of server virtualization for Parallels, suggests that even DevOps has its limitations, though, and that it could eventually get in the way of advancing productivity. “However, one cannot help thinking that DevOps, while a leveler, is also a separator because it is only accessible to developers with the Ops skill, not to all developers. Additionally, the utility of DevOps depends upon the availability of Infrastructure and, while IaaS is clearly the dominant Cloud technology today; it won’t be forever. At that point, one might imagine that the DevOps technique might impede rather than assist the next paradigm shift in the cloud.

    For now at least, DevOps technologies enable developers and IT admins to take a modular, platform-agnostic approach to many aspects of applications and infrastructure to simplify and streamline regardless of the underlying environments or operating systems.