Tag: application delivery

  • NGINX Unveils Hybrid Application Delivery Controller Platform

    NGINX Unveils Hybrid Application Delivery Controller Platform

    NGINX this week announced it has developed a common framework for managing application delivery that can be applied across both monolithic and microservices-based applications.

    Announced at the NGINX Conf 2018 conference, the NGINX Application Platform has been rearchitected to provide traditional load balancing capabilities and a web application firewall (WAF), as well as a built-in service mesh for managing microservices and an integrated application programming interface (API) management platform.

    Sidney Rabsatt, vice president of product management at NGINX, said an update to NGINX Controller is at the heart of a much more comprehensive to approach to integrating load balancing, service mesh technologies and API management. Due out later this year, NGINX Controller 2.0 is based on a modular architecture that enables additional functions to be added via plug-in modules. The module for API management is slated for release in the fourth quarter, while the service mesh module is scheduled to become available in the first half of 2019.

    Rabsatt said it’s become clear IT organizations don’t want to replicate existing application delivery controllers just to manage microservices. There will never be such a thing as an enterprise IT environment this is made up entirely of microservices. The latest release of the NGINX Controller makes it possible to manage application delivery across the broad spectrum of applications that need to be addressed within modern IT environments, he said, noting that in effect, it’s a one-size-fits-all approach to managing application delivery via a single fabric.

    As part of that effort, NGINX this week also revealed that NGINX Plus R16, an enterprise-grade version of the core NGINX load balancing software, has been updated to apply load balancing algorithms to microservices running on Kubernetes clusters, in addition to support for Amazon Web Services (AWS) PrivateLink integration.

    Finally, NGINX announced version 1.4 of Unit, an open source web and application server that support TLS encryption, dynamic reconfiguration via an API and experimental support for JavaScript with Node.js to extend existing support for Go, Perl, PHP, Python and Ruby languages support. Full support for JavaScript and Java is planned for 2019.

    In general, Rabsatt said it’s clear organizations that have embraced DevOps are the most advanced when it comes to the need to unify management of application delivery. In fact, much of the recent success NGINX has enjoyed as of late starts with developers downloading an open source instance of NGINX to embed within their applications. As those instances of NGINX start to proliferate across the enterprise, more IT operations teams become exposed to the rest of the NGINX platform.

    It may take a while for microservices-based applications to achieve enough critical mass to force organizations to rethink their approach to application delivery. But it’s now a matter of time before organizations need to decide the degree to which they want to deploy standalone application delivery controllers and service meshes for microservices applications instead of pursuing a more hybrid approach. NGINX is clearly betting on the latter, given the number of legacy monolithic applications that will be running for years.

    — Mike Vizard

  • Automation: Achieving Faster Rollouts with Better Accuracy

    Automation: Achieving Faster Rollouts with Better Accuracy

    A changing landscape requires new processes

    At the recent Symposium/ITxpo, Gartner shared a list of technologies and trends that will be important for organizations to embrace and prepare for in 2017. These trends, which are listed in the report, “Top Strategic Predictions for 2017 and Beyond: Surviving the Storm Winds of Digital Disruption,” reinforce the breadth of technology that IT must support, roll out and engage with. This includes everything from the 100 million consumers who will shop using augmented reality to dealing with the roughly 21 billion endpoints expected to be in use in 2020.

    The report also demonstrates how fast technology changes directions. For example, Gartner predicts that in 2019, 20 percent of brands are expected to abandon their mobile apps. “Many brands are finding that the level of adoption, customer engagement and return on investment (ROI) delivered by their mobile applications are significantly less than the expectations that underpinned their app investment,” the report notes. However, this doesn’t mean less work. IT departments continuously have shift gears to support new processes, news apps and new technologies, such as the Internet of Things (IoT) and the massive amount of data that it produces.

    The dynamic needs of today’s businesses are driving organizations to increasingly adopt new technologies and applications that oftentimes don’t play nice with the existing set of infrastructure and legacy systems in place. So, while it’s clear that the technology landscape is changing, what isn’t so obvious is how IT and business decision makers should be adapting to an industry that is in constant motion.

    In-Steps DevOps

    To keep up, IT must implement agile methodologies that can adapt quickly to market changes. The DevOps mentality is making its way into many organizations and involves the development team creating, building and evolving products to ensure the organization is up to date, while the operations team confirms everything is running smoothly prior to a launch going live. This level of checks and balances isn’t just a nice to have, it’s a necessity—one mistake and the entire system can be brought down. Fostering a greater level of collaboration between development and operations makes it possible to efficiently and effectively build, test and correct new features and new products.

    While the shift to a more collaborative environment between the Dev and Ops teams can take time, using modern IT automation solutions can make this transition easier. Such solutions automate many of the routine—and even not so routine—elements of the application release process within DevOps. Many of the actions necessary to move from code to production—not to mention maintenance, testing and cleanup tasks—can be taken off the backs of developers and operations, saving them time so they can focus on higher-level projects and reduce manual errors.

    Finding the Balance Between Speed and Accuracy

    In 2012, Facebook announced it was increasing the speed at which it released code to twice a day, every day. As Chuck Rossi, director of Release Engineering at Facebook said, his team follows the advice “ship early and ship often.” Facebook continues to follow this model, and while the company certainly didn’t invent it, the model has caught on and is spreading among companies developing virtually every type of technology. The catch? It’s an incredibly time-intensive process and not every company has the resources necessary for a dedicated release team. Plus, a true shift to DevOps doesn’t happen overnight, especially since there is a ramp-up time for folks to get on board. For example, Phil Dibowitz, systems engineer at Facebook, told TechTarget that it “led its Chef team through a three-year process to rethink configuration management to scale on par with the web-scale company’s data centers.”  This took three years, he said, “not because of the technological change, but because of the structural change.”

    A slow transition to a new technology or new way of operating is a common occurrence because historically the production systems are cordoned off from development groups. While the Ops team has to ensure the rollout will meet certain standards, the Dev team wants to speed the process to begin the final rollout process as soon as possible. A happy medium exists, but if it isn’t found, things can go very wrong. Unfortunately, 2015 gave us two major examples of what can go wrong if products can’t speak to each other and rollouts are completed too early: Remember the New York Stock Exchange and United debacles?

    Breaking Constraints Through Automation

    This is where modern workload automation comes into play. Automation and solid change management allows IT to flexibly add on new technologies with automated processes for building, testing, upgrading and configuring IT—all while reducing the slack time between various steps. For instance, a workload automation solution should be able to trigger a build, deploy the build to the test environment, run the test suite and, assuming testing meets acceptable criteria, promote the build to production. If something does go wrong, necessary remediation can occur, and through monitoring and alerting capabilities, the required parties can be notified proactively.

    Additionally, automation solutions with pre-built integrations make it easier for disparate applications to communicate, creating an end-to-end approach to workflow creation and maintenance. As a result, IT organizations can minimize the risk of business disruptions and achieve a more fluid technology delivery to the business.

    Although it’s not a silver bullet that will solve all DevOps transition issues, automation does reduce manual intervention, which leads to fewer delays and errors and improves speed at which tasks are completed. However, beyond the technological aspects, there must be a clear understanding by both sides (the Dev and Ops group) on what their counterparts need—and this requires a high level of trust and coordination.

    While the specifics around the DevOps methodology certainly will change, automation will remain a critical piece of the process. With IT automaton, DevOps teams are able to refocus on critical IT business and operational processes, thereby reducing delays, decreasing errors and improving the speed at which tasks are completed. Ultimately, automation makes it possible to increase the speed of product releases and enable companies to stay ahead in the age of unpredictable customer preferences and ever-changing technological developments.

    About the Author / Mehul Amin

    Mehul Amin, a 21-year veteran of Advanced Systems Concepts Inc. (ASCI), previously held roles as product engineer and technical support manager and played an integral part in building the company’s workload automation solution, ActiveBatch. In his current role as director of Engineering, Mehul drives high-profile initiatives and leads both the Product Engineering and Release Engineering teams. Mehul received a master’s in computer science from the Stevens Institute of Technology.

  • Q&A: CNCF on Instilling a DevOps Culture, Part 2

    Q&A: CNCF on Instilling a DevOps Culture, Part 2

    In part one of this two-part series, devopsy.kinsta.cloud introduced the Cloud Native Computing Foundation (CNCF), a nonprofit organization with 49 members engaged in promoting the development of cloud native applications. Let’s continue with the CNCF’s thoughts on instilling a DevOps culture.

    devopsy.kinsta.cloud: Why do developers need the freedom to choose how they build software? What kinds and levels of freedom? Is this about approaches, development tools or something else?

    Brian Grant: All of the above: approaches, tools, languages … Different solutions work better for different workloads, scenarios, environments and people. Even new applications developed from scratch to be cloud-native aren’t typically developed in a vacuum—their developers may be familiar with particular languages or tools, the new application may need to interact with legacy applications; it may need to be built with and/or deployed onto existing infrastructure, etc. Often developers need to be able to adopt new technologies or approaches incrementally.

    devopsy.kinsta.cloud: How do you recommend providing this freedom to developers? How do you help provide it?

    Grant: Containers provide an ideal mechanism for providing this freedom, since they can be used to deploy both new and legacy applications, written in any language, built by any tool, into any environment. It’s a goal of the CNCF to foster an ecosystem of composable technologies, such as Kubernetes that facilitate the management of container-packaged applications.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: Because containers are small and fast, one application can be packed in each container image. Consequently, immutable container images can be created at build/release time rather than deployment time, since each application doesn’t need to be composed with the rest of the application stack nor integrated into the production infrastructure environment. This empowers developers to deliver deployable artifacts to operations.

    devopsy.kinsta.cloud: How is code reuse a need of the developer?

    Craig McLuckie: The vast majority of the actual code that is run in any given deployment is written by others. Only a tiny fraction of code in any given instance is actually written by the developer. The rest is everything from common libraries, to full OSS subsystems, to commercial software that systems, to adjacent software projects that provide some business functions. Developers need a common way to integrate with existing systems (when it makes sense) or to find and reuse existing code in a way that is controlled and operations-friendly.

    devopsy.kinsta.cloud: How do you recommend giving developers the ability to reuse code? How does your organization help with this?

    McLuckie: CNCF stands behind two technologies that are critical to code reuse. The first is the use of containers, which represent an intrinsically easy and predictable way to reuse even a relatively complex piece of software. The second is microservices-based architecture that make it easy to wire together systems and reuse existing services versus having to build their own.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    McLuckie: Containers make operations far more predictable and reduce possible avenues of error when deploying and updating systems. Rather than run potentially error prone imperative configuration systems to reuse code, containers are simple, lightweight and predictable, and reduce the potential for errors.

    Microservices allow for better operations specialization and create systems that are more intrinsically agile and easy to evolve. They allow for smaller teams that are focused on delivering a specific function versus having to align around large system boundaries. This creates a more productive and operationally viable environment.

    devopsy.kinsta.cloud: What is cloud-native? What does that mean?

    McLuckie: For CNCF, ‘cloud native’ is about a new pattern of application development that was pioneered by the internet companies, but that is equally applicable to developers and operators running more traditional workloads.

    We see three common attributes that make systems ‘cloud-native’:

    Container-packaged: Applications and processes are run in software containers as a unit of application deployment, which facilitates reproducibility, transparency and resource isolation. This improves overall developer experience, fosters code and component reuse, and simplifies operations.

    Dynamically managed: Applications are actively scheduled and managed. This radically improves machine efficiency and resource utilization while reducing the costs associated with maintenance and operations.

    Microservices-oriented: Applications are loosely coupled, with dependencies explicitly specified. This significantly increases the overall agility and maintainability of applications.

    Together, these three capabilities allow developers to build systems that are intrinsically agile and scale well. They significantly reduce the operational complexity of running an application, allowing operators to be more focused on application-level concerns and relying heavily on smart systems to do the operations heavy lifting.

  • Q&A: CNCF on Instilling a DevOps Culture, Part 1

    Q&A: CNCF on Instilling a DevOps Culture, Part 1

    The Cloud Native Computing Foundation (CNCF) is a non-profit comprised of some 49 industry participants that have come together to drive development and adoption of cloud-native applications and services. The CNCF is uniting such giants as Google, IBM, Intel and Cisco Systems to distill a collection of container technologies that end-user companies deem praiseworthy to reach its goal.

    The CNCF intends its membership to represent end users (the CNCF website lists one end user, Goldman Sachs), cloud and container technologies, online and IT services, and academic institutions.

    On behalf of the CNCF, Craig McLuckie, its Governing Board chair, and Brian Grant, its Technical Oversight Committee representative, weigh in on leading the DevOps transformation and instilling a DevOps culture in this two-part Q&A.

    devopsy.kinsta.cloud: How is the CNCF specifically involved in leading the DevOps transformation by instilling the DevOps culture, in the industry or in member companies, for example?

    McLuckie: We believe that at the heart of the DevOps culture is the need to reduce the friction and, indeed, the barriers between teams that build an application and the teams that run an application. Developers learn to think about an application as a living service that evolves continuously and rapidly to meet the evolving business needs. Operations is there to deliver the tools and environment needed for them to successfully drive their application.

    devopsy.kinsta.cloud: Why do developers need an environment that is safe to change? What kind of change? Safe how?

    McLuckie: Safe change has many potential meanings: The first kind of “safe” is about creating deterministic behavior in operations. Does the system handle a change correctly every time? If I make a change to two systems, will they have the same state? How about to 1,000 systems? It’s important to focus on creating strong determinism by removing the moving parts in a production deployment.

    The second kind of “safe” is about being able to validate that a change is good—not just in pre-production environments, but in the actual production environment—with a simple and deterministic rollback. It is important to make it trivial to replicate environments, and offer a way to run a simple experiment in production (e.g. route 1 percent of my traffic to this new version) with the option to deterministically roll forward or backward without effort.

    A third kind of “safe” is about being able to ensure that every change is deliberate. One of the problems we often see in production systems is “configuration drift” that isn’t driven through any kind of formal process. This should be addressed by creating a strongly declarative toolset that makes every change deliberate and trackable.

    devopsy.kinsta.cloud: How do you recommend providing these things that developers need? How do you help provide them?

    McLuckie: There are multiple issues like data, security governance and applications that need to be addressed. Additionally, companies want to deliver apps with high velocity. How do you solve all of this? A vendor-neutral organization that can harmonize emerging technologies is important for facilitating cloud-native. Given the large number of players in the marketplace with competing approaches, having an open source way to solve this is also important.

    Grant: Cloud-native infrastructure enables self-service and “hands-off” operation, including provisioning, deployment, scaling, healing, discovery, monitoring and more, with relatively little marginal effort for specific applications. By supporting open source projects such as Kubernetes and Prometheus that provide such functionality, the CNCF hopes to democratize high-velocity application delivery, which was previously achievable mainly by web-scale companies.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: In a DevOps culture, operators are both partners and customers of the developers. Developers take responsibility for meeting operational requirements: security, reliability, availability, scalability, efficiency, actionable monitoring and logging output, necessary configurability, compatibility with the production environment, etc. Cloud-native infrastructure provides mechanisms developers and operators need to facilitate and capitalize on those capabilities.

    Stay tuned for part two of the CNCF interview.

  • DevOps Debates: Image-Driven or Build-Driven Delivery

    DevOps Debates: Image-Driven or Build-Driven Delivery

    In the last 12 months, Docker and the containerization paradigm has challenged the foundation of some of the software delivery principles. People are resorting to things that were unheard of 18 months back and are now using them to successfully deliver software faster and cheaper. One such thing is the debate around build-driven delivery vs image-driven delivery.

    Over the last few decades, software has been packaged and built by a build system and tagged with a number; testers aligned their testing to the tag as the entity being tested and promoted them until it reached production. The build number was one of the most important tag for anyone to communicate about the status of the software in the delivery pipeline.

    For some time now—primarily due to Docker—several teams are moved to a methodology in which the image defines the version of a software. Every change in application program and deployment program will together create a new image, which is tagged and used as the version of the software to be launched for downstream use and finally into production.

    The debate then is, which option is better?

    Let me take a shot at this, and will invite your thoughts on this as well.

    For builds-driven delivery:

    1. Builds helps software to be tagged irrespective of the target hardware and other deployment options. It bundles all dependencies to ensure the software works when deployed to the expectation. This provides the development team a good hand-off point to move on to the next set of work, or sprint.
    2. Builds are much smaller in size, as the build bundles only necessary software needed by the application; hence, keeping them aligned with every change will not be a costly storage proposition.
    3. Versioning of artifacts and bundling them at run time has given tools such as maven to build and link dynamically, collecting all dependencies from the cloud. This makes it easier to keep a thin build and further reduce the redundant data to be kept in each build.
    4. Build repositories have matured over the years to provide a very easy way to version and mark dependencies so deployment tools can find new versions and automatically upgrade environments as needed.

    For images-driven delivery:

    1. Images takes the concept of build to the next level and ensures the variability in target hardware and deployment options are removed completely. It bundles the application as given in the build or built as part of the image creation and pushes the image as a build.
    2. Docker registries have started to compare and contrast themselves into a build repository by providing similar options for end users.
    3. The images-driven option provides a much better benefit of standardizing all your environments, removing the question,”It works in my environment; does it in yours?” If it works in the container in a developer’s laptop, it should work in production as well—everything is same, except for the size and number of resources.
    4. Images are much larger than builds, given that it has to now carry the system software and the application base software within the image. This option was unheard of earlier, but with container images coming down to megabytes, this is not such a big issue today. With layering sizes can be reduced much further as you start peeling the onion of dependencies. Take a look at this nice article by Brian on this topic.

    I guess the choice depends on where your application is in its life cycle, the questions teams should really ask are:

    a) Do we need to change too much to pick an option for an incremental benefit?

    b) Do I have the issue of environmental differences?

    c) Can I merge these options to get a hybrid solution going?

    But for me the larger question is, Which option would you choose, if you were starting from scratch tomorrow? I would love to hear your thoughts.

    Finally, irrespective of which way you lean, image-driven solutions is one of the best way to bring DevOps culture to a team: If the image works, the team has won; it doesn’t matter whether it was ops code or dev code!

     

  • F5 Releases 2016 ‘State of Application Delivery’ Customer Survey Results

    SEATTLE–(BUSINESS WIRE)–F5 Networks (NASDAQ: FFIV), today released the results of its second annual State of Application Delivery customer survey. Expanded to include feedback from more than 3,000 customers worldwide, this year’s report details how they are delivering applications successfully, how they keep data and users secure, and how hybrid cloud, software-defined networking (SDN), and DevOps are changing IT. In addition, F5 executives will host a series of live panel sessions and a webinar that will offer attendees deeper insights into the data. The first live panel session is on January 28, 2016, and will be hosted by F5’s CTO and EVP of product development, Karl Triebes. Sign up for the panels and webinar, and download the full report at: http://f5.com/SOAD.

    Survey Highlights

    This year’s report goes bigger and broader with input from F5 customers in the Americas (AMER); Europe, the Middle East, and Africa (EMEA); and Asia-Pacific (APAC) regions. A variety of industries are represented, with the widest participation from customers in finance, technology, telecom companies, and government entities. Key takeaways include:

    • Application services are essential and pervasive: Ten or more application services are used by well over half of respondents, who recognize that slow, unresponsive, and unsecured applications can have a substantial negative impact on revenue and operations.
    • Hybrid cloud is the new normal: The vast majority of respondents (81 percent) are moving toward a hybrid cloud environment to leverage the flexibility and potential cost savings it offers, especially for small and mid-sized organizations.
    • Security focus is on protecting users, data, and applications:Security professionals who have the highest level of confidence in their ability to ward off attacks are protecting clients, requests, and responses—the critical points at which data can be easily compromised.
    • DevOps and SDN are key to improving operational efficiency:Because DevOps and SDN enable automation and orchestration, they are both seen as key factors for reducing operating costs and improving time to market.

    “Applications are vital to business success. Used by every employee, applications contribute to greater efficiency, lower costs, and increased margins,” said Triebes. “Without the correct services to support applications, they won’t be available, secure, or fast enough to meet companies’ needs. The results of this year’s State of Application Delivery survey offer valuable insights into how customers are managing and implementing their application services within dynamic and complex IT environments.”

    Additional Resources

    The following items are available at: http://f5.com/SOAD

    • Download the full 2016 State of Application Delivery report
    • Summary infographic
    • Register for the free online live panel sessions and webinar

    About F5

    F5 (NASDAQ: FFIV) provides solutions for an application world. F5 helps organizations seamlessly scale cloud, data center, telecommunications, and software defined networking (SDN) deployments to successfully deliver applications and services to anyone, anywhere, at any time. F5 solutions broaden the reach of IT through an open, extensible framework and a rich partner ecosystem of leading technology and orchestration vendors. This approach lets customers pursue the infrastructure model that best fits their needs over time. The world’s largest businesses, service providers, government entities, and consumer brands rely on F5 to stay ahead of cloud, security, and mobility trends. For more information, go to f5.com.

    You can also follow @f5networks on Twitter or visit us on LinkedIn and Facebook for more information about F5, its partners, and technologies.

    F5 is a trademark or service mark of F5 Networks, Inc., in the U.S. and other countries. All other product and company names herein may be trademarks of their respective owners.

    Forward-Looking Statements

    This press release may contain forward-looking statements relating to future events or future financial performance that involve risks and uncertainties. Such statements can be identified by terminology such as “may,” “will,” “should,” “expects,” “plans,” “anticipates,” “believes,” “estimates,” “predicts,” “potential,” or “continue,” or the negative of such terms or comparable terms. These statements are only predictions and actual results could differ materially from those anticipated in these statements based upon a number of factors including those identified in the company’s filings with the SEC.

    Contacts

    F5 Networks
    Nathan Misner, 206-272-7494
    n.misner@f5.com
    or
    WE Communications
    Holly Luka, 415-547-7054
    hluka@we-worldwide.com

  • DevOps Is About Serving The Customer: Q&A with Shridhar Mittal

    DevOps Is About Serving The Customer: Q&A with Shridhar Mittal

    As a longtime proponent of continuous delivery and fast deployment schedules, Shridhar Mittal has advocated for DevOps operational patterns since before the DevOps moniker was even coined. It was a philosophy that stemmed from what he and his colleagues at what was then Interactive TKO saw happening in response to the service-oriented architecture movement: many organizations were slowing down their releases as opposed speeding them up, which was the whole “promise” of SOA, he says.

    “So we started a whole company around how do you change your development processes to get speed with quality in this new world of distributed architectures,” he explains.

    Since iTKO’s acquisition by CA Technologies in 2011, Mittal has used his current role as general manager of application delivery at the company to focus his efforts on evangelizing DevOps cultural shifts within the enterprise. He believes that DevOps is on the brink of revolutionizing the way IT departments function and in addition to his anecdotal evidence from frequent talks with IT leaders, he points to a recent survey CA conducted together with IDG for evidence. According to technology decision-makers, while only 7 percent of organizations have already adopted DevOps practices with enterprise-wide scope, it is gaining traction. Another 39 percent report that they’ve either implemented DevOps principles with limited scope or are in the process of adopting DevOps. And another 28 percent are either planning on implementing or are evaluating DevOps.

    devopsy.kinsta.cloud recently spoke with Mittal to discuss the mainstream uptake of DevOps, the biggest transition challenges and the attitudes about IT job performance in a new era of cooperation.

    devopsy.kinsta.cloud: Why do you believe that DevOps is gaining so much traction today?

    Mittal: I think the whole promise of DevOps is around better customer experience. Better quality for the customer, but in a much, much faster way than you could do it before. To me, that is ultimate goal.

    Ever since the whole consumerization of IT, everyone uses the web and everyone uses mobile devices, and there is no buffer in between the application and the end consumer now. Previously to that you used to have, in the call center, you had people who are using applications and the consumer never actually interacted with the application.

    So if it sucked, its internal people that had to deal with that–it wasn’t the consumer. Now, you cannot afford to have your customers have a bad experience because then you are going to lose business. One of our case studies is the .com part of a very large company–one of the Fortune 100. They had done a study that showed that for every one second delay in the response in the website dropped the conversion rate of sending someone to the next step of purchasing. It dropped significantly for every second.

    Think about it. If you’re doing a big marketing event, you’re sending hundreds of thousands of people to your website, and just because your website doesn’t respond properly, you lose that many more potential customers.

    That’s the kind of value that we’re talking about right now. Take a simple example, say there’s the launch of a phone and the telecomm company wants to release it at the same time the manufacturer is releasing it and the systems are not connected in time. They would end up losing hundreds of millions if not billions of dollars of business because they didn’t release it at the same time, and one of the competitors actually released on time.

    These are the kinds of the hundreds of millions worth of value we’re talking about. In the past, people thought about it as, maybe if I can get three percent or four percent more efficiency I can save x numbers of millions. But what I think they’ll really be looking for now is the ability to grow their business much faster.

    devopsy.kinsta.cloud: How can organizations start meeting the challenge of transitioning to DevOps?

    Mittal: Start small and then build up to the big There are at least three different on-ramps we talk about to get to DevOps. One is, just start with the development side of the word and decouple the development teams from each other so that they can do their things faster and still be able to deliver things on a higher quality. That’s using things like server virtualization and API testing. The second on-ramp is just improving your environment management, the release management capability. People today are spending tens or hundreds of man-hours creating and maintaining these environments then tearing them down and then bringing them up again.

    So figure out how automate that process where you can take so many man-days of work and bring it down to something that can be handled by one person and can be done as a self-service in a matter of minutes as opposed to taking days weeks or months to happen.

    And then the third on-ramp is to put more automated testing processes in place, for instances doing performance testing. Trying to do it in-house today is becoming more and more difficult because there’s never enough infrastructure internally to be able to handle simulating these tens of thousands and hundreds of thousands of people coming to your web site. It’s just not possible. So figure out ways to leverage cloud-based automated testing capabilities to support that.

    There are many different on-ramps and people can start from one or another and then start building to much bigger things. Start small and eventually expand to put it across the enterprise.

    It is also important to get the trust built between developers and operations through better visibility. The classic scenario is, the developers just want to write code, release it, then they want to go back to writing code again. Operations want to slow things down because all they care about is a stable environment. If I could get devs to have visibility and ownership and be measured on how the products are actually behaving in production and, same thing with ops, if I could give them visibility to what’s in the pipeline, what’s coming out, why is this coming out, what is the business case and how this impacts your business, they’ll all start feeling an ownership for the whole process.

    devopsy.kinsta.cloud: That brings up an important question: how critical is it to change job performance metrics in both development and operations in order to make DevOps work?

    Mittal: I think it’s very important. I think it’s not something that has to be done from the get-go but I think somewhere after you have done the first couple of projects and some of the people have started buying into DevOps, that’s when you have to fundamentally change the culture of the company. In my mind, that’s contracted behavior—and it’s not because people are coin-operated.

    I’m not saying this in a bad way. To me, people look at the way they’re comped as a way of understanding what their direction is. What are they being asked to do?

    So if they are not getting measured on quality, to them, that means “Just make sure that you just get things out as fast as possible and then if you have to roll back, then you have to roll back.” And if you’re not getting measured on constant speed, then that’s like being told by the executives that, “All I want you to do is have a stable environment; I don’t care as much about getting new stuff out there.”

    So there has to be changes in the comp structure, how people are rewarded, to really change the culture of a company.

    devopsy.kinsta.cloud: What other things need to be done on the line-of-business executive leadership side of the house to make DevOps work?

    Mittal: I think that the business side needs to be the driver to a large extent, because the business needs to say why something is important. If supply of IT capabilities is much less than demand, that means there has to be some kind of prioritization of work. And who’s making that determination? Who is doing the prioritization? To me, without a business context, you can’t be doing direct prioritization.

    I think the business has to be very involved in helping IT understand a prioritized list of what needs to get done. They don’t say how it needs to get done, they just need to say, “This is more important than this, and this is the impact to our business of that.”