Commitment Issues: The Case Against Multicloud

Transcript

Forrest Brazeal: We are going to be in a multiple cloud provider industry for a long time to come.

Rahul Subramaniam: I still believe that producing complexity should be the goal of any organization.

Forrest Brazeal: This is not just a pie in the sky whiteboard architecture. This is trying to manage existing complexity.

Hilary Doyle: This is AWS Insiders, an original podcast by Cloud Fix about the services, patterns and future of cloud computing at AWS. Cloud Fix is a tool that finds and implements 100% safe AWS recommended account fixes. I’m Hilary Doyle and this is Rahul Subramaniam.

Rahul Subramaniam: Hey Hilary, how are you doing?

Hilary Doyle: I’m well, thanks. In this episode, we are getting into one of the greatest debates in the cloud: commitment. When it comes to your cloud tech, are you more Tinder or are you a little match.com? Do you want to choose one vendor for life or are you going to play the field with multi-cloud? Listen, if you just got cold feet or you broke out into a nervous sweat, I can relate and we will help you see the forest for the trees, or at least we’ll let you hear from him. We’ve got Forrest Brazeal from Google. But first let’s cover the basics. Rahul, all in on one single vendor versus multi-cloud. What’s what and which is which?

Rahul Subramaniam: So it’s all about complex relationships, Hilary, as you know.

Hilary Doyle: Isn’t it always.

Rahul Subramaniam: A common practice in traditional procurement is to have multiple vendors for a service to hedge your risks? And if you figure out how to work with multiple cloud providers, we just call it multi-cloud.

Hilary Doyle: So that’s actually some kind of happy meal combo of AWS plus Google plus Microsoft Azure.

Rahul Subramaniam: Absolutely. So the idea is that companies want to avoid potential risks that one of the vendors might go out of business or in an extreme case, [00:02:00] may hold you for ransom. I mean, can you guess what I’m talking about?

Hilary Doyle: You never miss an opportunity to slam Oracle.

Rahul Subramaniam: I don’t. And that kind of hostage taking is basically what we call vendor lock in. Now you are locked into vendor agreement in such scenarios where you don’t have the flexibility or choice to move out.

Hilary Doyle: I mean that sounds awful, also like a number of my teenage relationships, but you have everything with AWS. So isn’t that a form of vendor lock in? Are you a hostage? Should I be staging an intervention?

Rahul Subramaniam: Absolutely not. In fact, in this case, we actually have a vendor with benefits and so I would say we are all in on one cloud and that is better than either of those other two examples for a bunch of different reasons that we’ll talk about in just a bit. But for right now, all in on one does not mean that you’re taken hostage. You can always dissolve the kind of relationships that we are into.

Hilary Doyle: Sounds a little like Stockholm syndrome, but we will get to the bottom of this. Okay, the lines are drawn, the gloves are coming off, multi-cloud versus all in on one. Rahul and Google’s Forrest Brazeal will go head-to-head. Plus, as always, we’ve got hot takes, a Hollywood use case and the ever valuable tips and tricks. But first, your AWS headlines. Rahul with AWS systems manager quick setup, you can now install and regularly update the CloudWatch agent in instances across accounts and regions at scale. What does this mean?

Rahul Subramaniam: Sorry, I can’t even begin to tell you how big of a deal this is. It has finally made it possible to up the cost savings game. So to be able to do any kind of instance resizing, which is a big chunk of what you do with cost optimization, you really need to know the CPU memory disc and network IO usage. Now, memory is tricky because memory metrics can only be observed from within the instance and AWS can’t automatically monitor that for you for security reasons. So you need to install an agent explicitly in every one of these instances and AWS has finally made that easy and automated. So I love this.

Hilary Doyle: That’s great. Nothing you just said sounded easy. But I think it will be easy for you to tear this next news item to shreds because Oracle recently announced their cloud infrastructure revenue jumped 58% year over year cloud application revenues went up 48%. I know you want Oracle to die, Rahul, but it looks like they’re going to be around for a while to come.

Rahul Subramaniam: What a perfect example of vendor lock in. I mean, Oracle customers have relied and made their database setups so complex that it is practically impossible for them to switch out to anything else. So now Oracle, true to its game plan, just keeps jacking up the prices and reporting record profits.

Hilary Doyle: Listeners do not get on this man’s bad side, so docile and agreeable. But bring up Oracle and he turns into the Hulk. So on that note, let’s pivot to Hollywood and Netflix. They lost almost 1 million subscribers in the first half of 2022. As audiences were migrating to streaming competitors like Disney plus and Apple TV, we know that Netflix has been downsizing their workforce. They’re offloading real estate, but they are also looking at curbing their cloud costs, which means a potential hiccup in their very committed and loving relationship with AWS. Rahul cut down on their corporate merch fine, but AWS are we in the Upside Down here?

Rahul Subramaniam: Don’t worry, Hilary. Stranger Things isn’t going anywhere, but I can think of a lot of other shows that I wish just disappeared. Anyway, Netflix is one of the most sophisticated users of AWS. I mean, just look at their contribution to open source AWS tools and that’ll really paint the picture for you. But even Netflix finds tons of wastage and savings opportunities. So imagine what the opportunities in other customer accounts look like. I really don’t think Netflix is getting off AWS at all. I mean they’re just getting more efficient. And anyway, that subscriber loss was reversed in Q3 and Q4 when Netflix gained back over a million customers.

Hilary Doyle: Sounds like Netflix could use a little Cloud Fix, but I digress. Okay, we’re laying out the case for multi-cloud versus all in on one. Rahul, it is no secret that you are an AWS super fan. You’ve spoken to me a little bit about the genuinely meaningful relationship you’ve built with them, and this goes well beyond a pros and cons list of which provider to work with and how in a sense you’ve sort of built a marriage with them. So can you share with us how you work with AWS and is this kind of relationship the one that you’ve built replicable for other companies and developers?

Rahul Subramaniam: So I absolutely think that this is replicable. When I first started with the cloud, there was just one provider, it was AWS. So my choice of vendor was really simple and what I valued the most in the cloud provider was the pace of innovation. I wanted to see them turn yet another niche product into a commodity service at a significantly lower cost. Now, AWS had already had six to seven years of a head start.

Hilary Doyle: That’s an Olympic head start.

Rahul Subramaniam: Absolutely. Now, one advantage of being an early adopter in the AWS world is that you encounter issues very early on and you get to talk to the product teams that are very eager to hear about your feedback and you get to share your experience and suggestions with them and you start building those relationships.

Hilary Doyle: Amazon is known for its customer service. So this doesn’t surprise me.

Rahul Subramaniam: I would actually say they’re known for their customer obsession. And I remember talking to the networking team years ago in their Seattle office telling them about how this non-transitive peering and VPCs were just such a nightmare for me and my teams that were managing thousands of accounts. We spent a couple of hours whiteboarding ideas and a short while later we had AWS transit gateway, which is a solution to all my problems with AWS networking.

Hilary Doyle: This is a great relationship. So wait, you helped create an entirely new AWS product?

Rahul Subramaniam: Well, I’m not sure if I was the only one with all those struggles, but yes. I mean I couldn’t even count the number of times that the inside track has helped us over the last 15 years. I mean, what I was pleasantly surprised by was the fact that AWS’s two pizza teams just love to talk to any committed customer, even if they weren’t an early adopter of AWS as a service. It really makes you feel like you are an AWS insider, just like the name of the show.

Hilary Doyle: Nice plug, but let’s get back to the pizza teams. What are they and how do I play for one?

Rahul Subramaniam: Amazon has an amazingly scientific metric to decide how big your team should be, and the rule is that an order of two pizzas should be enough to feed the entire team. Now these teams have since come to be known as the two pizza teams. Had I joined Amazon back 15 years ago and given my appetite back then I might have been the only person on the team.

Hilary Doyle: I want to know how big these pizzas are. This is also making me think I need to reconsider my org chart. Rahul, as a child of the 80s and early 90s, I spent many nights at blockbuster browsing VHS tapes, wrestling with the agonizing decision of which movie to take home.

Rahul Subramaniam: You mean in a world before streaming videos?

Hilary Doyle: That is exactly what I mean. No longer with our podcast, my friends, he has gone off to Hollywood to make his fortune. But back to our use case at hand, like an analog knight in shining armor, Netflix arrived. They disrupted everything initially with mail for those too young to remember, Netflix would snail mail DVDs to its subscribers. Yes, DVDs, the future of technology. Netflix delivered their billionth DVD in 2006, and then they started offering – wait for it, Video on demand online. Rahul, take it with your husky voice from here.

Rahul Subramaniam: So I’m going to start by telling you, Hilary, that my kids don’t know what DVDs are. So you can imagine how old that is.

Hilary Doyle: Kids these days. No appreciation for the classics.

Rahul Subramaniam: Absolutely. So yes. So that’s when Netflix really started having problems and soon after they built two data centers to handle all of those mail order data and the new streaming service. But the demand just kept growing and the data centers kept running out of capacity. And then in 2008, they suffered a three day database corruption where they couldn’t ship any DVDs. Can you imagine? Not being able to ship DVDs. I mean the entertainment industry was collapsing.

So this stopped them in an important lesson. They were great at delivering movies, but not building data centers. Again, focus on what you’re good at. So they turn to AWS. What happened next is an incredible story, a timeless love between a customer, Netflix and one vendor. Just one vendor. AWS.

Hilary Doyle: Why hasn’t Netflix made this love story? We’ll come back to it because as you know, we’re lovers and fighters on this show and we have a gentleman’s brawl to ignite with the self-proclaimed bird of the cloud, the polymath and poly cloud promoter, the one the only, and Google’s very own Forrest Brazeal vendor lock in versus multi-cloud. Let’s get ready to rumble. Forrest Brazeal has done about all there is to do in the engineering world, front end backend database admin. He’s racked and stacked servers. He’s crawled around ceilings, laying CAT5 cables. He is an enterprise cloud architect, one of the original AWS serverless heroes. He’s also a writer and he started writing about the rise of multi-cloud years ago. Now he is the head of developer media at Google Cloud. Forrest, welcome to the show.

Forrest Brazeal: Thanks so much. It’s great to be here.

Rahul Subramaniam: So Forrest, all of those things sound really amazing and I know that you’ve spoken to customers across both AWS as well as Google Cloud. So what are the factors that you see driving decisions between these single vendor and multi-cloud choices?

Forrest Brazeal: I’ve been around large enterprises, I’ve been around startups, been around everything in between, and the reality on the ground is sometimes where a company looks around and they say, ‘Hey, as much as I would like to have this single simple clean vendor story, I have a company that I acquired and it’s going to be years before we can unwind it.’ That’s not something I’m going to re-architect and put on a different cloud. Or maybe I’ve got, I don’t know, a little bit of what we might call service envy where I look at what I’ve got on my cloud, I look over at another cloud provider and say, ‘Wow, I really like that data analytics service. I really wish there’s a way we could use that. Don’t get me wrong, we’re still primarily on this one cloud provider, but there’s this one thing over there that’s just so good, we need to go over and get that and add that in.’

Hilary Doyle: Do you expect companies to stick with multi-cloud solutions permanently or does this become an interim step to landing with one cloud provider more fully?

Forrest Brazeal: I believe that the complexity of IT, footprints and IT vendor relationships is only going to increase over time. I don’t see a world where things are going to get clearer, simpler, and more straightforward.

Rahul Subramaniam: For me, the multi-cloud architectures that people pursue are more from the perspective of a single application or solution. When you are building one solution and then you basically try to build out that solution across different cloud providers, that for me is the quintessential multi-cloud and the problem of added complexity in those scenarios. I do understand that they’re completely disjointed products in a portfolio and one happens to be on AWS, one happens to be on GCP or one happens to be on Azure. That’s completely fine because they’re isolated. They have picked one cloud provider as their platform to be on. To me, that is not multi-cloud.

Forrest Brazeal: To be clear, we can’t say no one has ever built a multi-cloud app. I have a friend named Ben Keho who used to compare multi-cloud solutions to cow tipping, meaning that we know it’s not real because there’s no videos of it on YouTube. Teenagers were really going out and tipping over cows in fields at night. That would be on TikTok. Since it’s not, we know it doesn’t really happen. And he’d say, because nobody’s talking about these multi-cloud solutions at conferences, we know that they’re not actually being built.

Hilary Doyle: Sorry, did everybody know that cows aren’t getting tipped over or is this just news to me? I’m feeling lied to. I’m also feeling incredibly relieved. But sorry, getting back to the issue at hand, this isn’t about impacting reality at the workload level, right? This is about perceived solutions at the organization level.

Forrest Brazeal: Yeah. We don’t often see people just saying, Hey, I think the best thing for me to do is to choose the lowest common denominator on these different clouds and build one giant middleware layer that I’m going to use and maintain myself to keep all these things running. The reality is if you do try to do that, maybe you’re trying to hedge against some sort of resiliency issue, right? Where you say, ‘Well, if AWS goes down, I want to make sure that my application doesn’t suffer any downtime.’ But what you’re really doing is you’re not then pegging your reliability to either the reliability of AWS or your second cloud, maybe Google Cloud. You’re pegging it to the reliability of your middleware and all the stuff that you’re creating day in and day out, right? That’s going to keep this whole system online. You’ve created something more brittle than if you had just really bought in and trusted a provider.

Rahul Subramaniam: In my experience as a talk to a lot of CTOs, Kubernetes seems to be the platform that everyone jumps on. It’s kind of become the de facto model that everyone adopts. To me, Kubernetes sounds like just the middleware layer you were just talking about a minute ago, and they rely on that as the mechanism to build their cloud architecture, which seems like a highly suboptimal way of going about migrating stuff to the cloud.

Forrest Brazeal: Well, I think we’ve just described every large complex environment, right? They’re all suboptimal. If there was an optimal world, take me there, that’s the world I want to live in. But no, I’m not here to defend Kubernetes as the be all and end all or right in every scenario or even the most simple and straightforward way to do things. I do think it’s an advantage over writing your own completely custom middleware layer. At least it’s a standardized system at this point that a lot of people understand and that it has a lot of eyes on it, buy and invisibility across the community. I would advise getting as managed with it as you can to take away as much of that operational toil and pain as you can. That’s why I like some of the things that Google’s doing with the autopilot version of GKE, which takes away some of the management around nodes. That’s why I like some of the things that Google’s doing with Anthos, which people tend to think of as a “multi-cloud tool” but it’s really not.

Hilary Doyle: You’ve said in the past that multi-cloud becomes an inevitability once a company crosses what you’ve said as a surprisingly low level of organizational complexity. I mean, I would’ve thought that multi-cloud actually adds more complexity to an operation, even just at the administrative level. So how do you avoid adding complexity to complexity with this solution?

Forrest Brazeal: It gets back to what you mean by multi-cloud because when I say multi-cloud is an inevitability at the organizational level, I mean it’s inevitable that you’re going to have bits and pieces of different service providers floating around in your environment. It’s about, look, here I am in a multi-cloud setup because it happened to me and I’m just going to have to make the best of it.

Rahul Subramaniam: I really want to pick on the Anthos example that you just talked about because for me that is quintessentially multi-cloud architecture. I’d love to know from you about what customers are saying that prompted Google to build something like Anthos that allows you to create your Kubernetes clusters across both Google and Amazon. There must have been a dire need for GCP to build that.

Forrest Brazeal: I’m really not the best person to ask about the nuances of that, but what I can tell you is that as we look at what businesses are actually doing, they end up in states where let’s say they have an existing footprint with one cloud provider and then they’ve decided, you know what? Strategically in the future, we actually are going to bet on a different cloud provider going forward. That does happen. And so it could be the case that a tool like an Anthos could be a really helpful product to help you manage a switch like that to help you take some burden off of your platform teams. And again, these we’re just, we’re talking very real gritty things that happen. This is not just a pie in the sky whiteboard architecture. This is trying to manage existing complexity.

Hilary Doyle: Rahul, I have a question for you because we spoke earlier about the importance of leverage in the business that you do – and how being all in on one provider with AWS has given you a leverage that you didn’t think you’d have. Were you to move your business across multiple cloud providers. How significant is leverage for you in the business that you’ve built Rahul, and can it exist in any way in a multi-cloud operation?

Rahul Subramaniam: The cloud space is just evolving so rapidly and dramatically, and it’s changing so many things about how we build software, how we deploy software that having the inside track in new services coming out and figuring out how to leverage all the best tools to stitch all these services together to come up with a solution – that is far greater leverage because from a cost standpoint, that could mean a 90% reduction in your costs or reducing your complexity of your deployments by an order of magnitude. To me that leverage is far more important and that for me comes from being all in on one provider because you can build those relationships again, all in on one provider, on something that is on a single application that is significant.

Forrest Brazeal: I mean, if you have the autonomy to choose what stack you’re going to use for a project, your bar to bringing in tools from multiple providers should be very high. There should be a really compelling business case for why you need to jump out of band and do that. Because for all the reasons you just mentioned, not only the complexity, not only the extra integration time, not only potentially the cost differentials, not only potentially the lost just flywheel effect of getting more deeply integrated with your provider, right? But also just the skill aspect. I mean, it’s a lot harder to be good at two things than it is to be good at one thing, right? You tell me, I have to go hire people now that know both Azure and Google Cloud. Why don’t we just pick one? Right? So if we have the choice to pick, if that option is on the table for us, then yeah, let’s go all in.

Hilary Doyle: Sounds like a great argument for an all in on one vendor, but listen, as you say, let’s talk about hiring. When it comes to the difficulty of hiring, you’ve highlighted that there isn’t a skills gap among developers so much as there can be an experience gap, which is ultimately how developers level up their skills. So as you’ve pointed out, it’s tough enough to be an expert on one platform. How are devs supposed to cultivate enough experience with multi-cloud to have these skills to ultimately get hired?

Forrest Brazeal: Yeah. And I’ve advocated for multi-cloud being something more that happens at a people level than it does at a workload level. I think that particularly as you become a more senior developer or you move more into technology leadership positions, whether or not you ever use more than one technology stack more than one cloud provider for a given workload – it’s important for you to have a good understanding of the landscape, of the differences between what the providers offer so that you can make educated choices. I think it even helps you as you’re building on a single provider to just know what else is out there. But if you’re asking how do I level up my career given that it’s hard enough for me to get experience on one cloud, let alone two? I mean, I would say start with one, show enough experience with one cloud that you can get hired. And if you work in an organization of significant complexity, you are more than likely over time going to start to butt up against some other clouds because that’s just what happens in the real world.

Hilary Doyle: Okay, guys, final thoughts?

Forrest Brazeal: I’ve been calling out that multi-cloud is happening and it’s inevitable whether we like it or not since, well before I went to Google. You can go back and look at some older things that I had written in that respect and not just me. I think it’s a well understood view in the industry at this point. So it’s my belief that we are going to be in a multiple cloud provider industry for a long time to come, and that because of that complex organizations are going to end up with bits and pieces of different cloud providers in their environments for the foreseeable future. So it’s important for us as an industry to have patterns and frameworks to handle that. It’s important for us as individuals to have skill sets that will adapt well to those environments.

Hilary Doyle: Rahul, what have you got to add?

Rahul Subramaniam: Forrest’s contention is that as the organizational complexity grows, you invariably end up with the multi-cloud scenario, but that just leads to so much more complexity, which is exactly what you’re trying to avoid in the first place, isn’t it? Reducing complexity should really be the goal of any organization, and that happens when you go all in on one vendor. Now you really need to resist moving to the other side. There are scenarios though, where there are different products on different providers, and that’s completely fine. I mean, that’s not the multi-cloud scenario that I’m forcefully against.

Hilary Doyle: Thank you so much for being with us. For us, this has been a really enlightening conversation. We’re delighted to meet you.

Forrest Brazeal: Of course. Thank you so much for having me.

Hilary Doyle: Okay. As a champion of the all in on one approach, what are the best practices to maximize what you get with one provider?

Rahul Subramaniam: Not to sound scandalous.

Hilary Doyle: Oh please do.

Rahul Subramaniam: But one of the core principles of design is KISS, which is keep it simple, stupid. Use the well architected framework to build a highly available elastic and reliable solution that’s going to really help you.

Hilary Doyle: Worst kind of kiss out there. But I’ll take it for tip number one, what’s two?

Rahul Subramaniam: So as unpopular as it sounds.

Hilary Doyle: Oh, love it. Already.

Rahul Subramaniam: When it comes to cloud architecture, follow the road most traveled, as against the road less traveled.

Hilary Doyle: Paraphrasing Frost.

Rahul Subramaniam: Architectures and patterns that are widely used and well-tested will really stand you in good stead. They’re publicly available, they’re easy to get started with. Reinventing a new wheel really isn’t adding a new value over here. It just adds loads of risk that you should avoid at all costs.

Hilary Doyle: I hear you. Okay. And three.

Rahul Subramaniam: So a lot of people that I hear talking about multi-cloud say that they choose multi-cloud because it helps with disaster recovery. But as I’ve said and can’t repeat enough, a good cloud-based high availability design just does away with the need for disaster recovery. It’s just irrelevant in the cloud space.

Hilary Doyle: The man has spoken. Rahul, please tell me the last thing you watched on Netflix.

Rahul Subramaniam: Hilary, if you looked at Netflix’s profile, it is literally filled with movies and shows that my kids watch all the time.

Hilary Doyle: Sounds like an excuse.

Rahul Subramaniam: The last one is Kungfu Panda. So all of my recommendations are about Kung Fu Pandas and various versions of that.

Hilary Doyle: Solid film.

Rahul Subramaniam: But I usually settle for the latest Bollywood movies when I get a chance to decide, in my house. What about you, Hilary?

Hilary Doyle: Well, I started watching the final season of Peaky Blinders and it literally blew up my television. So now I just go to plays. But I do want us to get back to that epic love story of Netflix and AWS. From the moment Netflix laid eyes on AWS from the instant they went all in. I beg your pardon. Online streaming exploded. The Netflix audience tripled between 2008 and 2012. It’s grown exponentially in the decade since. What are the pieces of this alliance that really stand out for you?

Rahul Subramaniam: So from the Netflix perspective, AWS really was a godsend for them. I mean, they could scale up or down in a matter of minutes based on viewership demand. And not only that, I mean with every expanding set of regions and POPs, by the way, that’s points of presence.

Hilary Doyle: Thank you.

Rahul Subramaniam: They were able to deliver low latency streamings to customers across the world.

Hilary Doyle: It’s funny, all I’m doing here now is casting AWS and Netflix in their romantic comedy. I dropped off for a second there, but I’m back. What would’ve changed and be kind if you can, had Netflix taken a multi-cloud approach?

Rahul Subramaniam: I think that would’ve been completely untenable based on all the stuff that they’ve published about their architecture on AWS. I mean, Netflix has an extremely complex deployment and they spent years fine tuning their higher availability service on AWS. I can’t even wrap my head or imagine what a nightmare a multi-cloud setup would look like for their deployments.

Hilary Doyle: You’ve talked to us as an individual about your close relationship with AWS. They’ve invited you into their fold. You’ve literally had an impact on their evolution. Take us through the Netflix AWS relationship. How significant is Netflix’s influence on the inside?

Rahul Subramaniam: So I have to admit, Hilary, that I’m in awe of how Netflix went all in on AWS. I mean, they are tied at the hip with AWS and just by looking at their open source contributions, you get a sense for it. Check out netflix.github.io for dozens of AWS centric tools that they’ve created. I mean, I do want to talk about one tool in particular that has had an enormous impact on the ability to ensure high availability, not just for Netflix, but for everyone else. And that tool is called Chaos Monkey. Funny name. I know, but hear me out.

Hilary Doyle: I’m all ears.

Rahul Subramaniam: So Netflix is one of the first organizations to realize and embrace the ephemeral nature of compute. I mean, just because AWS allocated an instance to you with an API call, it does not mean that that instance was always going to be available. A data center or even an availability zone might go down at any time. Now, Netflix started building one of the most effective high availability systems out there with a very close partnership and relationship with AWS. At the same time, they needed to know really if their high availability system was actually going to work.

Hilary Doyle: So they needed to be able to test the limits of their system and mimic disasters.

Rahul Subramaniam: Absolutely. So Chaos Monkey is basically a tool that randomly sits and shuts off machines and services across your entire deployment. And that’s how if your system is capable of surviving disaster scenarios, that’s how they tested for their high availability. That deep rooted grasp of cloud services and high availability would have been unthinkable without the deep relationship that Netflix has with AWS. And that Hilary is what you get when you don’t go multi-cloud.

Hilary Doyle: And that listeners is what you get when Rahul drops the mic. That’s it for us for now. We’ll be back. You’ve been listening to AWS Insiders from Cloud Fix. I’m Hilary Doyle.

Rahul Subramaniam: And I’m Rahul Subramaniam.

Hilary Doyle: CloudFix is an AWS cost optimization tool. Learn more about them at cloudfix.com. Check out the show notes.

Rahul Subramaniam: And please leave us a review and follow us.

Hilary Doyle: We’ll catch you later.

Rahul Subramaniam: Bye, bye.