The evolution of DevTest Labs with DTAP environments, cloud, containers, toggles and serverless platforms. New platform capabilities and architectural patterns will change the need of a DevTest Lab.
Dev/Test Labs are used in software development for decades. Different types of environments are helping teams with continued integration, deployment and testing while delivering business value. Maintaining proper environments for these activities is known as a must-have practice for DevOps teams in Application Lifecycle Management.
Multiple environments (or stages) are used by teams. The development environment (or better an integration environment), the Test environment , Acceptance environment and the Production environment are often the minimal set used by teams. Wiki
It is very difficult for teams to keep up with this good practice of maintaining environments, for on premise infrastructures it is often impossible. Production is more important, you never get the correct configuration, the infra guys never have time, patches are forgotten, no money, no time to recreate an environment after a test, etcetera. I think you all know the challenges.
The Cloud helped teams enormously with their environment needs. It gives teams the capability to create environments themselves. Scripting environments with Chef, Puppet, Vagrant PowerShell, ARM and more made it even easier for teams to re-create infrastructures over and over again on a cloud platform.
But still challenges like environments aren’t the same as on premise. Steep learning curve on scripting and infrastructure knowledge, need for a hybrid connection between on premise and cloud for deployments, test runs and others.
Solutions and services like the Sogeti OneShare service, Azure DevTest Labs are supporting teams using the Cloud for their environments needs,making it easier and more controllable to use environments on Cloud.
Another DevTest Cloud solution, which takes a lot of attention in the DevOps world are the container based environments. Docker, first focused on Dev Test now gets more and more mature that it is a solution for production solutions. Container solutions have many benefits and solves the challenges of running equal environments in development and test stages. But when you want the full flow of DTAP stages, you also need a container based system in production. Not something every company wants and can with all the internal decencies.
Software toggles, for controlling visibility of features for end users, are a common solution. A feature, service, piece of business value, deployed on a production environment, is switched on or off for specific users or DTAP stages. Canary releases and A/B testing are practices used with toggles.
Having the code only deployed once, in production, and control the stages via toggles removes the need of a DevTest Lab. Although you still can use it, but it is double work and adds to unnecessary costs.
Toggles require a clean separation of business value and system functionality. A micro services architecture together will make a release with toggles more valuable.
Toggles also require a way to manage them via releases. An extension that just was announced during //BUILD is for example https://launchdarkly.com/microsoft/
Developers going to production at the moment a feature/service is finished and controlling the usages and visibility to others via toggles, and monitor how this feature behaves will make a DevTest lab needless. But still there needs to be a way, a script that the team can use to create the ‘production’ environment from scratch, either for disaster recovery or experiments.
There is another Cloud trend which makes DevTest Labs go away – Serverless Cloud Compute platform services. Azure Functions, Azure Service Fabric, AWS Lambda, Google functions are all Serverless Cloud Compute platform services, real Platform as a Service.
It is as what the word says ‘Serverless‘ no server to think about anymore by the team, no challenges with the underlying infrastructure. There is still a platform, but it is managed by the cloud provider.
Serverless Compute Platforms have the capability to run multiple versions of the same functions and functionality side by side. This ‘run multiple versions’ capability makes it easy for teams to develop, validate or rollback new capabilities easily, which makes DTAP environments with a DevTest Lab redudant.
- DevTest Labs will stay relevant for at least ten or maybe more years, business software doesn’t change that fast. Business have investments in big datacenters, in monolith systems which are hard and expensive to change.
- These hard to change companies want to start adopting DevOps, want more customer engagement, more experiments and faster releases (see our Report on DevOps.). Start using the Cloud for team environments needs (read: Cloud usage flavors for Development and Test teams.), with support of Azure DevTest labs and Sogeti OneShare are a good choice to get more flexible in delivering software and to start explorer the Cloud benefits.
- With Serverless Cloud Compute Platform Services coming along, with their sophisticated deploy, update, versioning and rollback capabilities, a DevTest Lab isn’t necessary anymore. Releasing of components and functions needs to gets more attention the same with health analysis. Serverless is still pretty new and needs to be proven for business solutions first till a wide adoption starts.
- Breaking down your application landscape in more independent manageable and updateable components is never a bad decision. Controlling the visibility to end users of these components with a feature flag architecture makes releasing and testing in production smooth. Deploy these independent components in a container infrastructure makes it even easier for teams. Still be aware of the additional complexity of maintaining versions, containers and flags. The next step for business adopting a micro-services, flags, container solution will be Serverless.
- Removing the dependency for teams to use the hard to maintain DevTest Lab environments will make them faster. Without all the stages experiments are easier to execute, switch on and off via toggles or only make s specific version visible for specific users, as long as the data gathered is relevant for the business, use DevOps to the Max.