It’s project crunch time and all teams are working to meet the deadline. Multiple applications, interfaces and business functionalities need to be tested, bugs fixed and last-minute changes implemented.
The same problems come up every time. The number of environments is limited, and teams have to either wait for their turn to access one of the environments or perform their fixes and tests in an environment shared with other teams, running the risk of affecting each other. The project timeline is extended, and effort is wasted on failed tests, data corruption and clashes between teams.
Simultaneously, DevOps are struggling to overcome glitches in tests, fix bugs and establish processes for business as usual. Due to such high workload, environments are not regularly updated with software versions offering the latest fixes, which leads to even longer deployment cycles and more lost effort.
After the endless iterations of Unit, Integration, End-to-End, User Acceptance (UAT) and Operational Readiness Testing, the day of the roll-out finally arrives, with runbooks, quality gates and control centers used for overseeing the go-live. The software and its environment will have been tested a couple of times, but many steps require manual intervention and need thorough coordination between teams. Stress levels are high because the uncertainty is high, and the project stakeholders must now evaluate if they incurred risks due to this last-minute frenzy…
Sounds familiar? Many IT projects encounter these or similar bottlenecks. In such scenarios, Environment as Code (EaC) together with cloud services can greatly improve the situation by eliminating some constraints - for projects, end users (often within business units), project sponsors and project team members. In this blog, we look at how this works and what will be different in future projects.
Cloud computing has gained popularity in today’s IT infrastructure and cloud-based infrastructure has become good practice.
New software is built for the cloud and old applications are being migrated so that aging servers can be switched off. The key driving factors are cloud’s flexibility, scalability and, in many cases, reduced operating costs. These factors are central to considerations regarding application operation in the cloud.
But what does the environment that the development teams use to build and test their applications look like? Usually, between one and three environments limited to the application that is being developed are available. Live interfaces to other applications are rarely available.
It would take substantial effort from the development team to maintain, update and deploy further applications and interfaces for their build and unit test environments. Instead, the arguably more efficient strategy to remain siloed is used and thus uncertainty is accepted as part of integration testing.
Environments are setup for specific test use-cases. The cost of each environment is calculated in terms of setup, licenses of included applications, hardware (even when virtual machines are used) and operations. The more encompassing the environment the higher the bill, but the real price driver is the human labour underlying the aforementioned costs (except licenses).
So, what can be done differently and how will this benefit project sponsors, project teams and operations (before, during and after the hand-over)?
Environment as Code (EaC) technically rests on Infrastructure as Code (IaC) as a means for delivering functionality. Beyond utilizing a DevOps toolchain for code and infrastructure deployment, it implies providing fully functional environments consisting of a bouquet of servers and applications and may - depending on the audience - additionally include further topics such as Compliance as Code or Security as Code.
Infrastructure can nowadays be scripted including virtual machines, pods and containers, application deployments, network infrastructure and data deployment. Configuration is parametrized and the setup processes are managed by products for deployment and Infrastructure Management which are available on the market. Finally, the required data is automatically loaded.
Creating a new environment thus becomes a matter of executing a script. It requires applying the DevOps toolchain - not for an individual application or infrastructure, but for the entire environment an application is supposed to be embedded in.
Environments as Code will encourage teams to use the right tools, which is easier, faster and more efficient than leveraging the tools that are currently available. After adopting EaC, running a specific piece of code in a pod is just a couple lines of configuration away. In contrast, in an environment where every server is costly, the team faces an uphill battle for commissioning a dedicated server and may instead choose to reimplement the functionality in the current software stack.
The approach to utilize cloud technologies and DevOps practices in the project setup by using Environment as Code offers several benefits for the project delivery:
Capco has vast experience in project execution on any scale as well as DevOps practices expertise and the know-how of cloud technologies. We support clients in selecting the right tools and shaping processes to implement the desired change. Contact us to find out how your IT projects and ultimately your organization can benefit.