DevOps was predicted to grow dramatically in 2016. This definitely happened, especially in enterprises with large software portfolios (which is all of them). However, as more companies attempt to adopt DevOps for all their software development activities, rather than a few pilots, the gaps in DevOps tools are becoming much more apparent. I predict that we will see more enterprise-class DevOps tools become available in 2017, including cloud sandboxes, to address these gaps.
Two issues in particular require enterprise DevOps teams to look beyond simple DevOps toolchains:
1) One of the biggest issues that enterprises encounter is the challenge of getting all their many software projects working in a single DevOps pipeline. They have a mix of application teams that use agile development tools and DevOps practices and other teams that are not yet as mature in their DevOps capabilities.
2) The second issue faced by nearly all enterprises is their mix of legacy applications that were designed for the data center world and new cloud-native applications. Each type of application has its own architecture and dependencies on the underlying physical, virtual or container infrastructure. Supporting these different infrastructure requirements within a single DevOps pipeline is extremely difficult.
There are significant advantages for organizations that can get all their software development teams onto a single DevOps pipeline. This maximizes their ability to share “artifacts” – software components – across projects. More importantly, it allows the Ops team to accept delivery of new software and releases in a single consistent way. It is difficult for DevOps to realize its true promise if the Ops team is still required to support many different processes to manage software. Having one pipeline eliminates this issue.
Enterprises will begin to separate their DevOps pipeline from the individual DevOps tools. They will enable individual development teams to choose many of their own tools but require that those tools plug into a common pipeline. Mature DevOps teams will use the pipeline to deliver as frequently as multiple times a day while immature DevOps teams will use the pipeline to delivery several times a year. Regardless, the Ops team will receive software deliveries in a single consistent way.
The most difficult part of developing enterprise applications using DevOps is automating the creation of environments for development and testing those applications. Since most enterprises will develop and test a mix of legacy data center applications and new hybrid-cloud and cloud-native applications, it is nearly certain that the environments needed for developing, testing and operating these applications will be different. Legacy applications may have physical and virtual infrastructure dependencies. They often depend on a three-tier architecture with supporting network connectivity.
Next-generation cloud-native applications will often be built on container infrastructure using microservices architectures. These applications are more portable than legacy applications but also have dependencies on orchestration tools such as Kubernetes or Mesosphere in order to operate. In addition, microservices architectures require testing of their scale-out capabilities, and these distributed architectures are notoriously difficult to debug.
Development and test environments for all types of enterprise applications need to replicate the production environment; and for enterprises, the production environment is pretty complicated. So cloud sandboxes that automatically create replicas of production environments for use in development and testing will become a critical part of every enterprise DevOps pipeline. Even though legacy application environments are very different from next-generation cloud-native application environments, they can both be easily defined and automated using cloud sandboxes. This means that the tool for automating environments is common and can be called from common DevOps pipelines while still supporting a wide variety of different target environments.
What types of configurations and resources need to be in the sandbox? While there are many common components that must be provisioned and automated in a cloud sandbox regardless of the type of application, there are also some unique components and configurations for each target environment from legacy to migrating to cloud-native applications, as shown in the table below:
Until 2016, the focus of DevOps was on new application development efforts, pilot projects and cloud-native applications. The rapid adoption of DevOps methodologies and tools in enterprises in 2016 resulted in a realization that the DevOps tools are not enterprise ready. There is a real lack of understanding of how to migrate from legacy applications to next-generation cloud-native applications, and the current batch of DevOps tools demonstrates this. In 2017 and over the next three to five years, the major emphasis will shift to migrating applications between legacy and new environments. New DevOps pipelines and tools will become available to accommodate this shift.
Joan Wrabetz is CTO for QualiSystems. Earlier she was VP/CTO for EMC’s emerging product division. Joan has over 20 years’ technology executive experience. She was founder/CEO of Aumni Data, CEO of Tricord Systems (now Adaptec), VP/GM at StorageTek, founder/CEO of Aggregate Computing (now Platinum Technologies) and held management positions at Control Data Corporation and SRI International. She was a BlueStream Ventures partner, on the board of many startups and holds multiple tech patents.