Cloud Foundry PaaS shops hone software delivery process
Enterprises that have deployed Cloud Foundry platform as a service found it catalyzed new thinking about the application delivery process and other organizational practices.
BOSTON -- IT pros shared lessons learned from the ways a Cloud Foundry deployment prompted wider, ongoing organizational change at their companies.
At Liberty Mutual Insurance in Boston, IT staff deployed Cloud Foundry PaaS six years ago, which prompted the company to create an automated application delivery pipeline with Atlassian tools. Previously, sys admins manually transferred application WAR files onto systems, but they didn't have the same access to the infrastructure through Cloud Foundry.
"We had to move to a pipeline to move things to Cloud Foundry," said Jessica Schniepp, senior product owner for cloud and security at Liberty Mutual, at the Cloud Foundry Summit here this week. A project to simplify identity management and authorization for developers also prompted a reorganization of IT ops teams into product teams focused on services, such as identity, secrets and network security management.
Reshuffling IT teams laid the groundwork to improve Liberty Mutual's overall organizational efficiency. Eighteen months ago, IT leaders set out to remove a roadblock to newly hired developers' productivity: a complex identity management and security authorization process that typically took 22 days to complete.
For simple use cases, the company can now bring developers on board in a day. Developers used the company's improved application delivery process to add REST APIs to security and identity management tools, which simplified coordination between those tools.
CSAA trades ITSM for CI/CD
CSAA Insurance Group in Phoenix, Ariz., deployed Cloud Foundry after an "engineering revolt" among developers frustrated with the company's change management practices in a traditional IT Infrastructure Library (ITIL) IT service management (ITSM) framework.
Once developers had access to an automated application delivery process and a PaaS environment, they demonstrated that some ITIL axioms about change management were false, said Kyle Campos, DevOps transformation and cloud operations leader.
Kyle Campos of CSAA shares his feelings on change advisory board meetings at Cloud Foundry Summit.
ITIL's change management definition emphasizes the words "efficient" and "prompt," Campos said in a Cloud Foundry Summit presentation. "But when you look at the ITSM side of the house and the Cloud Foundry side, those words mean entirely different things," he said.
In the old change management process, approvals were supposed to create accountability, but often the executives who approved changes didn't know what those changes really meant, Campos said. At the same time, faster, automated application delivery processes are too reckless to be practical, according to this way of thinking.
"We've been able to move beyond rejecting these false dichotomies and into showing inverse relationships," Campos said. "In the new system, the volume and speed of changes actually reduces operational risk."
Cloud Foundry PaaS gives the application delivery team the control to make these less risky automated processes work, such as security validation tied to blue/green deployments, Campos said in an interview.
However, the process of organizational change and process optimization isn't as straightforward as rolling out a new technology.
"Some teams still don't see the problem with the old way of doing things," he said. "You have to keep reconquering the same ground, rewinning this argument every couple of weeks, but each time the scope [of process improvement] gets a little bigger."
Application delivery process improves with experimentation
Cloud Foundry PaaS has anchored the application delivery pipeline at the Royal Bank of Canada (RBC) for over two years, but that pipeline has undergone extensive changes to make microservices easier to deploy.
Processes designed for monolithic systems and infrequent releases with many moving parts create a high burden for release teams with microservices.
Reid Levesqueprincipal software developer, Royal Bank of Canada
As the company moved from batch jobs for data format changes between databases to a system based on Apache Kafka data pipelines and Elasticsearch, it also established separate code repositories for each of its microservices, swapped out bash for Python scripts, and redeployed Jenkins on Docker containers after a process of trial and error.
"Processes designed for monolithic systems and infrequent releases with many moving parts create a high burden for release teams with microservices," said Reid Levesque, principal software developer at the Montreal-based bank, in a presentation.
"With Docker, we don't have to worry whether the Cloud Foundry [command-line interface] is installed, how to scale out or if we're running the right version of Python," Levesque said.
Still, RBC's pipeline remains a work in continual progress. Chatbots will soon be added between the continuous integration and continuous delivery phases of the pipeline. There are discussions about how to run Docker containers in the Cloud Foundry environment, but no decision has been made about a strategic approach to container orchestration, Levesque said in an interview.
Reid Levesque of RBC celebrates his company's improved developer experience at Cloud Foundry Summit.
Analysts see the focus on process optimization here as a sign of maturity among Cloud Foundry shops. Many organizations encounter these growing pains as they absorb computing platforms designed for cloud-native apps, but Cloud Foundry customers seem further along on that path than most enterprises, said Carl Brooks, an analyst at 451 Research.
"Once you discover and deploy this kind of technology, the rest of the process is about addressing the limits of the organization," Brooks said. "If the organization isn't ready and is still dealing with monolithic apps, what you've deployed doesn't matter."
Dig Deeper on Systems automation and orchestration
