Hi, I am the regional director here at Infoblox and I'm here with Jorge Figueira. Jorge, you want to introduce yourself?
Sure. Hi guys, good morning. Jorge Figueira. SC major for the West coast of the United States. Business partner and crime partner, partner in crime of Jacob Webb.
That's right. So, and we try our best not to commit too many crimes, but it does occasionally happen. Just kidding of course. Jorge, so today we're gonna talk about some of the cloud implementations we've been working on.
And I know over the past several years we've done several, on premise, public, hybrid, but there's a lot of buzz around multi cloud as well. So can you explain to us what the difference is between multi cloud and hybrid cloud?
Sure. So the multi cloud and the hybrid cloud terms seem to be fluid in the sense that so far you can't find a single formal definition for each that is crystal clear and separate from the other. But, in most cases what we have seen in most cases is that multi cloud is more of a strategy where companies and CIOs decide to implement different work loads and different environments depending on security reasons, compliant reasons, business cases. So, for example any company today that is operating on VMware, Ajera and AWIs or google cloud platform all at the same time, even if it is for different tasks, then we can consider that company as executing on a multi cloud strategy.
Whereas with hybrid cloud it has a lot to do with the lower level implementation. So in some cases some companies may decide to ground some applications in AWIs, but some of the data may be stored on premise or the other way around. So some of those cases where it makes sense to share responsibilities among different environments or among different clouds, then that tends to be more defined as hybrid cloud.
Now, we are hearing multi cloud as basically getting more and more popularity and people are starting to use it a little bit more. Okay but that's just a matter of the trends that we hear from what we've been talking to with customers.
Understood. Well that's great, thank you for that response. Now, I'm curious, we've worked with customers around multi cloud, can you share some instances or things that they've learned when implementing multi cloud, that maybe others that are considering it don't know about?
Sure, so some of the most important lessons have to do with trade offs. Right? So as I mentioned in the blog post that I wrote few weeks ago that the whole problem or the whole issue here that a lot of these environments, VM ware open stack, AWIs or Ajera plus the regular data center environments, a lot of those they already have some sort of embedded freeware capability to manage IP addresses or manage their name space.
And the issue with using those is that it's almost impossible to have a single cohesive view of all of the naming conventions for all the name spaces for all of everything in the network across all of those platforms. So what ends up happening is you then start having silos of naming conventions and inconsistencies and then you have different areas where you can't audit or you can't secure in the same way, or it also happens that there is disparity in the functionality.
So for example your AWI's and your Ajera environments don't really comply with all of the DNS RFC standards so they can't do things that are simple as a zone transfer, but they are very sophisticated when it comes to APIs and automation. And then pretty much the opposite happens when you go into the buying world, the traditional world, where it absolutely complies with the RFCs but it's extremely difficult to run any kind of API based automation because the customers basically have to build that on their own or install that as an overlay.
So there seems to be this tug of war between the cutting edge world that wants everything automated and everything API based and then the rest of the company that still needs to catch up. They still need to operate, they still need to integrate with other systems. In a lot of cases RFC features that have been there for decades. So, that mix, that disparity, means multiple management consuls, multiple security models. It may be sometimes very different skill sets. So organizationally it can become a challenge pretty quickly when an architect sees the crunkled mess across the environment.
So it sounds like people are moving to the cloud to become more nimble, more agile, deliver more to the company but in a sense it's creating a lot more logistical nightmares and when you implement a solution such as info blocks you're giving yourself more visibility, more security, more availability and a single pane of glass to do all this through.
So you're truly getting the economies of scale that you implemented cloud solutions for, you're getting the automation you're looking for and at its core you're getting some security as well.
Yeah, so, the really interesting thing that we learn, and these customers also learn with us, was by deploying our technologies and especially considering our API capabilities we a bring a pretty much uncontested combination of RFC compliance but also API access, automation capability, consistent security and the ability to employ our virtual instances across all of those environments.
So it doesn't matter if we're talking about our customer who wants to install a DNS server on their premises, whether it's a data center or an office location or if they want to deploy that in AWIs or in Ajera in the future maybe even other cloud platforms. They're going to see this consistent feature set where we comply with the RFCs but we also allow for automation we also allow for API integration.
So there's very little compromise. And then obviously as a very foundational, from a very foundational angle we have the same infrastructure from our grid that we used to have for a long time and it brings hard and secure infrastructure , very easy maintenance, centralized software management. They basically enjoy all of these benefits, now into their public clouds. And that has been the biggest thing, bridging the two worlds in a graceful manner.
That's great. So, who do you typically engage with in a customer? Is it the traditional IT folks is it on the dev side, or is it something a little different than we are used to?
It has been different because in some cases, depending on their customers, or the contacts we've had up until that point. A lot of times what we hear is look, we've had a bind server or a Microsoft server sitting on Ajera and AWIs for a while now, but we're just tired of managing that separately from the info blocks infrastructure. It feels like going to a vacation home without a microwave. You know, can you still cook? Absolutely, but good luck making some popcorn in less than five minutes. You know, they understand what they have to do but they feel like they're wasting so much time.
So, as you remember some of those engineers came more from the IT side that said look, my Ajera environment or my cloud environment, they're demanding from me that I give them a DNS service with these capabilities and I don't want them to use route 53 in that case or I don't want them to use the acura DNS service. But at the same time I don't to give them a Microsoft server. I want to extend my grid.
So, when deliver on those member on the public clouds it came as a blessing for them. Now that was kind of the angle from the traditional IT, but you've also, you probably remember us sitting in a lot of meetings with architects and sometimes even directors. And that makes a ton of sense because it's those guys that have an overlaying view where they can actually see what's going on across their environments and then they can set the policy and set guidance. Okay, we need this as a strategy across our environment and we should not have any compromises, these are minimal requirements that we need out of this infrastructure, so need to start speaking with vendors that can deliver on that.
By far architects are the ones that seem to see this quote unquote mess the quickest and obviously from the more management perspective this usually makes it into directors and senior directors.
Yeah, we've seen, I think, you stated it really well. We've seen the cisos and directors really fully immerse themselves in the cloud so they really want to make sure they have complete visibility and it's interesting your bring all that up because I was at a CISO event, a ciso event, about six months ago. And one of the cisos said, I love the agile nature the cloud has brought to my org, but I am also very concerned about the blind spot I have and what you've just described really addressed the blind spot that in this case the ciso had.
And I think you did a really good job of explaining why customers aren't leveraging free ware or your standard tools for things like IP address management, IP automation and DNS. I'd be curious though, how are these folks measuring success when they implement something like info blocks into their overall cloud strategy?
Sure, so, some of the more notorious cases that we have seen is having some companies that are here and near us at HQ where their processes for availability, so to speak, from the moment that somebody requests a virtual resource, a server, a client, a storage controller, it doesn't really matter what it is. It used to be a matter of days before that resource was accessible. In some cases it could be, quote unquote, available a lot quicker, but it didn't have a DNS name, it didn't have an IP address. It's sitting there but it's not really usable, right?
There was a lot of email exchanges or ticketing systems between the moment the device was requested and when it was finally accessible. We cut down that time to ten to fifteen minutes. So, when we're talking about cutting days to minutes, you can think of the mindset shift of when developer needs a resource and they can get it that much quicker how much more productive they can be.
In a lot of cases we're dealing with creative minds that the more readily they can access these data to do their tests, then the more productive they are going to be. So, time has definitely been a larger measure of their success and of their impact. It's been something easily included in our business case or return of investment calculation.
The other one has been security. A very different use case that we had with a company in the Pacific Northwest was they installed some of API servers in order to bridge different worlds with different security mandates. So in other words the PCI network vs the development network vs the public network, etc, etc. So this was not only to address automation but it also helped them address the challenges of centralizing management but distributing the different access points in order to have better security. So, different access points, different APIs so that they have the ability to say, you have access to this environment and only this environment. You have access to this other environment and only this other environment and then nobody can really access, nobody has the keys to the kingdom, which is the centralized management platform which is sitting in a very secure environment.
Initially what we thought about these functionalities when we thought about these products we had a lot in mind about performance and availability. Security came always as a function of our architecture, however this customer saw very cleverly how this could fit exactly in a multi security environment scenario. And we fit very naturally in there and our model was just very friendly with what they wanted to do.
So to them specifically they really saw an improvement to their security policy, cutting down on security rules and cutting down on the amount of people who needed access to the higher security environment.
Awesome. That's great. That's a great example of successful implementation. I know we've had a lot of successful implementations around cloud hybrid, pubic and multi cloud. We have case studies on our website that talk to this, but I just really want to thank you for your time Jorge. I think this was very educational and you know we look forward to doing a lot more in the clouds.