Screaming in the Cloud - Network Agility for the Cloud Era with Alkira

Episode Date: July 13, 2021

Links:CTO Whitepaper: Reinventing Enterprise Networks for the Cloud Erawww.alkira.com

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. This episode is sponsored in part by LaunchDarkly. 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, visit launchdarkly.com and tell them Corey sent you and watch for the

wince. If you're familiar with Cloud Custodian, you'll love Stacklet, which is made by the same people who created Cloud Custodian, but put something useful on top of it so you don't need to be a YAML expert to work with it. They're hosting a webinar called Governance is Code, the guardrails for cloud at scale, because it's 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. It's going to be on Thursday, July 22nd at 1pm Eastern. To sign up, visit snark.cloud slash stackletwebinar, all one word. That's snark.cloud slash stackletwebinar. And I'll talk to you on Thursday, July 22nd. 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 12-week exploration of networking in the cloud and how that wound up impacting how companies do business. Today, my guest is cloud networking evangelist, Rassam Taloui, and he works over at a company called Alkira. Rahsam, thanks for joining me.

Thank you for having me, Corey. Pleasure. 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. Oh, that's funny.

A cloud networking evangelist, to me, 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. Many of them have become natively multi-cloud just by default, 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. 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 pearl. 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? No, that's absolutely accurate, for sure. 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.

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 from 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, you know, SaaS was sort of the tip of

the spear that's 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 sort of have the opportunity to really enjoy the uptrend of the ride. You know, I'm looking for the next emerging innovation, 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, you know, 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. 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 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 that 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 until 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? So to build on your point about the complexity of cloud networking, there are 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 are 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, in 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 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 learned 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 the stuff separately. And then actually as an amplification of the challenge that is associated with the hop-by-hop configuration. When you wing up a region, for example, and create a 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. 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 lock-in. 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. 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. It's the fact that cloud is a competitive imperative these days. That's where innovation's 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 disruptor 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 kind of 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 co-location and in 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, OK, look, DevOps is all about automation. 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 investment, 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 is 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, etc. 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. 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 ofently 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 something, 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. Yeah, absolutely. I mean, the proof's 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, that 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's 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 for 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, right?

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 the proof's in the pudding. And when we have a chance to actually demonstrate that to our prospective customers, it truly is game-changing. It's clear that you've built something that works. You have a laundry list of customers on your website who are reference customers. And these are logos and

names people recognize. It's not, oh, wow, that sounds like you made half of those up and bought 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 if there's a capability story that goes along with this, which it sounds like there very much is, that's the real win. The fact that it saves money is almost icing on the cake. Yeah, absolutely. You're right. The holy grail is time to market, which is 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 a velocity and iterative testing and scale that that cloud provides.

For example, recently I've been working with one of our prospective customers whose really underlying challenge is, look, I've already built this really robust infrastructure from a cloud networking perspective. It is really colocentric. That's my model for my cloud interconnect. 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 what, they can't just copy and paste the config from one to the other again and again

and again in the true Stack Overflow tradition? Or get the circuits dropped in the colo or get all that hardware delivered and deal with all the complexities of international customs control etc etc right 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 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 it is operationally viable. The actual provisioning and turn up of it is very, very quick. 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 a 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. 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. Can you give me an example of a

customer pain point that you 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? Yeah, sure. So our customer Coke Industries, and they're a public reference for us, you can check out their story more in depth in our website. But they were like 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, etc. That comprised 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 in 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 18 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 they were using cloud compute and 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. 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 those other cloud providers do. Yes, but that other cloud providers, this is 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 are still going to be significant variances as the rest of the cloud world grows up on top of that bedrock foundation? 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 get you to the edge of cloud. Some really reside on the edge and try to interconnect 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 at code strategy that ties the pieces together elegantly or ends up being, you know, all these various piece parts that are solving a best-of-be problem but still need to get stitched together, I think remains to be seen. 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? I think at the root of that problem is the visibility and control problem, right? Because it's easier to do something, to turn some knobs, 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.

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 that their biggest misunderstanding along the way was? 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 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, right? 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, right? 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 can 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, right? So you go through a process of providing your credentials for your cloud properties, and you attach the cloud properties to the Alkera fabric. And in the middle, there's the step of defining your segments, right? 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, 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. Like, 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 like way, way different than anything I've seen before. 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 the networking section of the console and 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 Alkira begin to make sense? Yeah, I think I use the term enterprise sort of more generically than your large enterprise. 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. 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. Like 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 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. 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? On alkira.com. So www.alkira, A-L-K-I-R-A.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.

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. Thank you, Corey. I really appreciate it. Rassam Talui, 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've hated this podcast, please leave a five-star review on your podcast platform of choice, along if you've 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. If your AWS bill keeps rising and your blood

pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.