staging-devopsy.kinsta.cloud

Tag: devops

  • Intuit’s DevSecOps: War Games and Culture Hacking

    Intuit’s DevSecOps: War Games and Culture Hacking

    If you ever wanted to learn about Rugged DevOps (some call it DevSecOps), sit down for a spell with Shannon Lietz, Ian Allison and Scott Kennedy from Intuit. We discussed a number of important topics including internal war games, culture hacking, gamification of Rugged DevOps and starting as a small team. There are 100 gold nuggets in this conversation for novices and experts alike.

    Derek Weeks: I have some of the Intuit DevSecOps team here with me today. We’re going to talk to them a little bit about Rugged DevOps and how things work over at Intuit. Let’s start with some introductions.

    Allison: I’m Ian Allison. I help run the Red Team at Intuit, which is, I guess you’d say, an interesting way of taking control of security at our company. We try to get ahead of the attackers by basically being the attackers. We’re essentially ethical hackers. We go after all of our own stuff to make sure we can find where the deficiencies lie in all of our software.

    Lietz: I’m Shannon Lietz. I’ve been working at Intuit 3 1/2 years and helped to found the 24×7 DevSecOps capability at Intuit, leading the Red Team, our security operations capability, our cyber SOC, and what we also consider “blue teaming”: being able to hunt for defects.

    The organization has really had to transform how we do software development because we’re a 30-year-old software company. We are now seeing the traditional way of putting together software really embracing DevOps. For us, it’s been exciting to really work in the industry with Rugged DevOps, trying to help build security into the DevOps movement.

    Kennedy: I’m Scott Kennedy. I run the forensics and threat intelligence part of cyber work.

    Weeks: Shannon (@devsecops), tell me a little bit about software supply chains and how that vision of software development has impacted the way you see things at Intuit.

    Lietz: That’s really a great question. It was interesting when Josh Corman and I first talked; we had a lot in common. One of those things was the software supply chain. What I really love about the concept is being able to have processes driven a certain way so that you can reduce defects.

    Having worked for Toyota in the past and understanding the supply chain mentality, you get a sense of how you could put something together better, incrementing on it, figuring out how to share that process, and then really figuring out what things are important. Having that notion of fewer, better suppliers was really a core concept.

    I love the idea of transparency, building things a certain way, and really getting into continuous improvement. You need to look at things from an opportunities perspective—making sure you’re not just looking to make things perfect. You’re looking for those opportunities to improve over time.

    https://www.youtube.com/watch?v=nRaURhaTH9o

    Weeks: As we think about Rugged DevOps within your security team, how do you measure the success of what you’re doing? What kind of metrics are you looking at that matter to the business?

    Lietz: We measure everything. For example, mean time to remediation (MTTR). Once somebody finds a defect, we analyze that defect from the time it got into the supply chain to when it actually gets resolved. We track everything from mean time to remediation to when the ticket was created, to being able to look at when the code actually got published, to when it actually got found, and then we work on those things over time. We really try to uplift.

    ____

    Once somebody finds a defect, we analyze that defect from the time it got into the supply chain to when it actually gets resolved.

    ____

    We leverage JIRA [Software] just like a software development team does. We register our defects and figure out how to get development teams to take responsibility for those ideas. It goes through their process of release and regression testing. As part of that, we look back to see where our opportunities are.

    As an example, we started out where things may have taken weeks. We then reduced it down to days and ultimately got it down to hours. We’ve seen defect resolution where it’s now minutes. When it’s something we’ve discovered that was just a mistake by an engineer, we realize “mistakes do happen.” We found that our cycle times also help us to find fault stack vulnerabilities in real time because we get to do end-to-end testing more aggressively utilizing this method.

    Weeks: How has consistency in your operations helped with Rugged DevOps and has it fragility within the organization?

    Allison: One of the things we do is to utilize a golden image for all of the AMIs (Amazon Machine Image) we use, for all of our customers, and we require everybody to use these AMIs. We’ve also built some really interesting automation around scanning these AMIs. So one thing we realized quickly when we first started native U.S., when we try to do full vulnerability scans against another system, if it’s set up to autoscale, we all of a sudden have 50 systems. Right? We can’t … it’s really hard to do a full vulnerability scan right against the system, so we came up with a way to share back all of the AMIs with a special account. Then we bring those up and we scan them. Then we grade them.

    Based upon the vulnerabilities that are found, you’ll get a letter grade, like A through F, based upon the system you have. While we always strive to have our base image be an A, people continue to run on older images. But they get graded, and those grades get pushed up, so everybody in their org structure gets to see what the grade is for their account. I think by being a little standardized, basically with these images, lets us know what’s in everything, and we have a grade for everyone. It helps everyone have a really good idea of where they stand when it comes to a security standpoint.

    ____

    Based upon the vulnerabilities that are found, you’ll get a letter grade, like A through F … so everybody in their org structure gets to see what the grade is for their account.

    ____

    Weeks: That’s not only a grading but a policy enforcement governance kind of role that grading plays. How rapid is the feedback loop in that grading system for the teams that you’re working with?

    Lietz: It’s really quick, and we’ve discovered through some science that having component-based resources like AMIs provides us with an advantage when doing things like remediating vulnerabilities. Using AMI-based resources, we have seen that when there’s a defect in it, we can find and remediate all of the defective AMIs quickly. That improves everyone’s security across the company.

    So if you’re just picking out really good components, keeping track of those components and adding security into them, then you’ll actually see a different effect across our pipeline. A single change can actually have a dramatic effect on reducing the problems within the pipeline.

    Allison: It’s really interesting. This morning I got an email from somebody that said, “Why did our baseline AMI go from an A to a C today?”

    We had just received notice of a new vulnerability. Our stuff caught it, we scanned it, and we pushed the grade out to our portal where all our customers go to look at the grades. Our customers were able to see that change quickly.

    They could now say, “Wow, it changed from an A to a C in less than 12 hours.” I think the feedback is really important. The other important thing is that we have people going and looking. I wouldn’t be getting emails about why has this changed if people aren’t actually looking and wanting to make their grades better.

    Weeks: You mentioned customers. Are these internal customers?

    Allison: Internal.

    Lietz: Yeah, for our development teams, we as a security team really have changed how we think about things. It used to be that the security team would go out and govern. Basically, you got the fear of the security team coming in, descending upon you.

    We’ve really changed how that happens within our organization. We grade our resource components, and we grade the way in which our applications come together. That changes how developers want to operate because they really want to figure out how to get better grades in security. And it creates a learning dynamic that incentivizes somebody to improve continuously.

    ___

    That changes how developers want to operate because they really want to figure out how to get better grades in security. And it creates a learning dynamic that incentivizes somebody to improve continuously.

    ___

    Weeks: Does it create a competitiveness or gamification of who has better grades?

    Lietz: Absolutely, which is why we did it in the first place. To your point there, gamification is something where when you start to grade components like that, you can actually start to leverage a leaderboard concept. We do have leaderboards as part of this. We have APIs where you can actually pull down your grades and include them in your automation. With these, you can make governance decisions.

    If you sort of have that “game afoot,” right, your leaders can then ask for specific grades within their pipeline. That up-levels the system, and you just see a continuous improvement lifecycle come to bear. Ultimately, you see fewer defects, and ultimately, you get to the notion of Six Sigma in our way of thinking. DevOps is really about continuous improvement and embracing automation. Embracing that concept allows us to get to fewer defects faster.

    ___

    DevOps is really about continuous improvement and embracing automation. Embracing that concept allows us to get to fewer defects faster.

    ___

    Weeks: As you embraced continuous practices and DevOps practices, were there points when you realized certain old ways of doing things weren’t going to enable you to move forward?

    Kennedy: In looking at the progression of what we’ve been doing, one of the decisions that was made in Intuit and one of the things that I saw was really unique was the way they decided we were going to migrate into AWS. Our idea was to have the chaos team be the first people out, and that’s the security team. So the security team was the one that was going out and finding out how to use each of the products that AWS has and creating the concept of whitelisting. Each product was rated as to whether or not it met security’s requirement.

    Therefore, no team can go ahead and pull down this new cool tool that AWS released yesterday and use it in production because it’s not been “whitelisted.” That can go into their scoring. Their scoring is not only used by the development teams but also is useful when reporting to the board. When the board asks, “How are we doing as a company across the entire organization?” we can say that product A got a lower score than product B, and then they turn to the VP in charge of it and say, “Well, why?”

    ___

    When the board asks, “How are we doing as a company across the entire organization?” we can say that product A got a lower score than product B, and then they turn to the VP in charge of it and say, “Well, why?”

    ___

    We decided to not rush into the cloud but to take a careful, considered approach and migrate in a very intelligent and well-thought-out way. At the same time, we gave the chaos team the ability to make the mistakes and grow and learn, so they can immediately turn around and share the mistakes with everyone else. They could say, “Hey, these are the things that didn’t work for us. We came across a lot of problems, especially when you look at things like accounts and account roles.”

    How do you control when you have thousands of accounts and you need to have some sort of administrative control?

    You can either have a gigantic effort to force your namespace and your Active Directory to be the source of control. Or you can use the vendor-specific tools like IAM and have each account have their own separate islands, but with the concept of cross-account roles, you can then do remote administration from a centralized account. You have it locked down. You have the capability to have a restricted group and be able to remotely go in and do the necessary actions.

    That also gives you an audit trail. That also gives you multifactor built in because the AWS products get those things added to them.

    Lietz: I think when it comes down to it, I think culture-hacking your environment can have a profound effect, especially when you’re going through a DevOps transformation.

    Weeks: What is culture hacking?

    Lietz: That’s a great question. We use it when really trying to figure out how we as a security team can change and transform. A lot of the things that take place in a company are really based on traditional processes: What has worked before, and why would we change something that is working, right? If you’re really going to go into an innovative frame; if you’re really going to get into that next-generation innovation; if you are trying to figure out what’s going to work in that … it’s never going to be the thing that is working. It’s going to be the thing that you’re going to learn as you go to that next step.

    Culture hacking is really about looking at the people who are operating right now and trying to figure out how you’re going to help them go from A to B, making that change. What is that the experience going to be like?

    What we have done, to Scott’s point, is we’ve forced our security team to have empathy for the DevOps teams. We go through the process of developing something in the cloud, utilizing it as a method of taking their paranoia and trying to balance the notion of getting something done within a specific time frame. We try to really wrangle what it takes to do those things securely and safely but, ultimately, still be able to deliver for the business.

    I think that culture hacking really comes into play when you’re trying to figure out how to move somebody from the rock they’re on to the rock you need them to be on and trying to figure out what those mechanisms are.

    ___

    Culture hacking really comes into play when you’re figuring out how to move somebody from the rock they’re on to the rock you need them to be on.

    ___

    Weeks: Part of your security practice is looking at open source and third-party components and your own binaries. Can you shed some light on how Intuit is using Sonatype solutions to better manage those vulnerabilities?

    Lietz: Yeah, Sonatype Nexus is a fantastic platform. We love the Nexus repositories. We love how you guys put together a community. We learn a lot.

    A lot of our DevOps practice is working together with it. We’ve put together our Nexus repositories to do code signing and figuring out how to really secure our pipelines a certain way. We are taking advantage of the fact that we can pick up components, track them and then scan them [for known vulnerabilities].

    That’s allowed us to reduce the defect count that goes to production. Actually scanning and looking for vulnerabilities within our components and our open source libraries allows us to make better decisions about what we’re including in our software.

    Weeks: When you govern what open source, third-party or proprietary components are being used by developers, is there any kind of feedback from the teams saying, “Hey, you’re restricting my behavior, not improving my innovation”?

    Lietz: What we’ve found is that the notion of security approvals, exceptions and gates really doesn’t work. Quite often, you just create a culture where developers are going to go out and do it, and then you’re going to find out about it. When it comes to really partnering and being boundary-less about how you think about security in your business, it’s all about transparency. It’s all about benefits. It’s creating things like a security markdown file within your repository manager. It’s about taking responsibility and accountability for the things that you’re doing from a security perspective in your development process. It’s ultimately having an attacks.md file, keeping track of what’s out there, keeping track of your open source, understanding what components you’re leveraging, and why you made the decisions that you made to bring those things into your project.

    ___

    It’s about taking responsibility and accountability for the things that you’re doing from a security perspective in your development process.

    ___

    At a top level, all of those things work. But really having tools that can help the decisions that were made by some of the other open source programmers that you’re getting contributions from is really necessary. All of the things that they might be deciding are also part of your decision tree, and ultimately, you’re rolling all of that and bundling it together. The attack surface is not just the decisions that your team is making, but the ones that you share across the code base that you’ve got.

    Weeks: Your practices are very mature. You’ve clearly developed them over a long time, and some people watching this might think, “Well, Intuit’s a huge organization,” and it may be daunting to them if they haven’t started down the path of Rugged DevOps. Can you be a small team and have success in these kind of practices?

    Lietz: We’re not exactly a huge organization, but we are relatively large in size now. When we got started, I believe I was one of maybe three people that started this, only a couple years ago. We have hired into our group pretty extensively to help grow it, and some of the things that we’ve done have really allowed us to operate differently, to bring in people and have them immediately be successful. Our practices allow someone “day one” to be able to work with the environment, to be able to develop code, to be able to contribute code that week.

    We do things like weekly demos, where we actually do video demos. A person has to come in, program something, secure something, operate it and create a demo, all within their first week. So having the right bar for those folks is really important, but more importantly, our Red Team leader here (points to Ian), he came in and just is amazing, has created a Red Team pretty much out of thin air. So is having somebody from forensics, who’s just done an incredible job to help us, to make it so that we have a life cycle where we can snapshot something and be able to learn from it when it’s actually offline.

    ___

    A person has to come in, program something, secure something, operate it and create a demo, all within their first week.

    ___

    Those are the types of practices where you start to extend yourself past the normal baseline practices of processes today and really think past that about how you’re going to support innovation. You get into it very quickly. You get a learning culture. You get people who know that making mistakes—and figuring out how to learn from them—is okay. That’s a really important part of that actual culture that you’re putting in place.

    Allison: Yeah, I was going to say, it’s all about iteration, right? We started small, and we just continually iterate on what we’re doing to try to get better and be better at what we all do.

    When I first started this journey, I was a security guy—a pen tester. It was always the developer’s fault. Developers always made the mistakes. I always had to clean up after them. But after six months of developing Ruby APIs and Ruby and working my butt off in code, the empathy was there.

    I really understand what the developers are going through and why they make the choices they do. But I think by allowing us to help them, by creating tooling that allows them to self-serve, to understand it without making them … helps them make themselves more secure without them having to become a security professional. I think that’s kind of our ultimate goal.

    Shannon: Being friendly hackers, right? Basically going out and attacking them so their applications don’t get attacked by external attackers is really part of that frame.

    Kennedy: The Red Team shift at the company has been profound because you see how people react. When the Red Team started, it was not as well shared, and a lot of people suddenly were very upset that they were attacked by the Red Team. But when it was pointed out, “Well, what would you rather have happen? Would you rather have somebody in China do this to you, that didn’t work with you, didn’t sit next to you and help you fix the product, or would you like to have a friend who, by the way, their job is to attack?”

    When we went through several drills and actually practiced the muscle of defending the company against an attack, people were upset. “Oh, I had to do all this work.”

    My response to them: “Well, you did the right work.”

    “You did the right thing. You saw something bad. You did it. You did good. You practiced the muscle. Now when it happens again and it’s not the Red Team, I know that you’ll know what to do. You know that the process works, and we can actually defend the company faster and more securely.”

    ___

    You know that the process works, and we can actually defend the company faster and more securely.

    ___

    Weeks: Yeah. That’s an incredible story. Thank you for sharing it.

    My final question: If you could pick a superpower in dev, security or ops that you would have in the organization, what would it be?

    Allison: To me, they’re all alike; they’re the same, right? That’s what we do, DevSecOps, right? We try not to actually separate them out because I think once you start to separate them out, you start to lose perspective.

    Kennedy: Yep.

    Allison: There’s a good thing about having them all be one thing, so I’d choose them all.

    Kennedy: It’s been pretty consistent. DevSecOps is the answer. What was the question? (Laughter)

    Lietz: I think the reason we went out and created DevSecOps was just simply to change how we thought about doing development and technology—and to really to get ahead of it, to realize that attackers weren’t setting up appointments or meetings to help you figure out how they were going to attack your software, and so then why were we? Why were we operating at a fragile level?

    I think that the superpower that I would like to have is DevSecOps because I know that we are going through the process of creating a less-fragile capability in security that will allow us to get ahead of attackers, make it much harder for them to go after the software that gets built, and we’re seeing those improvements. That’s actually a great thing.

    Weeks: It sounds really exciting, and it’s very cool, so thank you all very much. I really appreciate it.

    All: Thank you.

    If you loved this interview and are looking for more great stuff on Rugged DevOps, I invite you to download this awesome research paper from Amy DeMartine at Forrester, “The 7 Habits of Rugged DevOps.”

    Untitled2

    As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”

  • Conjur Delivers Automated Access Management to Windows Platforms

    Native .NET Libraries and Windows Remote Desktop Support Spans Microsoft Workloads in Cloud, Hybrid and PaaS Environments

    WALTHAM, Mass. – April 5, 2016 – Conjur, Inc., provider of automated access management software, has released significant product enhancements for Microsoft® Windows® environments that addresses the growing customer requirements for building, managing and securing Windows workloads in cloud and hybrid cloud environments. Conjur’s Windows capabilities deliver a consolidated approach for access, control, authorization and audit for Windows resources and development environments.

    Now, customers can seamlessly extend their on-premise datacenter operations to cloud services, leverage Microsoft Azure services and accelerate the .NET software development lifecycle while strengthening security practices.

    Conjur’s new support for native Windows authentication and real-time application of authorization and permissions to dynamic virtual machines ensures an IT graceful migration.

    “As we broaden our market adoption, the need for first class Microsoft Windows support is apparent, especially in hybrid and heterogeneous environments,” said Mitch Haile, Vice President of Products at Conjur. “We are excited to support both .NET native client APIs and Windows Remote Desktop Access Management for modern, highly automated IT environments.”

    Conjur’s Window’s release incorporates support for:

    • Windows Remote Desktop Connector: Integrate Windows authentication for user login to Windows instances operating in cloud environments
    • Native .NET Client Library: Conjur’s new .NET client library is open source and available immediately.

    “Conjur’s new native .NET libraries and Remote Desktop access to Microsoft Windows hosts in the cloud is a significant step forward in enabling automated infrastructure security,” says Dave Bechberger, Senior Architect atExpero Inc.

    Through a centralized authorization service exposed through APIs, Conjur enables enterprises to apply a consistent set of policies for production, staging and test environment access throughout the entire software development cycle. These latest enhancements meet the requirements for the scalable, enterprise-grade secret management solution for organizations in highly regulated industries.

    About Conjur

    Conjur is preventive security for companies that are automating their IT systems, who need to control access, and need to demonstrate control.  For enterprises that need to protect their infrastructure, Conjur is the only solution with comprehensive identity and authorization for every cloud, VM, container, service, job and user. Conjur helps companies such as Netflix, Box, and Puppet Labs solve critical operational, compliance, and security challenges that originate in modern automated infrastructure. Headquartered in Waltham, Massachusetts, Conjur is funded by Avalon Partners and Amplify Partners. Visit www.conjur.net  and follow @conjurinc on Twitter.

     

    PRContact:
    Tracy Wemett
    BroadPR
    +1-617-868-5031

  • Gene Kim and Industry Experts to Discuss DevOps for High Performance IT at Perforce Conference

    MERGE 2016 Brings Speakers from EA, Dolby, McKesson, Scania, NetApp, Intel and Others to Address Software Development and Delivery Trends

    ALAMEDA, Calif., April 5, 2016 /PRNewswire/ — Perforce Software today announced that MERGE 2016, its user conference that brings together customers, partners and thought leaders to discuss software development trends, will take place at the Parc 55 Hotel in San Francisco April 13-15. During the conference, the 300+ attendees will discuss best practices for embracing trends such as DevOps and other shifts in enterprise collaboration.

    MERGE 2016 will feature talks on the merging of development and operations teams (DevOps), and the adoption of DevOps by many of the world’s most high-performing IT teams. Other topics addressed include the merging of DevOps with security, artists merging with coders, and distributed workflows merging with centralized workflows. Highlights from the conference include talks by Gene Kim, the leading authority on DevOps and IT operations, release engineering expert J. Paul Reed, and Perforce customers Samsung, Dolby Labs, EA, McKesson, Scania, Tableau, Intel and Citrix, among others.

    “We’re seeing customers across industries become technology companies and adopt software development practices like DevOps in order to remain competitive,” said Janet Dryer, CEO of Perforce Software. “MERGE 2016 will give attendees the inspiration, knowledge and tools they need to deliver real value to their customers in a software-driven world.”

    About Perforce Software

    Perforce Software helps companies build complex products more collaboratively and securely. Its highly scalable source code management (SCM) and collaboration platform, Perforce Helix, enables global teams to collaborate on any type or size of file. It supports both centralized and distributed (DVCS) workflows while safeguarding intellectual property with advanced behavioral analytics. Perforce is trusted by the world’s most innovative brands including adidas, Samsung, NVIDIA, Intuit, Pixar, Salesforce, EA, Ubisoft, and VMware. The company is headquartered in Eden Prairie, Minnesota, with offices in California, the United Kingdom, Canada and Australia, and sales partners around the globe. For more information, please visit www.perforce.com

    Media Contacts

    Global
    Ivana Gaspic
    Perforce Software
    Ph: +1 510-473-3186
    Mob: +1 415-955-7483
    igaspic@perforce.com

    US
    Michael Thomas
    Edelman
    Ph: +1 312-233-1361
    Mob: +1 773-822-6182
    michael.thomas@edelman.com

    UK/EMEA
    Maxine Ambrose/Nicola Males
    Ambrose Communications
    Ph: +44 1491 412944
    perforce@ambrosecomms.co.uk

    Logo – http://photos.prnewswire.com/prnh/20141021/153498LOGO

  • FLAP, Part 1: Server Provisioning

    FLAP, Part 1: Server Provisioning

    We have reached the state where end-to-end data center provisioning is a reality. It’s early yet, so there is a certain amount of work involved, but today a DevOps team essentially can turn on the automation and move on to other DevOps priorities. It takes some effort, depending upon the solution chosen, but the end result is an infrastructure that provides for installation of operating system (OS), hardware (if needed) and apps, along with configuration of the whole, at the push of a button.

    There are a number of solutions ready for your data center today, and this three-part series will explore them. In the first part, we’ll talk about server provisioning—the part that takes you from uninstalled server or virtual to a functioning OS configured for your environment. The following two articles will cover application provisioning and merging the two to achieve FLAP. (Yes, I made up FLAP. Use it or not, as you see fit.)

    Disclaimer: I work for a vendor in this space. While I do not believe that impacts my objectivity, I will note where my employer is mentioned, and leave it to the reader to decide if I’m blinded to some items/issues based upon my association.

    Server Provisioning: What and Who

    A server provisioning system takes a physical or virtual server from nothing to fully installed OS. This layer of FLAP is fundamental to automating the entire process. If the system has to be installed manually, using tools and scripts to install applications just doesn’t offer the overall benefit as when the entire process is automated.

    For this discussion, we will be sticking with the major provisioning tools out there. To be sure there are more, and I have information about them, but for this short blog post, we’ll stick with the ones that hold something special—market share, history, integrations, associations—that make them a good long-term bet. Our list is alphabetical, and does not show preference by ordering.

    Cobbler

    Cobbler is one of the original server automation tool sets, and definitely has the history and stability to warrant your attention. For shops that use a lot of Fedora and CentOS, Cobbler in combination with Spacewalk is particularly appealing, as we’ll talk about later. Support includes most Linux distributions. Users have created ways to include Windows in the list of installable OSes, but there is not yet an official solution for Windows.

    Cobbler is integrated with Ansible, Spacewalk, Saltstack, Puppet(user created), and older versions of Satellite. There is some amount of concern about Cobbler’s future growth, simply because Red Hat moved Satellite off of Cobbler with release 6.0, though Red Hat still supports Cobbler. It is too soon after the split to predict how this will fall out, but currently it seems to have motivated the Cobbler core team to do more. Users concerned should check GitHub analytics to see what the trends are for committers and commits at the time they are evaluating (good advice for all of these products, but more pertinent for one where there is a question of its future).

    Cobbler’s hardware support is better than most, and in terms of application support it is a pure-play server automation tool; there is no support for applications at all—application provisioning is expected to deal with that aspect.

    Foreman

    Foreman is an open source project that is currently enjoying the sponsorship of Red Hat, but support is not limited to Red Hat OSes. In fact, Foreman will install just about any flavor of Linux, and can target most physical/virtual/cloud platforms. Using WDS, Foreman can also install Windows.

    One of the big strengths of Foreman is its interoperability—it doesn’t much care which application provisioning tool you are using. It is integrated into Satellite (with Puppet), and has support for all of the other major application provisioning tools. This means that no matter what you’re using to get your apps installed, Foreman is worth looking at for getting your servers installed.

    Like most products out there, Foreman provides CLI, API and GUI. They’re relatively stable in relation to the market, simply because Foreman implemented them earlier than most competitors, and is constantly improving them.

    In short, if you are in an environment that has a wide selection of OS, architecture and application requirements, Foreman should be at the top of your short list. For more focused solutions (in terms of OS, whether or not cloud, or application provisioning tools), it makes more sense to compare specific features/functionality with some of the more focused tools in this list.

    MaaS

    MaaS was the sleeping giant of the automation world, but it does indeed look as though it is awakening. MaaS is part of Canonical’s Ubuntu project, so there is plenty of backing, but historically its goals have been modest and its documentation more so. That changed some time over the summer/fall, and MaaS is showing increased support for OSes, better documentation and a more focused attempt to get the word out. If you are primarily an Ubuntu shop, it is well worth considering.

    Like most of the products in this offering, MaaS uses PXE to get the machines into its system, and then uses predefined images that have been imported (Ubuntu images don’t need importing) to install a machine from bare metal/virtual to working OS. MaaS proclaims support for CentOS, RedHat, SuSE, Ubuntu and Windows. For those unfamiliar with the space, that’s an impressive list. But the last time this author used MaaS, it was still only Ubuntu, so I cannot comment on the level/quality of support for each of the OSes. Due diligence should involve testing with those OSes your organization needs.

    The weakest part of some installers is non-standard hardware, such as RAID controllers, specialized network cards and the like. MaaS supports these components and includes UCS support in its packaging. Directly mentioning UCS support is only to be found with MaaS and Stacki, so if you’re a UCS shop, it is worth considering.

    In addition to CLI, MaaS touts an API and a GUI. These are important tools in the DevOps sense, because the API lets you tie MaaS into your automation architecture, and the GUI helps find issues specific to MaaS and its domain. Particularly interesting is the collection of logs that show install results and operations results clearly for each server.

    The one major drawback to MaaS is its limited application provisioning support—it is well-integrated with Juju, but none of the other big names in the space.

    In short, for Ubuntu shops using Juju, this is the tool to put at the top of your short list. For everyone else, the tool is viable, but should be considered against the features/functionality of other tools.

    Razor

    Razor is Puppet’s newer bare metal installer. It is young yet, and there are still issues to be worked out, but the large cadre of developers that are dedicated to Puppet say that Razor will continue to improve as time moves on. At current it directly supports most flavors of Linux and Windows installations. The catch to Razor is on the other end: It is designed to work with Puppet, and support for other application provisioning tools is low—indeed, is limited to user-designed solutions. Needless to say, because it is sponsored by Puppet, it is expected that official work in this area will remain slow, as it is not a priority.

    Razor does not have a dedicated GUI; instead, it uses Puppet’s GUI to report results. As with integration, this is okay for Puppet shops but pretty much eliminates Razor from consideration for other shops. (More on this in a future blog in this series.)

    Because Razor is new, there are a couple of serious caveats with the product. First, install is one of the worst in the market, with a lot of pre-install steps, a lot of install steps, and configuration of an array of underlying systems by hand. Second, each currently installed server that you do not want Razor to re-install must be entered into Razor manually on the command line. This is so limiting in a generalized data center environment (where Puppet shines) that you can expect this limitation to be resolved quickly.

    In short, for Puppet shops that do not see their application provisioning tool changing, this is the tool to put at the top of your short list. For other shops, it’s worth looking at competitors first, simply because Razor requires Puppet.

    Stacki

    Stacki is an open source project sponsored by StackIQ (as promised, this is my employer). Having roots that stretch back more than a decade, Stacki specializes in RedHat/CentOS installations with additional support for clustered software. As of this writing, CoreOS and Ubuntu have been added to Stacki’s list of supported OSes, and expect that list to grow over time.

    The biggest appeal of Stacki is the variety of ways to get systems under management. All of these apps will auto-detect a new server on the network, grab it and install it. Stacki adds the ability to list just the servers that should be clean-installed in a spreadsheet, the next time each of those machines boots they will be installed, but no other machine will. While there are ways in all of these systems to simulate this functionality—you can add exceptions to the “install all machines that boot on this subnet” rule via the command line in Razor, for example—using a spreadsheet to affirmatively manage what machines are to be installed and how gives an offline bulk way of managing installations and re-installations.

    As of this writing, Stacki does not have an API, and only with commercial add-ons can a GUI be had, but expect one or both of these things to change as the community begins guiding development efforts. Stacki is optimized to spin out hundreds of servers in minutes or hours instead of weeks or months, utilizing a peer-to-peer parallel installer to service installations faster as more servers come online. While it works as well as others in smaller environments, it really comes to its own when there are a large number of servers under management. On the initial installation front, while the other systems in this list require hand-installing and/or configuring prerequisites and sub-systems, Stacki comes as an ISO with a UI that asks a few questions and configures everything.

    Stacki has been used with most (Ansible, Puppet, Saltstack) of the major application provisioning tools this series of blogs will consider, making it versatile on the application side of the equation.

    Overall, if you’re a Red Hat shop that uses CentOS a lot—particularly a larger shop—Stacki should be the first stop on your short list. For everyone else, the tool is viable, but should be considered against the features/functionality of other tools.

    Stay tuned for part two of this series, which will cover application provisioning.

  • IT Revolution Announces Call For Presentations And Conference Themes For DevOps Enterprise Summit San Francisco 2016

    Leading enterprise DevOps event encourages experts in IT and software delivery to submit topics that focus on implementing change, security & compliance and modern technology adoption

    PORTLAND, Ore., April 4, 2016 /PRNewswire/ — IT Revolution (http://itrevolution.com), the industry leader for advancing DevOps, today announced its call for proposals for DevOps Enterprise Summit 2016 San Francisco (DOES16), the premier industry conference for the leaders of large, complex organizations implementing DevOps principles and practices (http://events.itrevolution.com/us). The call for proposal submissions will be accepted until midnight PDT on May 2(http://bit.ly/SFOCFP16), and the conference is scheduled for November 7–9 at the Hilton San Francisco Union Square. Abstracts should address the conference theme of “Leading Change,” and its sub-topics of organizational design in the enterprise, the functions of people, modern processes and technology adoption, and addressing security and compliance.

    Early Bird registration for DOES16 San Francisco has opened (http://bit.ly/doessfo16reg) and is highly encouraged, as the popular event has doubled in size while selling out the past two years. In addition, the DOES16 London event set for June 30–July 1, has opened Blind Bird registration. For more information, visit: (http://bit.ly/doesldnreg).

    “Our goal is to help accelerate the rate of DevOps adoption in large, complex organizations, and to increase the probability of those transformations succeeding,” said Gene Kim, founder of IT Revolution and co-author of “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.” “One of the ways we do this is to understand the top obstacles in these transformations. A great community is one that helps one another — by having leaders share how they’re overcoming the top obstacles identified last year, my hope is that we can quickly elevate the state of the practice.”

    IT Revolution and its founding partner Electric Cloud are proud to present the third year of DOES16 San Francisco – an event for enterprise IT leadership and software delivery experts to join together to identify and amplify the evolving technical and architectural IT practices as well as the methods needed to lead widespread change efforts in large, complex organizations. For more information about DOES16 San Francisco, please visit: [http://events.itrevolution.com/us/]

    Share This: DevOps Enterprise Summit San Francisco call for proposals is now open! Submit your proposals here:http://bit.ly/SFOCFP16 @DOESSummit #DOES16

    About IT Revolution

    IT Revolution assembles technology leaders and practitioners through publishing, events, and research. Our goal is to elevate the state of technology work, quantify the economic and human costs associated with suboptimal IT performance, and to improve the lives of one million IT professionals by 2017.

    Contact:
    Jeremy Douglas
    Catapult PR-IR
    303-581-7760, ext. 16
    jdouglas@catapultpr-ir.com

    Logo – http://photos.prnewswire.com/prnh/20160322/346968LOGO

  • Does DevOps Improve or Undermine Quality?

    Does DevOps Improve or Undermine Quality?

    In my earlier blog, “From QA to Continuous Testing,” I explained that “several industry developments converged to make continuous testing the winning method for software engineering quality assurance (QA).” The “combination of improved test methods, agile processes, continuous integration speed afforded by automation and orchestration tools and low-cost test dynamically configurable infrastructures afforded by virtualization has resulted in DevOps.”

    However, a recent survey by Parasoft indicated that some important concerns such as non-functional requirements (NFRs) (examples are: reliability, testability, availability, resiliency) are being overlooked in many organizations that are operating fast-paced Agile and DevOps environments.

    Some results gleaned from Parasoft’s survey run counter to popular expectations:
    1. Agile teams are less likely to monitor NFRs than non-agile teams.
    2. Ownership of quality, especially for agile teams, tends to be QA team members.
    3. Business members think NFRs are being measured but technical folks do not.
    4. Confusion and disagreements exist regarding who owns NFR objectives.

    The report implies that quick Agile and DevOps processing cycles steal time from broader QA concerns.

    The Question

    So what is the truth? Do agile, DevOps and continuous testing improve QA, or do they undermine quality?

    My own observation is that DevOps can improve or undermine QA. The outcome depends on whether an organization explicitly takes a holistic view of quality that assures all of the “ilities” are taken care of during agile, DevOps and continuous testing.

    A complete DevOps environment requires a more sophisticated view of continuous testing than simply “shift left,” “fail early,” “fail often” and “test fast,” which are four popular tenets espoused by the DevOps community. A fifth tenet, “relevance,” must also be fully considered. With “relevance” as a tenet of DevOps QA, the entire DevOps and continuous testing pipeline has woven into it, from end to end, the concept that all of the quality aspects relevant to customers are emphasized in continuous testing and analysis of test results. When relevance is fully considered as an equal tenet to the others, then NFRs and “ilities” are not forgotten and the tools, goals and tests explicitly take into account all aspects relevant to customers’ perception of quality. What is more, when relevance is applied to continuous test selection and results analysis, the system not only produces better quality but it also is more effective and efficient.

    At Spirent we think that a holistic approach to DevOps and continuous testing, including “relevance,” is critical for successful DevOps. When continuous testing is implemented with relevance as an equal tenet, quality is improved.

    You can read more about our views at Spirent.com/solutions/DevOps

    What are your experiences and suggestions?

  • DevOps Without Scale, Part 1

    DevOps Without Scale, Part 1

    When most people think of DevOps, what comes to mind first are continuous integration (CI) and continuous development (CD) pipelines. While they are arguably the most important parts of DevOps, they are not all of it. So, then, what is DevOps? It is a philosophy of how to build and operate software products and systems to provide the best user experience. It’s a way of thinking that blends the previously independent disciplines of development and operations so that software products can both evolve functionally and be stable operationally. In practical terms, it means development teams are involved in operations and, in many instances, fully own the operation of their products.

    The top companies are already there because they otherwise couldn’t deliver their massive and feature-rich products with 99.9 percent uptime. But there are still too many companies and developers who aren’t “doing it.” And it’s typically reflected in product quality.

    It seems DevOps has been stigmatized as difficult, requiring expensive tools and generally classified as needed if you’re big. In this blog I’ll walk you through different aspects of DevOps and share the business value behind each, the common implementation techniques and the free (or inexpensive) tools that will let you jump-start your DevOps in a matter of weeks.

    Product Health: The User Experience

    Our goal as engineers is to build products that will be used by others. Typically we call them users and sometimes we have a strenuous relationship with them. But if users don’t like our products and aren’t using them, we have failed at the very core of our job. So what do users want—besides features, that is?

    Users want products that are reasonably fast and work when they need them. Your site going down is an obvious example of why it’s important to be aware of your product’s health. But there are more nuanced examples. Sometimes a new release breaks an edge case and isn’t caught by regression testing. Sometimes a service becomes slow—it still works and nobody is complaining, but it’s dangerously close to being unusable. You need to be aware of your users’ experience so you can be proactive in fixing problems and delivering quality products.

    Thus, the first set of metrics you need to measure are user experience metrics. These typically include success/failure and latency of all external endpoints: REST, web pages, etc. If the users are external, you want to measure the experience from their point of view, which includes the network latency and HTML/CSS/JS execution time for web pages. If this was a car, these metrics would be your low coolant red light. If the light is on, you must stop as soon as possible and add coolant before your engine block cracks from overheating.

    To measure and monitor customer experience for web pages, Google Analytics is by far the most popular choice. It’s easy to set up and gives you exactly what you’re looking for: error stats per page, page load times, including individual page components and even browser parsing time for HTML. You can slice and dice the data by geographic region, browser type and so on to zero in on improvement or problem areas. Google Analytics is a great tool for tracking other product aspects as well, and you can kill many birds with one stone by adopting it.

    However, Google Analytics will provide data only as long as there are users and your site works. But what if the site breaks, maybe partially or maybe only for a certain geographic region? And what do you do for public APIs that aren’t instrumentable with Google Analytics? You’ll need a synthetic monitoring service. These services emulate clients by calling your APIs or opening your web pages in an automated fashion. They are typically scriptable and run from multiple places around the world. They can tell you when your services are up or down and can measure (emulated) user latencies by geographic region. Pingdom is one of the newer generation of such services that delivers what you need for a modest price. It also integrates with a graphing and alarming tool called Datadog, which I’ll talk about later.

    Product Health: Technical Innards

    Now you have a solid understanding of your user experience and can detect user problems in real time. But how do you find the root causes? And can you do even better by detecting user problems before they happen? What you need to do is go a level deeper and monitor key technical aspects of your apps so you can correlate them with user problems. The technical metrics are important to watch because they can be early signs of trouble, which can be averted if you act quickly.

    This can be a dangerous territory as the first desire is to monitor everything. Please keep your cool here, lest you drown yourself in hundreds of metrics that nobody understands and miss the important ones. In software, failure typically happens at integration points, so that’s what you should focus on: database and cache interactions, calls to other services, disk operations, queue sizes (for pub/sub architectures) and so on. Typically you don’t need to instrument business logic, as it either works or doesn’t and problems are caught in testing. This is where it is easy to create many metrics in a blink of an eye. A notable (and rare) exception is load-intensive parts of code that you want to monitor for performance reasons.

    If you see latency in database calls creeping up, cache hit ration going down or thread pool or queue size growing, you can frequently identify and fix the problem before it affects the users. Going even deeper, you want to keep an eye on the virtual machine (VM) and server performance. If your garbage collection times are increasing, if your thread count grows or if your server is showing signs of strain, it’s time to pay extra attention. If this was a car, these would be your check engine yellow light. If the light is on, you need to check it out soon but can keep on driving for a little bit longer.

    The most popular way to measure application metrics is with code instrumentation. Presently, Coda Hale (a.k.a. Dropwizard) Metrics framework and its ports to most popular languages are the way to go. Given the abundance of documentation and integration with all sorts of systems, this isn’t difficult. There are a plethora of coding patterns or external libraries you can use to avoid writing boilerplate code. Note that you want to include as much as possible in measuring requests (serializing, logging, etc.) so you need to put this logic as high up the filter chain or middleware as you can.

    The last piece of the puzzle is VM and server monitoring. Traditionally, this has been the territory of specialized ops tools, but Datadog, a service that I will talk about in the next section, provides this out of the box. Its agents run on each machine or VM and collect server metrics, JVM/JMX data, IIS info (yep, it supports even Windows) and more.

    Processing and Displaying the Data

    Now your code is instrumented and generates all sorts of interesting data. What do you do with it? And where does the data go in the first place? All this data is useless if it just sits there. You want to be able to look at the trends, correlate them and get a basic set of statistical information such as averages, means, standard deviations and so on. You also want to see pretty graphs (who doesn’t?) and be able to create dashboards. This is the cool part, where all the previous work comes to fruition.

    Datadog is a great way to start. It provides everything you need and more. All you have to do is install its agent on each box and configure the Metrics framework to send data to Datadog. Most Metrics ports already include Datadog adapters so there is no extra coding required.

    Now you have everything and can slice and dice the data whichever way you want. You can export data for further analysis. You can check it periodically for problems. You can even display dashboards on big screens around the office (looks cool, eh?).

    Putting it All Together

    I have seen all of this put together in a couple of weeks. However, if this whole area is new to you it might take longer, as you’ll be learning the concepts along with the tools. Sometimes the deadlines are tight and even a few weeks is a luxury. However, launching a product without any insight into user experience or product health is not a good idea. If I had limited time and had to prioritize, I’d start with instrumenting user experience metrics and hooking it up to Datadog. Even for web pages you can start with only monitoring the REST services that power them, or the controller layer, if you’re on model-view-controller. Soon you will realize how nice it is to have hard metrics and will want to add Google Analytics and deeper code monitoring to your product.

    All of this might seem like a lot, but you’re only dealing with four tools here: Pingdom, Google Analytics, Metrics framework, and Datadog. If your product is an API then you don’t need Google Analytics and if your product is internal, you don’t need Pingdom.

    As I mentioned earlier, Metrics framework is ported to multiple languages already. But even if you have specific requirements that aren’t supported out of the box, it’s easy to extend it. For example, at Guaranteed Rate we wrote and open-sourced the Metrics/DataDog adapter for .NET and a library for code instrumentation and DataDog integration for Clojure.

    .NET is particularly known to be behind on DevOps. Until recently one of the reasons was the lack of tools; however, that’s not the case anymore. All tools mentioned here, as well as Part 2 and 3, work in .NET and have adapters and ports where needed. With .NET entering the new open-source age, there are no more excuses to stay behind.

    Give yourself two weeks, read the docs, go one step at a time, and you’ll be surprised how far along you can get!

    What’s Next?

    Part 2 will cover what you can do to maximize product uptime based on the data you now have. It also will discuss making sense of the data, automated alerting and troubleshooting when the inevitable production problems happen.

    About the Author/Jack Korabelnikov

    JackKorabelnikov_avatar (small)Jack Korabelnikov wrote his first computer program when he was 10. Another 15 years later, after success in the role of senior engineer at Orbitz.com he transitioned into management. He still enjoys the tech side of things and continues to tinker with cool new tech. He is presently the VP of Engineering at Guaranteed Rate, leading the company’s technical evolution and the buildout of next-gen mortgage products.

    Prior to that, he worked at Orbitz Worldwide in multiple business areas such as hotels, private label and B2B web services. He played a key role in rolling out agile and, most recently, was the main driver behind the continuous delivery and DevOps adoption across the organization.

    jack@korabelnikov.com | LinkedIn

  • Another piece in the DevOps puzzle – Redgate launches ReadyRoll at Build 2016

    Cambridge, UK, March 31, 2016 – At the Microsoft Build Developer Conference 2016, Redgate is launching ReadyRoll, a key piece in the DevOps puzzle that addresses the pain often associated with managing database changes alongside the application.

    It fills a gap in the software development process which, over the last decade, has seen significant improvements in reducing the cycle time between an idea and useable software. DevOps and Agile practices play a key part in enabling organizations to deliver value to customers sooner by enabling teams to work more collaboratively and productively.

    Redgate ReadyRoll applies that same thinking to the database by enabling teams to develop and deploy databases in Visual Studio following a migrations-based approach. It removes the pain of managing SQL migration scripts by generating numerically ordered scripts to take schema from one version to the next. This allows teams to version control their database and application changes side-by-side from within Visual Studio, and enables them to build and release, and automate deployments, all in one process.

    During the DevOps session at Build 2016, Data Platform MVP Steve Jones will join Microsoft Corp. to discuss the importance of including the database in DevOps processes. In a live demo, he’ll show how Redgate ReadyRoll integrates into Visual Studio Team Services to ensure continuous integration, and how automated release processes cover both the application and the database.

    Daniel Nolan, who originally founded ReadyRoll and is now the Product Manager at Redgate, comments: “When I originally developed ReadyRoll, it was to solve a particular pain point I had when I was deploying databases. In the last nine months, Redgate has put enormous resources behind it and it’s fantastic seeing how more and more users are able to develop and release changes significantly faster because of ReadyRoll.”

    Mitra Azizirad, General Manager, Cloud Application Development & Data, Microsoft Corp., said: “I am excited about offering a migrations-based approach to database change management from within Visual Studio. Applications and databases aren’t separate entities – they’re two sides of the same coin. Enabling teams to implement DevOps practices and manage database and application changes side-by-side is a key step towards improving team collaboration and productivity.”

    As a long-standing ReadyRoll customer, John Adams of TrueBlue Inc. agrees: “This product is fantastic. It saves us a lot of time and makes our release process consistent and repeatable.”

    To learn more, or download a free trial of Redgate ReadyRoll, visit Redgate online: http://www.red-gate.com/products/sql-development/readyroll/.

    – ENDS –

    Further information from:
    Wibke Carstensen
    Marketing Manager
    Redgate Software
    wibke.carstensen@red-gate.com
    +44 (0)1223 438665

    About Redgate Software
    Redgate Software makes ingeniously simple software used by 650,000 IT professionals who work with SQL Server, .NET, and Oracle. More than 100,000 companies use Redgate products, including 91% of the Fortune 100. Redgate’s philosophy is to design highly usable, reliable tools which elegantly solve the problems that developers and DBAs face every day.

  • cPrime and AgileCraft Partner to Scale Agile with Atlassian’s Jira Suite

    Partnership enables organizations committed to Atlassian suite to scale agile across all levels of the enterprise – including team, program, portfolio and enterprise levels.

    Foster City, CA (PRWEB) March 31, 2016

    cPrime, the industry leader focused on solutions to help companies adopt, transform and scale their business with Agile Development methodologies and AgileCraft, the leading provider of enterprise agility platforms to simplify software at scale, have partnered to help companies drive business agility and transformation at scale.

    “Customers interested in scaling agile to the enterprise are rapidly adopting JIRA along with AgileCraft to align business and technology.” Said Zubin Irani, CEO of cPrime. “Our customers tell us that using AgileCraft with JIRA allows organizations to bridge the PPM / ALM gap in a modern and highly scalable way. The result for customers is better software – delivered on time and on budget – with clear visibility and trace-ability from start to finish.

    “Our business model is to embrace partners to drive the implementation and customization of our platform” said Steve Elliott, CEO of AgileCraft. “cPrime already deeply understands the needs of organizations scaling agile, and was looking for a tool to help solve the problem of true enterprise agility. cPrime has repeatedly worked with our team to deliver innovative solutions that accelerate the path to operational agility.”

    Built from the top-down to support agile at scale, the AgileCraft platform helps align entire organizations around common goals and objectives while providing actionable views and metrics to everyone touching the technology product lifecycle.

    To learn more about scaling agile to the with cPrime and AgileCraft on platforms like Jira register for a one-hour complimentary webcast featuring a product overview and technical deep dive to be held on May 10, 2016.

    About cPrime Inc.

    cPrime enhances the full lifecycle of product development with comprehensive solutions for adopting and scaling Agile methodologies and software. Hardware, DevOps, JIRA, cPrime covers it all. The alignment of  people, processes and technology solutions build and optimize a lasting framework for client growth. cPrime works with the most notable enterprises; providing training, consulting, and team augmentations to help organizations adopt and scale Agile methodologies. Additionally, cPrime deploys and optimizes the software used to support client’s unique processes. The cPrime solution sets span the full application lifecycle management pipeline to ensure quick and quality product delivery.

    About AgileCraft

    AgileCraft® delivers the most comprehensive software solution available for scaling agile to the enterprise. AgileCraft transforms the way organizations enable and manage agile productivity across their enterprise, portfolios, programs and teams by aligning business strategy with technical execution. The AgileCraft platform combines sophisticated planning, analysis, forecasting and visualization with robust, multi-level collaboration and management. Designed to be open, the AgileCraft platform compliments and extends existing agile tools, methods and processes and can be deployed through the cloud or on premise. AgileCraft customers get the best agile solution on the market and benefit from a platform that is specifically designed to scale enterprise wide. For more information, please visit http://www.agilecraft.com.

  • Dynatrace and HCL Technologies Partner to Help Organizations Accelerate Their Digital Transformation

    Partnership Enables HCL Clients to Deliver Superior Experiences to Their Mobile and Web Users

    Boston, MA – March 31, 2016 –– Digital Performance software company, Dynatrace, today announced a global partnership with HCL Technologies, a leading IT services company. HCL will leverage Dynatrace’s best-of-breed digital performance management technologies within HCL’s DryICE platform to deliver world-class user experience and application monitoring to HCL customers from digital natives to traditional enterprises transforming into digital enterprises.

    “Automation in the 21st Century is all about agile thinking, lean delivery and great customer experiences,” said Kalyan Kumar, Senior Vice President & Chief Technologist at HCL Technologies. “Dynatrace is the industry leader in digital performance and the best technology to help our clients around the globe achieve these priorities more efficiently, through every application. Its unique breadth and depth made our decision to partner with Dynatrace an easy choice over competing solutions.”

    HCL’s digitalization strategy orchestrates a unified experience across the user ecosystem to achieve agility, growth and profitability. Dynatrace empowers HCL to deliver best-in-class application performance to its customers in the following key areas:

    • Know Your Digital User: HCL will leverage Dynatrace Synthetic and Real User Monitoring to empower digital business owners to drive more business and superior customer experience through better insights into their users’ mobile and web experience.
    • HCL Digital Services Monitoring Platform: This platform will leverage Dynatrace Ruxit as part of HCL ElasticOps for next generation, user-centric digital performance capabilities to optimize user experience and digital services operations within enterprises.

    “We are extremely pleased to partner with HCL. Our focus on digital performance squarely aligns with HCL’s digitalization strategy,” said John Van Siclen, CEO at Dynatrace.  “In the digital economy, customer experience has never been more important and we look forward to helping HCL deliver superior digital experiences to their customers.”

    About Dynatrace

    Dynatrace is the innovator behind the industry’s premier digital performance platform, making real-time information about digital performance visible and actionable for everyone across business and IT. We help customers of all sizes see their applications and digital channels through the lens of their end users. More than 8,000 organizations use these insights to master complexity, gain operational agility and grow revenue by delivering amazing customer experiences.

    Read more about Dynatrace’s leadership in the digital performance and APM market, here.

    Follow Dynatrace on:

    About HCL Technologies

    HCL Technologies is a leading global IT services company working with clients in areas that impact and redefine the core of their businesses. Since its emergence on global landscape after its IPO in 1999 and listing in 2000, HCL Technologies, along with its subsidiaries, today operates out of 32 countries and has consolidated revenues of US$ 6.1 billion, as on 31st December 2015 (on Calendar Year basis). HCL focuses on ‘transformational outsourcing’, underlined by innovation and value creation, offering an integrated portfolio of services including Enterprise Digitalization, Internet of Things, Engineering Services Outsourcing and Next Generation IT Outsourcing that focuses on transformation-led infrastructure services, applications services and business services. HCL leverages its extensive global delivery capabilities and integrated innovation labs across the world to provide holistic, multi-service delivery in key industry verticals including Financial Services, Manufacturing, Telecommunications, Media, Publishing & Entertainment, Retail & CPG, Life sciences & Healthcare, Oil & Gas, Energy & Utilities, Travel, Transportation & Logistics and Government. With 103,696 professionals from diverse nationalities, HCL Technologies focuses on creating real value for customers by taking ‘Relationships Beyond the Contract’. For more information, please visit www.hcltech.com.

    For Sales and Marketing Information:

    Dynatrace, 404 Wyman St., Suite 500, Waltham, MA 02451, 781-530-1000, http://www.dynatrace.com

    Dynatrace Press Contacts:

    Kayla Siefker, Global Public Relations, 313-227-3092, kayla.siefker@dynatrace.com

    HCL Press Contacts:

    Meenakshi Benjwal, HCL Corporate Communications, Meenakshi.benjwal@hcl.com