devopsy.kinsta.cloud

Author: Don Macvittie

  • DevOps Abandonment: Reasons Not to Give Up

    DevOps Abandonment: Reasons Not to Give Up

    The Never-Ending Story

    When a new process or methodology comes along—particularly when one gets a lot of attention like DevOps has—there always will be failures. I’m not talking about those always-present group of people who say they’ve seen this cycle before and, thus, it is just a fad; I’m talking about actual implementers who, in the end, come up empty-handed.

    DevOps is no exception. In fact, because it radically changes much about IT, it probably has a higher rate of this problem than most new methodologies.

    The end result is easy enough to identify: Either an organization abandons DevOps altogether or shunts it off into that area where other processes and technologies have been implemented by only one team and eventually die.

    Problem Children

    In almost every case of DevOps failure, people are the problem. That is not to say people purposely undermine the system, but IT is built, managed and run by people. And the breadth of people in an organization has immense influence on the success or failure of DevOps (or any other IT initiative).

    With that said, let’s look at some problems that contribute to DevOps abandonment organizations should avoid in their attempts to evaluate/implement DevOps.

    Team Isolation

    It is a standard enterprise reaction to split off a team to look at a new technology/process and isolate them from the rest of IT. I was the first hire in a “New IT” at an organization—it was weird to have rooms of cubicles filled with people I was not allowed to talk to. One of several keys to success in DevOps is communication, and no application or application portfolio works in a vacuum. The need to discuss server space, security, routing and a host of other topics with core IT means isolation will not work. It is one thing to clear the pilot team’s workload to allow them to focus on assessing DevOps for the organization, but it is quite another to isolate them (functionally, geographically, whatever). If they find some quick-hit streamlining opportunities in standard operations, don’t you want those shared with the wider IT department?

    Getting the Tools Side Right, but Missing the Culture Side

    I make no secret about the fact that I’m a bigger fan of the automation side of DevOps than the culture side. But sooner or later, all the whiz-bang tools are deployed, and culture becomes the main focus. That includes not only communications between different parts of the DevOps team, but also the “can jump in and do” mentality that is more prevalent in DevOps than in a more divided IT environment. Getting the culture and communications down early is important for success. And success is important for wider gains in IT’s ability to meet the demands of the business.

    Adding to the Workload of Overloaded Team Members

    This is perhaps the most common pitfall that causes organizations to leave DevOps or minimize their exposure to DevOps practices. DevOps holds the promise of increased productivity and decreased backlog. But it is a promise. Implementing tools and forging new relationships and new paths of communication … these things take time. And that time is added to existing workloads, unless steps are taken to lighten existing workloads.

    The team working 10 to 12 hours a day just keeping the lights on will not side-track into anything that requires a definite investment of more man-hours unless it is mandated to them by the business. Asking them to start working on it is a recipe for failure; the best you can hope for is some automation that makes their life easier in some other way.

    Not Managing/Meeting the Expectations of Various Leaders

    What line of business (LoB) leaders and the CIO expect out of DevOps are different things. While vaguely similar—increased responsiveness to business needs is normally 100 percent shared—the details show different concerns.

    It is up to the CIO to manage what those under him in IT expect/demand from DevOps, and what those peers in the line of business expect from it. There is no reduction in commitment from LoB teams—indeed, one could argue there is an increase, as IT is no longer the bottleneck. And, perhaps most importantly for some organizations, DevOps doesn’t make IT mind readers any more than previous new methodologies did. The LoB still must define what is needed and get requirements into IT.

    Trying or Retrying DevOps? A Few Tips

    Pilot

    Run a pilot project. Lighten the load of the project team so members can focus on DevOps and bring its value into the team. Do not isolate them in any way. Including other teams by asking for help/ideas should be encouraged. In fact, if the pilot team is motivated and enjoying the pilot, this type of interaction can help smooth the way for extension of DevOps to the wider organization.

    Use Existing Resources/Management

    Don’t bring in specialists to do DevOps. DevOps can be learned, and there are a ton of resources available, so use people who know your environment and can apply standardized tools and practices to it. That includes management. The last thing an organization should have in a pilot is a manager that knows DevOps but not the relationships within and special quirks of your organization—both technical and social.

    Pick Your Pilot Carefully

    Pilot a project that is relatively small but is visible to the organization. Actively manage expectations, and see where DevOps takes you.

    Rethink Everything

    Empower the team to look critically at every single process/workflow and see where the most gain can be had. DevOps is not a switch; prioritizing high-value/important items for change in this iteration and lower-value items for future iterations is part of the process. But if you don’t look at everything, you can’t guarantee you’re getting the most bang for your buck on this—or any—iteration.

    Clearly Communicate Goals/Changes

    Make sure everyone in IT and out understands what the pilot is testing. Is it increased time to market? Is it ability to apply tools and processes to intractable sub-projects? Is it a test of the benefits touted by talking heads? Communicate what you are measuring and how you’re measuring it. If possible, share a dashboard showing those measurements with everyone who cares to follow along.

    This Time is Different

    DevOps is different from any other new methodology that has gained traction for the operations side. Ever. I’d say it was different than any other new methodology at all, but Agile is the precursor to DevOps on the Dev side, and they share a lot. It challenges decades-old thoughts on the best way to do things. It will fail sometimes, for a variety of reasons. Give it the best chance for success that you can, don’t tie the pilot team’s hands and use it where it succeeds, even if it doesn’t include every project in the portfolio.

    In the end, if it really does help the business succeed, then—like it or not—it is the right tool for the job.

    — Don Macvittie

  • Choose Your Toolstack — and Manage It — Wisely

    Choose Your Toolstack — and Manage It — Wisely

    Every DevOps toolstack has a control point, be it a bus, an app, a management app or whatever. Something always is in control and driving the other pieces of the architecture to do their part. It is a basic tenet of automation that jobs are mostly kicked off by something in the software hierarchy.

    In DevOps, most of us have defaulted to Jenkins for a large chunk of that automation. It was the center of the continuous integration/continuous delivery (CI/CD) side, and increasingly it is used to run both sides of DevOps (as I have called it previously, both DEVops and devOPS). CloudBees and recognized this trend, and an increasing amount of control and process functionality has been turning up in Jenkins.

    On the other side, there are organizations running all of devOPS from deployment tools such as Ansible or Puppet. Again, that’s not a terrible solution, since they can configure the software on the server and make sure all is ready to run.

    But neither of these toolsets was originally envisioned with the idea it would control as much of the DevOps stack as they currently do.

    If you read me regularly, you know I’m not a huge fan of this type of default control structure. There is a lot of functionality that can be laid over the CI/CD and environment automation tool. But to do some of it, the tool needs to be above the day-to-day functionality these tools specialize in.

    ARA can do it—and honestly, for a first brush at connecting the worlds represented by CI/CD and configuration management tools, is pretty impressive. Other vendors have come at it from a service bus perspective, allowing everyone to communicate through their tools and doing roll-up reports based upon what has been integrated. That’s not a terrible solution either, if it works with or can be made to work with your tools.

    ARA as a market is short on the monitoring and management end of the process when the app is deployed and clipping along. It’s getting better, and hopefully ARA that is fully integrated with monitoring tools will be the next step in this evolution, but for now most companies are handling tooling, monitoring and response to that monitoring outside of the ARA system.

    The queue systems tend to lag behind ARA in their ability to correlate and coordinate, but again this is getting better. They know only what is reported through them, so as they gain add-ons, expect they’ll handle the overall stack better.

    The long-term goal is, after all, to run from commit to release with only designed “go/no-go” checkpoints involving humans, and then to monitor, with humans getting notifications only as needed. How we get there may not be so important—or it might.

    In the market, the sand is still shifting too fast for vendors to keep up. In any given implementation, how fast you adopt all the new products is a function of choice. Use controlled chaos, changing things out for the better only when you have a quantifiable benefit and they fit into your overall architecture. Most importantly, no matter which toolset you choose to use to control the check-in-to-release cycle, new tools you introduce should integrate with it.

    So what am I recommending? That you choose a control tool that fits your specific environment and needs, and that you make certain when choosing new tools you have a path to get them integrated with that control tool. Nothing more. Don’t put a tool in charge of half or all of your DevOps toolstack just because it was there. Have a real reason, then use that reason as a gauge when adopting new tools.

    — Don Macvittie

  • From Thought to Leadership

    From Thought to Leadership

    Thought leadership is a term that those of us in the industry hear a lot. A thought leader is a person who has ideas/thoughts that push the edge and brings great ideas to the rest of us. Most vendors want to be seen as thought leaders—and some do, through the agency of rocking individual employees.

    We all benefit from true thought leaders. They dream up new ways to do things (such as DevOps and agile), or find new uses for things (such as adapting agile practices to operations) that, in the long run, we can all benefit from. Good thought leaders (in any space) either look outward and see how what we’re doing today can be used to greater benefit tomorrow, or look inward and make us think about ideas and where we are in accepting them.

    This Isn’t About Talking Heads and Vendors

    The thing is, if you are establishing or attempting to expand DevOps operations in your organization, you are a thought leader. And that’s what I’d like to discuss.

    Those of you who say, “No, not a thought leader; I’m showing how long-established DevOps practices can improve the organization,” are wrong. The key to thought leadership is that you are there, and your audience isn’t. If those long-established DevOps practices were acknowledged in the organization then there wouldn’t be a need for DevOps leaders to establish or expand. Everyone would agree and it would just happen. After sufficient meetings, of course. (The definition of “sufficient” varies by organization and falls somewhere between zero and infinity.)

    In short, a thought leader must simply see what others do not (yet) see. If the audience is internal and resistant, then a DevOps leader is indeed a thought leader for that audience.

    So, What is Required?

    It is true that a big chunk of DevOps is communications. I’m an “automate first, streamline communications after” kind of DevOps person, but acknowledge that the opposite route is also valid. But increased communications are going to be required for long-term DevOps success. Part of that communications is with other managers both in and outside of IT. There is no better time to start than the present, by acting like a thought leader.

    Target the next application/portfolio you think would greatly benefit from DevOps. Sit and refine where you think improvements and/or savings would occur, get the buy-in of line-of-business leaders responsible for the application or portfolio, and go on a PR blitz.

    Thoughts are Great …

    But leadership is better. Be the leader, advocate for what you believe to be right. There are those who will tell you DevOps is inevitable, and it’s not a big deal once there is at least one project in the building doing DevOps. I could not disagree more. Change—any change—doesn’t happen without a champion. If you are in charge of DevOps, yes, take the DevOps Institute Leadership Certification (Disclosure: I have written paid promotional material for this certification. But it’s good material, so I’m mentioning it here anyway), but also look outward. Bring the organization to the table; be visible; be driving.

    But don’t be annoying. Know when to back off, or maybe target a different application first. And know how the existing system reporting and deploying will be mirrored in a full-on DevOps environment, so you can answer important questions such as, “How will we get through test and deploy if we re-target the application?”

    Do I think DevOps is inevitable? No. But I do think it will have a lasting impact on the way we develop and deliver software, even if a particular shop doesn’t claim to be a DevOps shop, deployment automation, test automation, enhanced defect and runtime monitoring, increased communications. These are coming because they’re good ideas. It’s best to have a plan, be a thought leader and get it rolled out so the organization can reap the benefits.

    — Don Macvittie

  • DevOps: Build a Continuous Improvement Culture

    DevOps: Build a Continuous Improvement Culture

    DevOps was built around the concept of continuous everything. We even use it in many of the names—continuous delivery (CD), continuous testing, continuous integration (CI)—and it is a worthy goal to want to improve the places that form bottlenecks in your software delivery systems and processes.

    But what about the bottlenecks in the DevOps systems and processes?

    Like any other system, DevOps involves tools. We choose those tools, invest in learning those tools and use them to do great things. But then we have investment in the tool. If our knowledge and systems for deployment are all based around CD tool X or ARA tool Y, we are just as unlikely to want to move from it as we were unlikely to want to move away from the previous toolset.

    Even if you discount the number of shops that have done pilot or small-team DevOps but kept the core of their business waterfalling, there are still a large number of organizations that stepped into DevOps and stopped improving. Granted, it is a huge job to move a significantly sized application portfolio into the DevOps mold and toolchain, but it is contrary to the process/goals to stop just because you did.

    The market is nowhere near finished evolving: New tools are coming available and massive improvements to existing tools are being released. Keep taking advantage of those facts.

    The more projects/portfolios you have moved into DevOps, the more weight there is to resist change. That is the simple reality, just as the larger a rock, the harder it is to move (assuming the same type of rock, of course). The answer: Watch for those improvements that will make moving the rock worth the force required to do so.

    Working containers into the overall DevOps process, for example, can benefit every step in the toolchain. But if they’re not already in the process, it is a lot of work to get them folded in. I chose this example because for most shops, a little research will show it is well worth the effort. From preconfigured Dev/Test/Prod servers to run-and-done compile instances, containers can make the process more manageable and more agile. The benefits outweigh the costs for most shops.

    So keep an eye out. Don’t implement and spend all of your time on the tools you’ve chosen. Stay aware of what is out there, and what is coming. Understand how it would impact the DevOps process and try to pull in those items that fit the environment.

    And, as always, keep rocking it. The end goal is to keep the systems up, running and usable. And most of you are doing a great job.

    (This, and all blogs, brought to you as much by the geeks behind the scenes as the author and editor.)

    — Don Macvittie

  • Portability Shmortability: Most Applications are Going Nowhere

    Portability Shmortability: Most Applications are Going Nowhere

    I’m a huge fan of the idea of taking our super-duper applications and deploying them where it makes most sense. I always have been. Those of us in application development spent forever bemoaning the fact that our applications weren’t all that portable between operating systems. In fact, looking back through the history of computers, you find there has always been one roadblock or another to stop portability.

    First there was byte order and instruction set, and we’ve largely overcome those. Internationalization wreaked havoc on us all for a while, and we overcame that. We’re still pretty mightily struggling with OS-dependent things such as windowing systems, but browser-based apps have largely overcome those also. Java takes a lot of heat for a lot of reasons, but it did improve portability of apps written in it. Maybe not “Write once, run anywhere,” as was often claimed—things such as file locations were still OS-specific—but still a lot closer than compilers that were deeply tied to the operating system they ran on. Virtualization and containers have enhanced portability in another dimension, letting the developer take the OS with the app.

    We have overcome a ton of issues, and advancing technology has introduced a ton more. Now we have to either choose mobile targets or find a tool we like that can generate code for wildly different mobile systems from a single source. DevOps really isn’t helping with this process—though it will, eventually. By automating the build process, the target will be switchable at the targeting end, meaning our app—given a tool that can multi-target—can be built for whatever mobile platform the cool kids are playing with today, and the ones that are considered “cost of entry” can be generated in the same run.

    So far, so good, right? We find problems, we overcome problems, DevOps helps us overcome them faster with a wider selection of outputs …

    And then we hit the data.

    Vendors in a variety of spaces would love to paint you a picture where it doesn’t matter. It does. The mass of your data, wherever it resides, is a pull like gravity to new application development. And it should be.

    Some will try to explain to you that in the age of APIs, it doesn’t matter where the data actually resides: You can get it.

    But it really does matter, and this is not Utopia. Even if you ignore the performance implications of data being latency-infested miles away from applications that need to use it non-stop, those APIs are only a viable option if the data can be secured and protected. By definition, an API is an advertisement that whatever data/service it fronts can be found right here. For applications that traditionally are data center apps, it might be possible to expose your customer file or other critical data via API and then lock down access to the API by IP …

    But then we quit ignoring the latency problem. If every bit of data an app needs has to flow from San Francisco (or Tokyo, or Bejing, or London, or wherever) to Seattle before the calling app can do what it needs to and then has to be sent off again to Albuquerque (or Rostov, or Madrid, or wherever) the delays will, by definition, be more than they would be if the app sat with the data and had to transfer over a 1GB (or 10GB) connection between servers before sending it to users.

    This means most data-heavy apps, no matter the level of agile or DevOps, aren’t likely to move. Vendors with a stake in the process will trot out the one or two customers they convinced to make such a move to tell you how great it is, but performance math and security sense tell you it is only great until things get busy or that exposed API is used by bad actors to vacuum user data.

    Some applications have smaller datasets and can move the data with the app. Other applications can be architected not to care where the data is. A few don’t need a database at all. Move these applications to whatever platform makes sense. Make the CD for them retargetable.  Most serious business applications rely too much on core data to fall into these categories. And thus, they aren’t moving, unless someone comes up with a viable way to move a ton of data between platforms that is safe and fast and effectively translates where necessary.

    So, that’s what we need to see next in the march of portability. We currently have containers that can be run pretty much anywhere and languages that will work on pretty much any platform. We need data tools that can alleviate the current set of non-portability/latency constraints and get data where it is needed, when it is needed, securely.

    Unfortunately, I don’t see that happening soon. So addressing the issue, “Where do we target our new application?” will have to start with the question, “Where is the bulk of the data it needs?” At least for now.

    Most of you knew that, because you’re living it. I just thought you might have a use for a third-party article about it. Because someday, you will have this conversation with someone who isn’t living it. Enjoy.

    — Don Macvittie

  • DevOps: The Things We Must Stop

    DevOps: The Things We Must Stop

    Anytime there is a popular movement in technology (and I would argue any other field), people get carried away. We’ve seen it over and over, and DevOps attracts this kind of attention. In fact, DevOps caters to those who get carried away by mainstream folks screaming, “THIS CHANGES EVERYTHING!” That type of hyperbole pushes those who get carried away even further. And marketing always takes things to whatever place they have to in order to, well, sell their ideas to the market.

    Rack ’em Stack ’em Robots

    My all-time favorite purposeful over-the-top is the tendency to pretend that prior to the cloud, every project was started with “rack ’em, stack ’em.” This is demonstrably false, as by the time the cloud was taking off, VMware’s market penetration was significant. And yet, the number of blogs/amount of marketing material that starts out with the premise that every application required waiting for physical server delivery and configuration is insanely high.

    No. Enterprises, in particular, had to wait for VM allocation and configuration.

    Another that isn’t really mainstream—and I’ve mentioned in other locations—is the AWS TCO calculator. The simple calculator is not a bad tool, and I’ve used it numerous times in the past, but the TCO calculator makes some assumptions about deployment costs that are a little wild, such as that TCO includes the cost of VMware and its supporting hardware for an individual app. Of course, that’s not how enterprises do it. There is a VMware infrastructure and it is shared across apps. While it would increase the complexity a tiny bit, a simple checkbox that asks, “Do you already have a VMware cluster?” would go a long way—or better, one that asks how many apps you are running on VMware and divides the overhead by that number before including it in TCO. But of course, if you are getting your TCO comparisons from a competitor, expect the TCO will be stilted, no matter who is generating it.

    Oversimplification

    Whether it is infrastructure orchestration or app deployment, there is a lot of content out there that talks about how much easier infrastructure as code will be, and how much less documentation we will need. This, sadly, is a bogus premise. Whether you’re using the 50,000 service offerings of AWS or the power of HashiCorp’s Terraform—or any of half a dozen other competitors—it is complex. We’re not doing anyone any favors by glossing over the complexity that inevitably occurs in enterprise-class deployments, and we’re doing a massive disservice every time someone claims that documentation needs will be less because it’s “self-documenting code.” Self-documenting code sucks without a ton of comments in App Dev, and it’s worse in deployment. Employees new to the process need, and should be provided, solid documentation on how the system works and where different pieces fit.

    We’re deploying complex apps on complex infrastructures with evermore complex compliance and security requirements. It is not simple.

    All or Nothing

    There is a belief among too many aficionados that their way is the “One True Way.” The fact of the matter is that all enterprise application portfolios are complex and there is a metric ton of extant code that must be managed. A startup with one web-based app (no matter how large it may be) or a games developer focused on Android as its only platform might well have agile and DevOps as their only development/deployment methodology. No one else does. The enterprise running a hundred or a thousand different apps on several platforms is not going to flick a switch and say, “We’re all X now,” no matter what X is. Anyone who has tried to standardize the database in an enterprise knows that just doesn’t happen (I did, as an architect in a financial services org. It was ugly).

    Some projects are simply great fits for agile and DevOps—those with a high rate of change, where a little bit of instability in return for rapid feature rollout—while others simply are not—ones that maintain data that must be rock-solid, ones with a low level of change, etc. Any given enterprise is a mix of these things. Back in the days of the language wars, I used to say, “Right tool for the job,” and today, in the days of the architecture/automation wars, I say the same thing. If the project is rapidly evolving and you want lots of small changes in a constant stream, agile and DevOps are the right tools. If the project moves slowly and has an emphasis on stability or data quality, it’s not a great candidate for these tools at this time.

    I’ve talked about some of the bad vendors in this post, so I’ll call out IBM for being a good vendor on this point. Looking at the company’s model for moving the mainframe is a good example of how you could look at all of your IT, because IBM doesn’t say, “This changes everything!” It says, “Here’s how to tell what offers the most bang for the buck in moving to agile and DevOps.”

    Just Keep Rocking It

    Working in IT? You’ve been keeping your org running. Don’t start second-guessing your gut now just because the new shiny is being waved in front of you. Learn, change, do. But don’t rush into something with misinformation. Obey your gut and keep rocking your org’s world.

    — Don Macvittie

  • Continuous Delivery is Not Continuous Deployment

    Continuous Delivery is Not Continuous Deployment

    Every once in a while, it is worth revisiting a topic that flies under most people’s radar. The differences between continuous delivery and continuous deployment is one of those topics. While those steeped in DevOps are well-aware that software can be delivered daily (or even more frequently), deployment is less frequent, and more dependent upon both development and marketing cycles.

    Most CI/CD tools can and do crank out “deployable” apps on a daily basis, or even each time that code is checked in. In theory, each of these builds is a candidate for deployment, and each has had at least some level of testing.

    But setting up the environment to host these apps is a separate step. Quite often today, it is a step that is handled by scripts that configure/move everything to build the app environment into a comprehensive system with knowledge of network, data sources, storage, etc.

    I’m revisiting this topic because new people often hear “CD” and assume that is the end state. Of course, it is not; the application has to be deployed—to Test and Production at least, and in many enterprises to Staging, also.

    While these environments are almost invariably different (Test does not share IP space with Prod, for example), the deployments must mirror each other as much as possible to make Test representative of what Prod will look like.

    As with any step in the DevOps toolchain, scripts to achieve continuous deployment are not a great solution. They are certainly a good first step—automating what previously was done by hand—but tools that make the experience easier and more dynamic are available, and should be considered.

    Whether an explicit continuous deployment tool or an application release automation (ARA) tool (or an ARA that calls a continuous deployment tool, as we’ve seen some used), something to remove dependence on hand-edited scripts is useful for many reasons, starting with the fact that separate scripts are maintained for Test and Prod and changes must be made in two places when a change is made to an application (such as changing where the DB is located or switching to a dedicated AAA server). This makes scripting fragile. Tools can offer shared deployment and custom deployment sections so that multiple changes can be restricted to those things that truly need to be handled separately.

    Deployment is very much a target exercise. The code has been built; deployment is simply giving it a home. Historically, this required agents be strewn about the data center to help target deployments. Increasingly, agentless tools are available that allow the adaptability of continuous deployment while not requiring agents to be installed on every machine that might participate in the deployment activity.

    The other major benefit of moving beyond scripts and into a continuous deployment tool is huge: Everything else is version-controlled, which provides built-in rollback. A developer made a mess of fixing that bug, and things are worse? Roll back the update until the issue can be addressed. Tools such as Git make that particularly easy to do. On the deployment side, the same functionality is required. “Release 7.2 has been deemed to violate GDPR” might require moving back to the previous release. But script-based deployments are always forward-looking. It is enough to modify scripts to reflect the current environment, and it is a rare organization that requires parallel development of backout scripts. However, this functionality comes for free with a continuous deployment tool—that which it has built it can undo, because it is versioned automatically.

    And the benefit of versioning goes beyond rollbacks: It allows multiple version deployments for AB testing and allows for skipping forward and back as far as necessary to meet current goals.

    Is it a panacea? Of course not. Each technology brings new challenges. But continuous deployment solves more problems than it creates. And most of the problems it creates—a desire for greater integration with networking and storage services in non-cloud environments, for example—will be solved in a consistent and repeatable manner by these tools long before any scripting does. Because the tools are designed to create consistent and repeatable results.

    While you are out there kicking it, consider implementing continuous deployment tools to tackle the DevOps last mile. They’ll make your life easier, and your environment less fragile.

    — Don Macvittie

  • Microsoft and GitHub: The Sky is Not Falling

    Microsoft and GitHub: The Sky is Not Falling

    The consternation seen in some corners of the internet over Microsoft’s agreement to acquire GitHub is overblown and too early.

    For those who don’t follow me normally, I am a developer for Windows, Android and Linux. I am also a user of both GitHub and BitBucket. While I am an advocate, I am more of an IT productivity/tools advocate than a pro/con MS advocate. So pretty much, I am IT. I’ve worked in pretty much every IT environment from developing embedded devices to cell phones to apps for smartphones to a raft of enterprises from financials to utilities.

    Until we know what Microsoft intends with GitHub, it makes no sense to go crazy with plans to migrate away from the platform.

    Oh, I could draw up plans to move my company’s GitHub repositories to BitBucket (or GitLab, or wherever), but honestly at this point there is no reason to do so. We (all of IT) have a limited amount of time available, and is migration away from GitHub the best use of that time?

    I argue that at this point, it absolutely is not.

    Stop. Breathe.

    There are things Microsoft could do that would make my company want to move away from GitHub. I do not expect that any of those things will happen. Or if they do happen, it is because they were going to happen anyway.

    Remember, early rumors of this merger started with, “They were working on joint marketing, and GitHub let slip they needed a cash infusion …” needed a cash infusion. That means something at GitHub needed to change regardless of ownership. You don’t go as long and get as large as it has and need a cash infusion, if you’re doing things right. So change was likely coming, regardless of ownership.

    But until we see what Microsoft has planned, expending energy either complaining about it or planning to move away seems like a bad use of your time. As long as git pull still works, and the terms of service haven’t changed, it is much ado about nothing.

    Stay focused on your customers, and keep a wary eye on developments with regards to all of your back-end tools, but don’t waste energy in potentially unnecessary or fruitless exercises. Think about it, and if it becomes necessary, we can all make careful, planned moves when it’s clear that is the proper course.

    — Don Macvittie

  • Don’t Forget to Automate Cloud Security

    Don’t Forget to Automate Cloud Security

    Cloud has been around long enough, and we’ve had enough breaches stemming from unsecured cloud (mostly data objects, but other items, too) that we should know better. I cringe whenever I see a security headline along the lines of “… Unsecured S3 Bucket.” Would you publicly expose a server in your data center and not lock it down? No.

    So, what is the problem? Frankly, “cloud” now consists of so many separate-but-integrated offerings that it can be daunting, even improbable, for security staff to lock it down. Add in dozens or even hundreds of instances/storage locations/routers, and you have a separate data center with different requirements—at least, that’s what it essentially is for your security team. Then add agile and DevOps, spinning up new infrastructure and changing the parts at a rapid pace, and you have a fast-moving, complex data center environment. Yet, if you are a typical organization, your security staffing hasn’t significantly changed, nor do you have requirements for securing the physical infrastructure. In short, same group of individuals, a ton more work to do.

    Before it was purchased by VMware, I had the pleasure of working with CloudCoreo, and truly liked what I saw. The problem in highly automated environments, be they DevOps or just automated, is that a lot of parts are moving as the system is maintained/updated. Some of those parts are changing security settings in a complex (data center-size complex, in many cases) environment. For security teams to keep up and be part of DevOps—or just keep up with automation—quite often corners must be cut.

    That’s bad for all of us—security staff, the company and customers. If anything, when the cloud environment grows complex, security needs to be more cautious, not less. And yet, the number of data leaks/exploits that involve “misconfigured” security settings in the cloud says we have a problem.

    So what to do? One option is to check out security control and auditing software from the likes of RightScale, Dome9 or Evident.io. (DISCLAIMER: I have not used any of these tools. They were chosen because each shares attributes with CloudCoreo, which I have used.)

    The ability to scan and apply policy to a broad array of cloud artifacts—from users to back-end storage—is essential in allowing security to keep up with DevOps. There is just too much change in a fully automated cloud-based environment to expect security to keep up without the same level of tools as developers and ops get. “Shift left” doesn’t stop misconfigurations, but scanning can detect them, and some tools can even auto-fix those misconfigurations.

    In the end, protecting systems and data is what the security team does. Bringing them along on the DevOps grand tour and offering them the same type of automation opportunities as the rest of IT is benefiting from is mandatory. It is not “would be nice to have” to give security the chance to keep up; it should be a requirement.

    And you might still have rogue S3 buckets that security doesn’t know about that might be misconfigured, but any that are paid for by the corporation will be available to security and those automated tools and, thus, will be locked down.

    And if security isn’t enough of a reason for you to want to implement one of these tools, “Come for the compliance, stay for the security.” Most solutions offer auditing that helps with compliance.

    — Don Macvittie

  • Continuous Testing and Business Assurance

    Continuous Testing and Business Assurance

    As development moves ever faster, continuous testing can help further reduce the risk of introducing errors

    In IT circles, “risk management” implies information security. But in the business as a whole, risk management is a function that spans the organization. The risk that an application will negatively impact corporate image, sales or employee morale is very real in the age of automating everything.

    Once properly identified, these types of risks can be mitigated with continuous testing processes. The ability to set up a test to prove the login system works as expected keeps users able to get to the application.

    Increasing use of agile and DevOps offers the opportunity to receive rapid feedback. Among other things, that includes business (as opposed to InfoSec) risk management. Requirements from the business side can clearly delineate items that create risk for the business unit and the requirements to reach desired outcomes. Continuous testing can turn those requirements into tests that validate the application is not contributing to business risks.

    After all, there are enough risks in the business environment: competition, suppliers, coordination of marketing, legal, etc. Making application development less of an issue is good news for business owners and IT alike.

    By translating business risk management requirements into automated tests early in the development process, stability and risk aversion are built into the application from (or nearly from) inception. This offers stability and provable correctness in the application development cycle.

    As the pace of development continues to accelerate, there is a risk of negatively impacting the user experience. Whether that negative impact be through failures of critical parts of the system or degradation of performance, it harms the application and the business it supports. Continuous testing can help alleviate fears by testing for these scenarios and pointing developers at fixing them early.

    Test automation tools are becoming more prevalent, and the next step is to include business requirements designed to mitigate business risks at every step in the process. It is simple to say and test “valid users must be able to log in,” but as development progresses, if the login prompt takes more than 10 seconds to return, that adds the “in a timely manner” business requirement that is then refined by IT to a number, and a new test is run. Only by having the inputs from the business at each stage can such refinements be identified and implemented.

    Interested in this topic? Check out the ebook here to hear from experts on balancing speed of development with risks to the business.

    And consider it. The purpose of any given piece of software is to serve the business. Speed that introduces unwarranted risk to the business cycle is not the best answer. Continuous testing, and attendant business owner involvement, can mitigate those risks.

    — Don Macvittie