devopsy.kinsta.cloud

Category: Editorial Calendar

  • Managing Your DevOps Releases Efficiently

    Managing Your DevOps Releases Efficiently

    The Top 5 Things You Need to Know When Selecting a DevOps Release Management Solution

    DevOps is a modern software delivery movement that encompasses agile principles and encourages automation in application delivery. Why adopt it? It allows teams to reduce errors due to manual steps and break down silos between teams to improve communication and collaboration between all stakeholders within the business.

    Whether you’re knee deep in a DevOps transformation or just getting started, implementing a DevOps release management solution is an important step along the journey. Why? Because in today’s on-demand economy, organizations must capitalize on any opportunity to improve application delivery throughout the organization, irrespective of the development processes in place.

    Based on a recent discussion between Michael Azoff, principal analyst at Ovum, and Anders Wallgren, CTO of Electric Cloud, I was able to glean why DevOps release management is a must for enterprises to modernize the software delivery process and compete at a higher level. More specifically, Michael and Anders discussed the top five requirements for selecting a release management solution, which I’ve laid out for you below.

    No. 1: Application Manifest: Model and version applications, infrastructure and middleware.

    This is what you’re looking for in an enterprise grade solution—a solution with ease of use in defining an application deployment blueprint, and being able to reuse it and version it and have variations to meet the complex and ever-changing needs of your organization. If you are doing continuous delivery and DevOps correctly, you should never have to make a change to a deployed application by hand—ideally, changes are made to the application model and then re-released into a production environment. This allows you to make and test changes in one place, and easily keep track of everything in production. Having an application manifest is a key facet for a great release management solution.

    No. 2: Pipeline Design: Model, version and refactor pipelines, workflows and processes.

    This is not only an important consideration for selecting a release management solution, but also is at the very heart of continuous delivery—the ability to define and manage delivery pipelines for complex legacy applications or newer microservices. For large organizations with lots of technical and process debt, being able to flexibly model and manage that sort of complexity is essential.

    Ultimately, the whole concept behind DevOps comes down to the idea that there is the “what,” the “how” and the “where.” The “what” is the application manifest, mentioned above. The “how” is the pipeline design. What are all the stages this particular application or component or service goes through? Understanding your end-to-end pipeline is very important. You need to have the end to end of what your software goes through—not just conceptually, but even physically written down somewhere. If you don’t have that that process completely nailed down, you don’t really have a full understanding of what it takes to ship your software. Without this complete understanding, it can be much more difficult to have success. By modeling these pipelines, you allow teams to visualize the flow of value through the life cycle, and make iterative improvements on it in a collaborative and safe manner.

    No. 3: Pipeline Execution: Predictably and efficiently deliver legacy and CD-style pipelines and releases at scale.

    One of the most important things when practicing DevOps is enabling fast feedback, so getting visibility into pipeline execution as they’re occurring is very important. This provides teams an easy way to troubleshoot problems quickly, and then refactor and optimize the pipeline over time. Enterprise pipelines can be very complex and touch a lot of tools—your Dev team might be using Jenkins and Chef and Selenium, and your Ops team might be using ServiceNow and Azure cloud and Puppet. We have customers that have more than 60 tools as part of their ultimate DevOps toolchain. For each one of these tools or services you need to make sure you’re getting the best performance possible, and operating them as efficiently as you possibly can. As you execute them, the ability to see those executions live as they happen, then collect information about them and optimize your pipeline helps to make the entire process more efficient.

    No. 4: Governance, Security: Role-based access control, traceability and auditability.

    This is one of the key functions to consider for an enterprise-grade solution. If you just tie together your release capability with tools that still require some manual steps, you’re not able to scale that. This is where a large-scale organization, especially one that is regulated and has auditors, will want a solution that can demonstrate clearly that the whole process is governed such that no one can make a change to the process, environments or binaries without it being logged, and that any change that is made has gone through a QA and testing process. Those are the sorts of things that are really crucial for the Ops people, as they are handed responsibility for ensuring a low-risk environment.

    When DevOps was starting, the overwhelming belief around security and governance was, “Gee, this is going to really bother the auditors.” However, it turns out it is quite the opposite—to get good at DevOps and continuous delivery, you really need to automate everything. What do auditors want? They want companies to do two things:

    1) Document their process and

    2) Demonstrate they are using that documented process.

    In the process of sitting down and automating your software delivery pipeline, you are essentially documenting that process. Executing that pipeline gives you the record of what you did: How did we deploy? When? Who did it? What was the pipeline that was used? What was the testing? All of those things are now available to be audited.

    No. 5: Integrations: Works with the tools you already use

    You want a solution that fits in with the tools and process that you have. It would be a non-starter to show up and say, “Throw away all of your current tools and let’s use this new thing.” It would also be inefficient to have to change your process to fit into some tool’s preconceived notion of how your enterprise should run. Make sure you don’t have to change the way you do business, and that can help the DevOps adoption curve quite a bit.

    By keeping these top five considerations in mind when selecting a release management solution, you can help ensure your journey into DevOps and continuous delivery is a much smoother, more efficient and more fruitful one. Regardless of the tools your organization decides to use, consider first how you can make your pathway to production a competitive advantage and reap the benefits of an efficient delivery pipeline!

    If you have the chance, take a listen to the full conversation between Michael and Anders.

    About the Author/Sam Fell

    sam-fell-leadershipSam Fell is the head of Marketing at Electric Cloud, responsible for driving awareness and demand for the company’s DevOps release automation and acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling and implementing DevOps release automation, IT change management and application performance management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft.

    Sam holds a Bachelor of Arts degree from Illinois Wesleyan University.

  • 7 Reasons to Move to Parallel Testing

    7 Reasons to Move to Parallel Testing

    While development operations are more scalable now than ever, there is one area that continues to constrain the ability of organizations to scale: functional testing.

    Most organizations still rely on sequential tests to deliver quality assurance. No matter how rapidly a business can produce great products, its ability to bring them to consumers quickly is limited by its dependency on a slow, tedious testing process that does not adapt well to changing development needs or ever-faster business processes.

    That, at least, is the way things traditionally have been. But today there’s a replacement for sequential testing: parallel testing, which lets you leverage the cloud and virtualization to perform more tests at faster speeds than your physical infrastructure or homegrown testing grid could support on its own.

    What is Parallel Testing?

    First, a definition: Parallel testing is the process of running multiple test cases on multiple combinations of operating systems and browsers at the same time. The process is automated, and it often runs on virtual machines. For the QA professional, no additional effort is required once the appropriate test scripts have been developed. All the testing solution needs is the test suite and a pool of resources.

    Granted, new does not always equal better. But it is hard to make an argument against parallel testing, especially if you leverage a robust testing cloud. Here are seven key advantages of parallel testing to consider over sequential testing:

    You Can Test for Wider Compatibility

    Because parallel testing is faster, it allows you to test for wider compatibility in the same amount of time. If you’re releasing a new app and want to test the user interface (UI) functionality, you don’t have to limit yourself to testing against only the most popular OS and browser combinations or mobile devices—you can test all the combinations that are important to your users.

    You Can Radically Reduce Testing Time

    Good software testing must be thorough and comprehensive. In a sequential testing environment, it can be (and usually is) a very time-consuming process. Parallel testing can divide invested time (roughly) by the number of test machines being used in parallel, so that overall testing time is a fraction of that required for sequential testing.

    For example, if you are running 10 concurrent tests, you can reduce your testing time by a factor of about 10. This can cut days or even weeks from delivery time. This reduction in testing time also allows you to make more efficient use of your engineering team. They are freed from a set of necessary but time-eating and repetitive tasks, allowing them to concentrate on more forward-looking and innovative projects.

    Parallel Testing Optimizes Continuous Integration and Delivery

    Modern development best practices such as continuous integration and delivery require frequent and rapid functional tests. The execution of pre-scripted tests on a web or mobile app saves considerable time, plus having test data accessible in detailed reports is valuable to development teams who can use this information to quickly identify issues. Parallel testing in the cloud allows you to execute test suites continually as developers submit and integrate code changes throughout the day.

    The Cost per Each of Your Tests is Less

    Because parallel testing is automated and and can run at high concurrency in the cloud, the cost per test is considerably less. Leasing test time on a cloud testing service generally will be much less expensive than building and maintaining your own test infrastructure.

    Even the common practice of using development hand-me-down computers as test machines has its costs and practical limits. For example, as used systems age, they require more maintenance and they become less capable of duplicating real-world deployment conditions. Cloud-based testing grids mean environments have high availability, and they are up-to-date, making parallel tests the better option.

    It Supports Testing Science

    Parallel testing enables teams to focus on making tests repeatable, measurable and accurate. By simply testing faster, you can test more, and testing more produces more actionable data to find bugs and also improve test cases. Automated parallel testing delivers strong data on test results with key indicators of where tests can be improved. The net result is a test process that is more scientific.

    You Can Still Perform Sequential Tests, If and When Needed

    Parallel testing simply offers a different framework for testing, which can easily accommodate most or all of your existing test regime. This means that transitioning from sequential to parallel testing does not force you to sacrifice test targets, strategic testing goals or test quality.

    If anything, moving to parallel testing increases the range and depth of your test program, allowing you to better meet your test goals and it improves the quality of your testing. When you make the move to parallel testing, you are not abandoning traditional software testing. You are simply applying modern development practices and technology to it.

    You Do Not Need to Make the Switch to Parallel Testing All at Once

    The great thing about parallel testing is that you can transition to it in steps, starting with the tests that are most easily converted to parallel, then adapting some or all of the remaining tests after your team has had time to adjust to the parallel testing environment. Once you have started to use parallel testing and have integrated it into your development process, it is easy to expand the quantity and scope of parallel tests as the need arises.

    Conclusion: A Faster Test Run is a Penny Earned

    The faster you run a test, and the more tests you run, the more frequent the releases and the more defects you can find. The math is simple. Parallel testing in the cloud decreases the cost of maintaining test infrastructure, the cost of lengthy testing cycles, the cost of delayed releases and, finally, the branding cost of unhappy customers due to poor application quality.
    Even without changing the way you test, a shift to a parallel testing environment will provide an immediate speed enhancement—which means every test that still runs serially is a cost that can be avoided. And every test run in parallel is an opportunity to test your application better and faster at the same time.

    About the Author / Lubos Parobek

    Lubos ParobekAt Sauce Labs, Lubos Parobek leads strategy and development of Sauce Labs’ web and mobile application testing platform as VP of product. His previous experience includes leadership positions at organizations including Dell KACE, Sybase iAnywhere, AvantGo and 3Com. Parobek holds a Masters in Business Administration from the University of California, Berkeley.

     

  • DevOps Matchmaking: APM + CI = A Perfect Marriage

    DevOps Matchmaking: APM + CI = A Perfect Marriage

    As anyone who has ever been set up on blind dates by friends can attest, finding the right match in today’s world is a tricky feat.

    There’s a lot of evidence suggesting that the frantic pace of life makes such matchmaking more difficult than ever. That said, when the right set of complimentary traits exist and there’s a willingness to find common ground, things can work out.

    Spike Jonzian-notions of artificial intelligence aside, certain technological partnerships are increasingly being perceived as “a perfect marriage” within the context of DevOps automation.

    Register today for the upcoming webcast: “Using APM to Turbocharge Continuous Integration”

    These technological matrimonies closely support the underlying tenets of DevOps methodology—collaboration, experimentation and increased velocity. In fact, it’s easy to wonder why no one ever conjoined them before. But we were using traditional waterfall development and operations and so couldn’t conceive of such a thing. On the other hand, emerging availability of tooling supporting new integrated workflows represents a significant catalyst.

    Finding the Perfect Fit

    One such DevOps confederation getting a lot of attention is the matchmaking of continuous integration (CI) and application performance management (APM) technologies. Tying together these once-disparate systems makes a lot of sense, despite the fact that few tools would seemingly appeal to more (traditionally) polarized constituencies.

    Continuous integration has been a staple of the development community for many years. It emerged as teams evolved the practice of long build times into more frequent check-ins to deliver code and look for potential errors more quickly. Today, with the rise of CI tools such as the Cloudbees Jenkins platform, some development teams are touting tens of thousands of builds per day.

    On the other end of the spectrum, squarely on the turf of IT operations, APM has been evolving rapidly over the past few years as organizations have sought to improve use experience and applications reliability via dedicated monitoring. Enabling this ability to identify and address emerging issues has resulted in APM becoming the fastest-growing segment in the IT ops management market, according to Gartner.

    DevOps matchmaking factors in when you bring these tools together to create an automated workflow that spans their respective use cases. A cross-functional team can leverage APM-level monitoring and KPIs within the domain of CI and testing to identify potential performance obstacles introduced in new code. Doing so then rather than waiting to respond later in the applications life cycle benefits everyone.

    Reaping the Benefits

    For example, say an e-commerce applications developer has implemented a new inventory search functionality—something considered a key differentiator by business management. The developer knows this feature could rely heavily on some back-end database system and wants to ensure it’s tested properly, even as the code is being introduced.

    Integrating APM and CI allows the entire team to monitor the process and test various conditions related to the update, tracking multiple builds and looking out for related performance issues. Such integration also allows for centralized tracking of other key attributes such as build number, status and build date, to further ease management.

    Most importantly, by tying these two critical aspects of the applications delivery life cycle together, the collaboration and feedback loops required to truly embrace DevOps methodology become ever more valuable as these core Dev and Ops functions become intrinsically linked.

    If this type of DevOps advancement gets your heart pumping, you’re not alone. Later this month, we’ll host a webcast here on devopsy.kinsta.cloud featuring experts from CA Technologies and Cloudbees. They’ll be discussing the benefits of matchmaking with APM + CI integration. They’ll also detail real-world benefits organizations leveraging integration of our respective technologies (CA APM and Cloudbees Jenkins) enjoy.

    We obviously feel that this is a DevOps tooling marriage that will mature, change and stand the test of time. We’d love to garner your questions and feedback on the topic.

    Which is all good, because thankfully there’s no such thing as Tinder for DevOps … yet.

  • Trusting Continuous Delivery

    Trusting Continuous Delivery

    DevOps, continuous delivery and the pipeline for faster software development are fundamentally different from traditional software development. It’s such a different approach and a different culture that it can take some time before Dev and Ops teams embrace and trust it—a necessary step for DevOps to make progress in any organization. By mixing containers and their value proposition into DevOps, this new software creation and deployment paradigm can readily foster that trust.

    What Continuous Delivery Brings

    DevOps and continuous delivery offer application development using containers, providing the required level of trust to get over that hump and move things forward. According to David N. Blank-Edelman, a DevOps veteran and currently technical evangelist at Apcera, the following container features lead to trust because they answer Dev and Ops concerns:

    • Containers are resource-friendly replacements for virtual machines, built to encase the coder’s development environment
    • Containers are the complete package format replacement, possessing everything you need to run an app
    • Containers create an abstraction that enables development and its results to sit in a host in any of a number of infrastructures including on-premise and inside any of several public cloud providers
    • Containers are the fastest means to launch short-lived, purpose-built testing sandboxes as part of a continuous integration process
    • Containers are the end result of a build pipeline (artifact-to-workload)
    • Containers form the boundary for loosely coupled components as part of a larger app or service. Such is the case, for example, when each part of a microservice-based app lives in its own container

    According to Blank-Edelman, the aforementioned features imbue trust because they satisfy the following Dev and Ops queries:

    • Is the container allocated to use only the resources it should?
    • What resides in that container / workload?
    • Where did that container come from? Is it OK from a security, coding and business requirements perspective?
    • Where is the container permitted to live and run such as in what cloud, environment, country, and in proximity to other containers technically?
    • Can the container communicate with only the things it should such as other containers and any hypervisor or other management resource? “If I move the container to another location, do the answers to these same questions still apply?” asks Blank-Edelman.

    Though these questions express concerns in direct and simple language, experienced DevOps engineers who have felt the frustration of building development processes and attendant infrastructure understands these are difficult questions to satisfy. Without modern containerization efforts to sustain DevOps, development and production goals grow further out of reach.

    The Importance of Policies

    As containers undergird DevOps and continuous delivery, policies support containers. Developers input changes and innovations in code to the continuous delivery pipeline. Developers then respond to the needs of the growing code in a nurturing fashion, fixing errors and enabling new features. This pipeline works when automation, together with each progressive step in the development process, lays a foundation for the next step in a predictable and reliable manner.

    “Here’s where it gets tricky: First, not only do you have to be able to answer the trust-related questions for each step, but it is entirely possible (and entirely likely in an enterprise environment) that different people/teams will share control of and input to each step on that path,” says Blank-Edelman. With so much collaborative effort in play juggling all these pieces, policies are necessary to configure these steps, address networking and other elements, and control the component parts of the process ahead of time and everywhere along the way.

    Policies that make particularly good container watchdogs include those that set steps in the DevOps/continuous delivery pipeline apart, hemming them in on all sides. “Just like having your papers in order makes for an easier border crossing when you travel abroad, so, too, does having your policies reflect the trust required to move from one step to another,” says Blank-Edelman.

  • How Continuous Delivery Challenges Security

    How Continuous Delivery Challenges Security

    Security and continuous delivery each have implications in their effects on each other. While continuous delivery can demand new security measures, traditional security can slow continuous delivery or simply not address its security needs at all.

    Micro Case Study Clarifies Security Conflict

    Amrit Williams, now CTO of CloudPassage, shares an experience that exemplifies the challenges continuous delivery poses for security. Williams once worked with one of the largest national HMOs in the United States, which developed and supported a customer healthcare portal to enable customers to access health data and take advantage of other HMO services.

    At the time of his service there, the company sought to enhance its portal’s performance to challenge other HMOs in the marketplace that were popular, in part, due to the strength of their portal.

    “They wanted to add a bunch of new features and make continual improvements by way of moving from a development model of new releases every six-month period to new site releases and updates every couple of hours or about four times per day,” says Williams. But every time the Ops team would bring up new containers and compute resources to deploy new technologies and application code, success would count on repeated manual changes to firewall rules to appropriately pass data, enabling applications to talk to the portal and its technologies.

    “They finally decided to allow the firewall rules to apply to the application at the server level rather than at the underlying network level so that they didn’t have to go changing those rules all the time,” says Williams.

    In DevOps, Security Still in First Gear

    “Traditionally in the enterprise, security has been about speed only when the company is potentially dealing with a compromise, a policy violation or some other threat to the business,” says Williams. The organization is not used to having to respond quickly with security simply to deliver code. Common security tools were not designed to shift and adapt to automated code development and deployment.

    “For example, a lot of times the security teams will rely on endpoint security tools that typically require static IP addressing, which is antithetical to dynamic compute models,” explains Williams. These mammoth resource-hogging security applications ask too much and secure too little if they can even work effectively in DevOps shops at all. When you must stop to adjust these security tools, you may trigger change management processes that can slow the development process even further.

    Why Not Fail Fast?

    While DevOps makes it easier to isolate and fix coding errors quickly, this doesn’t appear to spill over to security. Fixing errors to make the code work doesn’t mean the code is more secure. These changes could even introduce new security flaws that were not there before.

    Securing continuous delivery is about the security team surrounding dynamic processes with protections that keep up with the speed of the continuous delivery pipeline. This can be difficult when these processes are automated, bringing up resources on demand to create and deploy software.

    “It is really the deployment and configuration of these environments that can lead to some of the biggest security concerns and not necessarily the code itself,” he says. “It is that aspect of DevOps that security is usually not very familiar with, which can really result in them being left out of the process because they try to apply a rule or a government policy that is again, antithetical to that process.”

    Continuous Delivery Security Incidents Challenge Legacy Security

    In this case example, Williams shares a particular type of threat that legacy security tools would not prevent in a continuous delivery environment.

    “It was 2012, during Christmas and it happened to customers using a region of Amazon‘s public cloud services. Amazon rebooted a bunch of servers, and some of those servers were running local host-based firewall management tools that were reliant on connectivity back to the management consoles as well as a static IP address,” says Williams.

    When those systems came back online, neither the agents on the hosts or the tools functioned properly. Amazon and its customers had to work to ensure the agent software on the hosts worked and communicated with the firewall management tools and that customer systems were secure. This was important because of the number of sales Amazon customers had to process securely at the time, which was just a few days before Christmas Eve.

    Again, this is an example of the failure of legacy security tools inside an environment that was increasingly adding automation while approaching continuous delivery. The lesson here is that as DevOps and continuous delivery approaches are altogether unique from legacy development, so the security tools that protect these environments need to be new, unique and suited to continuous delivery by design, lest they fail to survive partial outages such the Amazon example.

  • Experts Weigh In on the Evolution of DevOps

    Experts Weigh In on the Evolution of DevOps

    DevOps is an ethereal concept. It means different things to different organizations and individuals. It also is going through an evolution, which means that as quickly as we might think we have a grasp on what it is and how to effectively employ it, DevOps has moved on. There’s no way to accurately predict whether DevOps will even still be a thing in another five years, or if it will have faded into oblivion—replaced by the next hot tech or development model. We can, however, take a look at how DevOps has changed in the past year, and what the immediate future holds for it.

    It isn’t an easy question to answer because first we have to agree on what DevOps is. Are we talking about DevOps as a culture or business model, or are we referring to the evolution of the tools and applications generally used in a DevOps environment? I reached out to the DevOps community to get some expert insight.

    Current State of DevOps

    “The technology question is a common one when it comes to DevOps. We are still faced with the problem of a clear definition of DevOps. So what makes this difficult is … I’m squarely in the camp that believes DevOps is more about culture than tools or tech,” explains Andrew Storms, vice president of Security Services at New Context. “That being said, a well-rounded and mature DevOps organization does require a shift in people, processes and technology. A lot of people will likely point to orchestration of infrastructure as the most important DevOps tool. However, I think the bigger driver of orchestration has been virtualization and cloud.”

    One of the defining characteristics of DevOps from my perspective—aside from the IT culture aspect—is the fact that we continue to raise the bar for automation. Each new automation tool further streamlines the process and puts a spotlight on the next bottleneck. Eventually, a new solution is developed to automate that as well.

    Chef CEO Barry Crist believes that one of the most important evolutions in the world of DevOps in the past year is continuous delivery (CD)—or the process of rapidly developing software and iterating through quick, small-batch releases. “Continuous delivery was previously exclusive to the web innovators like Facebook, Amazon and Google, but over the last year companies have realized it’s a primary key to unleash an organization’s innovation engine. When the whole stack—infrastructure, compliance, security, microservices and apps—are all expressed as code, IT is able to deliver value more quickly.”

    DevOps also has introduced more common ground between developers and security/compliance officers. In high-velocity organizations that have embraced DevOps, IT can deal with security threats more quickly by assessing a vulnerability, creating a fix, testing it and deploying it rapidly before damage is done. DevOps is also starting to automate and define compliance. When compliance is defined as code, the software can be managed and tested like any other piece of code in the organization.

    The Evolution of DevOps

    Storms stresses that the immediate future of DevOps revolves around it becoming more mainstream—the new normal. “We are already seeing the business value of DevOps. Companies are getting code out the door faster and at a more efficient means. Other departments, like those of security, are starting to see the value of DevOps and looking at ways to incorporate key points into their departments,” he says.

    Crist sees DevOps as evolving beyond IT itself. “In the next few years, the DevOps tent will expand beyond ‘devs’ and ‘ops’ to include executives and other business units,” he says. “DevOps is really about building high-velocity organizations. Mature DevOps organizations see both innovation and quality increases that drive more profit and shareholder value, as well as advances in security and safety.”

    Only time will tell how DevOps will actually adapt and evolve. I tend to agree with Chef’s Crist that the natural evolution is to take the core principles and practices of DevOps and expand them beyond development and beyond IT to streamline all aspects of the organization. I guess the real question is whether or not we’ll still refer to it as “DevOps” at that point.

  • 5 Things DevOps is Not

    5 Things DevOps is Not

    For those who have been embracing and championing DevOps for years, the growing popularity of DevOps is as exciting as landing your first job out of college! Okay, maybe not that exciting, but still really cool. More and more companies of all sizes are embracing DevOps by including the adoption of DevOps practices directly into their fundamental strategies.

    On one side, this is giving teams the leverage they have needed all along to either begin their DevOps journey or to increase the maturity of existing DevOps adoptions. On the other side, when DevOps becomes a mandate, some of that grassroots passion can become watered down, as the use of the word becomes increasingly overused or incorrectly used.

    DevOps incorporates a new collaborative culture that embraces numerous practices combined together for a continuous software development methodology that places significant emphasis on feedback loops, collaboration and continuous improvement. DevOps requires fundamental cultural changes and includes so many practices that can be overwhelming to those just starting their journey.

    Instead of highlighting everything that DevOps is, I thought it would be good to take a step back and highlight what DevOps is not instead.

    1. DevOps is not simply combining Development & Operations teams

    We’ve all seen this one when the term DevOps comes up. “Let’s combine the Development & Operations team and, voilà!, we now have DevOps.” DevOps combines a set of processes and practices to be adopted throughout the entire delivery pipeline and spans multiple stakeholders. A couple of the key practices within DevOps adoptions include continuous integration (CI) and continuous delivery (CD). Simply combining two teams and calling it DevOps cannot accomplish those practices.

    2. DevOps is not a separate team

    Setting up a separate DevOps team is another trap many organizations fall into when beginning their DevOps journey. In general, I’m not a fan of the DevOps team as I believe it leads to more silos in the end. I’ve also found the creation of these teams can lead to further confusion when the mission is not clearly defined.

    There are some cases where a temporary DevOps team may make sense to help enable the processes and potential tooling that may be needed for adoption, but the key is making it temporary—which is often better in theory than in practice. There are several great blogs out there discussing DevOps teams such as Matthew Skelton’s blog, “What Team Structure is Right for DevOps to Flourish?”

    3. DevOps is not a tool

    Let me be the first to say I actually love the growing number of tools that enable us to continue maturing our DevOps adoptions, but I’ve noticed the use of one or two tools starts to lead to the perception that DevOps is a tool. How many times have you heard?

    “We’re already doing DevOps. We have Chef.”

    “We do DevOps. We automatically deploy through Jenkins.”

    Keep in mind, I’m a big fan of both Chef and Jenkins, but I think the power of DevOps is drastically underutilized if you’re equating the utilization of a single automation tool to DevOps success. Adopting automation and tooling is, of course, a part of DevOps, but only when combined with end-to-end practices of increased collaboration with continuous integration/continuous delivery, amplified feedback loops and continuous improvement (to name a few)! DevOps is a journey and that journey may start with a tool, but the goal should be to first identify your DevOps strategy and then find a tool or tool chain that meets those goals.

    4. DevOps is not a one-size-fits-all strategy

    Because there are so many different business drivers and technologies to consider when setting up an overall DevOps adoption strategy as well as identifying your DevOps tool chain, it’s important to apply the same tenets of DevOps to your DevOps strategy. Embrace change, gather metrics, understand feedback, fail fast and correct your course quickly. As an example, if you initially identify a tool that no longer works for your technology or environment, abandon it and move on. Just because you used it on the last project doesn’t make it a silver-bullet fix for the next one. We need to first understand our current strategy and environment, then react accordingly.

    5. DevOps is not automation

    That one may have caught the eye of a few people, so I’ll clarify: DevOps is not solely automation. Automation is absolutely a huge part of DevOps; however, it is not the only part, and deploying some degree of automation is often used interchangeably with DevOps. I think understanding the key DevOps practices is a great precursor to ensuring DevOps is viewed as more than just automation. Understanding the core DevOps principles is key to understanding the true benefits of DevOps adoption.

    There are a lot of things that DevOps is and I think I share a widely spread passion for DevOps. There are also a few things that DevOps isn’t—or isn’t solely. If you’re just starting your DevOps journey or still maturing your existing model, making sure everyone on your team has some basic DevOps education and is aware of the DevOps strategy for your project is key. It will go a long way in helping everyone understand that DevOps is about a lot of things. It’s also not about a lot of things.

    The list above isn’t exhaustive and I’m sure you all have a few you’d like to see on the list. I’d love to hear you thoughts and suggestions at @Shelbee_SE.

    You also can download and browse through the DevOps for dummies e-book.

    About the author/Shelbee Smith-Eigenbrode

    Shelbee

    Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM Cloud Infrastructure Center of Competency. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.

  • Gartner Evaluates APM Tools for DevOps

    Gartner Evaluates APM Tools for DevOps

    In 2009, Gartner analyst Mark Nicolett created the Critical Capabilities report. Over time, this document became paired to individual Magic Quadrant reports, and in 2014, Gartner mandated that Critical Capabilities be paired with each Magic Quadrant. Instead of graphically plotting vendors on a x- and y-axis, this research takes a deeper look at a product and its fit for specific use cases.

    So how does this pertain to DevOps?

    In its latest “Critical Capabilities of Application Performance Monitoring” research, Gartner notes, “Because of its wide lifecycle purview, the DevOps release team often leverages many of the capabilities found in APM suites.” Since the foundation of DevOps is to foster collaboration among the two, typically disparate teams, modern application performance monitoring (APM) solutions are geared perfectly to help encourage this feedback loop. “When examining the capabilities valued by this buyer, APM tooling is critical when attempting to quickly assess the quality (and effectiveness) of a recent release. Detecting and diagnosing issues must be done quickly, which often requires in-depth data sourced from multiple, integrated tools,” according to Gartner.

    “Much of the activity of APM technology is focused on detecting and providing insight into root causes. Identification of the impact on system and application resources is based on existing (or proposed) transaction-level trends,” the report continues. “This capability provides IT operations and DevOps release teams with the ability to tell the (line of business) and application owners the potential impact for any planned changes or continuation of resource consumption trends. Although capacity-planning tools have often filled this role, APM suites increasingly offer predictive analytics capabilities for shorter-term horizons”

    Of course, we can’t ignore the key to DevOps success: culture. However, no tool—no matter how good—can foster the right type of culture. John Rakowski, my current colleague and ex-Forrester analyst, wrote a compelling ebook on the intangibles that successful DevOps teams need.

    The Critical Capabilities research report provides a comprehensive and technical product analysis ranking APM suites from 15 vendors on critical APM capabilities across five different usage scenarios, including DevOps. The capabilities assessed for each use case included business analysis, service monitoring, anomaly detection, distributed profiling, application debugging and workload planning.

    The vendors evaluated were AppDynamics, AppNeta, BMC Software, CA Technologies, Dell, Dynatrace, Hewlett Packard Enterprise, IBM, JenniferSoft, ManageEngine, Microsoft, Nastel Technologies, New Relic, Riverbed Technology and Tinygun.

    The report is free of charge and can be downloaded here.

  • Continuous is the Engine that Drives DevOps

    Continuous is the Engine that Drives DevOps

    It has been stated time and time (and time and time) again that DevOps is primarily a matter of shifting IT culture. The tools and practices that comprise DevOps play a secondary role. But that is only partially true: In reality, the culture shift revolves around continuity, and the applications and tools that fuel continuous delivery drive the DevOps engine.

    I alluded to this point in a post in early 2015. I stated, “Everything is continuous. Continuous development and continuous testing lead to continuous deployment and continuous delivery, which requires continuous support. Continuous monitoring produces continuous integration and continuous change. Continuous security results in continuous incident response … or vice versa. To top it off, all of the continuous activities continuously feed each other to drive more continuousness in some sort of DevOps Mobius strip of continuity.”

    That post last year was a bit tongue in cheek. I have since refined my position, however, and come to the conclusion that the hint of sarcasm was perhaps unwarranted. That continuous continuousness is the crux of the culture shift. It is the thing that separates DevOps from non-DevOps.

    On the Continuous Journey

    Speaking on the topic of continuous security, Andrew Storms, vice president of Security Services at New Context, explains, “Smaller incremental changes are always easier to handle than a large behemoth of a release that can include hundreds of changes. Try finding the single change in a monthly release that resulted in an unexpected security hole in your database configuration vs the release with only two changes that was just developed and released in the last few hours. Security practitioners cannot continue to rely on manual, human-controlled processes to defend against attacks. Automation is a requirement for the next evolutionary phase of security protection.”

    That sentiment extends beyond security to all of IT. When we talk about the culture shift in IT required for DevOps, we are generally talking about breaking down silos and removing the barriers between different teams. The goal of the culture shift is to shed tedious bureaucracy and red tape and empower employees to freely collaborate and cooperate to get things done. In other words, we want to eliminate barriers and roadblocks so productivity can be more continuous.

    Assuming the DevOps transformation begins at that level, it creates an environment of continuous collaboration which becomes continuous development. What follows is a natural evolution of continuity. Continuous development becomes continuous delivery, which requires continuous testing and continuous deployments, followed by continuous monitoring, which provides the metrics and feedback that take you back to the beginning of the loop.

    All of the “continuous” tools and solutions may seem to be part of the technologies and practices that come after the DevOps culture shift, and to some extent, that is true. However, they are also indispensable and inseparable from that DevOps culture shift because without all of the various gears meshing together smoothly—and continuously—what you’re left with is a more traditional approach to IT where everything comes to a halt.

    Is DevOps more of a cultural shift than a collection of tools? Absolutely. That culture shift revolves around continuity, though. Continuousness is the culture shift that drives DevOps.

  • Where will DevOps be in 10 years’ time?

    Where will DevOps be in 10 years’ time?

    What will the DevOps landscape look like in 10 years’ time? Ten years ago, Agile was seen as new and different. Now it’s part of everyday life of most developers. Will it be the same with DevOps? It’s time to clasp the crystal ball and unravel where the future is headed.

    First things first. DevOps is here to stay. The overwhelming trend towards the digitization of services accelerates the need for agility and shorter release cycles with DevOps as an invaluable building brick: think the Uber vehicle booking service, the Airbnb property rental service—even Amazon’s move to take the terrestrial version of Top Gear and launch it as a digital-only, on-demand broadcast service. Services are going digital. And so are companies: banks, retailers, telcos and others are increasingly positioned as software-driven businesses where IT makes the difference.

    These organizations will need to develop and deliver compelling, customer-centric apps quicker than ever before. Agile development will become the battle cry of every business. Dev and Operations teams will increasingly need to shake hands in a middle ground of rapid development and reliable, high performance services delivery.

    At a technical level, DevOps enablement will be driven by increased public and private cloud adoption: Infrastructure, Platform and Application Service Clouds are all important enablers for DevOps practices. Moreover, DevOps will also grow through the replacement of IT Operations Management tool chains – including automation, monitoring and service management – from non-DevOps to DevOps-enabled and DevOps-ready tools.

    If agile is a journey, DevOps can be seen just as another part of it; one, that suits companies, which successfully completed the first phases of agile transformation and are now looking at ways to further enhance their agile maturity levels and accelerate releases. The increased adoption of agile development methodologies and the increase of related maturity levels thus will also fuel growth. Gartner, for example, has indicated that agile development is essential for mobile application development, arguing that the traditional methods used to define and develop desktop applications will not work with mobile application development.

    Still not convinced? Then how about this. Research by Computing in the UK shows that 30% of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13% planning to go down this route.

    Awareness of existing DevOps success will also fuel this continued growth. Recent research, for example, shows that high-performing IT organizations are deploying code 30 times more frequently with 50% fewer failures using DevOps practices. And demand for DevOps skills is soaring too: DevOps engineers are among the highest paid IT practitioners today, according to APM Digest.

    Make no mistake, the software delivery chain will continue to accelerate and change cycles will shrink. In many competitive scenarios, an advantage can only be sustained through organizational agility. In fact, agility can make such a competitive advantage sustainable. Since IT is so important already in the “legacy” enterprise and becomes even more so in the digital economy, existing IT systems and methods will need to move towards agile.

    Here’s another thought. I predict that within the next 10 years the split of ‘Mode 1’ and ‘Mode 2’ companies will disappear. Mode 1 is the traditional approach to development, emphasizing scalability, efficiency, safety and accuracy. It’s the blueprint for how IT Operations works. Mode 2 meanwhile is non-sequential, emphasizing agility and speed. And it requires new thinking and processes around issues such as investment management, governance and collaboration.

    It will disappear for two reasons. First, distinct cultures and operational modes are not sustainable within the same business. Second, if agility is not a requirement, the service should not be operated within the boundaries of the firm for strategic reasons. Own “mode 1” operator companies should be used to outsource non-differentiated IT services.

    In due course, bimodal IT will flourish within organizations, servicing two modes of IT, each designed to develop and deliver information- and technology-intensive services in its own way. Success in both modes demands smarter, more flexible tools that support today’s complex IT operations. Bimodal IT is not without its risks and challenges, but it will be increasingly powerful in helping companies meet ever-growing customer expectations. DevOps will help firms help them bridge these two modes.

    Market demand for DevOps skills will continue to grow too in the next 10 years. Research indicates that DevOps engineers are among the highest paid IT practitioners today and aggressive hiring of people with DevOps expertise will continue in the years to follow.

    One final, more controversial thought. In 10 years’ time, we might not even be talking about DevOps anymore. By then, all stakeholders will understand how to work holistically to achieve business value through the end goal of delivering high quality applications and services to customers. So DevOps might even become redundant. But continuous delivery will be the norm.