Tag: enterprise devops

  • ‘DevOps in the Multicloud World’ Virtual Summit Puts IBM Z in the Spotlight

    ‘DevOps in the Multicloud World’ Virtual Summit Puts IBM Z in the Spotlight

    Got mainframes on the mind? Wonder how you can unlock the value of the platform for mission critical workloads? Trying to figure out where IBM Z fits in an increasingly cloud native IT environment? Those questions and others will be discussed in an upcoming virtual summit that explores the role of IBM Z —within the context of delivering higher efficiency and greater productivity for hybrid multicloud environments.

    “DevOps in the Multicloud World” virtual summit is scheduled to take place Oct. 24, starting at 10 a.m. Eastern. The day-long event features a passel of IBM experts, partners and customers sharing their knowledge and offering a deep dive into how to build and manage hybrid applications for agility in a multicloud world of continuous delivery. Panels and presentations will be held on a multitude of topics ranging from open source and DevOps to provisioning and user experience—all with a focus on the IBM Z systems.

    In addition, IBM customers will discuss how they’ve successfully included IBM Z in their multicloud strategies to improve their operations and bring real value to their end-user customers.

    Featured speakers include:

      • Barry Baker, Vice President, IBM Z Software
      • Rosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps, Member of the Academy of Technology, IBM
      • Mike Fulton, IBM Distinguished Engineer, CTO Enterprise DevOps, IBM Systems
      • Keith Wilson, Principal Technical Architect, USAA
      • Patrick Wawrzoszek, Senior Programmer Analyst, Scotiabank
      • James Gill, Mainframe DevOps Engineer, Triton Consulting (Lloyds Banking Group)
      • Arun Sharma, Product Manager Core Banking, DXC Technology
      • and more….

    In between sessions, attendees can roam the virtual conference hall, where they can chat and socialize with other attendees including IBM staff, and visit the virtual expo floor, featuring virtual solution zone stands equipped with video, downloads and even prizes for attendees.

    Perhaps best of all? Because this is a virtual event, you don’t have to leave the comfort of your own environs. Feel free to log in wearing your pajamas, even—we don’t judge!

    This event is free, but space is limited, so register now to reserve your spot today!

    — Charlene O’Hanlon

  • Take the 2020 DevOps Institute Upskilling: Enterprise DevOps Skills Survey

    Take the 2020 DevOps Institute Upskilling: Enterprise DevOps Skills Survey

    Everyone is talking about upskilling but how do you know which skills are considered a must-have, nice to have and not as important these days? What are the hiring trends within the industry including the most sought after roles and plans? With the vast array of tools, technologies, process frameworks and human/soft skills, it is daunting to try to establish a meaningful enterprise upskilling program or personal upskilling strategy.

    DevOps Institute published the first-ever “Upskilling: Enterprise DevOps Skills Report” in 2019 based on a detailed global community survey completed by over 1600 respondents. The results were very deep and insightful. The 2019 Upskilling report provided the DevOps community with a solid benchmark on the state of DevOps skills across those categories. But once is not enough in a rapidly changing skills landscape. It’s time to do it again in order to analyze and validate the data year over year.

    The 2020 Upskilling: Enterprise DevOps Skills Report survey is active through December 20, 2019 and the second annual report will be published in early 2020. The new survey builds upon the 2019 report to help IT professionals understand the skills they need to become more T-shaped, by supplementing their depth of specific knowledge with a range of general knowledge. Further, it helps IT professionals understand the specific disciplines that will best fill the top of their “T.”

    We are once again honored to have organizations such as CloudBees, Continuous Delivery Foundation, Urban Code and others sponsoring and supporting this important project. The second annual Upskilling report will publish in February 2020. You can read the full press release here.

    Let’s never forget upskilling is a purely human endeavor. We need the help and support of enterprises, individuals, vendors, consultants and influencers. Please help DevOps Institute fulfill its mission to advance the human elements of DevOps by completing the survey and sharing the link with your friends, colleagues and community.

    Your effort will also go to a much need charitable cause. We’d like to do our part to help the under-served pockets of youth around the world and to that end, we’ve identified a global charity that aligns with our vision, Teach for All. We will contribute $1 for each completed survey and we are aiming for 5,000 participants.

    Teach for All tackles complex challenges facing children in disadvantaged communities as millions of children lack the education, support and opportunity they need to thrive. Teach for All is developing collective leadership to improve education and expand opportunities for all children, so they can shape a better future for themselves and the world around them.

    Every donation, no matter how small, can make a huge difference and we are happy to contribute on your behalf to thank you for your participation with the 2020 Upskilling Survey.

    Your participation is valued, and it helps support a great cause. Take the survey and share the link with your colleagues today!

    — Jayne Groll

  • DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    Adopting DevOps means changes from how you build software to organizational processes and cultural behaviors. Large enterprises have even greater challenges to overcome, including supporting a large number of applications and addressing technical debt while also taking on new development initiatives like digital transformation.

    What can we learn from experienced DevOps practitioners?

    In this DevOps Chat we spoke with Mark Levy, director of strategy, software delivery at Micro Focus, covering seven keys to successful DevOps implementations at large enterprises.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, we’re tackling the topic of large enterprise adoption of DevOps—no small task, for sure.

    I’m very happy to welcome Mark Levy from Micro Focus. Mark, welcome.

    Mark Levy: Thank you, Mitch, and glad to be here.

    Ashley: Would you just tell us a little bit about yourself and what you do at Micro Focus?

    Levy: My name’s Mark Levy. I am a director and working in the product marketing organization, and I focus a lot on strategic marketing initiatives as an evangelist, a DevOps evangelist. I develop and write content and commentary about the DevOps market. I’ve had a 25-plus-year career, and like many people, I’ve had many positions. I started out as like a sysadmin and was a developer and managed dev teams.

    But, in 2007, I started to focus exclusively on application delivery. And so, that has been—this whole area of application delivery, software delivery is something that I’ve been really focused on for the last 10 or so years.

    Ashley: Well, tell us briefly, a little bit about Micro Focus. Not all of our listeners might know what you all do.

    Levy: So, Micro Focus has also gone through this major transformation over, I would wanna say, the five to eight years or so. You know, we’re a global enterprise software company. We were established in 1976, we have 14,000 employees and 40,000 enterprise customers, about 4,800 software engineers, and we really focus on large enterprises, helping them run and transform their business. We have sort of focused on four key areas of how do we support our customers through their digital transformation journey, and enterprise DevOps is one of them.

    Ashley: I imagine that our folks, listeners that are from large enterprises are gonna be particularly interested, and I’m sure there are learnings and information that will be useful to other folks as well.

    So, you talked about playing in the space with large enterprises. I imagine that’s probably some global international companies, maybe some that are both European or U.S.-based as well. How would you describe how you differentiate what you do as Micro Focus as compared to other folks? There’s a lot of companies, of course, working to try to help enterprises adopt DevOps.

    Levy: Yeah, of course. And that’s sort of what I’d like to do first maybe is just sort of set the stage, because I always look at this, especially in the enterprise IT world, it’s so interesting. You know, Gartner made this sort of—you know, their strategic assumptions. And they said something like, through 2021, at least 80% of the DevOps initiatives will fail.

    Ashley: I have not seen that, no. Interesting.

    Levy: I don’t know if you’ve heard that, but—yeah. So, it’s interesting. What does that tell me—tell us, I believe? One is, the business is already in the fight. The enterprise, the business side is already in this digital economy and fight. We see that on the streets.

    And the other thing is, you know, IT is sort of behind the curve. And the reality is that our customers, the IT customers, the IT organizations have this incredibly complex hybrid landscape, it spans mainframe, mobile, on-prem, off-prem, and while the principles—the main DevOps principles—are similar to what the unicorns, so to speak, are delivering, that it’s really a whole different challenge.

    Because what’s critical is that there’s this above the line mandate to drive new digital revenue, but at the same time, you know, optimize the enterprise. And, you know, I sort of—I like one of my colleagues, his reference. It’s like, redesigning a jet plane while you’re flying it, you know? And so, I think that’s how, you know, what’s critical with large enterprises is that they’re trying to transform themselves and at the same time run the business.

    Ashley: Yeah, I would almost describe for a large enterprise, it’s like trying to build or transform the entire fleet of planes while you’re building it.

    Levy: Yes! Exactly.

    Ashley: Talk a little bit about—I mean, we all, I think, can appreciate in every business, especially large enterprise, they’re saddled with technical debt; they, of course, are working on operational efficiencies; they have applications that they’re trying to support and maintain.

    How do they take on something like a DevOps initiative successfully, as you were pointing out earlier, so that it doesn’t just stop at one group and kind of fall off from there, they really wanna be able to transform their part of their business? How do you do that?

    Levy: Right. So, I think one of the key things that we focus on enabling our customers to build on what already works, okay? They have all these core investments, and how can they take their core investments and leverage the ROI that they’re already having today, but implement new technologies and DevOps practices and capabilities? And I think that’s critical. I mean, how do they implement and scale DevOps practices, for example? It’s very, very important, and it’s hard.

    And so, we look at it from the basis of, how can our solutions and our products help them really get from point A to B? What is their current state now? Which is what they really need to understand. And it’s amazing how many companies really don’t have a current understanding, detailed, of their current state.

    Ashley: Mm-hmm, or a common one. [Laughter]

    Levy: Or a common one, because, you know, it changes a lot, but how do they deliver value to the customer? You know, what are their value streams, and what are the processes and the flow of artifacts? And so, they need to understand their current state.

    And then, they need to do a number of things that I know the people that are helping the DevOps community, the DevOps community have been evangelizing for a while—I think critical, especially in large organizations and enterprises, you know, they need to first really create this culture of continuous improvement. I think that’s critical.

    Ashley: Okay.

    Levy: You know, they need to enable, motivate and empower the teams, and the leaders really need to get on board, right? Without the leaders, it just will not work.

    Ashley: Yeah, I can speak from personal experience—instituting a continuous improvement culture is no small task in and of itself.

    Levy: Right, and you know, the thing is, the leadership style must also change, right? I mean, command and control really doesn’t work, decisions—it’s about empowering your product teams to drive as much decision making as possible. And that sort of has gone contrary to, you know, the organizational structure of the large enterprises.

    Ashley: Mm-hmm.

    Levy: So, that, I think, you know, is one of the critical challenges that these companies are faced with. Edward Deming made a great quote, “A bad system will beat a good person every time,” right?

    Ashley: Mm-hmm.

    Levy: And when I think of a bad system, I think, in its largest sense, the system. And this is where I think Micro Focus can help quite a bit is, anyone wanting to change this culture really needs to define the actions and behaviors that they desire and then design sort of the work processes that are necessary to reinforce those behaviors.

    So, you know, systems, processes, tools, help with and enforce good culture. But you know, if you have a bad system, it’s not gonna work. So, I think, you know, these are areas that we can help on the cultural side. I come back to thinking about the idea that, you know, sort of the general friction between dev and ops teams, where ops teams are really, initially, only measured by mitigating risk, and dev teams are only measured by delivering change. You know, there’s the conflict that has to be resolved. That’s critical.

    Ashley: You’re talking about culture; the other thing that occurs to me is, there can also be inherent or built in incentives that are counter to the culture that you’re trying to create. That friction is a good example for one. But, you know, there may be past punishment for failures or, you know, emphasis on down time, so the answer is always minimize change or whatever it might be. You’ve gotta take those things head on.

    Levy: Exactly, yeah. And so, I think, you know, you ask sort of where people start. I think, you know, you need to start—and everyone, a lot of people talk about this, and it is true. You really need to start instituting this culture of change, because DevOps drives a lot of change. It’s a transformational journey in the enterprise.

    Ashley: When you said, the number one thing you said was, “Leverage what works.”

    Levy: Yes.

    Ashley: What do you look for? What kind of things are you trying to say, “That’s a practice you do well, and let’s keep that, or let’s build upon that”—what do you look for?

    Levy: Well, you know, I think about, there’s a lot of legacy systems, core investments that these large enterprises have had and invested lots of money and time into it. And take, for example, COBOL, okay? That language, I think people are not necessarily aware how invasive it is. There’s still about 250 billion lines of COBOL around, right?

    Ashley: Mm-hmm, mm-hmm.

    Levy: It drives 70%, they say, of all business transactions—still, in the world.

    Ashley: That’s amazing.

    Levy: It is amazing.

    Ashley: [Laughter]

    Levy: And so, you know, I’ll give you an example of sort of what we’ve done and we’re, you know, we are very good at managing and understanding those environments. We have, you know, that’s a big part of our business. So, we can, you know, lift—if we can lift and shift, you know, COBOL workloads off of, you know, sort of the more legacy platforms into, let’s say, AWS, you know, that’s a big win for our customers.

    As an example, we had one customer that basically had—it was a major global insurer, had about eight different IT environments with a back end COBOL app sitting on the mainframe and then front end and WebOps. And basically, each environment cost about $3 million a year. And, to request that environment, to provision that environment, took six weeks.

    Ashley: Mm-hmm, mm-hmm.

    Levy: And so, we built, through our solutions, we were able to lift and shift that workload to AWS and reduce the cost from 3 million to 120K and reduce the provisioning time from six weeks to two hours.

    Ashley: And I wanna mention, too, to our listeners, too, we just had a webinar in the last week talking about mainframe APIs and frameworks specifically to mainframe environments to make it a little bit easier to adopt WebOps. So, though it doesn’t get the kind of sex appeal that necessarily new technology does, it is a huge, huge issue for enterprises and how do you bring the mainframe environment with the rest of the cloud and everything else.

    Levy: Right, it’s—you know, back to the theory of constraints. I mean, in your value stream, if—you know, you can develop and you can be an agile team, but if it takes six weeks to provision, you know, your mainframe environment?

    Ashley: Where do you suggest people get started? Is it go pick a new, from scratch greenfield project, or pick something that’s, you know, reasonably mission critical so we’ll get the support?

    Levy: Yeah. Well, I think one is, I like, initially, to set up a lab, like taking a greenfield. You need a place to learn. A lot of these things aren’t easy, or they’re not, people are not, the teams are not used to. So, like, I love the idea of what a lot of the community’s doing with DevOps dojos and building sort of a team level, maybe CI/CD, have a place to experiment and take that.

    But then, you know, ultimately, in large enterprises, they’re gonna come up. They might get easy wins early, right, but the challenge is, once they scale, they’re gonna run into some of the more challenging times. And that’s where, back to what they have to really start doing is taking this broader, system level view of the enterprise.

    So, you know, if they understand how they’re delivering value to their customers—and in enterprise, there’s many ways to do that—then they need to understand and prioritize according to the business objectives. Let’s say one business objective might be, we need to recapture value. Maybe our IT budget isn’t really growing, but we need to drive for more innovation. So, we need to—our objective is to recapture that value and redeploy it into delivering value and innovation. And so, that would drive a lot of your decisions in where you optimize.

    Ashley: Speaking of budgets being flat or not growing, digital transformation is all the rage, that’s what many, many companies are taking on, not just in customer experience, but across the enterprise, bringing them into the digital world. How does that fit on top of this if you’re trying to introduce DevOps?

    Levy: I don’t see how they can really run their digital transformation without DevOps. I mean, software today—you know, I talk about this a lot where business innovation and software innovation are generally becoming one and the same, right?

    Ashley: Mm-hmm.

    Levy: And going quick, innovating faster with less risk is critical. And so, IT is, you know, it’s imperative to really deploy DevOps practices to support the digital transformation of the business. So, I think, you know, the IT organizations that implement DevOps, those people are the drivers.

    Ashley: Well, and it’s hard to imagine how you were gonna transform systems and applications you already have as well as ones you might leverage as SaaS services or create yourself without an environment to integrate those altogether due to continuous integration testing, etcetera, as well as be responsive to the business.

    Levy: We’ve seen enterprises, they will typically start out, right, with their team level implementation and they might do really well, and it might be a greenfield app. Maybe it’s a new growth app, which is great, and they may get some early wins, which is super, but it’s still not their core business.

    Ashley: Mm-hmm.

    Levy: And so, they have to, ultimately, really transform their core business in order to be competitive in the market.

    Ashley: Mark, what’s the one thing organizations should not do when they’re looking to adopt DevOps—don’t make this mistake?

    Levy: I think the idea that they can just automate their way out of it, I think, is something that could get them in trouble. Because, you know, really leaving out the whole cultural aspect of it, it really is—you know, it’s interesting, if you read Jeff Bezos’ letter to shareholders every year, he just provides some incredibly insightful, you know, insights on how Amazon runs. He talks about this accelerated decision making process that they run, and they make these decisions, really, based on only 70% of the information that they need, basically. Whereas, large enterprises wait until they typically have 90%.

    And so, they are able to make decisions earlier because of the agility that they’ve built into their system and their culture of change. And this allows them to not only, you know, get earlier into the market, but it allows them to—everyone, it allows them that if they make a mistake, they can recover from their mistakes faster, and the cost of making a mistake actually goes down.

    Ashley: Mm-hmm.

    Levy: But this whole idea of organizational agility and providing that—there’s more than just delivering value faster to the customer, because it’s never a straight line, right, to success. So, we make a lot of mistakes and wrong turns in our journey, and being able to identify that quickly and have the agility to correct that quickly is actually more of a differentiator than just delivering fast.

    Ashley: It’s certainly required for any kind of agility. It’s not just getting things and getting decisions made faster, but changing when things aren’t headed in the right direction—or change.

    Levy: Right, right. And so, this is where, you know, if people are looking at DevOps, they’re saying, “Okay, well, we’re just gonna automate the deployment pipeline and we’re done?” No, there’s no “done,” it’s about really, ultimately, improving as an organization, right, and having that continuous improvement, the Kaizen kind of mentality of the organization. And that, to me, is what is so transformative as a company.

    Ashley: Going back to what you said in the beginning about having a culture of continuous improvement.

    Levy: Yeah, absolutely. And that, it would be, you know, frankly, the most powerful thing leaders can do—is that change. Because it really just changes the whole business. The business, then, gets more confidence, which is critical, right? With all this change, sometimes they’re not confident to make business decisions, but if you can provide them the confidence to go out there and really be aggressive, you know, that’s—you’re gonna see, you know, a whole bunch of positive results on the revenue side, on the public side of the business that’s been driven from, traditionally, the back office IT organization.

    Ashley: Well, Mark, I’d like to thank you. I’d like go for another 30 minutes, [Laughter] but I’d like to thank you for the time on the podcast. You know, I walk away with several things from our conversation. The things you shared that I heard were leverage what works, define your current state, create a culture of continuous improvement, command and control doesn’t work—you’ve got to empower product teams. Start with a lab or a dojo, some learning environment. I think your premise of, you can’t do digital transformation without DevOps is pretty intriguing. And last but not least is organizational agility, being able to make decisions quicker, get out ahead of things without having to have 100% of the information, kinda the Amazon model.

    Well, and that should wrap things up. I’d like to thank Mark Levy from Micro Focus for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat.

    — Mitchell Ashley

  • DevOps Hiring: What Do You Need?

    DevOps Hiring: What Do You Need?

    IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”

    But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.

    If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.

    Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?

    Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.

    And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.

    It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.

    And get the best people for the job. After all, you are going to have to work with them.

    — Don Macvittie

  • Can You Implement DevOps in Large Organizations?

    Can You Implement DevOps in Large Organizations?

    Trying to modernize workflows through DevOps can be a challenge for any company, but there are different challenges, risks and benefits for bigger companies

    It is now more or less standard procedure to implement DevOps principles in startups or smaller companies. But what if you’re trying to utilize DevOps in large organizations? This is a bit more challenging, but let’s take a look at how such enterprises might approach a DevOps transformation through a few of the core tenants of DevOps.

    Rapid Feedback

    There are different types of feedback that come with DevOps: automated feedback about specific code (typically through unit and integration testing software), personal feedback from other team members, consumer feedback from customers using your product and cross-team feedback throughout the organization. Startups and small companies may find it easier to have open lines of communication between individual team members as well as across teams.

    Large organizations will need to make a conscious effort to keep team communication open. On the other hand, they will have more resources available (both money and employees) to field customer and in-house feedback about individual services or larger products. They may also be able to better purchase and implement automated testing and CI/CD tools, which leads to …

    Automation

    One of the biggest tech benefits to a DevOps approach is automating away the manual tasks that bog down critical projects. Large organizations often have the time, money and people to set up automated tools, such as CI/CD pipelines, unit and integration test suites and config management systems. The biggest challenge in the enterprise world is trying to make everyone happy.

    One approach is to standardize on a single tool for each purpose, such as Jenkins or Chef. This can enable your IT staff to specialize in those tools but may make some users unhappy with being forced into a tool they may not prefer. The alternative is to allow each team or business unit to use their own preferred software, but this can turn into a “toolset hell” with a mashup of every combination of applications within your organization. Each approach has its pros and cons, and often comes down to a management decision.

    Eliminating Silos

    Having individual teams that handle their part of the puzzle and nothing else is the biggest hurdle that enterprises face when trying to apply DevOps principles. The combination of “dev” and “ops” (and other disciplines, such as “sec” and “fin”) is naturally split out in a large organization, so recombining them can be a huge undertaking. Then again, that gap is exactly the problem the DevOps approach seeks to solve.

    Some companies solve this by having a separate team that handles the cross-team support and communication. Other companies break down these silos by enabling employees to migrate seamlessly between teams depending on the project or application. The more “DevOpsy” method is to utilize ChatOps and centralized documentation repositories for open communication and collaboration, which can help break down unify the distinct teams.

    Holistic Thinking

    The idea of holistic thinking tends to come easier to larger organizations, as successful enterprises typically have a system in place for “big picture” thinking, either through a management or product team, or through a cross-functional committee. That said, communication of this vision down to the employees, along with communication up to that management team, is crucial for enabling outside-the-box thinking to get past any roadblocks and hurdles that are in the way of creating and deploying the end product. Sometimes, the hardest part is convincing programmers that not everything needs to be solved with code!

    DevOps in Large Organizations: Challenging but Rewarding

    Some folks think that DevOps only applies to startups and small companies, but we’re seeing more and more teams benefit from implementing DevOps in large organizations. The benefits of the above DevOps principles are numerous, but frequently come with a different set of challenges based on your organizational size. Once you are aware of those challenges and have a plan to overcome them, you can start to transform your enterprise to a DevOps shop.

    — Jay Chapel

  • Dev vs. Ops Needs for Large-Scale Version Control Systems

    Dev vs. Ops Needs for Large-Scale Version Control Systems

    Distributed version control systems (DVCS) such as Git (introduced in 2005 by Linus Torvalds, the creator of Linux) rapidly gained worldwide acceptance by the global software development community. DVCS offer very fast, lightweight and local software change control capabilities that support many parallel code branches across large project code bases. These are compelling benefits for individual developers and development teams. At their heart, DVCS accomplish this by tracking software changes as a series of file system snapshots in local repositories instead of via management of individual file changes in a central database. “A Short History of Git” explains this in more detail.

    The DVCS approach is ideal for individuals and small agile teams because it puts control directly in their hands without the need to transact all file changes with burdensome systems that were designed using a central management paradigm.
    However, the distributed approach taken by DVCS has historically presented challenges for operations, especially when large-scale enterprise software systems consisting of components from many separate repositories need to be managed and controlled. Enterprises with many developers, large source or binary files (e.g. graphics, audio or video), many artifacts or many large containers need granular end-to-end version traceability. Enterprise-class support requirements exceed the original design intentions of DVCS.

    End-to-end software version management offerings that on one hand leverage efficiencies of distributed systems for developers yet still support scalable operations are required to address the needs of Dev and Ops communities in enterprises with large software version management needs. These complementary requirements have driven the evolution and best practices of large-scale hybrid version control systems:

    • Simplify builds and manage complex projects by organizing multiple repositories
    • Move code and build assets into the DevOps pipeline quickly
    • Improve performance for remote sites by using a central system as a proxy/cache
    • Speed up many activities at the system level, such as cloning and copying code
    • Implement a seamless workflow that incorporates assets such as large graphics and binaries, in addition to source code

    Related Content:

    35+ Tools Every DevOps Expert Must Know

    Automation: Achieving Faster Rollouts with Better Accuracy


    As stated, historically, these were problems that could only be addressed by a centralized version control offering. DVCS alone simply couldn’t handle the large-scale continuous integration (CI) and operations requirements of large-scale software development communities. While there are still inherent issues in the way DVCS manages large binary assets, select vendors have begun to tackle the problem by mirroring DVCS repos in real time, which marries the developers’ need for easy branching and local control with the operations team’s needs for faster and more efficient builds.

    For enterprises developing complex software incorporating both binary and text-based assets, large-scale enterprise hybrid version control systems with supporting both distributed and centralized structures offer a best practice solution. They provide capabilities for a global single source of truth, replication of all types of artifacts and manage versions of everything from planning to release. By resolving operational management problems resulting from sprawl of individual Git repositories, while at the same time preserving benefits of distributed systems, today’s enterprise-class centralized and/or hybrid version control systems can meet the needs of both Dev and Ops without sacrificing efficiency or operations control.

    Summary

    What do you think? Do you agree that the benefits of hybrid versions control systems listed above are important to achieving large-scale version control? Are there other solutions you recommend?

    — Marc Hornbeek

  • Avoid Crashes: 5 Best Practices for Load Testing

    Avoid Crashes: 5 Best Practices for Load Testing

    Demanding customer expectations and the rapid distribution of information across social media have made website and applications crashes an off-limits path for today’s companies and organizations.

    Crashes resulting from traffic spikes cause immediate and long-term loss of sales, as well as tarnishing the brand name. When servers or websites go down during highly anticipated events such as Black Friday, the Big Game or before a major concert, the repercussions can be permanent.

    Yet, avoiding the “website temporarily unavailable” screen is also easier than ever before. By performance testing your website continuously and proactively you can easily detect errors, bottlenecks and bugs, and then fix them to ensure your website handles any amount of traffic.

    Here are five best practices for load testing your website or app:

    Define Your Load Goals

    Before starting your tests, you need to figure out what it is that you need to test.

    This includes the number of concurrent users, traffic patterns and areas that users can visit on your site. For example, if your site has 10,000 users concurrent at its peak, but  3,000 arrive in the morning and that total slowly climbs up to 10,000 in the afternoon—and these visitors mostly just browse your homepage—you’ll need to run a different test than if you have 10,000 concurrent users on your website all day long, constantly browsing multiple pages.

    To determine your load goals, you need to engage directly with your business colleagues. For instance, get your product manager to set the system’s expected abilities, ask the marketing team to inform you about any special campaigns that might increase website traffic, and then look at server logs and tools such as Google Analytics to determine previous customer patterns.

    Choose Your Load Testing Tools

    There are multiple open-source load-testing tools that you can use to run your tests.

    JMeter is the most popular tool, but you can also use Gatling, Locust, Tsung, The Grinder or Selenium. See here to learn more about the differences between these toolsets.

    Does this seem complicated? Taurus is an open-source automation test framework that simplifies running these tools, by using a simple YAML script. If you need to run your tests from the cloud, utilizing rich analytics or requiring user collaboration, you might consider using BlazeMeter.

    Take Your System to the Limit

    To make sure you stand up to your load goals, you need a buffer; specifically, you need to make sure that your system can handle heavier loads.

    This ensures that the CPU stays low and you don’t experience memory leaks. However, we also recommend you take your system to the limit and see when and how it fails. This ensures that you know exactly what your system’s weaknesses are, giving you a better ability to fix any errors that might occur.

    This is especially important if you come across an unexpected traffic spike—say, if your competitor’s website crashes and all their customers come running to you. Wouldn’t you rather be prepared for that?

    Monitor Test Results

    Set aside resources for looking at test results.

    Examine KPIs including Response Time and Hits/s, as well as the correlations between them, to learn what your system’s abilities and bottlenecks are. This information will help you see what needs fixing.

    As you continue testing over time, you will be able to identify KPI trends, which will help you monitor system health. We also recommend you monitor backend KPIs like DB Queries, with APM tools.

    Test Again

    So, you’ve tested, you’ve analyzed, and you’ve fixed.

    Now you have one last thing to do: Run your tests again to make sure everything is working smoothly after the committed changes. That ensures nothing gets overlooked. It would be a shame if all your hard work went down the drain due to a minor oversight.

    Now, let’s get testing!

    To get more load testing tips, check out this free whitepaper, “How to Ensure Your Website or App Won’t Fail at Peak Times.” To learn more about BlazeMeter, request a demo.

    — Noga Cohen

  • When DevOps Disrupts DevOps

    When DevOps Disrupts DevOps

    As longtime readers of my blogs will know, one of my hobbies—when not writing about or playing with technology—is modeling. There is a similarity between quality tech work and quality modeling, but the brain power involved in modeling is much less, leaving me time to think about tech issues or listen to audiobooks (when I’m not listening to music, anyway).

    In modeling, as in tech, there is a process. The process varies based upon what you’re working on, but is largely the same, with some steps slightly different or skipped altogether and others taking longer. At the moment, I’m building the first day of Gettysburg from the American Civil War, but I simply enjoy modeling—and wargaming with the models, but that’s a separate story for a hobby-focused blog.

    The thing is, that process is nailed down, and to the extent it can be, is automated. One step leads reasonably to the next, and while one step is completing on a given model (glue or paint drying, etc.), there is an opportunity to advance a separate project.

    Sounds a lot like DevOps, doesn’t it?

    The thing is, every once in a while, you will get something that is so different, it totally interferes with the carefully planned flow. My current primary project is a little over 300 figures. While one unit is getting the final two coats of finish (that are basically the same or every model), the next unit is getting primed. Assembly of all the figures came first, so there is only the priming step before painting can commence.

    Picture, but you missed it.
    Piper Millin and Lord Lovat cross Pegasus Bridge.

    But here is a work-in-progress picture of Pegasus Bridge. This came as a complete set, and took a large chunk of time to get together, find the correct water for, get placed on foundation boards, etc. This is outside the normal process of assemble/paint/base figures and vehicles. The set is beautiful, and even this picture, which was taken well before completion and only to study color and weathering effects versus reality, shows how truly nice the model was. But it totally disrupted the process flow.

    DevOps and Multisystem Installations

    That’s what complex system installations such as Hadoop or OpenStack do. You’re installing across multiple systems, configuring them for load-sharing and communication, and doing it by hand is a long process that interrupts the normal DevOps flow. Crafting scripts to install them is possible but highly complex and frustrating, simply because of the complexity and interrelationship of the nodes in the system.

    Having installed both by hand, and installed both with tools designed to make it easier, I will happily tell you that yes, you will understand more if you do it by hand, and no, that immediate understanding is not necessarily worth the cost of weeks or months figuring it out and getting it installed.

    You see, to operate these systems, you will need much of the knowledge you would gain hand-installing, so you’re going to learn it either way. Your choice is a simple one: Get a working system and learn by tweaking settings or swapping nodes in and out, or have no working system and learn by the frustrating process of trying to figure out what you’re supposed to do next, and why that step is failing for your specific hardware.

    DevOps and Multisystem Maintenance

    The only real problem is that it is painful to maintain these systems. It’s not as simple as

    yum update [[packagename]]

    because that would only upgrade one package on one system. But these tools span multiple systems, and even just dependencies generates a massive list for each system in the cluster. Seeing the need, most of the traditional application provisioning tools (Puppet, Ansible, et al) have built or cobbled together solutions that will get the job done. But custom solutions exist for these products, too. The problem is that, like Pegasus Bridge, as beautiful as they are they disrupt the DevOps flow. No system goes without exceptions, and I’ll go out on a limb and say that custom solutions to install and maintain solutions such as Hadoop and OpenStack are worth having yet another tool in the DevOps tool chain. The trend is multipurpose tools to be used on many projects, but the importance of a cloud or big data cluster in your IT operations makes them worth the extra tool. As long as the extra tool reduces the amount of work and the chances for human error (which, in my opinion they do—it is kind of their selling point).

    That Leaves Time

    These tools (a good example, though in general I won’t be talking about the competing vendors here, is the Mitaka-based release of Mirantis) allow not just installation but also ongoing management of the OpenStack cloud or big data cluster. That means there is less nitty-gritty for DevOps (or operations for that matter) teams to worry about, freeing time for working on what actually gets built on top of these powerful platforms. Cloud and big data both are just enablers for more functionality when looked at in the right light, which means more work (and often more meaningful work) for DevOps teams.

    When you consider either of these technologies, check out what’s available for installation and maintenance, even if it is outside your normal DevOps tool chain. Like Pegasus Bridge, the change is likely to disrupt you for a bit, but once you have a tool and process in place, it will just be something that happened—and was going to happen with or without the tools. They just make it less painful.

    — Don Macvittie

  • Webinar:  Lesson Learned  in Scaling Enterprise DevOps

    Webinar: Lesson Learned
    in Scaling Enterprise DevOps

    DevOps is evolving into a major enabler of business innovation. If done well in a consistent, scalable and repeatable manner, it can accelerate digital transformation at an enterprise level. But crossing the chasm from successful DevOps pilots with two-pizza teams to enterprise-wide adoption remains a challenge. Join this live panel session featuring guest speakers from Nationwide Insurance, South African Revenue Service and IBM as they share their unique challenges and best practices in scaling-up DevOps adoption as well as steps you can take now to assess your own organization’s readiness.

     RECORDING

    SLIDES

    [slideshare id=72914854&doc=webinarslidesfinal7march-170307193318]

    — Jules Louis

  • Release Automation: Delivering the Big Quality Payoff

    Release Automation: Delivering the Big Quality Payoff

    Have you ever gone down the path of testing the latest release of an application only to find out that you had the wrong version?

    Maybe you accidentally grabbed the wrong build or you didn’t have the correct configuration file for the environment you were testing against—or your database wasn’t updated correctly, or the script you were using was still pointing to a prior version of the software.

    Whatever the case, we can agree that keeping track of all the various artifacts, database schema changes, configuration parameters and other components needed to accurately test and deploy an application is both time-consuming and prone to errors.

    Today, many companies are looking to DevOps, continuous delivery and agile development methodologies to shorten their application delivery cycles and reduce the number of errors and the costs associated with application deployment processes. Nearly all enterprise companies are software companies, and their mere existence depends on delivering differentiating products and services via software to their customers.

    It’s imperative to be able to react to customer demands and competitive pressures quickly, if not immediately, to stay ahead of the competition. Gone are the days of yearly release cycles.

    Today we see companies deploying new capabilities into production environments on a monthly, weekly or even daily basis. At some companies, hundreds, if not thousands, of deployments are occurring across dev, test and production environments daily. The old methodologies we once used simply can’t support this type of volume and cadence.

    Employing Release Automation

    So, how are these companies transitioning to this new way of thinking? In a word—automation; specifically, by automating early and often.

    Everything about your release process is a candidate for automation. This includes environment provisioning and configuration automation, build automation, test automation and release and deployment automation.

    A customer of ours recently implemented CA Release Automation, and within eight weeks had automated 90 percent of its deployments. Deployments that once took more than five hours and a team of people now take a matter of minutes.

    “This not only saves us a huge amount of time, but it also mitigates the risk of human error being introduced by manual processes,” said Tim Dallmann, platform engineer at Jewelers Mutual.

    Another customer, a major airline, implemented CA Release Automation and immediately reduced their production outages from an average of 237 over a three-month period, down to 15, seven, six and five over the following four months.

    And Molina Medicaid Solutions reduced their cost of human error by 90 percent, all the while responding quicker to emergency deployment requests and improving deployment quality.

    Automation is critical, but I believe these results prove that implementing a framework to manage and deploy release processes in addition to automation works even better.

    Increased Flexibility and Visibility

    Continuous delivery helps break down barriers often seen between development and operations teams. It provides, even forces, a more collaborative approach and automation is a key enabler of this.

    “One of the best things about automation is that it gives us the flexibility to skill-up end users—deployments in our test environments are no longer solely the responsibility of the operations or IT teams,” explained Dallmann.

    With an application release automation (ARA) solution, artifact, build, configuration and release processes are no longer tracked with spreadsheets or embedded in complicated scripts.

    Increased visibility into these processes ultimately enables all stakeholders to take a more active role in the release process, and access to real-time information can significantly reduce the amount of time and resources needed to resolve and recover from problems when they do occur.

    Automation leads to:

    Integrating with the Ecosystem

    An enterprise ARA solution can help you create a single control point to streamline all your application delivery processes for better predictability and reduced risk. A critical component of this is the ability to integrate and orchestrate tools and technologies required along the continuous delivery pipeline, including source control, automated testing tools, provisioning and configuration management solutions and change management and performance management solutions.

    Integration with an application lifecycle management solution can provide even further alignment, governance and traceability between development projects and what is ultimately being tested and promoted to production.

    “By integrating the two solutions, we will have a complete audit trail of deployments to help us understand how, where and by whom stories have changed,” said Phil Nickolai, director of application services at Jewelers Mutual.

    “What we really needed was a solution to streamline our whole way of working,” he said. “We had numerous people working on projects, competing for resources and causing complexity. Now we’re back in control and getting smarter every day.”

    The Time Is Now

    Let’s get rid of the problem that exists between the keyboard and information kept in spreadsheets, scripts or emails. Not only will you stop wasting time testing the wrong version of an application, but you can also ensure you have the right test data, the appropriate test cases and the correct configuration parameters for your environment.

    Stress-inducing release weekends and nights become a thing of the past. Developers can spend more time on developing innovative capabilities that generate revenue and keep customers coming back for more.

    — Tim Mueting