Author: Mike Vizard

  • 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

  • Akamai Gives DevOps Teams More Control

    Akamai Gives DevOps Teams More Control

    When most DevOps teams think about platforms, it’s usually a conversation about some form of software sitting on a server in a data center. But many web and mobile applications employ a content delivery network (CDN) as the platform on which they depend most to run. Akamai Technologies is moving to provide DevOps teams with much greater visibility into and control over what’s occurring across its namesake CDN.

    Ari Weil, senior director of industry marketing at Akamai, says CDNs now play a pivotal role in enabling IT organizations to deploy web and mobile applications in the cloud. To provide DevOps teams with more control over those deployments, Akamai is committing to treat the core CDN as code that can be programmatically invoked in addition to providing real-time visibility into applications running on Akamai and simplyfing the modification of applications in production, says Weil.

    As part of that effort, Weil says, Akamai is expending the range of application programming interfaces (APIs) that it exposes via toolsets spanning frameworks such as Terraform, Varnish and WordPress. The goal is to expand significantly the level of scripting and automation enabled by the Akamai CDN. Akamai is also making available a testing suite that DevOps teams can employ to test and fix applications in real time.

    Akamai is making it possible to deploy custom configurations and code across Akamai’s CDN in minutes, including the ability to remove content in seconds and revert to past configurations whenever necessary.

    Akamai has also released mPulse Lite, a free version of a digital performance management tool that identifies ways to improve application performance and the end user experience, and its IoS mobile application and companion IoS watch app to specifically optimize the performance of iOS applications accessing the Akamai CDN.

    Most DevOps teams are hyperfocused on what occurs inside the data center. But in the age of extended enterprise the level of dependency on caching and security services provided enabled by a CDN has never been greater. The fact that Akamai has also begun a more DevOps initiative is also testament to how far the DevOps movement has been able to extend its influence. Historically, providers of external services have been reluctant to provide any visibility into how their network services operate.

    Weil notes that it’s apparent the developers are also exercising more influence and control over IT. As such, providers of external services are now under more pressure to programmatically expose their services in much the same way as any other cloud service. In fact, many cloud service providers are leveraging their global footprint to make available CDN services that rival Akamai.

    Regardless of the CDN chosen, developers are under more pressure than ever from the business to optimize the end user application experience. Mobile and web applications are core to any digital business transformation initiative. In the face of that pressure, DevOps teams are finding that having more control over the CDN used to deliver those applications is now an absolute necessity.

    — Mike Vizard

  • BMC to Infuse AI Across Software Portfolio

    BMC to Infuse AI Across Software Portfolio

    At its recent BMC Exchange event, BMC Software announced it will be infusing machine learning algorithms and other artificial intelligence (AI) technologies across its entire portfolio of IT operations software.

    The first instance of BMC software to make use of machine learning algorithms is the latest version of TrueSight AIOps platform, which ingests data from multiple data sources to automate processes across BMC service desk, IT operations and tools for managing DevOps processes. BMC also is working with IBM to employ the cognitive computing services known as the IBM Watson cloud service across its portfolio.

    In addition, the company launched TrueSight Cloud Cost Control, a tool for managing and tracking usage of cloud services across multiple providers, and BMC SecOps Policy Service, which easier to embed compliance and testing via an external service that gets included in their software development processes.

    Finally, BMC announced it has signed an alliance with Amazon Web Services (AWS) under which the two companies will work to accelerate the migration of application workloads to the AWS public cloud.

    Dan Streetman, a senior vice president for worldwide sales and marketing at BMC, says his company is developing a product strategy around three major themes:

    • IT organizations will require management tools that will work across multiple clouds;
    • As part of general “shift left” developers now expect to be able to programmatically invoke IT operations and security services; and
    • IT professionals now expect the tools they use to manage IT to have the same types of advanced capabilities that consumer applications provide via speech interfaces such as Apple Siri or Microsoft Cortana. Various IT and customer service desks also soon will use speech interfaces to provide a highly automated self-service experience to end users.

    In fact, given the complexity of the IT tasks that now need to be managed, Streetman says a race is now on between IT vendors to live up to those expectations. Much less of a concern, he says, is any notion that AI technologies might one day replace IT professionals that by and large are already overtaxed; rather, it is apparent that IT vendors are now being evaluated on their ability to maximize existing investments in IT professionals that are already in short supply. The real opportunity is to free IT professionals to enable them to concentrate on higher-value tasks.

    Naturally, it remains to be seen how various AI technologies will impact the management of IT. It certainly will take a while for IT administrators to put their faith in AI. But as those technologies continue to mature, there may soon come a day when IT professionals look back with wonder at all the things they used to have to accomplish one manual task at a time.

    — Mike Vizard

  • Google Launches Software Supply Chain Initiative

    Google Launches Software Supply Chain Initiative

    Maintaining the integrity of a software supply chain is an issue that has long bedeviled IT organizations. With the rise of microservices based on containers, however, this issue has become more acute. As a result, software supply chains are an issue that Google now plans to tackle.

    Google, along with JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security and CoreOS, is taking the lead on an open-source Grafeas initiative that aims to create a standard application programming interface (API) through which metadata about the software components that make up an IT environment can be more easily captured. The whole software supply chain issue has become even more challenging now that enterprise IT organizations regularly make use of open-source software within larger applications. There are now more dependencies on software modules that are being created and updated outside the IT organization, most of which are not prepared to keep track of the modules’ history.

    One of the first instances of Grafeas is going to manifest itself in the form of Kritis, a policy engine that Google has developed for the Kubernetes container orchestration engine. Because of its long history with Kubernetes, Stephen Elliott, product manager for developer platforms at Google, says Google tends to approach every issue these days through a container prism. But the expectation is that the Grafeas API will be more broadly applied to collect data about and enforce policies across a broad range of types of software components, he says.

    Elliott says that while there is no shortage of tools for managing software life cycle, each of those tools generate their own proprietary metadata. Grafeas promises to provide a consistent means to, for example, identity developers, determine when the code was checked in and built, what vulnerabilities have been detected, and what tests were passed or failed. Trying to manage those issues is at the heart of any approach to DevOps. A standard API would not only go a long way toward simplifying those issues, it also should also serve to make many of the tools DevOps teams rely on today more interoperable. That would also go a long way toward preventing IT organizations from finding themselves locked into a specific set of DevOps tools.

    Obviously, the launching of an initiative represents only the beginning of a process that should extend well into 2018. The number of IT vendors that have a vested interest in software supply chain issues exceeds that number that has signed on to the Grafeas initiative, and when this API issue is addressed by an industry standards body remains to be seen. Google is betting that as IT organizations become more familiar with microservices-based containers, there will be lot more support for addressing these issues now than anytime in the past. In the meantime, IT leaders should take some comfort in the fact that, at the very least, the IT vendor community is starting to better appreciate their software supply chain pain.

    — Mike Vizard

  • GitHub Applies Data Science to Managing Code

    GitHub Applies Data Science to Managing Code

    Over the last several years GitHub has emerged as one of the primary repositories around which application development now revolves. At its recent GitHub Universe 2017 conference, the company revealed how it is extending that central role to provide DevOps teams with the addition of a dependency graph that can be employed to alert DevOps teams when a module of code has been updated and a security alert service that will notify them anytime a patch has been made available for a specific module.

    Miju Han, engineering manager for data science for GitHub, says both new capabilities are examples of how the company is applying advanced algorithms and data science techniques to make it easier to manage DevOps processes that revolve around GitHub.

    In addition, Han says GitHub is making available a news feed through which DevOps teams can track updates to groups of modules stored in the repository, as well as a tool through which they can explore a curated set of modules.

    Han says his company intends to combine a variety of emerging data science tools to simplify the daily workflow that revolves around GitHub. As the repository has become more widely used, the sheer volume of code and related updates a DevOps team is supposed to track has become, in many cases, overwhelming. That’s why the company is now pouring resources in several data science research projects with an eye toward making it simpler to navigate the repository.

    The latest annual edition of an Octoverse report published by GitHub finds that there are now more than 24 million developers in 1.5 million organizations around the world accessing 67 million GitHub repositories. A total of 25 million of those repositories are public. The most popular programming languages in use across GitHub are JavaScript (2.3 million projects); Python (1 million projects); Java (986,000 projects) and Ruby (870,000 projects). In terms of pull requests, GitHub notes that Python surpassed Java in popularity in the last year. The company also notes that half of the largest companies in the U.S. based on revenue are employing GitHub repositories.

    There is no shortage of repositories being employed inside and out of enterprise IT organizations, including an enterprise edition of GitHub that the company claims has been implemented by 45 percent of the Fortune 100 list of the world’s largest companies.

    Arguably, the biggest challenging many organizations now face is trying to reconcile the various code repositories in use. Just about every provider of an application development platform provides access to a code repository. In addition, providers of everything from container frameworks to application lifecycle management (ALM) often provide similar capabilities. Keeping track of what version of any given piece of code resides where at any given time has become a significant challenge.

    The good news is that providers of repositories are starting to address that issue on their own platforms, which means it stands to reason that one day soon tools for managing code across heterogeneous repositories may not be all the far off. In the meantime, DevOps teams can take some comfort in the fact that the management tools they rely to manage all the code are about to become a whole lot smarter.

    — Mike Vizard

  • CA Technologies Positions Automic at the DevOps Core

    CA Technologies Positions Automic at the DevOps Core

    After acquiring Automic earlier this year, CA Technologies suddenly found itself with an embarrassment of IT automation riches. Now the company is moving forward by further integrating the Automic IT automation platform with the rest of the portfolio of tools and services that it says are required to construct a software factory.

    Ron Gidron, technology evangelist for Automic, says the latest version of Automic increases the number of integrations with the rest of the CA Technologies portfolio to include support for CA Test Data Management, Service Virtualization, Privileged Access Governance, Application Performance Management and Veracode application security software, among others.

    CA Technologies has made it clear it intends to make the release automation software originally developed by Automic the foundation of its overall DevOps strategy. Most of that effort is now focused on integrating the various elements of the CA Technologies portfolio. Longer term, CA Technologies will eventually move to rationalize any duplication in functionality.

    Version 12.1 of Automic also brings forward orchestration tools and self-service capabilities to enable developers to provision resources within guidelines defined by IT. Gidron says that while there will always be a need for IT operations specialists, CA Technologies is making a concerted effort to “shift left” to provide developers with more programmatic control over the IT environment. To facilitate that process, Automic and the rest of CA Technologies have been investing in creating a standard set of external-facing REST APIs, which also will be used to make it easier for products and services created by the company to consume a wide variety of external data and metrics.

    Via acquisitions and internally developed software, CA Technologies is clearly trying to unify application, infrastructure and security management with the context of a single DevOps framework. The company doesn’t plan to force organization to consume that entire stack of software. But it will try to make acquiring as much of its portfolio as financially attractive and frictionless as possible to drive what the company describes as intelligent automation across a modern software factory. Driving that need is the realization that just about every company in every industry is now dependent on some form of custom software to drive one digital process or another.

    The rate at which CA Technologies has been expanding its DevOps portfolio via acquisition is a major contributor to what appears to be a wave of consolidation starting to occur across the DevOps category. Regardless of how advanced any organization might become in terms of building a software factory, major IT vendors realize that it’s only a matter of time before IT organizations start to pressure them to bundle more DevOps-related functionality together. In fact, the line between what’s DevOps today and tomorrow versus what was considered traditional IT management appears to be getting more blurred with each passing day.

    — Mike Vizard

  • With Distelli Technology, Puppet Expands DevOps Portfolio

    With Distelli Technology, Puppet Expands DevOps Portfolio

    At its PuppetConf 2017 conference, Puppet made it clear its ambitions now extend well beyond its namesake IT automation framework for IT infrastructure. On the heels of acquiring Distelli in September, the company announced it is adding several products to its portfolio based on technologies developed by Distelli.

    The new offerings include Puppet Pipelines for Apps, to automate commits; Puppet Pipelines for Containers, to automate the building of Build Docker Images from a source repository and then deploying them on a Kubernetes cluster; and Puppet Container Registry, to host Docker images and unify views of them regardless of whether the repositories are local or remote.

    At the same time, the Blueshift platform developed to automate deployments of container platforms such as Kubernetes, Docker Swam and Mesos is also being enhanced. The Kubernetes module now installs the container cluster in a more secure way that is also highly available. The Docker module adds support for Puppet Code Manager, Docker Swarm mode and Docker Secrets. A Kream tool makes it easier to deploy Kubernetes and Helm, a package manager for Kubernetes, at the same time. Helm also now can manage applications deployed on Kubernetes.

    In addition, the company announced Puppet Discovery, a tool that makes it simpler to identify infrastructure distributed across a hybrid computing environment, and Puppet Tasks, which employs new open-source agentless software dubbed Puppet Bolt to automate entry-level IT tasks. Bolt is capable of running existing scripts written in any framework and executing them on any platform that Puppet supports.

    The company is also adding a Task Manager to Puppet Enterprise that makes it easier to manage ad hoc tasks and executing them across hundreds of Puppet nodes. The latest release of Puppet Enterprise includes tools for inspecting packages deployed on and a tool to simplify configurations of those nodes.

    Puppet has also expanded its alliance with Splunk to tighten integration between the two IT operations’ platforms, and formed new alliances with Baracuda Networks, CloudPassage, Conjur/CyberArk, Cumulus Networks, Electric Cloud, F5, Intelliment Security, Onyx Point, Praecipio Consulting and Sensu. In addition, the Puppet module for the Microsoft Azure cloud has been updated to provide access to more disk storage, expanded networking support and support for Azure tags.

    Tim Zonca, vice president of marketing and business development, says with these products Puppet should no longer be considered a one-product company. It is now committed to developing a full range of DevOps management capabilities. That’s significant, notes Zonca, because today there is too much tension between IT operations teams and developers caused by silos of automation across various DevOps processes. As part of that effort, the company is also committing to start to synchronize the release cycles of the various elements of its portfolio.

    As DevOps continues to mature, the line between how infrastructure, applications and security are managed continues to blur. Many IT organizations prefer to acquire a set of DevOps tools from one vendor because it simplifies purchasing and support. Over time, those vendors combine those tools into an integrated suite that aims to unify the management of infrastructures, applications and security. Most vendors today are a long way from unifying those functions, but a wave of consolidation across the DevOps sector suggests the race is on to provide a unified DevOp stack capable of being employed across multiple platforms.

    The percentage of IT organizations that make extensive use of IT automation frameworks such as Puppet is relatively small. Much of the resistance to IT automation frameworks can be attributed now to simple inertia. But as the size and scope of IT environments exceed the capabilities of an internal IT team to manage manually, it’s now only a matter of time before reliance on IT automation increases.

    Puppet and other vendors also have infused their platforms with machine learning algorithms to expand the scope of what can be automated within an IT environment. In general, Zonca says reliance on those capabilities tends to increase in time once the DevOps teams gains confidence in the algorithms’ abilities to make the right decision. Until such time, Zonca says most IT professionals employ those algorithms to either present them with a series of suggested options based on the most recent events that have occurred. Given the nearly infinite number of possibilities that can be inferred from those events, most DevOps teams already are going to need all the machine learning algorithm help they can get.

    — Mike Vizard

  • Cloud Foundry Study Confirms Accelerated App Development

    Cloud Foundry Study Confirms Accelerated App Development

    When it comes to accelerating the development of applications, having a standard set of runtimes can make all the difference. A new study of 753 IT professionals conducted by ClearPath Strategies on behalf of the Cloud Foundry Foundation (CFF) finds a marked decrease in the time it takes organizations using the Cloud Foundry platform-as-a-service (PaaS) environment to develop code—just 18 percent need three months or longer, compared with 51 percent of respondents that don’t use the Cloud Foundry Application Runtime. And, according to the study, the 46 percent of responding companies that use the Cloud Foundry Application Runtime see application development times of less than a week, compared with only 16 percent of non-users.

    Abby Kearns, executive director for CFF, says use of Cloud Foundry Application Runtime has expanded considerably in the last year. Nearly half (45 percent) of the respondent have been using the PaaS environment in the last year. The survey also finds that more than half (51 percent) now have more than 10 developers employing Cloud Foundry Application Runtime, while 28 percent now have more than 50 developers.

    Kearns says those results are noteworthy because it shows that CF is now being used for a lot more than simple proof-of-concept projects. In fact, Kearns notes use of CF to develop a broader range of cloud-native application is increasing. The study finds half of Cloud Foundry users currently use containers, with another 35 percent evaluating or deploying containers.

    Kearns says there’s a high correlation between implementations of CF and adoption of DevOps processes. He notes that often organizations decide to implement CF to force the DevOps issue—a PaaS environment the size and scale of CF requires every process and function within an IT environment to participate in what has become a large-scale continuous application/continuous integration (CI/CD) platform operating at scale. Confronted with that requirement, Kearns says it’s not too long before the IT culture adjusts to that new reality by implementing a new organizational structure.

    CF is not the only PaaS game in town. But via CF distributions from Pivotal, IBM, SAP and others, use of CF has steadily grown, especially among larger enterprises that have the skills required to implement CF at scale. The survey finds that enterprise IT organizations with more than $1 billion in revenue account about half (49 percent) of all CF users. As deployments of the various elements of a PaaS environment becomes more automated, adoption of CF in small-to-medium enterprises should increase.

    In the meantime, IT organizations need think through the amount of time and money developers are wasting using alternative approaches. Not every IT organization appreciates the opinionated workflows that are baked into a PaaS environment. But given the length of time it takes to build applications using other platforms—as well the total cost of maintaining those environments—building and deploying applications at a higher level of PaaS abstraction is difficult to ignore. In fact, managing IT at a higher level of abstraction may eventually prove to be the difference between thriving and merely surviving.

    — Mike Vizard

  • Platform9 Brings Workflows to Serverless Computing

    Platform9 Brings Workflows to Serverless Computing

    Serverless computing frameworks are widely regarded as the next big thing in enterprise IT because they are based on an event-driven architecture that makes servers, storage and networking resources dynamically available as needed using a programming construct known as functions. But DevOps teams are challenged in finding a way to orchestrate all those functions in concert with one another.

    To enable the orchestration of those functions, Platform9 has added support for Fission Workflows to its instance of a serverless computing framework. Platform9 CEO Sirish Raghuram says Fission Wokflows will make it possible for IT organizations to craft complex applications made up of thousands of functions.

    On the one hand, serverless computing frameworks promise to make DevOps easier by eliminating the need to provision infrastructure every time a workload exceeds whatever amount of capacity that has been assigned to it. On the other hand, attempting to manage what could easily become thousands of functions in an IT environment is likely to make DevOps even more challenging than it is today. While not a new concept, Raghuram says Fission Workflows provides IT organizations with a familiar construct for managing functions.

    Benefits of Fission Workflows include an ability to reuse functions as well as being able to upgrade entire related sets of functions all at once. There are also fault-tolerant capabilities that make possible to recover and restart a workflow in the event of an infrastructure failure.

    Platform9 is specifically making the case for a serverless computing framework based on Kubernetes clusters that can be deployed on-premises or in the cloud. Platform9 also provides support for containers on an instance of Kubernetes, and Raguham says the company expects that IT organizations will mix and match containers and serverless computing frameworks as they see fit. For example, a container might invoke a function via an API call to run a stateless process while Docker containers are employed for all the stateful processes that require access to primary storage, he says.

    Raguham notes the trouble with serverless computing frameworks put forward by cloud service providers such as Amazon Web Services (AWS) is that they lock an IT organization into a specific platform instead of taking advantage of a portable cluster technology such as Kubernetes, which is backed by the Cloud Native Computing Foundation (CNCF). Kubernetes also provides the added benefit of a common platform for both containers and serverless computing, he says.

    It’s still early days for the use of serverless computing frameworks in the enterprise. Nevertheless, it’s clear they will need to be managed from a DevOps perspective alongside cloud-native applications running on containers and platform-as-a-service (PaaS) environments and legacy applications running on virtual machines and bare-metal servers. Given the fact that none of these architectures is likely to supersede any of the others anytime soon, IT organizations would be well-advised to start crafting a DevOps strategy now on the assumption that the overall IT environment is about to become even more complex.

    — Mike Vizard

  • Quest Software Aims to Mend DevOps Fences for DBAs

    Quest Software Aims to Mend DevOps Fences for DBAs

    It’s no secret there’s been a lot of contention between application developers, who are under pressure to build applications faster, and database administrators (DBAs), who are charged with providing those developers with access to data. Historically, developers have been dependent on DBAs to create schemas that would allow them to access data. But it takes time to build schemas, which is why many developers as of late have opted to employ a NoSQL database that don’t require a schema to access data. While that provides developers with some much-needed flexibility, most of the data stored in an enterprise today is still inside a relational database.

    To make it possible for DBAs to respond faster to developer demands, Quest Software has unveiled the Toad for DevOps toolkit, which makes it easier to include relational databases such as Oracle within a larger continuous integration/continuous development (CI/CD) process managed by frameworks such as Jenkins, Bamboo and Maven.

    Greg Davoll, executive director for product management and marketing for Quest database management solutions, notes the DBA traditionally has been the last holdout in embracing DevOps—DBAs didn’t really have access to tools that would enable them to participate in an agile development environment. The Toad for DevOps Toolkit address that issue by enabling them to test PL and SQL code during the application build process and ensure schema, data and database integrity with the context of a DevOps pipeline process, Davoll says, adding DBAs participating in a DevOps process can now also perform static code reviews and promote artifacts into a target environment to see how they perform in a production environment.

    The arrival of Toad for DevOps Toolkit is scheduled to coincide with the release of Toad for Oracle 2017 R2, which will add pass/fail status notifications within the Code Analysis code review process, a redesigned multi-schema compare and sync function, and an enhanced REST API as part of the Benchmark Factory testing tool to help automate performance testing within a CI/CD workflow. Over time, Quest Software will add similar capabilities across the full range of databases it supports, Davoll says. Quest Software just announced a Toad for MySQL offering to complement its existing support for Oracle and Postgres databases.

    Many of the decisions over the years concerning what database to employ have come down to which platform incurs the least amount of friction for developers to deploy. That hasn’t always resulted in the right database decision being made. In fact, it’s usually not too long before a developer wants to offload the management of the database back to the IT organization. Invariably, that results in DBAs having to manage multiple database platforms. While there may be a perfectly rational reason to employ something other than a relational database, that decision should be based on the attributes of the database rather than internal IT politics and purchasing processes. The challenge facing DBAs now is how to re-engage developers who have developed a bias against specific classes of databases, no matter how much critical data they may hold.

    — Mike Vizard