Cloud for IT projects: Resolving Bottlenecks with the Environment as Code
By Florian Neming and Tobias Otterbein
It is projected 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 must 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 a 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.
How is software developed today?
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 the 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 set up 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 labor underlying the aforementioned costs (except licenses).
So, what can be done differently and how will this benefit the project sponsor, project teams, and operations (before, during, and after the hand-over)?
Environment as Code
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, in which an application is supposed to be embedded.
Environments such 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 of 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.
What would future projects do differently?
The approach to utilizing cloud technologies and DevOps practices in the project setup by using Environment as Code offers several benefits for the project delivery:
Cloud scales elastically to resource demand. This concept is commonly applied to applications regarding storage space and CPU power. Using a cloud-enabled infrastructure and applying EaC concepts, creates elasticity that will benefit project execution.
Cloud services offer flexibility with subscription, while DevOps encourages automation. Environment deployments become a matter of minutes. Constraints in available environments will be a thing of the past for development, testing, and production alike.
Cloud services are more cost-effective. The higher costs incurred in times of high demand can be recuperated in times when no development is ongoing, and environments can be ‘put to sleep’. Cloud offers a wide variety of possibilities. Infrastructure can quickly adapt to the changing project needs in scale, functionality, and location.
DevOps helps continuous improvement. Whenever a new software version is released, the upgrades to environments practice upgrade procedures. Every time a new environment is set up, the go-live is tested by executing the deployment scripts and loading data.
DevOps encourages end-to-end responsibility. As the infrastructure is generated by code, breaks between development, test, and production environments are minimized and developers can take full responsibility for operating the code they developed.
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.
(About the author: Florian is a BI Consultant while Tobias Otterbein, Senior IT Consultant bei Capco and the views expressed here are their own with CXOToday not taking any role in the promotion of any technology or solution)