Verizon is not solely a phone company anymore–it’s increasingly become a software company as well. As Josh Stone, DevOps and Cloud Architect explains it, the services Verizon is looking to deliver are higher up in the stack than the network, and to be competitive, the company has to deliver software faster to the market. Cloud Foundry is one of the ways Verizon delivers software faster.
Verizon started its Cloud Foundry journey in 2015 with five applications. Now, the Fortune 15 company with 170,000 employees has 1000 apps and 4000 containers running at any given time. Josh Stone has been with Verizon since the beginning of its journey with Cloud Foundry. We sat down with him to answer a few questions.
Q: What kind of applications are you building with Cloud Foundry?
A: The full spectrum. Pretty much everything except for mainframe systems are on the table for being able to get benefit out of Cloud Foundry. Some are internal-facing employee applications, some are external-facing applications providing data to customers. Really, a little bit of everything.
Q: What kind of feedback are you getting from developers?
A: With Cloud Foundry, speed has gotten drastically faster. When they work on Cloud Foundry, the infrastructure is no longer a roadblock.
Q: What other kinds of feedback have you heard from developers? Aside from speed, what else makes their lives easier?
A: Now they have the ability to prototype, innovate, and really work independently on what they think could be something worthwhile. They have the opportunity to create that thing, push it out in front of the business and then, it lives and dies at that point on its own merits. Before, the level of overhead that was required to get any idea in front of the business was so great that those ideas were never tried out. They never made it past paper.
Cloud Foundry gives us the opportunity to think about other ways to solve problems and it presents the opportunity to quickly try out that idea. That, I think, has been the biggest difference—being able to go from a mere idea to actually testing that idea, and then it becoming a real solution.
Q: Part of being able to build faster is also the concept of failing faster. Is there any resistance to that?
A: Around migration to any cloud-native 12-factor application, there’s resistance to failing faster. It’s a very new way of thinking. There are some areas where, as a developer, you start to cede control, and it takes a little bit of time and growing familiarity with the environment to understand that when you give up control, you gain so much speed in return. With Cloud Foundry, we get these ideas out into an environment and whether they succeed or fail, it’s such a short feedback loop that we can now stand behind this concept of testing and failing faster — because we aren’t losing time.
It used to take a long time to recover from failure. Now, with Cloud Foundry, we can fail faster and immediately move on to the next idea. I’d say we can take more risks because the risk itself is lower.
Q: Are you using Kubernetes?
A: We’re dipping our toes into Kubernetes.
Q: And what do you think about Cloud Foundry Container Runtime being able to manage Kubernetes?
A: There’s been a gap for a long time around being able to stand up and manage Kubernetes without having a PhD. BOSH helps close that gap. BOSH was really one of the reasons we went with our vendor. In the early days, BOSH was a first-class citizen there. Now, to see it expanded into the community and into use cases outside of Cloud Foundry is exciting stuff.
Q: What’s the real value of Cloud Foundry and developing things this way?
A: We know a culture shift is happening. We know the shift to microservices and cloud-native architectures is happening. Cloud Foundry, for its opinionated nature, has helped really push us down that path.
Q: I would assume security is a really important issue?
A: Yes. Cloud Foundry helps keep our workload secure just because those containers are so short-lived, in the event of an issue, we kill it off and we get a new one. We no longer have these long-standing vulnerabilities.
Q: Are you using it on multiple clouds, mostly private clouds, or some public?
A: We’re using Cloud Foundry both on-prem on a couple of different infrastructure providers, as well as up in the public cloud. Once we made the decision to go into public cloud, Cloud Foundry has been a vehicle for us to do migration from the data center to public cloud because it’s a like-for-like experience. We’ll probably end up seeing that same experience as we go from one to two public clouds.
Q: On the issue of talent, training, and finding the right people to hire — do you hire externally or train people from within?
A: We’ve been training from within. A lot of our team had a strong background as system administrators or from an operational role, but within Verizon, our Cloud Foundry team has been one of our first full-stack engineering teams. With the number of different technologies that make up the platform and that the platform integrates into, you really need to be a subject matter expert in the entire stack.
Q: Do you have any kind of internal training?
A: From a developer’s side, we are leveraging dojos or labs, bringing teams through on rotations not limited to Cloud Foundry as the tooling, but in general, looking for way to level up on new modern tooling. Cloud Foundry is in the discussion if it fits that application’s use case.
Q: Are you considering taking advantage of the training and certification program from the Cloud Foundry Foundation?
A: We’re definitely interested in Cloud Foundry certification as a way to both level up our operation side, as well as train those 15,000 Verizon developers on just what Cloud Foundry is and how it could be beneficial to their teams and their apps.
Resources:
- What Does It Take to Run Cloud Foundry at Enterprise Scale?
- How Verizon Uses Software to Break Into New Markets
