Subscribe
Share
Share
Embed
Rasam Tooloee is a Cloud Network Evangelist at Alkira, Inc., a company that’s working on reinventing networking for the cloud era. Previously, he was an enterprise sales director at Microsoft, a senior strategic account executive at Salesforce, and an IP telephony architect for RHI Inc. He also had a 10-year stint at Cisco, working as a networking and collaboration sales specialist.
Join Corey and Rasam to chat about how networking has changed over the last several years. They discuss what it was like for Rasam to work for Alkira and the solutions they’ve brought to the technology space. Rasam’s circuitous route that he’s taken over his career led him back to networking and thus his work at Alkira. A route that is the result of chasing the leading edge of innovation and how agility is the native value proposition of the cloud. They also discuss how Alkira is recognizing cloud is a competitive imperative and companies need to find solutions in that space.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: This episode is sponsored in part byLaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren’t what you expect? LaunchDarkly does exactly this. To learn more, visitlaunchdarkly.com and tell them Corey sent you, and watch for the wince.
Corey: If your familiar with Cloud Custodian, you’ll love Stacklet. Which is made by the same people who made Cloud Custodian, but put something useful on top of it so you don’t have to be a need to be a YAML expert to work with it. They’re hosting a webinar called “Governance as Code: The Guardrails for Cloud at Scale” because its a new paradigm that enables organizations to use code to manage and automate various aspects of governance. If you’re interested in exploring this you should absolutely make it a point to sign up, because they’re going to have people who know what they’re talking about—just kidding they’re going to have me talking about this. Its doing to be on Thursday, July 22nd at 1pm Eastern. To sign up visit snark.cloud/stackletwebinar and I’ll talk to you on Thursday, July 22nd.
Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. On this promoted episode, we’re returning to something I did a while back on the AWS Morning Brief. I took us on a twelve-week exploration of networking in the cloud and how that wound up impacting how companies do business. Today, my guest is cloud networking evangelist Rasam Tooloee, and he works over at a company called Alkira. Rasam, thanks for joining me.
Rasam: Thank you for having me, Corey. Pleasure.
Corey: So, let’s start with the obvious. What is a cloud networking evangelist? I’ve heard of people evangelizing all kinds of things, some of which make more sense than others, but this is the first evangelism title that actually made me sit up and say, “Ooh, this is relevant to my interests.”
Rasam: That’s funny. A cloud networking evangelist, to me—you know, what I consider my charter is really helping our customers and prospective customers understand that networking the way they’re used to doing it historically, if you look at legacy networking and the way that networking has evolved, specifically in the cloud, is just not sufficiently agile; it’s not sufficiently natively enterprise-grade from a visibility and control and compliance perspective. And that there’s just a better way of doing networking for this cloud era that we’re in. And I find enterprises that I talk to every day struggle with the complexity associated with how to get their properties into the cloud. There are many of them have become natively multi-cloud just by default, you know, some through business imperatives and priorities, some through acquisitions, but ultimately in the context of networking, that has led to a whole lot of complexities that they grapple with, and the evangelist in me is looking to help them find the better options that are out there for them.
Corey: In the earlier days, before I got into Cloud, I was deep into configuration management. And oh, we manage all of these systems via configuration drift detection, and every time they run, they remediate the drift, and it’s great. Cool, so how do we wind up managing the networking equipment? Well, there’s this thing called RANCID. It’s made out of some horrifying Perl and if you turn on ‘strict,’ the whole
thing breaks.
And it was this awful sort of dark ages technology to approaching networking. It felt like the DevOps movement towards agility really didn’t come to networking in any meaningful sense for a while after that. Is that accurate? Or was I just hanging out in the wrong shops?
Rasam: No, that’s absolutely accurate. For sure.
Corey: Your career has been fascinating. You went from Cisco, where you presumably worked on networking because that’s kind of the thing they’re known for, then Salesforce, which is sort of definitionally SaaS, as says on the tin. You went to cloud with Microsoft for a while, and now you’re at Alkira, where you’re sort of in the perfect center of all three of those things. Tell me a little about how you got to where you are?
Rasam: Yeah. Well, I have my roots in networking. I worked for Cisco—a great company—for a long time, and really got the opportunity to tackle networking for many different facets, both core networking as well as some of the advanced technologies that Cisco forayed into, and absolutely loved the ride and learned so much. And then there came a time where SaaS was clearly the next big wave. And being at Cisco, I watched that wave grow from afar, and at a certain point in my career, I decided to take the leap and go to the SaaS leader at the time, Salesforce, and really learn that business from the ground up, both in terms of the underlying constructs of how SaaS business model works, but also the core business that Salesforce has in CRM.
And then from there, I transitioned to Microsoft because SaaS was the tip of the spear that launched the cloud revolution, but then there’s a lot more to cloud than just SaaS. And going to Microsoft really helped me to understand that business from the ground up. I’ve always had this inclination of really being intrigued and curious about what’s next and trying to take that next leap before I have the opportunity to really enjoy the uptrend of the ride. I’m looking for the next emerging significant innovation, but what’s interesting is, come full circle, I’m back in networking. Which kind of begs the question of, like, what happened?
And to me, what happened was, in Alkira, I find the coming together of everything that is fascinating to me about cloud and SaaS with where I really earned my chops in technology, which is networking, and really solving this problem for this era, this moment in time in a truly innovative way. So, I feel like it’s actually—it may look like full circle, but it’s actually a continuous trend of seeking out the next innovative thing.
Corey: Back when I wound up getting into networking, the reason I did it was because first, it was the 2008 financial crisis and no one was hiring; we just had a salary freeze and I was demoralized at my job. But I realized that as a systems administrator, I was always sort of hand waving over the networking pieces. And all right, let’s figure out how this whole thing works. So, I got my CCNA, my Cisco Certified Network Administrator, cert, back in the days when that didn’t have a whole bunch of different derivative adjectives after, telling you exactly what kind. And what happened next was that, okay, now I understand it a lot better.
Every time I find myself basically scratching my head, trying to figure out exactly what the deal is with something that I’m working on technically, and I don’t understand what’s there, dig deeper into that and you’ll often discover that it makes everything else make a bit more sense. And then came cloud. And now we have cloud networking, and anyone who tells you they understand how cloud networking works is generally lying to you. It feels like it is complexity stacked on top of complexity, and these days, it more or less distills down to you fire up your cloud provider of choice, you click a few buttons in the console, and really hope you did it right. I’m guessing that you have not automated the clicking of the buttons in the console, so how do you folks approach it? What have you done that’s different?
Rasam: So, to build on your point about the complexity of cloud networking, there’re a number of reasons why it is so cumbersome and so complex for enterprises to tackle the challenge of cloud networking. One is, it tends to be rather rudimentary in nature, and there’s a lot of manual effort involved, there’s hop-by-hop configuration, you have to do unnatural things to solve for some basic challenges. For example, we often find enterprises or service chaining firewalls so they can have symmetric traffic routing. And they will do things like have a separate path for ingress and egress traffic; the segmentation is extremely hard. So, one part of it is—probably my personal opinion; I don’t think cloud was built with the idea of let’s solve for the networking from the ground up because that’s so important to how people are going to have to manage their compute and storage.
It was all about compute and storage, and networking was kind of an afterthought. And that shows. That it shows in the way that you actually have to configure your cloud network. Now, the other thing that really complicates it is the fundamentals of networking don’t change, but the way in which the fundamentals are applied and the vernacular that’s used to describe it and the UI that’s used to control it varies from cloud to cloud. So, just because you learn Azure doesn’t mean you know AWS, and doesn’t mean you know GCP.
So, if you are becoming multi-cloud, now you got to go learn all this stuff separately, and then actually as an amplification of the challenge that is associated with the hop-by-hop configuration, when you bring up a region, for example, in cloud provider A, that doesn’t mean that you all of a sudden did most of the heavy lifting required for region B, you got to go do the same thing in region B.
Corey: Oh, I had a client that had a very deeply skilled networking team that spent months without much success trying to get Terraform to set up IPsec between GCP and AWS at one point, and ultimately they gave up in disgust. My argument about, “Oh, we’re going to go multi-cloud to avoid locking.” “Well sorry, you already have lock-in, both in terms of what your staff’s up to speed on, but also the identity model, the security model, and critically, the networking approach.”
Rasam: Yeah, absolutely. And back to your original question of how we do it differently. So, what we have done is really looked at the problem differently through a new way of thinking. Again, this goes back to my prior point about the network isn’t sufficiently agile, and the reason it’s not agile is for all the reasons that I explained. And when our founders who come from decades of experience in networking looked at this problem and they looked at the native value proposition of cloud—which in our mind is agility—is the fact that cloud is a competitive imperative these days, that’s where innovation is happening, and we see enterprises every day increase their investment in cloud because if they don’t, they’re going to get left behind; they’re going to get left behind because the next digital disrupter or their competitor is going to do, in cloud, the things that their customers expect, and the things that are required to truly compete in today’s marketplace.
So, because it’s a competitive imperative, and at the heart of it is agility, our founders really contrasted what networking was like in the cloud and in the cloud era, which is really largely fragmented, and silos, highly complex, slow to deploy to your point, often CapEx heavy because you’re making substantial investments in things like colocation and dedicated bandwidth. There are a lot of delays and limitations like I talked about in terms of the various constructs between the cloud providers.
They contrasted that with DevOps and said, “Okay, look. DevOps is all about automation. It’s about rapid iteration. It’s about abstracting the underlying complexity on an elastic platform that scales with you. You can actually go into cloud with minimum upfront investments, test and iterate, and then scale as you need to with velocity and agility. That’s what cloud is about. That’s the way DevOps has adapted to the constructs of cloud. But network isn’t the case, so how do we rethink networking from the ground up, so that it is more in line with the business imperative of why businesses go in the cloud in the first place?”
And to do that, what they really did was design a unified fabric that’s a multi-cloud unified fabric that delivers a full stack of networking services that meet the vast majority of the use cases that an enterprise would have from a networking perspective, and does so in a way that’s natively multi-cloud, and does so in a way that natively addresses some of the complexities with things like security, compliance, visibility, control, et cetera.
Corey: And I’ve been very vocal about opposing multi-cloud as a best practice, and people sometimes are surprised to discover that as soon as I find a customer who’s doing multi-cloud, I dive right into discussions about that, and, “We thought you were going to yell at us.” Look, do I think it’s a best practice in the general sense? No, but you have specific constraints, and you have an environment that is how it is, and sitting here saying, “Oh, you should have made a different series of decisions six years ago,” it turns out is not the most compelling story. And there are always specifics that override general guidance. So, whether I like multi-cloud or not as a guidance perspective, I don’t think that I can intelligently deny the reality that it very much exists in an awful lot of places.
And sitting here just trying to be a purist by going through one cloud, whatever it happens to be, and nothing else doesn’t really solve any pain that customers have. Hybrid is and will be a big story for a long time. In my more cynical moments, I tend to view hybrid as, “Well, we tried to do an all-in cloud migration and got stuck halfway through because it turns out, it’s hard to move some things, so we gave up and called it hybrid and now we’re calling it good.” That might be overly cynical, but it takes time to move these things. It takes time to wind up wrapping around a bunch of different environments.
So, if you have something that makes it a lot, I guess, more straightforward to rationalize about and around the network layer, that really feels like it’s a great equalizer because that is one of the most differentiated aspects of all the different clouds.
Rasam: Yeah, absolutely. I mean, the proof is in the pudding, right? So, we find the challenge of getting to cloud, getting cloud networking enterprise-ready from a security, governance, compliance perspective, high availability perspective, disaster recovery perspective, to be a monumental challenge. And for an enterprise, it could be an effort of months, or years, sometimes, for a single cloud, much less a multi-cloud. And just because you did it with Cloud A doesn’t make Cloud B all that much easier.
And I agree with you; I think multi-cloud isn’t necessarily an easy and desirable place to find yourself, but that’s besides the point because enterprises are finding themselves there for a myriad of reasons. It could be business imperatives, partnerships, acquisitions, it just happens. And when it happens, you need the best possible strategies and tools to deal with that. And for us the proof is in the pudding because we’ve had customers be able to contract the amount of time that it would have taken them to get from Cloud A to Cloud B from months and months to a matter of weeks. We can provision something that would take multiple weeks of change control and manual effort, and do it in a matter of hours.
So, I don’t want to overstate how much the technology simplifies things, but the technology does literally simplify things that much. There’s still business process involved, there’s still change control involved, there’s still the human element of making sure that the change is well orchestrated, but the actual process of getting your cloud networking and multi-cloud networking up and running is simplified in a way that I think you have to see to believe and, you know, the proof is in the pudding, and when we have a chance to actually demonstrate that to our prospective customers, it truly is game-changing.
Corey: It’s clear that you’ve built something that works. You have a laundry list of customers on your website who are referenced customers, and these are logos and names people recognize. It’s not, “Oh, wow. That sounds like you made half of those up, and weren’t three of those the big evil corporation in some movie somewhere?” No, these are real companies solving real problems.
And digging a bit into what you’ve built before you came on the show, it is clear that you folks offer a TCO story that lowers the total cost of ownership, but lies, damn lies, and TCO analyses tend to be the three forms of lies people tell. I’m much more interested in the story of how you accelerate time-to-market because speaking as someone who focuses on AWS bills and cost reduction, it always takes a backseat to accelerating features being released. So, there’s a capability story that goes along with this, which it sounds like they’re very much is. That’s the real win; the fact that it saves money is almost icing on the cake.
Rasam: Yeah, absolutely. You’re right, the Holy Grail is time-to-market, which really, time-to-market is very much for me, synonymous with this idea of agility and the ability to pivot, and to get to the next iterative desired outcome for your organization, whatever that may be, quickly. That’s consistent with this idea of velocity, and iterative testing, and scale that the cloud provides. For example, recently, I’ve been working with one of our prospective customers who’s, really, underlying challenge is, “Look, I’ve already built this really robust infrastructure from a cloud networking perspective. It is really colo-centric; that’s my model for my cloud interconnects, but I am now in a global expansion phase. I need to go to all these new geographies, and if I were to do what I just did to build out my cloud networking footprint, I’m looking at a substantial CapEx investment and a substantial amount of time and runway to get that operational, and I just don’t have the CapEx or the time for that.” So—
Corey: What, they can’t just copy and paste the config from one to the other again and again and again in the true StackOverflow tradition?
Rasam: Or get the circuits dropped in the colo, or get all that hardware delivered, and deal with all the complexities of international customs control, et cetera, et cetera. So, what we bring to them as a value proposition is the fact that our points of presence are virtual; they’re software-defined constructs that run atop the hyperscale cloud provider. We can spin them up anywhere in the world where the hyperscale cloud provider has a footprint, and we are in many regions across the globe. And if we’re not in one, we can get one up and running in a matter of days. And most of that time is actually just spent testing it to make sure that is operationally viable; the actual provisioning and turn up of it is very, very quick.
So, the ability for us to be a virtual PoP for this particular customer and give them the ability to quickly expand into brand new geos in a way that also concurrently, natively streamlines and simplifies the complexities of cloud networking that we’ve already covered is extremely attractive to them. And from time-to-service perspective, it’s taking their ability to deliver the needed services in the cloud to their business users from something that would have taken months and months to something that can be up and running in a matter of weeks.
Corey: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility and detection. To learn more, visit lacework.com.
Corey: Can you give me an example of a customer pain point that you’ve resolved? Because, again, you have customers willing to say nice things about you, but one of the challenges I’ve often found with a lot of the, shall we say larger, more enterprise-y offerings is, “Well, what did you actually do for the customer?” And the answer requires two hours and at least 40 PowerPoint slides and at the end, you say you get it just to get the person to stop talking. What is the value, the better outcome that you’ve delivered for a customer?
Rasam: Yeah, sure. So, our customer, Koch Industries—and they’re a public reference for us; you can check out their story more in-depth on our website—but they were your traditional enterprise, originally designed for cloud using a hub-and-spoke architecture, which consisted of using the data centers as the focal point for data center interconnect, cloud interconnect, high-speed bandwidth, private Lan, et cetera, that comprise their overall architecture. And over time, they simplified—and I use the word simplified loosely here—but they simplified with a more cloud-native, cloud-transit type of architecture, where they leveraged more of the default capabilities and networking services on cloud, which helped considerably. There was a ramp involved in learning the native-cloud constructs and associated networking and security aspects of that, but over time, they did simplify. They were able to condense their overall provisioning time of a cloud interconnect from what they originally shared with us was eighteen months down to about six, and consolidated across about a dozen transit hubs from a cloud networking perspective.
But then, as we discussed previously in the podcast, when they took a step back and looked at it, what they still saw was an enormous level of complexity in networking, an enormous level of complexity in operations, and they still were seeking a better way, a way that was operationally viable in the long run with a lower total cost of ownership, and the ability to really consume networking services in a way that moved at the speed of business in a way that was more in line with the way that we’re using cloud computing storage, and in line with the speed and agility with which their business wanted to move. And that’s where Alkira came into the picture, and there was a real alignment of vision between how they saw their networking strategy moving forward and how Alkira delivered services. Long story short, they are now able to take their planning process down from six months to a matter of weeks, and the actual provisioning process of cloud networking to a matter of hours, sometimes less. And that has brought immense value to their business and to their IT organization, again, in terms of agility, in terms of total cost of ownership, in terms of visibility and control, in terms of governance. And another added benefit was historically they were single cloud, AWS, but in the process of their journey, with Alkira, the need came up to go into Azure for some Azure native services in a scenario where the data still resided inside of AWS, and that request historically would have been months and months of due diligence to get the environment up and running, and in their case, they were able to do that all within a day because they were already leveraging the Alkira multi-cloud platform.
So, a tremendous amount of value for them across a myriad of fronts that, again, have been pivotal to their long-term strategy and how they address cloud networking moving forward.
Corey: If we go back to the early days of cloud, we started off with some of the advanced stuff like, you know, virtual machines—some places called them instances—and there was a lot of competitive variation between them. “Well, these instances cost a fifth of what this other cloud providers do.” “Yes, but that other cloud provider [unintelligible 00:19:47] don’t fall over every 20 minutes and have persistent disk.” In the fullness of time, everything’s sort of commoditized to the point where now, in many cases, if you’re just running a bunch of virtual machines on cloud providers, it’s largely a matter of price. The same story has happened in many respects with object store. Do you think that the network will eventually wind up commoditizing as well, or do you think that there’s still going to be significant variances as the rest of the cloud world grows up on top of that bedrock foundation?
Rasam: I think that’s a brilliant question, and I think the answer is yet undetermined. I don’t think it’s clear. I think there are a lot of different approaches to trying to solve for the challenge of networking in a cloud, first world, right? And most of the solutions on the market address some subset of the problem: some gets you to the edge of cloud, some really reside on the edge and try to interconnect you to the various clouds that you want to be in, some are meant to help you orchestrate your cloud footprint once you’re in the cloud. The underlying challenge remains that, at its core, cloud networking itself remains extremely complex and extremely siloed.
If you zoom out and look at your traditional enterprise architecture, it’s a bunch of siloed solutions that have been stitched together to meet the end-to-end workflow. Well, cloud is kind of a microcosm of that. The same thing happens in cloud is, you have a lot of manual intervention of stitching together the various pieces to meet the end-to-end workflow. None of the existing approaches on the market are really operationalizing cloud from a networking perspective the way DevOps and containerization has done with compute and storage and made it really a seamless part of an end-to-end infrastructure as code strategy. So, I think everyone is really trying to tackle that problem in a way that hopefully, the end state will be one that is aligned with the underlying value proposition of what cloud brings to an enterprise.
But how that is going to end up looking and whether or not it ends up being a singular sort of end-to-end infrastructure as code strategy that ties the pieces together elegantly, or ends up being all these various piece-parts that are solving a best of breed problem but still need to get stitched together, I think remains to be seen.
Corey: One of the things that I think networking has had in common or is at least spiritually aligned with the world of security is that when it isn’t working, “Well, we’re going to go ahead and make things broader and broader and broader, and we’re going to go ahead and grant everything access to everything, and once we get it working, then we’re going to go back and dial that back down because we want to be secure.” Yeah, no one ever remembers to go back and dial things back down. Once it’s working, we’re on to the next ticket, in many cases. So, the complexity doesn’t just act as a drag on feature velocity; it also acts as significant security risk in many environments. How do you folks tackle that, or think about that? Or is that one of those, “Oh, that’s the best kind of problem: someone else’s.”
Rasam: I think at the root of that problem is the visibility and control problem because it’s easy to do something, to turn some knobs to get something up and running and then forget about it. And if you don’t ever go and touch that part of your network again, then you can easily end up in a situation like the one that you described. And that’s why we really think of the idea of solving for this problem as needing a new paradigm and a new way of thinking, which is a unified fabric, end-to-end, in a multi-cloud world, with a full stack of network services that addresses the vast majority of the use cases that an enterprise would have. So, we’re literally giving you a single user interface for full visibility and control end-to-end for all of your networking use cases, be they on-prem, for your remote users, for your branches, or any of the clouds that you might be in.
Corey: When you find that you’re talking to your prospective customers that, in the fullness of time, become actual customers, and they wind up going from, “Okay, this might work,” to, “This is awesome,” what do you find that they’re, first, the most surprised about during the adoption? And secondly, what do you think their biggest misunderstanding along the way was?
Rasam: You know, the way that you leverage the Alkira Network Cloud—which is what we call it. We call it Alkira Network Cloud because it is in fact a network cloud that delivers all your full stack of network services in a cloud model. But the way you leverage the Alkira Network Cloud is you go through a multi-step, really simple workflow. So, we have this concept of cloud exchange points, which you can think of as virtual PoPs, and they reside all over the world. So, the first thing you do is you pick your virtual PoP or PoPs—you can have one or multiple of them, as many as you need—and the next thing you do is you attach your sites to this fabric.
And there are multiple ways you can do that. You can do that through high-speed dedicated connectivity like AWS Direct Connect, you can do it by extending your SD-WAN fabric into the Alkira fabric, you can do it through IPsec connections, you could do it through remote access for your users. But that’s the first step. And then the next step is to attach your cloud VPCs or VNets. So, you go through a process of providing your credentials for your cloud properties, and you attach the cloud properties to the Alkira fabric, and in the middle, there’s the step of defining your segments.
So, you define logically what your segments will be, and then you assign your sites, or your users, or your cloud properties to that segment. And literally, I mean, that’s five steps, and at the end of those five steps, you just established end-to-end multi-cloud connectivity from your sites, and branches, and data centers, and users to your cloud properties end-to-end with full visibility and control. And usually, that process can take 30 minutes, if you have all of your credentials and the necessary data lined up for what you’re connecting and the sequence that you want to go through, and at the end of that half-hour, people that are new to the platform will stop and say, “That’s it? We’re done? It can’t be that easy.” And in fact, it was that easy. And that’s really the big aha moment for a lot of our enterprise customers that see the platform for the first time of, like, “Wait. This is way, way different than anything I’ve seen before.”
Corey: Your website has a 30-minute challenge for configuring a network, and I haven’t run myself through it yet with a stopwatch, but the fact that you can even make that claim means that there’s something radically different because frankly, it takes that long to find that the networking section of the console in many of the cloud providers. Something you just said was—talking about your enterprise clients; do you find that you’re generally working in the enterprise space, or do you tend to have offerings that make sense at the SMB scale? In other words, when is it time to start talking to you folks? Invariably, “After someone probably should have,” seems to be a common refrain, but at what scale does Akira begin to make sense?
Rasam: Yeah. I think I use the term ‘enterprise’ sort of, more generically than your large enterprise.
Corey: Oh, to me, a big company is anything with more than 200 people, so I’m the wrong person to ask on that score. But yeah.
Rasam: Yeah, and I would say I agree with you, and that’s kind of the definition of when I say enterprise for me. Because networking is a horizontal problem. Every company needs networking and no matter what the size of your organization, if you’re going into cloud, you’re going to have to deal with the challenges of cloud and operationalizing the challenges of cloud. Now, the larger you are and the more clouds you’re in, the greater the complexity that you have to deal with and the greater the operationalization of that complexity. So, we deal with large enterprises that are deep into their cloud journey and find themselves back-ended into complexity and looking to simplify.
And we also have enterprises that are born in—I’m sorry. When I say enterprise, I’m talking about customers that are born in the cloud, startups that are really looking for a simplified and operationally aligned networking solution with the way that they’re intending to leverage cloud. So really, if you’re getting into cloud, and you’re getting into cloud networking, and you have a cloud-first strategy, regardless of the size of your organization, the chances are pretty good that Alkira is going to be a good fit for you.
Corey: Thank you so much for taking the time to speak with me today. If people want to learn more about what you’re up to, how you view these things or basically take it for a spin themselves where can they find you?
Rasam: On alkira.com. So, www dot alkira—A-L-K-I-R-A dot com, and take a look at our resources page. It’s packed with great content. And like I said earlier, you really have to see this to believe it, so we’re happy to show you; request a demo and we’ll get online for you and take you through the journey.
Corey: Excellent. Well, thank you so much for taking the time to speak with me. I really do appreciate your being so generous with your time.
Rasam: Thank you, Corey. I really appreciate it.
Corey: Rasam Tooloee, cloud networking evangelist. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice along with a comment containing the proper Terraform configuration to get IPsec working between two different clouds.
Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.
Announcer: This has been a HumblePod production. Stay humble.