devopsy.kinsta.cloud

Tag: survey

  • 451 Research Report Highlights Value of DevSecOps for the CI/CD Pipeline

    451 Research Report Highlights Value of DevSecOps for the CI/CD Pipeline

    One of the compelling benefits of DevOps for many organizations is speed. Between breaking down silos, streamlining processes and automating routine tasks, the process of developing and deploying software can be significantly faster. A new report from 451 Research and Synopsys, however, points out the value of incorporating DevSecOps in the equation, especially with continuous integration/continuous delivery (CI/CD), and the pitfalls of prioritizing speed without also considering security.

    For the “DevSecOps Realities and Opportunities” report, 451 Research surveyed 350 enterprise IT decision-makers across the United States and Europe, focusing on organizations that have implemented CI/CD. The goal was to learn more about how organizations are implementing CI/CD and the role security plays in that equation.

    For most organizations, embracing DevOps and adopting CI/CD is about speed, not security, the survey found. Shocker! As per usual, security is typically an afterthought—something that might be nice to do if time and resources permit.

    Survey respondents indicated speed as a leading driver for and expectation from CI/CD. “The most organizations (36 percent) sought a 4x factor of improvement in time to deploy from their CI/CD workflows. A significant number (15 percent) sought a 5x factor of improvement. Another 7 percent sought more than a 5x factor of improvement, and 5 percent were seeking a 10x or greater factor,” according to the report.

    The irony is that organizations seem to prioritize speed over quality and/or security at their own peril. Maximizing for speed in the CI/CD pipeline without consideration for security typically leads to more bugs in the code, more downtime and increased time and effort to maintain and remediate applications.

    451 Research points out that as DevOps implementations mature, the focus will shift to what’s truly important. “We believe that as organizations evolve these processes, the focus will naturally move from ‘how fast can development teams iterate’ to ‘how reliably can we deploy high-quality, appropriately secure code each and every time,’” the researchers wrote. “That critical change in focus—that more mature view of risk management—will realign everyone’s expectations on what ‘4x’ really means.”

    Of those organizations that participated in the survey, only about half actually include some sort of application security testing as a function of the CI/CD workflow. Identifying open source software components with known vulnerabilities—also known as software composition analysis (SCA)—is ranked as the most crucial security component for CI/CD by survey respondents, yet nearly 40 percent of the participants admitted that they don’t do any SCA or insist they simply aren’t using any open source code. That seems highly unlikely, though, given that a recent report from Black Duck Software, “Open Source Security and Risk Analysis,” found that 95 percent of applications contain open source elements.

    “While some DevOps teams are starting to incorporate application security into their CI/CD workflows, driven by factors such as improved software quality, compliance and risk avoidance, there is ample room for improvement,” said Jay Lyman, principal analyst at 451 Research. “In many cases, security testing is not being integrated often or early enough in the process for organizations to fully benefit from reduced risk and rework headaches.”

    With security, it always seems a bit like the Bill Murray movie, “Groundhog’s Day”: No matter how many years security professionals have pushed, and fought, and screamed from the mountaintops that security needs to be woven into the foundation of software and integrated into the development life cycle rather than being tacked on with duct tape and chewing gum after the fact, organizations continue to insist on doing the things the harder—and more expensive—way. Hopefully, reports such as this will open the eyes of some organizations and they will break the cycle and start prioritizing security, recognizing that it is actually the best way to develop reliable code as quickly as possible.

    — Tony Bradley

  • Reliance on Cloud Foundry PaaS Increases

    Reliance on Cloud Foundry PaaS Increases

    A survey of 383 IT professionals published April 18 suggests the open source Cloud Foundry platform-as-a-service (PaaS) environment is gaining traction across the enterprise.

    The survey conducted by the Cloud Foundry Foundation (CFF) finds one-third of companies now have at least 100 developers using Cloud Foundry. The number of companies with more than 50 developers using Cloud Foundry rose from 20 percent to 47 percent in the last year. More than half the respondents (53 percent) report they have been using Cloud Foundry for less than two years.

    Companies with more than 50 applications on Cloud Foundry rose from 24 percent to 40 percent in just over six months and nearly a third (30 percent) of respondents describe their Cloud Foundry usage as broad.

    More than a third of Cloud Foundry users report they now save a few months or more per application development cycle, and 10 percent report saving more than six months. In addition, nearly a quarter report saving $500,000 per application development cycle, with 17 percent saying they have saved more than $1 million.

    The survey also finds there has been a sharp rise in interest in containers. A total of 13 percent of respondents already are using both the Cloud Foundry Application Runtime (CFAR) and the Cloud Foundry Container Runtime (CFCR), which is based on an instance of Kubernetes. Another 45 percent are evaluating CFCR.

    CFF CTO Chip Childers said he expects the Cloud Foundry PaaS and Kubernetes to be employed side by side for years to come. The CFF will continue to develop technologies that unify the management of Cloud Foundry and Kubernetes before there is an inevitable convergence of the two platforms, he said, adding that for now, a PaaS and container-as-a-service (CaaS) environment are serving different classes of applications. In the case of Cloud Foundry, that historically has been complex 12-factor applications. But Childers noted that the types of applications being deployed on Cloud Foundry is also expanding.

    Overall, Cloud Foundry reports more than 3,200 contributors participating in the community, with more than 60,000 commits in the last 12 months alone. According to Gartner, the total market value Cloud Foundry is approximately $3.1 billion.

    As application development continues to evolve, it is clear many organizations are embracing multiple platforms. Different business units within organizations want to be able to develop applications in the cloud or on-premises as needed. Ninety percent of ten Cloud Foundry users surveyed cited cross-platform flexibility as important capability, with 67 percent calling it “very important.” One of the core value propositions of Cloud Foundry is that it provides a highly portable platform backed by a consortium that includes IBM, Pivotal, SAP, SUSE and, now, Alibaba.

    In general, DevOps teams are embracing PaaS and CaaS environments to take advantage of higher levels of abstraction that don’t require them to manage the underlying IT infrastructure. The theory is that the more automated the environment becomes, the more resources there are to allocate to developing applications versus managing the platform.

    The trade-off is that each PaaS and CaaS environment is usually highly opinionated in terms of how the application development process should be managed. Because of that issue, many organizations still prefer to build their own platforms from the ground up. But as PaaS and CaaS platforms continue to mature, it’s likely many more organizations may decide there isn’t enough differentiated value to be gained by building a platform themselves.

    — Mike Vizard

  • Culture Becoming Bigger Issue as DevOps Goes Mainstream

    Culture Becoming Bigger Issue as DevOps Goes Mainstream

    Culture and resistance to DevOps processes appears to be growing at many organizations where DevOps projects have started going mainstream and involving more enterprise groups.

    Cloud automation vendor Quali recently surveyed 1,300 DevOps and IT professionals on some of the key barriers to DevOps adoption and found more respondents identifying culture as a top issue compared to last year. Twenty-two percent of the professionals in Quali’s most recent survey cited stagnant organizational culture as the biggest impediment to DevOps—a substantial 8 percent increase over the 14 percent who said the same thing last year.

    Quali interpreted the trend as likely the result of more groups getting pulled into broadening DevOps projects at many organizations. Innovation cultures and processes are being impacted in a broader manner as this is has happened. The trend shows why managing culture has to become a top-down responsibility, the firm said.

    “As technologies, processes and tools go mainstream, they touch a larger number of people who may need to change the things they do or how they do it,” said Shashi Kiran, chief marketing officer at Quali. “Eventually, change is never easy. It is actually a good thing that culture is there at the top, which means change is touching a lot of people across the organization, which eventually should be net positive.”

    An October 2017 report from analyst firm Forrester Research also suggests that more organizations are at least beginning to recognize the need for a cultural shift. Its research shows organizations are making culture a core focus when implementing DevOps projects. The focus is on shifting the mindset of teams to a culture of experimentation, where failure is used as an opportunity to learn and evolve processes instead of as a reason to add more controls and checks. “These mindset transitions are imperative for successful DevOps, and the market trends are encouraging,” Forrester noted.

    Other Barriers to DevOps Adoption

    While culture is a top barrier to DevOps adoption, it is not the only one. Quali’s survey showed application complexity and legacy processes to be major factors as well, with 20 percent and 21 percent respectively identifying the two issues as among their top barriers to DevOps adoption.

    The survey also found that DevOps teams at many businesses are still heavily dependent on their IT organization for infrastructure and continue to use a ticketing system to request and receive required resources.

    Nearly 50 percent, for instance said they had to wait for up to one month to get access to infrastructure resources that they had requested from IT, while the wait was even longer at about 24 percent of the organizations in the Quali survey. Only 27 percent—or barely more than 1 in 4—of the DevOps teams represented in the survey get access to requested infrastructure in less than one day.

    The numbers are important because slow access to required infrastructure often could have a big impact on the speed and productivity of DevOps teams, Kiran said.

    “DevOps teams don’t want to be bogged down by infrastructure. To a large extent, it needs to be invisible to them,” Kiran said.

    However, the fact is that environments need to be set up for DevOps and many times there is an infrastructure dependency on the back end. “This may be someone else’s responsibility, but the DevOps team ends up waiting for infrastructure to be set up and that’s frustrating for them,” he noted.

    Predictability is important in DevOps environment as is planning and being able to accommodate dynamic change environments, Kiran said. “Self-service is a preferred option where people are involved in environment buildouts, modeling different components and in testing and deploying them,” he said. One-third of the respondents, for instance, said they were strongly inclined to adopt platforms that enabled self-service automation.

    The Quali survey found that the degree to which an organization automates processes has a big impact on its ability to enable a self-service capability. More than two-thirds of the organizations surveyed had some form of automation. Of that, 33 percent had implemented a self-service capability for R&D, development and testing initiatives. Generally, organizations with automation and self-service reported improvements in production and agility compared to organizations that had fewer automation and self-service capabilities.

    So, where in the development life cycle is most of the automation happening in DevOps environments? The answer isn’t clear because automation is happening in a somewhat siloed manner, Kiran said. “Continuous integration is a starting point and larger organizations adopt continuous deployment as well, based on their internal methodology.” But, for the moment at least, there is no platform that can navigate creation of DevOps environments, expose them for testing and push them into production—all as a continuous life cycle—with full-on visibility, Kiran said.

    Kiran’s take on automation is similar to that reported by Forrester last year, which also found silos of automation continuing to be a barrier to DevOps success at many organizations. Forrester has identified “purposeful end-to-end automation” as foundational to DevOps success, especially at scale.

    According to the analyst firm, organizations that have implemented complete automation of the CI/CD pipeline have been able to enable rapid deployment. However, despite progress, plenty of opportunity still exists for automation and for deeper collaboration between infrastructure/operations teams and development teams, Forrester has noted.

    Quali also created an infographic illustrating some of the finer points of the survey, which can be accessed here.

    — Jai Vijayan

  • Barracuda Networks Survey: DevSecOps Is Hard

    Barracuda Networks Survey: DevSecOps Is Hard

    Organizations that have adopted DevSecOps processes may be making progress when it comes to improving cybersecurity, but it’s far from easy. A survey of 618 IT decision-makers conducted by Dimensional Research on behalf of Barracuda Networks, a provider of IT security software and appliances, finds half have adopted either DevOps, DevSecOps or a continuous integration/continuous development (CI/CD) platform. A full 93 percent of those IT decision-makers said they faced challenges integrating security into those practices.

    Top challenges cited include: Existing security technologies don’t integrate with application development environments (63 percent), application developers are not comfortable with security (48 percent), and security processes have not evolved (48 percent).

    Much of the frustration can be tied to reliance on firewalls that don’t feature application programming interfaces (APIs) or are natively integrated with a public cloud, said Tim Jefferson, vice president for public cloud at Barracuda Networks. Each cloud service provider has a unique environment that requires providers of IT security software to write code that natively integrates with that platform. IT organizations can’t simply cut and paste security controls created for on-premises IT environments mainly because the cloud provider has already implemented its own controls at the infrastructure level. The IT organizations need to develop their own controls for the application layer, each of which then must be layered on top of the controls put in place by the cloud service provider.

    In the absence of those capabilities, developers get frustrated because a firewall running on a virtual machine on a public cloud presents them with a graphical user interface (GUI) rather than an API. Developers in the age of the cloud are not going to engage with any technology that they can’t programmatically invoke via an API, Jefferson said.

    Not surprisingly then, the survey finds the most requested firewall capabilities requested are cloud-native integration (74 percent), ease of deployment and configuration by cloud developers (59 percent), ability to regulate traffic flows between on-premises IT environments and public clouds (56 percent) and distributed policy enforcement (53 percent).

    Because many IT professionals don’t have these capabilities many of them conclude on-premises IT environment are more secure than public clouds. More than half the respondents (56 percent) say on-premises cybersecurity is still superior to a public cloud. Clearly, there a lot of technical and emotional factors that go into those assessments, but regardless of the truth, perception remains reality.

    Regardless of the approach taken, however, organizations that deploy firewalls in the cloud are expecting to pay for those services on a consumption basis, which doesn’t always align with taking a firewall running on virtual machine and then deploying it on a public cloud.

    Jefferson said that as cybersecurity in the age of the cloud continues to mature, expectations are rising regarding the capabilities a firewall should be able to provide—especially when it comes to controlling the flow of traffic coming into and out of a public cloud.

    Obviously, anything to do with DevSecOps these days is still evolving. But whatever the cybersecurity future holds the relationship between on-premises and cloud security is far more nuanced than many appreciate.

    — Mike Vizard

  • Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

    Enthusiasm for DevOps Greater Than Actual Adoption, Survey Shows

    When it comes to DevOps practices, adoption continues to lag intention by quite a bit.

    GitLab recently surveyed some 5,300 software developers and engineers from mostly small and medium businesses around the world. The survey examined overall attitudes and perceptions around the state of DevOps, with a particular focus on uncovering any disparities that might exist between developers and IT management.

    The responses showed that many organizations are sold on the idea of DevOps, especially those who have implemented it. Sixty-five percent of the developers polled felt that using a DevOps workflow would save development time. An even higher 81 percent of managers shared that same sentiment.

    Organizations with an integrated DevOps strategy reported a high correlation between DevOps practices and overall team productivity. Development teams that deploy code on demand and spent more than half their time on new projects, for instance, had twice the rate of DevOps adoption compared to lower-performing teams. Higher-performing teams also generally considered automation of the software development life cycle a top priority and had access to better tools.

    Yet, the number of organizations in the survey that have actually implemented DevOps practices was far smaller than the otherwise enthusiastic support for it would suggest. In fact, only 23 percent of the respondents in the survey identified their team’s methodology as following a pure DevOps model. Thirty-five percent described their DevOps culture as being somewhat established.

    The low adoption rates are somewhat at odds with Forrester Research’s prediction about 2018 being the “Year of Enterprise DevOps” and may reflect the global nature of the survey base and the fact that many respondents were SMBs. Forrester found DevOps adoption to be around 50 percent when it conducted a survey of its own of 237 DevOps pros last year.

    GitLab’s survey found that while developers view DevOps as critical to software development life cycle, many have not implemented a DevOps workflow. Similarly, while over 95 percent of the survey respondents placed a high value on collaboration and 81 percent felt that such collaboration was easy to achieve, 25 percent said they did not have enough visibility into operations, security and production. And 42 percent reported unclear directions as one of their biggest challenges to getting work done.

    Culture continues to be a big roadblock. “It’s hard to get Dev and Ops to work together in a cross-functional way,” said Mark Pundsack, head of product at GitLab. “That challenge can be exacerbated by tooling. Disjointed toolchains lead to disconnected processes and barriers to communication that get in the way of working together.” Many developers in the survey reported using at least five tools to get their job done.

    Nearly 6 in 10 of the survey respondents (58 percent) pointed to ingrained practices as their biggest roadblock to adopting new tools and practices, while 50 percent blamed an inherent resistance to change.

    Interestingly, remote employees tended to have a more favorable outlook on how things were going with DevOps, with 67 percent saying they had good visibility into what others in the organization were doing compared to 57 percent of on-premises teams.

    “DevOps culture is clearly important to achieving high performance,” Pundsack said. “For managers … the survey identified the top challenge in getting work done was unclear direction and managers should be able to play a role in fixing that.”

    The apparent gap that exists between intent and adoption was not the only surprise in the survey, Pundsack said. Also unexpected was the extent of the discrepancy between how executives think their teams are operating, and what developers are actually saying. When asked how often they deployed code, 47 percent of managers were under the impression their organizations were deploying multiple times a day in contrast to the substantially smaller 39 percent of developers who said the same thing.

    That one area aside, though, developers and IT manager seemed better aligned on other issues in the Gitab survey. For example, more than three-quarters of both developers and managers feel they are set up to succeed and about one-third of them felt that they deadlines they have to deal with are fair.

    GitLab’s survey showed that most organizations expect to invest in continuous integration and continuous deployment tools in 2018, with nearly half strongly agreeing that CI can help speed up the development process.

    “CI can help alleviate blockers in the development cycle such as removing the manual process to verify code before deploying,” thereby allowing development teams to have a faster and more effective feedback cycle, Pundsack said.

    — Jai Vijayan

  • CA Technologies Survey Uncovers DevSecOps Challenges

    CA Technologies Survey Uncovers DevSecOps Challenges

    When it comes to infusing security concerns into a DevOps culture, most organization still have a very long way to go. A global survey of 1,279 IT leaders conducted by the market research firm Freedom Dynamics on behalf of CA Technologies finds more than half of respondents (58 percent) cited existing culture and lack of skills as hurdles to being able to embed security testing and evaluation within software development processes. Only 24 percent strongly agreed that their organization’s culture and practices supported collaboration across development, operations and security.

    More challenging still, less than a quarter of respondents strongly agreed that senior management would sacrifice time to market to make sure there is sufficient time to assess and repair software security vulnerabilities.

    Chris Wysopal, CTO for the Veracode portfolio of security testing tools CA Technologies acquired last year, said the survey results make it clear many organizations are still wrestling with the concept of DevSecOps. Many of them may be far along the path to building a culture around DevOps, but more often than not, security teams haven’t been included in those processes, says Wysopal.

    Because security teams are not included, many organizations wind up incurring substantial costs by having to address a much broader number of security updates to applications running in production environments. Organizations that have shifted security to the left as part of more comprehensive approach to DevSecOps discover and eliminate many more security issues during the development process.

    Wysopal said the survey bears out those conclusions. The survey finds the top 34 percent of respondents who report their organizations have been able to fully integrate security into their software development life cycles view security as an enabler of new business opportunities. These organizations typically exhibited 50 percent higher profit growth and 40 percent higher revenue growth. They are also 2.6 times more likely to have security testing keep up with frequent application updates. Wysopal conceded there’s no direct correlation between better security and better overall corporate performance. But at the very least, the results indicate that organizations that invest more time in DevSecOps are not adversely impacting financial performance.

    Organizations that embrace DevSecOps not only ship higher-quality software that reduces total cost of application ownership, they also typically are in a much better position to absorb the application update impact of unexpected security events such as Spectre and Meltdown flaws being discovered in processors. Because of the need to patch these flaws, most application update processes are now being stressed across the entire IT industry.

    It remains to be seen what impact the need to quickly address these flaws will have on adoption of DevSecOps. Wysopal noted the old way of addressing security issues during a waterfall-based approach to application development simply don’t work in the age of agile development. IT security teams now need to work hand in glove with application developers. The challenge now, Wysopal said, is getting the leaders of those organizations to come to terms with the impact that change may have on the pace at which software is developed. But given the critical role software now plays in critical business processes, organizations soon will come to appreciate the need to better balance the speed of application development speed against all the potential risks involved.

    — Mike Vizard

  • Red Hat Survey Sees Broad Adoption of Microservices

    Red Hat Survey Sees Broad Adoption of Microservices

    A new survey from Red Hat shows the extent to which IT organizations are moving to modernize their IT environments: More than two-thirds of respondents (69 percent) reported they are using microservices for both new applications and re-architecting existing ones.

    The survey, which includes responses from 168 IT professionals employing either Red Hat JBoss middleware or Red Hat OpenShift platform-as-a-service (PaaS) software, also confirms that IT organizations are employing a mix of legacy and emerging programming models to build and deploy microservices, says Rich Sharples, director of product management on the middleware team at Red Hat.

    Related content: DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    For example, Sharples notes, many of the microservices being deployed inside the same organization are being built with both traditional Java programming tools as well as so-called new stacks of software based on containers such as Docker. In fact, a full 87 percent of the respondents are either using or considering multiple technologies to build and deploy microservices, and nearly half the respondents (45 percent) said their organization is committed to “using the right tool for the right task” versus forcing the organization to employ a single technology, runtime or framework.

    The top five benefits attributed to microservices are continuous integration/continuous deployment (CI/CD), agility, improved scalability, faster time-to-market, higher developer productivity and easier debugging and maintenance. One-third of respondents (33 percent) said they have achieved two of goals by implementing microservices in the last two to six months.

    However, making the shift is by no means easy. The top four challenges associated with making the transition cited by respondents are developing/implementing in-house microservices tooling, reorganizing their organizations, working with vendor subject matter experts/using a vendor as a trusted advisor and purchasing or using a platform/solution.

    Microservices clearly are not for the faint of IT heart. Developing and managing a handful is relatively trivial. But managing them at scale can prove daunting to even the most skilled IT organization. Sharples says the most important decision an IT organization can make is determining what application workloads to deploy as a microservice. In many cases, IT organizations will be better off rewriting an existing application that they know how to run than trying to create an application from scratch employing microservices—not only to gain experience, but also to be able to compare the results achieved against what was previously delivered as a monolithic application, he says.

    In many ways microservices are the next logical extension of concepts that were pioneered with the advent of service-oriented architectures (SOA) more than two decades ago. The difference now is that microservices tend to be more granular and are often maintained by the developer rather than a centralized IT operations team. Regardless of what level of appreciation an IT organization may have for the history of computer science, the one thing that is clear is microservices are being more broadly adopted than advocates of SOA ever hoped to imagine.

    — Mike Vizard

  • 2018 Database DevOps Survey: Crises Still Prevalent, Mostly Avoidable

    2018 Database DevOps Survey: Crises Still Prevalent, Mostly Avoidable

    DevOps is not just a buzzword anymore, it’s a reality. With the unfolding evolution of automation and continuous delivery, DevOps practices have become an industry standard. Adopting technologies for rapid deployment has become essential for companies that wish to maintain their status as serious players in their industry, both from cost and production standpoints.

    But while DevOps is a significant piece of the IT puzzle across multiple industries, many have yet to adopt these crucial continuous delivery practices for their databases.

    In October 2017, DBmaestro conducted an online survey highlighting the challenges and best practices of companies using or looking to implement DevOps, with a focus on databases. The survey respondents are 244 IT professionals from around the globe, representing a variety of industries. The “2018 Database DevOps Report” revealed widespread adoption of DevOps practices on multiple levels across industries.

    DevOps Adoption Rates Increasing, Databases Still Lagging

    More than half of the companies surveyed (54 percent) are actively using continuous delivery practices and tools for application development in 50 percent or more of their IT projects. The same cannot be said for databases, however; to date, only 37 percent of respondents have adopted continuous delivery for databases.

    Continuous Delivery Adoption Rates

    Interestingly enough, while the rate of continuous delivery adoption for databases clearly lags behind that of application development, it remains an area of great interest for companies in 2018. In fact, 17 percent of survey respondents indicated plans to adopt continuous delivery for just that purpose.

    DBAs Face Huge Responsibilities, Huge Risks

    Slow adoption of continuous delivery practices for databases leaves companies exposed to costly errors. The report offers insight into the biggest challenges companies face with database changes.

    In many cases, the bottleneck in the process lies in the division of responsibilities: 59 percent of respondents reported that DBAs are the only ones in the company allowed to make changes to databases.

    Drafting database changes is a common task for DBAs, consuming approximately 22 percent their time, according to respondents. Deploying those changes, however, comes with big risks; when not done properly, deployments can cause significant downtime, impact the database’s performance and even result in data loss. It doesn’t help matters that database crashes remain disconcertingly common—almost one-third (28 percent) of survey respondents experienced a significant problem in the past month alone.

    Last Significant Problem in Database

    The good news is that many of the issues that can occur when database changes can be addressed through the use of release automation tools for databases, similar to what DevOps has been using for years in code development.

    Database continuous delivery not only assists in preventing mistakes; by simultaneously accelerating the release management process and making it more resilient, the results are faster database change deployment and fewer database errors.

    Database DevOps is (Still) the Solution

    Why do errors occur when deploying database changes? According to survey respondents, 19.3 percent attribute the biggest cause of errors to accidental overrides, followed closely at 19 percent by the use of invalid code. Rounding out the top three error causes, at 18 percent, are conflicts that occur between different teams.

    Database Change Errors

    Do these problems sound familiar? They should: Each of these issues has in the past been a challenge in the world of application code development. As far as application code development goes, version control management and automation of the application release process solved these problems. Therefore, it shouldn’t come as a surprise that the key to eliminating change errors lies in adopting these same methodologies and technologies for the database environment.

    Six percent of respondents reported that their company has no plan to adopt database DevOps practices. With database outages costing an estimated $8,851 per minute, can your company really afford not to?

    — Yaniv Yehuda

  • Survey Finds DevOps Teams Under Increasing Pressure

    Survey Finds DevOps Teams Under Increasing Pressure

    The fact that a much larger percentage of companies now recognize they are software companies that happen to specialize in a specific vertical industry is now putting a lot of pressure on developers, according to a new survey of 750 development team leaders in the United States and the UK conducted by Testplant, a provider of tools that automate application testing.

    The survey finds that 42 percent of the respondents claim they are expected to design, develop and test apps in an unrealistic amount of time. More than one-third (36 percent) also report they are not given enough time to ensure apps are properly tested before deployment, while 56 percent note that use of outdated techniques and tools is holding them back from meeting the demands of the digital world.

    Because of this combination of factors, nearly half the respondents (49 percent) say they are deploying applications before they go through an ideal testing amount of testing, and 45 percent admit to putting applications into production that will perform below initial requirements.

    Dr. John Bates, CEO of Testplant, says it’s a matter of time before IT organizations will have to rely more on tools that automate much of the testing process, as pressure on DevOps teams to roll out new applications and update existing ones is only going to increase. The survey respondents (60 percent) say most of the pressure to accelerate software development is being driven from within the organization itself. But nearly half (49 percent) say pressure comes from competitors. As more organizations realize their competitive differentiation comes from the software they develop, there’s now a lot more focus on accelerating application development, says Bates.

    The survey also notes that the applications being built are more complex than ever. Over the next 12 to 18 months, half the respondents (50 percent) say their company will develop more apps using components for an internet of things (IoT) environment. Well over half (58 percent) also say their company will develop more apps with artificial intelligence (AI) components, and 62 percent say their company will increase the amount of applications that incorporate machine and deep learning algorithms.

    When it comes to deploying applications, automation is ranked as the most critical challenge by 67 percent of the respondents, and 70 percent claim they are now more focused on automated testing today than they were in the past.

    In total, 75 percent of the respondents say that with access to better tools, the applications deployed by their team would have a greater impact on the business. A full 81 percent also say that with more time, applications deployed by their team would have a greater impact on the business.

    Unfortunately, more time for application development is luxury most business don’t have today. Not only is a wave of digital business innovation is making it easier for startups to not only enter markets, but companies that traditionally have focused in one market segment are now extending their reach to adjacent areas. The difference between surviving and being made obsolete now comes down the level of customer experience an organization can deliver by the applications it makes available to customers.

    Unfortunately, when it comes to those applications, customers tend to be unforgiving. Once bad application experience and many of them will move on to try an application developed by a rival. Bates notes that too many organizations still seem to think they can test their applications on end users on the assumption they can fix any issue that comes up rapidly. In reality, rather than participate in what amounts to an extended beta testing process, most end users will simply look for a better alternative application experience.

    In short, the difference between success and complete failure now hinges on the level of quality application testing that can be implemented in the shortest amount of time possible.

    — Mike Vizard

  • Maturity Models Help Measure the DevOps Journey

    Maturity Models Help Measure the DevOps Journey

    DevOps professionals often encounter clients who struggle with sorting through the “what”s and “how”s of where they are in their journey, and how they can either get started with—or improve upon—their current practices.

    As a project progresses, we often find that diving into a technical solution up front without taking a holistic view of where our clients are in the aforementioned journey will result in undesirable outcomes. That’s because no two projects or clients are alike, and there are a surprising number of dependencies within DevOps practices that must be satisfied before overall success is achieved.

    For example, a client who wants to jump right into a microservices-based architecture will have trouble without first implementing CI/CD practices and utilizing infrastructure as code. That’s where a measurement tool can come in handy, especially one that can help to identify a logical progression in these cases.

    Having seen more than a few clients facing this challenge, we set out to create a Maturity Model to provide an easy way to determine reasonable next steps in both helping clients improve practices and quickly assessing where they currently stand.

    To begin, we took a comprehensive look at the many ways we’ve helped clients with their DevOps practices, searching for common patterns that would help guide and characterize how an organization performed. Additionally, we examined our internal practices and procedures, using numerous projects we have done to self-evaluate the effectiveness of our teams and approaches. From there, we gleaned what we considered to be five distinct realms that constitute a comprehensive view of DevOps maturity and developed appropriate questions within the realms to evaluate performance.

    So who can benefit from engaging in a maturity evaluation?

    Anyone, really, at every level of an organization. To see where you are in your DevOps evolution, log on to answer a few questions and they receive easy-to-understand recommendations. We can discuss results in-depth with anyone who wants a more thorough understanding of where they are in their practice or more personalized advice. Or, just enjoy the exercise. Either way, the questions will help expose certain ways in which your practices can incrementally improve.

    About the Author / Matt Brewster

    Matt Brewster is DevOps Team Lead for Seattle-based Base2 Solutions. His proficiencies include deployment/build/test automation and infrastructure, systems integration and analysis, performance automation and analysis, infrastructure virtualization and containerization, aerospace information technology, software quality assurance and rapid prototyping. Matt’s DevOps/Infrastructure knowledge includes VMWare, AWS, Virtualbox, Docker, Vagrant, Ansible, Chef, Linux, Nginx and Jenkins.