Who is in charge of your new cloud deployments? Do you have a dedicated team that handles it from the start? Perhaps you’re just trying to keep up with the times and you haven’t converted your teams over to focused DevOps groups just yet. But most everyone says that the cloud deployments are handled by the teams that work on cloud. But what about cloud networking?
I had the opportunity to sit down and talk to the great folks over at Veriflow about this very issue. The sponsored a report from Dimensional Research that was published today that delved into some of the challenges that are associated with public cloud adoption. Jim Brear and Mike Kay discussed some of the report’s findings with me.
Survey Results
There were 337 respondents to the survey across many teams, including cloud, networking, and security. They were asked a variety of questions about public cloud. The results were pretty astounding. When asked whether or not the networking team is involved in new public cloud deployments, 60% said they were. That’s a good number, but it also means that 40% of the time the networking team has no idea things are being built and deployed in the cloud. Why is that? Well, in another question, 49% of respondents believed that someone other than the networking team was responsible for public cloud networking. That’s basically half. Imagine if 50% of your office thought that your networking team shouldn’t be consulted when deploying cloud networks!
And if you think the networking team is irritated, imagine being on the security teams. Deploying systems in the cloud is leading to huge security challenges. Of the respondents, 50% reported an increase in security incidents with cloud adoption. Almost 60% say they have no way to verify network segmentation in the cloud. A whopping 85% report that their public cloud deployments are non-compliant with security or regulatory postures.
The report goes on to detail how those networking and security issues are having a huge impact on the profitability of the business as it moves into the cloud. How could this be? Cloud is the answer to all our problems, right? How could it be less secure to use and create more hassles?
The answer, it turns out, is in the way that people deploy to the cloud. The first wave of cloud deployments were non-critical apps. DevOps and Cloud teams just wanted to figure out how to make this new cloud idea work for them. They moved non-essential workloads that could be offline for a period of time. Once they figured out how to keep everything running, they started moving the rest of the infrastructure much more aggressively. That meant more and more time was spent by the DevOps and Cloud teams uploading data wholesale without real planning.
Once those apps are in the cloud, they’re now the responsibility of Cloud/DevOps. That means the old silos are back, in a way. And since those teams see themselves as the primary point of contact for management and operations of those workloads, the networking and security teams feel shut out when it comes to ensure the proper operation of the systems. It has always fallen on the networking team to ensure uptime for all infrastructure and applications that access the network. And the security teams were needed to ensure that nothing was breached or stolen. Now, in the modern world, these teams act more like consultants than parts of IT.
Visibility Is Still Key
So, where does Veriflow fit into all this? Well, with the publication of today’s report, Veriflow is also announcing the release of CloudPredict SaaS. CloudPredict is designed to give teams visibility into cloud platforms and assurance that the networks are operating properly. This is a huge boon for networking and security teams that are tasked with keeping systems up and running no matter what, even when they don’t have control of them.
CloudPredict SaaS offers the ability for teams to visualize network paths in the public cloud to figure out which way the traffic is flowing. It can also verify that paths are segmented in such a way as to prevent applications from talking to each other or for specific data to be isolated for policy and compliance reasons. Veriflow can also take snapshots of your network and confirm that they conform to your own policies that are in place, all the while ensuring end-to-end connectivity for your systems across public and hybrid cloud environments.
In short, CloudPredict SaaS is going to help teams troubleshoot difficult networking problems and find security flaws no matter where they may be handing. And the ability for Veriflow to model the network and predict things like traffic behavior is a boon to help the cloud and DevOps teams see the need for specialized solutions like this. Just because cloud networking is the lowest common denominator doesn’t mean that they are easy to maintain. The DevOps teams have felt that they were always slowed down by the networking group. Now, CloudPredict SaaS lets the networking team take back some control of public cloud networking and introduce more agility and speed into operations.
Bringing It All Together
I’m happy to see that companies like Veriflow are jumping into public cloud networking. Things there aren’t as well architected as in traditional on-premises data centers. Instead, we’re still playing catch-up to get the visibility and analytics capabilities that we’ve enjoyed over the years. I think that CloudPredict SaaS is going to go a long way in helping those teams get what they need to make cloud networking a huge success.
For more information on CloudPredict SaaS, make sure to visit http://Veriflow.net/CloudPredict-SaaS/. If you would like a copy of the Dimensional Research report, you can register for it at this link. For more information on Veriflow, make sure to visit http://Veriflow.net.
Tom says, “…you haven’t converted your teams over to focused DevOps groups just yet.”
Following from the recent Twitter discussion, perhaps one factor is a difference in understanding what DevOps means. What would the responsibilities be of a focused DevOps group? What does DevOps mean in this context?
Generally DevOps, according to the literature, is the use of a few basic principles to enable a business requirement to get to production deployment with appropriate coordination among all the players. These participants include line of business, dev, classic ops, networking, security, DB, storage, and any other functional group that’s involved in the service delivery. Focused DevOps really wouldn’t exist in this thinking since it excludes some of these other groups, leading to the issues about networking and security that are mentioned.
If what I’m saying is the case, the concerns about inadequate coordination with networking and security (and DB, storage, and so on) go away. One industry issue is that many organizations want to adopt DevOps, but do no more than a light reorg and label a team DevOps, leading to the coordination issues mentioned in the article.
Also, an organization might have a team with cloud expertise, but it would be just one more group that would be a coordination point for a cloud deploy in the same way that a deployment to on site infrastructure would need coordination with the on site infra group. You might include coordination with both cloud and on site infra groups in every deployment anyway to maximize the convergence of architectures.