devopsy.kinsta.cloud

Author: Chris Tozzi

  • How Open Source Can Help Your CD Chain

    How Open Source Can Help Your CD Chain

    What can you do to make continuous delivery work better? Consider moving to open source software solutions. Here’s why.

    Many DevOps teams already may be using open-source platforms for reasons not related to continuous delivery. They might like the cost-efficiency or interoperability that usually come with open source. Or maybe they just like the open-source philosophy.

    Typically, however, open source is not viewed as a requirement for doing DevOps or achieving continuous delivery.

    How Open Source Speeds Continuous Delivery

    But maybe it should be. Consider the following ways in which open-source code can better facilitate a continuous delivery pipeline:

    • It’s easy to tweak. Because anyone can view and modify the source code of an open-source program, you can change it to work as efficiently as possible. Custom enhancements could make the open-source tools you use work more efficiently within your delivery chain.
    • No vendor lock-in. Most open-source tools and platforms are designed based on open standards. The threat of vendor lock-in is minimal. For that reason, adopting open source helps prevent surprises that could otherwise hold up your continuous delivery pipeline in the event that a vendor decided to stop supporting the tools you are using.
    • It’s well-known. Mainstream open-source tools are widely used. Chances are good that the people who are currently on your team, or will join it in the future, already know open-source tools. That’s an advantage for continuous delivery because it means you won’t have to spend time training staff—and risk introducing delays to your continuous delivery chain while the staff are being brought up to speed.
    • It gives you options. With open source, you usually have lots of implementation options. Want to deploy on Linux? There are about a dozen mainstream distributions you can choose. Want to run your cloud with OpenStack? There are lots of distributions of that, too. Having choice is a good thing for continuous delivery because it allows you to switch easily between different frameworks or tool implementations as your needs change. That agility prevents you from being locked into a specific solution.

    This is not to say that open source is a silver bullet. Achieving continuous delivery requires attention a lot of other factors; it’s not as simple as using a certain type of technology (if it were, everyone would be delivering continuously). But adopting open-source solutions when possible certainly can’t hurt—and it just might help as you seek to deliver software continuously.

    — Chris Tozzi

  • How Often Should You Release with Continuous Delivery?

    How Often Should You Release with Continuous Delivery?

    If you do continuous delivery, you could release software updates as frequently as you want. But should you? Here’s what to consider when deciding how often to release.

    Although the terms continuous delivery and continuous deployment are often used interchangeably, they don’t mean the same thing. Under continuous delivery, you prepare all software updates as potential candidates for release. But continuous delivery on its own does not mean that you release all of those updates into production as soon as they are complete. You would have to adopt continuous deployment to do that.

    So, if you’re doing continuous delivery, you have the option of releasing as frequently as you like—every day, every month or even every hour. Determining how often you actually release requires weighing several important factors, including:

    • How important are your updates? If changes to your app mostly involve mundane things such as interface tweaks, continuous deployment probably will confuse users more than please them. They will have to adapt constantly to new features. But if you can roll out big, user-friendly changes on a continual basis, then deploying continuously can help keep your users happy.
    • Is there a marketing advantage to be gained by waiting longer to release? Sometimes, advertising new features but waiting a while to release them can help build excitement. Case in point: Apple Inc.
    • Do other apps depend on your app? If you’re working within an ecosystem where your app integrates with other apps or platforms, continuous deployment makes the lives of partner developers more difficult because it requires them to adjust constantly to changes in your app. To help them ensure their work will always be compatible with yours, provide space between your releases.
    • Is your development pace consistent? If not, continuous deployment can be problematic because users will see rapid updates at some times, but stagnation at other times. Continuous deployment only works well for users if they can count on a relatively steady stream of updates.
    • Do your updates create a learning curve? If users will have to learn new tricks to use an updated app, continuous deployment may create more confusion than happiness.
    • Can multiple versions of your app coexist? If all users need to be running the same version of your app in order to be current, continuous deployment can help assure that they are. But if you can support multiple versions of the same app at once, less frequent releases should work for you.

    If you can’t decide how frequently to release, you might consider releasing on a fixed time schedule—once every two months, every six months, every year or whatever works for you. This is what Canonical has done with Ubuntu Linux for a long time: It releases a new version of the operating system on the second Thursday of October and the fourth Thursday of April each year (with a few exceptions). This system assures that developers and users always know the schedule for a new release.

    Whatever approach you take, the most important thing is to realize that continuous delivery does not require you to release as often as you can. It gives you the flexibility to release as often as you want. Deciding how often that should be is up to you.

    — Chris Tozzi

  • Compuware Survey Connects Mainframes, DevOps

    Compuware Survey Connects Mainframes, DevOps

    Mainframes are still necessary; integrating them with modern hardware and software is tricky; and DevOps is the answer. Those are the takeaways from a survey out this week that was commissioned by Compuware.

    The survey, which was released Dec. 14, was conducted by Forrester. It asked professionals how often their organizations rely on mainframe systems and what they do to overcome the challenges associated with using legacy mainframes within modern computing environments.

    The survey suggests that mainframes are not going anywhere soon: 57 percent of respondents said new business initiatives “always” involve the mainframe, according to Compuware. Even though mainframe systems are now decades old, they still have a place in modern IT.

    But bridging the gap between mainframes and more modern infrastructure and software delivery practices is tough, according to the survey. This is due not only to what Compuware calls “organizational bureaucracy” and “insufficient funding,” but also the difficulty of integrating mainframes with other types of technology that were designed in a different era.

    The survey shows that most professionals take one of three approaches to solving that challenge:

    • Move applications off of mainframes. The downside to this strategy is that mainframe applications may not run as fast or as securely on other hardware.
    • Avoid using the mainframe at all. This, too, is not always ideal, according to Compuware, because the mainframe is better at handling some types of workloads.
    • “Modernize” mainframes, which entails a lot of investment and effort.

    According to Forrester’s conclusion in the study, a better approach is to apply DevOps techniques to mainframe development. That means that the mainframe technology itself does not have to change or be hybridized; only the approach to mainframe app delivery changes. “Those companies embracing DevOps deliver faster and at a higher quality, all while fostering collaboration,” Forrester concluded.

    These are all things that a Compuware-sponsored study is likely to say, of course. Compuware specializes in DevOps solutions for the mainframe.

    Still, the survey is a good reminder that mainframe is alive and well—and DevOps teams should not leave it out of the picture.

    — Chris Tozzi

  • Compuware Buy Aims to Enable DevOps on Mainframes

    Compuware Buy Aims to Enable DevOps on Mainframes

    How do you bring DevOps to mainframes? Eliminate the need for developers and admins to have mainframe expertise. That’s the strategy mainframe specialist Compuware is following as it seeks to break into the DevOps market.

    On Dec. 6, Compuware announced its acquisition of Standardware Inc., adding Standardware’s COPE IMS virtualization software to Compuware’s portfolio.

    That’s important because the IMS virtualization product helps to speed the development of database and transaction-management software that is used widely on mainframes in industries such as banking and commercial aviation. It does so by allowing developers to create virtual mainframe development environments, instead of relying on actual hardware—which is more costly and more difficult to provision.

    “The result is greater digital agility across all tiers of the enterprise architecture, from front-end systems of engagement to back-end systems of record,” according to Compuware.

    Bridging the DevOps-Mainframe Divide

    But Compuware’s acquistion of Standardware is not just about bringing a new virtualization technology to mainframe developers. The ultimate goal is to make it easier for software engineers who don’t have backgrounds in mainframe systems to write code that can run on them.

    “Successful transition of mainframe stewardship from retiring Baby Boomer specialists to less specifically mainframe-experienced Millennials” will be key to enabling agile, DevOps-based application development and deployment techniques for the mainframe, according to Compuware.

    For the declining number of software engineers out there who are mainframe experts, the push to remove special knowledge requirements from the mainframe development scene will not bode well. For the DevOps world as a whole, however, Compuware’s strategy for keeping mainframes relevant in the DevOps sounds a lot like the “serverless” computing movement. The goal of serverless computing is to allow developers to write code without having to think about the hardware it will be deployed on.

    Making mainframes totally serverless probably is not a realistic goal. Mainframe development languages and frameworks are so different from those of commodity hardware that mainframe software will never be quite the same as code written for other servers. Still, software such as IMS virtualization can help to make mainframes feel less like mainframes for the developers working with them—and that will be essential for making sure that mainframes are not left out of the DevOps revolution.

    — Chris Tozzi

  • How DevOps Optimizes Use of Resources

    How DevOps Optimizes Use of Resources

    How is DevOps changing the way we compute? One big DevOps innovation is helping developers and admins consume exactly what resources they need to deploy an app—nothing more and nothing less.

    Traditionally, using (and paying for) only what you need has been tough in all parts of life. If I want to park my car for just 10 minutes on a Baltimore street, I have to pay $1 for a half-hour’s worth of time, because that’s the minimum parking fee. In similar fashion, I pay about $50 a month for the heating bill in the unoccupied house I just bought, even though the heat is turned off, because that’s the minimum monthly charge.

    The problem of having to pay for more than you actually need was a big issue in the pre-DevOps digital world, too. In the past, if you wanted to deploy an app, you had two options. The first was to run it on a bare-metal server. If you did that, to help mitigate the risk of the server becoming overloaded, you’d dedicate more resources to the app than would be necessary during normal usage. That meant paying for capacity that you were not using most of the time.

    The other option was to use a virtual machine (VM). Thanks to tricks such as live-migration and “hot-plugging,” commercial virtualization platforms provided some elasticity to VMs, helping to assure that the VMs consumed only the resources they needed at any given time. But virtualization still means you are wasting resources on hardware emulation and running guest operating systems that needlessly duplicate most of the functionality of the host. Even the leanest VM environment requires you to dedicate more resources to deploying an app than the app actually requires.

    DevOps and the Consumption Revolution

    DevOps technologies are changing all of this. They are revolutionizing the way we consume digital resources and introducing efficiencies that were not possible in the age before DevOps.

    The most obvious example of such innovation is containers. With a containerized app, you get the portability and elasticity that traditionally have been available only from virtual machines. But with containers, you don’t have to waste resources on virtualization. Your apps only consume what they need at any given moment in time.

    Technologies such as Lambda functions on AWS are bringing the same efficiency to the public cloud. With Lambda, you don’t have to pay for virtual servers, memory or disk space on an ongoing basis just to ensure that you have them available when you need them. Instead, you can use Lambda functions to get access to a large amount of compute capacity in the cloud instantly, and stop paying for it the millisecond you no longer need it.

    Also worth noting is all of the automation that DevOps brings to software delivery by promoting continuous delivery practices. In the age of waterfall development, each part of the organization had to wait around on other teams to push code or test results down the pipeline before it could perform its own tasks. With continuous delivery, everyone works continuously and in parallel. The result is no more wasted time and skills.

    In a multitude of ways, then, DevOps is optimizing the digital consumption. In the future, we’ll wonder why we ever accepted “miminum” fees or had to pay for more than what we needed to get the job done.

    — Chris Tozzi

  • Adding Usability Testing to the CD Pipeline

    Adding Usability Testing to the CD Pipeline

    Do you include usability tests in your continuous delivery pipeline? If not, you could be making a big mistake.

    Usability testing, which entails having actual users test an application for user-friendliness, intuitiveness and accessibility, gets easily lost within the DevOps conversation. If you want to do continuous delivery, waiting on manual usability tests may seem like a major barrier.

    Why Usability Testing Matters

    Yet, DevOps teams that ignore the importance of usability tests do so at their peril. Continuously delivered apps will provide little value if they are difficult for ordinary people to use. Users have little tolerance for applications that lack usability.

    It’s worth noting, too, that DevOps makes usability testing even more important than it would be within a waterfall delivery chain. When you do continuous delivery, your software changes more quickly. That increases the chances of introducing a change into production that negatively impacts app usability.

    How to Do DevOps Usability Tests

    So, how can you do proper usability testing without slowing down your continuous delivery pipeline? Unfortunately, there’s no easy solution. Unlike integration and unit tests, usability tests cannot be easily automated.

    You can, however, work closely with your in-house QA team to perform usability tests before changes reach the production stage of your pipeline. This will work as long as your QA team is able to replicate real-world usability conditions well.

    Alternatively, you could release changes to a select group of users before making them generally available. Those users would then test for usability issues quickly and report them to you before your updates reach the wild. This scenario would essentially mean doing a very fast beta release for certain users. If that seems unfeasible, keep in mind that, as long as each of your continuously delivered changes is minor, quick beta testing is manageable.

    Whatever you do, the most important thing is to avoid ignoring usability testing. Otherwise, all of the hard work you put into continuously delivering your app could be for nought.

    — Chris Tozzi

  • Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?

    Continuous Integration vs. Delivery vs. Deployment: What’s the Difference?

    “Continuous” is one of the most popular words in the DevOps lexicon. What does it really mean, and what is the difference between continuous delivery, continuous deployment and continuous integration? Keep reading for some perspective.

    Like many technological concepts, continuous integration, continuous delivery and continuous deployment are terms that DevOps teams tend to use without defining them precisely. For that reason, it’s worth taking a closer look at what each of these terms actually means.

    Continuous Integration

    Continuous integration can really mean one of two things, depending on the context.

    In the narrower sense, continuous integration refers to the work done by a continuous integration server, such as Jenkins or Bamboo. A continuous integration server automatically tests code written by individual developers to make sure it can be merged into the main code base. By automating this process, continuous integration servers help developers to write and test small chunks of code on an ongoing basis, which minimizes the risk that a code change could cause serious problems and force developers to revert their application to an earlier state.

    In a broader sense, continuous integration means the constant integration of changes to an application at all stages of the delivery chain. This includes but is not limited to the automated integration testing and code merging performed by an integration server. In this broader definition, continuous integration can include the integration of new design concepts to the delivery pipeline, for example. It also can involve other types of software testing beyond just automated integration tests.

    Continuous Delivery

    In most definitions, continuous delivery refers to the process of delivering software updates to users on a nearly constant basis. Continuous delivery is made possible by continuous integration and other optimizations at earlier stages of the development process. But the definition of continuous delivery gets a little cloudy when you start comparing it to continuous deployment.

    Continuous Deployment

    What’s the difference between continuous delivery and continuous deployment? For some DevOps teams, nothing. People tend to use these terms interchangeably. In fact, they are usually simply abbreviated as “CD,” leaving it up to the listener to decide what the speaker is actually talking about when he hears the term during a conversation about DevOps.

    Some developers draw a distinction between continuous delivery and continuous deployment, however. For example, Mirco Hering writes that continuous delivery requires that the DevOps team manually release updates to users. In contrast, the continuous deployment pipeline is fully automated; users get updates as soon as they are written and tested, with no manual intervention by developers.

    This distinction is a good way to think about the difference between the closely related concepts of continuous delivery and continuous deployment. It’s a distinction that will become increasingly important as technologies such as Docker make it easier to automate application deployment by allowing DevOps teams to drop new container images into production.

    What Does Continuous Mean, Anyway?

    It’s worth mentioning, too, that the word “continuous” is usually something of an exaggeration when used by DevOps folks. It implies that software changes roll down the pipeline in a totally constant, never-stopping fashion.

    That is an exaggeration. Integration, delivery and deployment are almost never completely continuous. In practice, a “continuously” integrated application is likely to be rebuilt and delivered something like every 24 hours, not every single time a code change reaches the end of the pipe.

    That rhythm is still a lot faster, and closer to continuous, than the “waterfall” delivery pipelines that were common before the introduction of DevOps. But it’s still important to understand that, even with all of the automation tools available today, software development is rarely completely continuous.

    — Chris Tozzi

  • Are We Leaving Developers Out of DevOps Spinoffs?

    Are We Leaving Developers Out of DevOps Spinoffs?

    SecOps. DataOps. NetOps. Reading these terms, you get the sense that the key to IT efficiency is to make IT Ops work with everyone else. But that’s a mistake, because it leaves developers out of the picture.

    It’s no secret that the DevOps movement has generated a number of other *Ops initiatives, including those listed above. The driving idea behind all of them is that IT Ops teams should work more closely with security teams (in the case of SecOps), data analytics teams (in the case of DataOps) or networking teams (in the case of NetOps). These are only a sampling of *Ops movements; the list could go on.

    To be sure, there are advantages to gain by having IT Ops collaborate more closely with other parts of the organization. But there are an equal number of advantages in doing the same thing with developers.

    To optimize security operations, you need developers, IT Ops and the security team to work together. If Dev is left out of the picture, it’s much harder for the other two parts of this equation to make sure that the code the organization deploys and manages is secure.

    For similar reasons, DataOps, NetOps and almost all the other *Ops you can come up with work well only when Dev also participates. The people who actually design and write the applications are important.

    Rethinking Ops

    Why does this matter? My point is not merely that terms like SecOps and DataOps are misleading because they don’t mention developers.

    On the contrary, giving equal weight to developers is important because if you don’t, you risk isolating developers. Some are already complaining that DevOps is “killing” them. The trend of defining new *Ops practices that don’t mention developers is not helping.

    So, maybe we should start mentioning and thinking about developers more prominently when we are talking about ways to extend the DevOps philosophy to other parts of the IT organization. This is already being done somewhat in the case of SecOps, which you sometimes hear called SecDevOps. But Google lists nearly 13.5 times as many results for “SecOps” as for “SecDevOps.” The numbers are similar if you search for “NetOps” as compared to “NetDevOps.” And I’ve never heard anyone say “DataDevOps.”

    The takeaway is this: Developers are as important as IT Ops to DevOps. Don’t leave them out.

    — Chris Tozzi

  • Don’t Leave Software Testers Out of DevOps

    Don’t Leave Software Testers Out of DevOps

    The term DevOps implies that software delivery is all about integrating the development and IT operations teams. But the software testing team is an important, if oft-overlooked, part of the picture. Here’s why.

    Could you deliver software continuously without involving the QA team in the continuous delivery pipeline? You could try, but it would probably not go well. Software testers play a vital role in continuous delivery, for the following reasons:

    They are the glue connecting developers to IT Ops. If there is no one to test the code that developers write, IT Ops cannot deliver a stable product.

    They help find problems before they become costly. If you skimp on integration, unit and performance tests, you won’t find problems in your software until after it reaches users. By that point, fixing those problems will be much more time-intensive than it would if they had been caught early on. Plus, your organization’s reputation will have taken a hit, because problems that could have been nipped in the bud prior to delivery ended up affecting users.

    They know things that developers and IT Ops don’t. If DevOps is all about continuous visibility across the delivery chain, then it only works well when the delivery team’s collective expertise covers all parts of the delivery process. Since developers and IT Ops people are not experts in quality assurance or testing, you need to involve testing professionals in the continuous delivery chain so that they can help everyone else understand the parts of the process that QA professionals know in detail.

    All of the above is to say that if the QA team is not plugged into every stage of the delivery process, your software either won’t be tested efficiently, or it won’t be tested at all. Not testing efficiently means that the QA team is not in sync with the rest of the organization. In this case, the QA team would delay software delivery because it would have to wait on developers and admins to complete its work, and vice versa.

    Not testing at all, of course, is even worse. No one should deliver unvetted software to users.

    Don’t Forget about QA

    The takeaway for organizations seeking to adopt DevOps practices is this: Even though the DevOps conversation on the surface may seem to be about only developers and IT Ops professionals, QA teams play an equally crucial role in continuous delivery. They need to be as involved in the continuous delivery pipeline as everyone else if an organization wishes to reap the full benefits of DevOps.

    — Chris Tozzi

  • Why PR, Legal and HR Matter for Continuous Delivery

    Why PR, Legal and HR Matter for Continuous Delivery

    By most definitions, DevOps involves making developers and IT Ops teams work better together. But integrating other parts of an organization, such as legal and public relations, into DevOps is also important. Here’s why.

    DevOps has become popular because it helps to speed the delivery of software. The goal is to reach continuous delivery, which means code is changed, tested, staged and delivered to users on a (nearly) continuous basis.

    If you think only from a technical perspective, then getting to continuous delivery of software involves only technical people. Developers, IT Ops admins and software testers are all you need.

    DevOps in the Big Picture

    Yet, to deliver software continuously on a reliable basis, you need to think beyond just technical processes and personnel. Effective DevOps workflows have to involve all of the other parts of the organization that play a role in creating software, delivering it to users and maintaining it once it is in production.

    For example, PR teams need to be plugged into the software delivery chain so they know when new features are coming down the pipeline and can prepare to promote them. Legal professionals should play a role as well, since they’ll know when code changes require tweaks to licensing, compliance procedures and so on.

    The list can go on. In most organizations, human resources has a role to play in DevOps, since personnel changes can affect the continuous delivery chain. Supply chain managers should be involved, too, since they have a hand in provisioning the infrastructure on which DevOps teams rely.

    To be sure, these various non-technical teams don’t need to be as plugged into the DevOps workflow as deeply developers and admins do. Code can be written and tested without their perpetual involvement. Still, at a minimum, all parts of the organization should at least be aware of the state of the delivery chain. Otherwise, visibility and communication break down.

    Taking this big-picture approach to DevOps is important because ultimately, despite the relatively narrow purview implied by the term DevOps itself, the value of DevOps lies in adding efficiency and promoting better communication across the entire organization in ways that optimize software delivery.

    So, if you want to make the most of DevOps, start thinking beyond just Dev and Ops.

    — Chris Tozzi