Cloud Foundry: Built To Survive
Deliberately breaking applications just to make them more resilient is a process that either delights or frustrates developers. When testing one’s stack to get an idea of where potential issues are, ops teams may be reluctant to unleash chaos across their well-curated environment.
In this episode of The New Stack Analysts embedded below, The New Stack founder Alex Williams spoke with Cloud Foundry CEO Sam Ramji, as well as with Daniel Otte, head of platform engineering at scientific publishing company Springer Nature and Simon Johansson, who is a Springer Nature platform engineer. They discuss the ways in which Springer Nature has utilized Cloud Foundry, and the ways in which Cloud Foundry can help developers better understand that tearing things down may be the best way to build them back up.
On Resilience: Sam Ramji, Daniel Otte and Simon Johansson at Cloud Foundry Summit
The conversation can also be heard on YouTube.
Initially, Springer Nature had evaluated a number of platforms before settling on Cloud Foundry. The deciding factor was trust, which Ramji cites as the main focus for Cloud Foundry as a company. Simply put, it didn’t matter how well Cloud Foundry was going to solve the issues Johansson and Otte were facing at Springer Nature if there was no transparency.
“You have to start by building trust, and then you can start to talk about the technology. Because, as technologists we’re so frequently only educated on the technology, it’s a really important lesson. You build trust by listening, communicating, and delivering incrementally on people’s needs,” Ramji noted.
After facing a reality of, “VM vending machines,” the team at Springer Nature knew they had to find a solution to their code deployment and architecture woes.
“Inception of a project took weeks, you had to request machines and really set up the infrastructure. A lot of people refer to it as DevOps, I think it’s inefficiency, to be honest. I think we did a trade off by removing ourselves from the developer teams. We deliberately took a step back and decided to create a platform that would take care of all of this mess, so devs can focus on writing code,” said Otte.
Naturally, once Springer Nature got Cloud Foundry up-and-running its stack without an issue, they decided to take the next logical step in the process:
Breaking it.
@moanops @karlsimonjohan @sramji @alexwillams How @SpringerNature does scaling with @cloudfoundry pic.twitter.com/ZhpX0hxm2m
— The New Stack (@thenewstack) May 25, 2016
However, that wasn’t as easy as they thought it was going to be. “We haven’t been able to break Cloud Foundry. We tried really hard,” said Johannson.
Ramji expected that and welcomed developers to try to break Cloud Foundry in any number of ways. However, it’s surprisingly resilient. Powered by Cloud Foundry’s BOSH lifecycle management software, Cloud Foundry also sports a self-disruption platform called Chaos Lemur, made for developers such as those Springer Nature who may be trying break their stack on purpose.
Companies such as SwissComm took that a step further, creating their own platform called Chaos Heidi which they discussed at Cloud Foundry Summit 2016. Chaos Heidi is a cousin to Cloud Foundry’s Chaos Lemur and Netflix’s Chaos Monkey. These self-disruption platforms are built for leaving a trail of smoldering destruction where your application once stood. Ramji then explained that anyone can access the BOSH demo to test Cloud Foundry’s resilience, utilizing Chaos Lemur in an effort to blow up their own simulated stack before BOSH can bring it back from the dead.
“No matter how good or bad you are at technology, you can do the BOSH demo. Get on the tutorial, you’ll build BOSH, launch Cloud Foundry, then you’ll try to kill apps and take it down before BOSH can bring it back. You’ll end up fighting with BOSH. It’s amazing what happens when you wrestle with the resurrector.”
Cloud Foundry is a sponsor of The New Stack.
Feature image via Pixabay.