I was always thankful as an analyst that I didn't have to publish something right after I learned something new. I admired my editor brethren for their ability to submit articles mere hours after a presentation, but I appreciated being able to consume it, mull it over, consider the implications and develop reasoned conclusions before putting virtual pen to paper. I'm in a sort of hybrid role now, but I'm still glad I thought before I wrote because I would have totally embarrassed myself. And had I been on Twitter (shudder), my shame could have been even more immediate.
During Light Reading's Cloud Native World virtual event a couple of weeks ago, I listened to a presentation from Cisco's Bob Everson (see above) about how CSPs should prepare to become cloud-native. He posed the question: "How do you want to consume, deploy and manage" cloud-native applications? The options were a continuum, from a fully private cloud model where the CSP managed the full stack, a hybrid one, where they managed part of the stack, and a fully public model where CSPs consumed SaaS.
Part of this discussion included how CSPs can get to be DevOps focused. Everson said that CSPs need to determine how involved they want to be in the process. Some would prefer to be less engaged in the development and just want to consume the applications. At that time, I made a note: "Are we sure there is a business benefit of being involved in application development?"
All under one roof?
A few days ago, when I started to write an article based on that question, I planned to ponder the question, "do we want to recreate the old AT&T model, where equipment and services were all developed under one roof?"
I had mentioned in my farewell article last year that maybe it would be better if CSPs just did what they're good at doing – providing a utility service – and leave application development to others.
On the other hand, given the push for "standardized" cloud infrastructure, perhaps developing applications in-house would be the best approach to achieve competitive differentiation.
Of course, this approach would require new skill sets and create the possibility of disruption – not to mention increased risk – but the potential benefits just might outweigh these concerns. Would they write their own network functions? I highly doubt it. Especially not at scale. Might they write customer-facing applications that leverage their network assets? Possibly. And would DevOps be an essential component of this approach? Absolutely.
Part of the enticement of being cloud-native is that services will be decomposed so that microservices can be mixed and matched in new ways. Granted, I've been away for a while, but I haven't seen any evidence that this is taking place – at least not from the CSPs. It seems more likely the vendors might do that as part of a re-packaging exercise. Still, there is merit to this idea because it too might allow for more differentiation.
DevOps in translation
When I went back to Everson's presentation to make sure I captured things correctly, I realized that I had made a mistake. He wasn't talking about application development, but rather how CSPs would participate in DevOps processes around the applications they consumed from their vendors. This is a separate but related issue that is also relevant to the cloud-native discussion.
DevOps processes are key to the cloud-native value proposition. Presumably, having the same team develop and manage the applications will make for smoother operations in the long run. While CSPs may not be involved in DevOps of the applications they use, they may want to use DevOps to manage their cloud infrastructure, as AT&T does with Airship.
Using cloud technologies to make its operations more efficient makes a ton of sense for AT&T and is an approach I would expect to become common as CSPs continue on their cloud-native journey. During my research, I used to regularly ask DevOps-related questions, "are you using DevOps? Where? Why? Have you seen benefits?" Eighteen months ago, when I last asked, very few (as in fewer than 10% of respondents) said they were.
I think that's partly why there has been such movement to partner with hyperscalers, which gets us back to the point Everson made in his presentation. In some situations, it will make more sense for CSPs to leverage public cloud infrastructure and consume SaaS applications. One reliable driver in favor of the public cloud approach is the consistency of experience regardless of location.
Mike Dano recently spoke with AWS about the public cloud approach to delivering applications. As is often the case when discussing options, the answer will likely be that CSPs will use a mix of private and public clouds. CSPs are control freaks after all, and they won't want to have to guarantee services from an infrastructure they don't directly control. Also, for highly latency-sensitive applications, CSPs are more likely to have resources located closer to the end user than do the public cloud providers.
The road to cloud-native is full of choices for vendors and CSPs alike. Understanding the benefits and trade-offs will be key, and plenty of mistakes will be made along the way. As much as we want things to move quickly, there is something to be said for taking a few moments to consider before moving ahead. This is just as true for CSPs as it is for a (nearly humiliated) analyst.
— Roz Roseboro, Consulting Analyst, Light Reading. Roz is a former Heavy Reading analyst who covered the telecom market for nearly 20 years. She's currently a Graduate Teaching Assistant at Northern Michigan University.