If you’re looking for older services at AWS, there really aren’t any. For example, Simple Storage Service (S3) has been with us since the beginning. It was the first publicly launched service that was quickly followed by Simple Queue Service (SQS). Still today, when it comes to these services, simplicity is key!
Today, we’re talking to Mai-Lan Tomsen Bukovec, vice president of S3 at AWS. Many people use S3 the same way that they have for years, such as for backups in the Cloud. However, others have taken S3 and ran with it to find a myriad of different use cases.
Some of the highlights of the show include:
Data: Where do I put it? What do I do with it?
S3 Select and Cross-Region Replication (CRR) make it easier and cheaper to use and manage data
Customer feedback drives AWS S3 price options and tiers
Using Glacier and S3 together for archive data storage; decisions and constraints that affect people’s use and storage of data
Feature requests should meet customers where they are, rather than having to invest in time and training
Different design patterns and best practices to use when building applications
Batch operations make it easier for customers to manage objects stored in S3
AWS considers compliance and retention when building features
Mentorship: Don’t be afraid of the bold ask
Full Episode Transcript:
Hello and welcome to Screaming In The Cloud with your host, cloud economist 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 of Screaming In The Cloud has been sponsored by CHAOSSEARCH. CHAOSSEARCH is a cloud-native SaaS offering that extends the power of Elasticsearch’s API on top of your data that already lives in Amazon’s S3. CHAOSSEARCH essentially turns your data in S3 into a Warm Elasticsearch Cluster, which finally gives you the ability to search, query, and visualize months’ or years’ worth of log and event data without the onerous cost of running a Hot Elk Cluster for legacy data retention. Don’t move your data out of S3. Just connect the CHAOSSEARCH platform to your S3 Buckets and in minutes the data is indexed into a highly compressed data format and written back into your S3 Buckets, so it keeps the data under your control. You can then use tools like Kibana on top of that to search and visualize your data on S3, querying across terabytes of data within seconds. Reduce the size of your Hot Elk Clusters and waterfall your data to CHAOSSEARCH to get access to an unlimited amount of log and event data. Access more data, run fewer servers, spend less money. CHAOSSEARCH. To learn more, visit chaossearch.io and sign-up for a trial. Thanks to CHAOSSEARCH for their support of this episode.
Corey: Hello, and welcome to Screaming In The Cloud. I'm Corey Quinn. Today I'm in Seattle meeting with Mai-Lan Tomsen Bukovec, the VP of S3 at AWS. Mai-Lan, thank you so much for taking the time to speak with me.
Mai-Lan: Hi Corey, nice to see you.
Corey: You are probably best known in recent history for appearing on the keynote stage at re:Invent. You were in a video of you walking through the spheres, having conversations of taping your hands to either go kickboxing or deliver one heck of a product review. You've been at AWS a lot longer than since November.
Mai-Lan: Yeah, that's right. I had a great time talking to the re Invent audience during the keynote. S3 is a favorite topic of mine, but I have been with AWS for over eight years now.
Corey: Which feels about three times longer once you wind up getting inside of it. It feels like it ages you prematurely. Let's start at the beginning. As you wound up recently informing me, S3 was the first publicly launched service followed very closely by SQS. So if you're looking for older services at AWS, there really aren't any. This is one that's been with us since the beginning.
It's interesting in that it's turned into something that almost sort of belies its name. It's become such a capable and foundational part of what people do on AWS, that it almost makes you wonder, is simple even the right descriptor for it anymore.
Mai-Lan: We think it is. I mean, to be honest, simple has been at the heart of how we build S3 from the start. In fact, it's part of our product tenants or service tenants that we as builders think about every time we add something to S3.
If you take a step back and you look at how people use S3, a lot of people use it in the same way that they used it over a decade ago, which is those backups in the cloud, right? How do I take the storage, which I know is going to grow really fast and put it a place where I know it's going to be really safe and secure. I don't have to pay very much for that storage. We have plenty of those customers, just like we did on day one.
For us, what's been really interesting is how people have taken that, just run with it, and started to use S3 in different ways. We still think of it as being simple because everything that we try to build is a very clean representation of what a customer is trying to do. Right now, customers are doing all kinds of things with S3.
Corey: One thing that's consistently surprised me, as I've moved through my career between companies where I was an employee or as a consultant, is the myriad use cases that I'll see S3 being used for. There's the stuff that everyone would expect it to be used for, such as backups or static assets serving. But there's also strange stuff, such as using it as a repository back end for git repositories and other things that seem a little bit on the strange side.
If I'm going to look back at the last couple of years of S3-based announcements, one of the prevailing themes that I'm seeing from the outside world is that a decent number of these enhancements are focusing on, what appears to be, moving compute closer to the data about taking data that lives in S3 and being able to do things with it where step one isn't pull all of that data somewhere else. First, was that an accurate assessment for more you see things? Secondly, what's driving that?
Mai-Lan: I think that's very true. I think a lot of customers sometimes will start with these very basic, "Where do I put it," type of scenarios for storage. Then they quickly go to the, "What do I do with it?" A lot of customers who are actually starting with their first use cases being a data lake, they start from, "What do I do with it," and all places kind of end up in S3.
If I think about a lot of new capabilities that we have launched over the last couple of years, whether it's a storage class or it's a new capability, a lot of it is focused on, "How do we make it easier to use the data." There's a lot of different examples about that. One of them is S3 Select which we recently added Parquet format for, will let you go in and use the simple SQL statements directly on your storage.
The way I think about it is that it's a byte-aware feature. You can go in and just get the bytes you want out of the object that you have in storage. You can do it without having to retrieve the entire object. We did that because we have a lot of customers that filter data sets in S3. To do that, they pull all the data out to do some type of analytics and then they put a very small set of data back in.
You have two different ways to do it. You have Athena, if you want to use that or you have S3. For me, that the tip I always give to customers when they're trying to pick between them is basically a joint. If you want to do complex sequel statements, Athena's your tool. But if you're just trying to find a needle in a haystack or you want a simple parsing or a simple SQL statement, then S3 Select is a really good way to do a targeted git of bytes in an object. That's one example.
Another example is, we have this feature called cross-region replication. Our idea with cross-region application is that, let's give you a policy-driven engine that lets you create another copy of data in another region if you want it. You can target that second copy of data in another region in a Glacier storage class or the same storage class you have in your primary region if you want to. But the way we think about it is that we know that not all data is created equal out of your storage and so we let customers tag or put a custom metadata on individual objects and then only replicate those individual objects.
We think about usage of data. It's not just usage and how do I use it in my business workflow, which might be more of a S3 Select kind of scenario. We also think about it as how do I manage my data in a way that is compliant with whatever company policies I have, and how do I do it in a fine grained way where I can save as much money as possible. That's how we keep on building on that kind of core fundamental get, put, list functionality that we started with over 10 years ago. We really take a look at what customers want to do with it and then we try to make that cheaper and easier.
Corey: One of the early arguments against AWS was what happens if they wind up adding a zero to the end of every price. We take a look back at almost years of history now and there has never been, that I've been able to detect anyway, a single case of a service that has cost more after it has been launched to general availability. The price changes only tend to go in one direction and that's down. It's one of the only systems where I think you can look at this and say, "Oh, yes, I'm storing data here," and the cost to store that is getting less expensive over time.
That's one of those transformative moments that you start to see that, "Hmm, maybe there's something to this idea of public cloud."
Mai-Lan: Yeah, we take that really, really seriously. In fact, if you think about the evolution of our storage classes, that's just a reflection on that commitment to cost savings. If you think about, for example, a few years back, we released Infrequent Access. Infrequent Access gives you almost 40% cheaper price on storage at REST and then you have to pay a retrieval fee. But, by and large, if you retrieve your object one time or even less a month, you're totally going to save up money every month on S-IA. We didn't just stop there, we kept on going with a one-zone storage class, which is very similar for that Infrequent Access pattern, which is 20% cheaper than S-IA.
At re:Invent, we launched this new storage class, Intelligent Tiering, where we will automatically give you savings on individual objects that happen to be infrequently accessed without you doing anything at all, without picking a storage class. It's not just continuing to try to decrease the price of an individual storage class. It's also how do we find new ways where even if you don't know the access patterns of your storage, you can still save money automatically. It's really important to us, it's part of our DNA, and it's what we come in everyday to do.
Corey: I was very excited at Intelligent Tiering launch at re:Invent for my own account, because I know there are objects that once I wind up putting into S3, I will never touch them again, so being able to pay less to store them was incredibly exciting. I remember that my account is nothing to speak of and my S3 charge is something on the order of $0.32 a month. It turns out that optimizing that is not really in line with what I want to be focusing on.
One thing you didn't mention, just now, as you went through the list of storage classes is the, I don't want to call it sunset, but for a while, there was a Reduced Redundancy Storage class, which is still there. The API is probably going to be there longer than I will remain alive. But what's fascinating to me, is that it isn't talked about, it's still there. In a majority of regions now, but I believe not all of them, it is no longer participating in price cuts, so that standard storage with better durability is now less expensive than the Reduced Redundancy Storage, But you can still use that service.
If you don't mind my asking, was deciding to change direction away from reduced redundancy storage into infrequent access a controversial one? What drove that decision?
Mai-Lan: I think a lot of it has to do with just straight up what customers are asking for. To be honest, not a lot of customers were using RRS. So we launched it and not a lot of customers started using it, we kind of looked at it, and we said, "Huh, why? What do customers want here?"
We took a bunch of that feedback and that's why we built our next set of storage classes. We built S-IA for the infrequent access, and now, we've got a huge amount of uptake very quickly. We built this new type of low-durability storage, which is this One Zone-Infrequent Access storage class that we have. The Z-IA storage class is actually growing really rapidly as well, because we hit on what customers are really looking for, which is I have a lot of infrequently accessed storage, which is, frankly, copy storage.
A lot of people have a lot of different copies and they don't really know who's using those copies, so I can't get rid of those copies. But they really don't want to pay too much money for it and so they need a place to just put that and One Zone is just perfect for it. I don't think there was a lot of controversy over it. I think it was more of a let's take a hard look at the storage class and see what customers are liking and they're not and how do we use that information to build what people want.
Corey: One topic that I enjoy bringing up from time to time when I'm giving conference talks is, at the start of the talk, when I'm waiting for people to finish filing into the room, I'll pull the audience with random questions that strike my fancy. One of them that I enjoy asking is for people to raise their hand if they've ever used Glacier to store something. A bunch of hands go up, as you might expect. My follow up to that is usually great, "Can you please keep your hand up if you've ever restored data from glacier?" Almost every hand winds up dropping.
Every time I go into a new account, I see different use cases that I generally hadn't considered before. I'm curious as to what you see and how that interplays with the recent launch of Glacier Deep Archive.
Mai-Lan: Glacier is a great product. To be honest, every time I talk to any customer, I ask them where are you putting your archives, because everybody has archives. One of the interesting things about Glacier is that we have customers that just see it as another storage class of S3. We've built a lot of capabilities around that. We built our Lifecycle tiering around that where you can do this movement into Glacier. A lot of customers also said how can I make it easier to use both S3 English or together.
That is something that we're kind of deeply investing in right now. I think what we're going to see is, all of our new storage classes. For example, the upcoming Deep Archive one, is going to be just another storage class of S3. By that, you'll be able to do things like user cross-region replication engine, that I talked about before, to set up a policy that says your second copy could be in Deep Archive or it could be in Glacier. I think it's just going to open up people to think about archive in different ways. Even that word "archive,” archive just sounds so monolithic.
Corey: It sounds like someone's about to try and sell me a tape drive if we're being honest.
Mai-Lan: That's right, to be honest, that's not how data works. Data is this organic living thing and it doesn't just fit into this box of archive. You've got very active archives. You've got semi-active archives.
That is a really smart way to understand what are your retrieval patterns? How can you get the lowest price point, which is always what Glacier or Deep Archive, any of these storage classes will give you. But how do you not think about your data as an archive? How do you think about it as a library of content, or you think about it as storage that just has different access patterns?
Corey: It's interesting when you look at the spectrum of storage, and what aspects people are willing to compromise on. There's the idea of I don't necessarily care if you lose the data, I can always rebuild it there, that's one angle. There's the argument of I don't care how much it cost me to pull it back because I very rarely need to do that. There's even the I don't care if it takes you a week to getting the data back to me. You can put it on a drive and mail it to me and that retrieval latency is just fine for my use cases. Seeing what decisions people make and the constraints that shape their choices and the interaction with storage has been fascinating to watch from a third party perspective.
Moving slightly away from the idea of storage tiering, I had a feature request, last spring, that I made on Twitter because apparently that is the best way to get attention is to be, first, really obnoxious, and loud. Secondly, request something that you would like to see.
My request was for an SFTP endpoint for an S3 bucket. Immediately, I wound up getting two very different responses. One was, "Oh my stars, yes, I would give my kingdom for that." And the other was, "SFTP is so 1990s, just teach whoever it is you're using to wind up interfacing with the S3 API."
I used to work in finance, teaching a bank how to use a new API opens Pandora's box of compliance. Being able to meet customers where they are and not have to ask your partners to completely refactor their entire security policy is one of those things that is transformative and was a great thing to see. What was it that drove that particular decision point, as far as deciding that that was a feature that was worth investing time in? Please, say it was my tweet.
Mai-Lan: Well, I actually will say it was your tweet but it was also a lot of other customers who said very similar things. To be honest, Corey, it's really important to know, we don't judge. We don't judge, I mean, if a customer comes in and says, I need this protocol, it's been around for a long time but we got a lot of customers who need it because the fact of the matter is, there's a lot of clients out there and there's a lot of business processes and a lot of B2B workflows built around it, and we'll go figure out how to how to build it. Whether it's that or if it's NFS, whether our file gateway, it's another one. There's all these protocols out there and what people are trying to do is they're trying to figure out, how do I create a bridge, how do I take what I got today and figure out how I'm going to get to the clocks. I know I want to get there but maybe I can't rewrite everything. Like I said, we don't judge. If customers are in that spot, they're in that spot and we have to figure out how to help them.
Corey: There's something to be said for meeting customers where they are. When the feature was announced, my mentions caught fire again with that previous dichotomy but there was also a bit of a flare up of people ranting about how extortionately priced it was. Looking at it, I seem to recall, please don't quote me on this, but it’s ballpark, a couple hundred bucks a month. People were saying, "Oh, I can spin up an EC2 instance and have it do its own thing." If you can do that, this product probably isn't aimed at you.
When you're doing this for something that has compliance eyes on it and has a an entire chain of custody concern, you need to build an AMI, launch an instance from it, make sure that it winds up polling to make sure the transfer is completed, validate the transfer complete successfully, you have data rotation, and you have archival concerns. Paying a couple hundred bucks a month to make this problem go away completely for an enterprise is an absolute no brainer with the caveat that it doesn't feel to me like this is an offering that is aimed at a tinkering hobbyist in their garage, which I very closely resemble.
Mai-Lan: I don't know about that, Corey. I think FINRA uses it for exactly what you're talking about, talking about the finance space. What they did is they were able to retire their entire SFTP infrastructure that they were having to maintain because they had a lot of clients that they had to maintain and a certain volume of transfers that they were doing.
Companies out there and know, if you are maintaining that infrastructure today, you know that there's a lot more costs to it and, honestly, maybe even just the money to run the compute, it's the overhead for it, it's the infrastructure. That's why we built that as a managed service.
Corey: With one or two big data startup exceptions, I've never had a client that is spending more on their infrastructure bill than they are on their own, I want to call it, their own engineering expense. The infrastructure is always number two or further down the list.
Mai-Lan: Yeah, I'd agree with that.
Corey: Here's a fun one that I've been meaning to ask someone here for a while and you're probably on the best people I can think of to ask this. What do you wind up seeing as far as interesting use cases for S3 that have taken you by surprise?
Mai-Lan: I think one of the fun things about working on S3, and I think you said it earlier, Corey. It's such a foundational technology for a lot of customers, it's just storage, and it's where your data goes. It cuts across every single, market segment. It cuts across all the different geographies. The use cases are actually phenomenal.
I've had so many customers come to me and say, "Hey, I use S3 is my data warehouse." They tell me what's working for them. They'll come to me and they'll say, "Hey, I use S3 for a video library." The satellite imagery and video imagery that we have on S3 is actually fairly phenomenal. Do you know Peloton, those bikes?
Corey: Oh, yes, I dream of affording one day and then I remembered that my version of fitness involves fitness entire burrito in my mouth and then I gave up on those dreams.
Mai-Lan: You could actually eat that burrito on the bike while looking at a video that's stored in S3. There's so many different environments, companies, types of data, it's customer care records, it's recordings, and it's imagery. I think one of the ones that I like a lot, it's the NGA, which is a government agency that has a satellite imagery.
To me, one of the really interesting things about satellite imagery is that it's not just pictures of our world. It's pictures of our world that's being used in so many different ways. The Ebola crisis used all those digital images, it was used for helping Nepal after the earthquake. For me, I'm a former Peace Corps volunteer. I went to West Africa to Djenné in Mali and I served there. For me, one of the things I really like about working on S3 is being able to find all these examples about how storage is not just helping companies, it's helping people. Whether that's genomics research for companies like GRAIL, looking for early indicators of cancer to help prevent disease and to treat disease at a stage where it's more treatable than in later stages. All of those different ways that we're helping, not just companies but also people and the company's missions, that's really important to me.
Corey: So from a perspective of someone starting out today with S3, what best practice advice would you have for them as they start interacting with effectively a type of storage semantic that many shops historically have either not existed until now or have been on-prem only, haven't really had to work with object stores were never generally a thing that storage vendors wound up offering. What advice would you have for those companies?
Mai-Lan: A lot of people just don't think of object. The word object itself is not something that flows from people's vocabularies and the work they do. The fact of the matter is that S3 is just used for storage. It's unstructured storage, it's unstructured data, it's just a lot of it in every single company. For folks who are just starting, I think the first thing I like to ask them is when you're thinking about what you're building, there's a bunch of different design patterns that you can use.
You have your lift and shift design pattern where for whatever reason, all you are trying to do is you're trying to take an application that you have on premises and just move it, whole kit and caboodle over to the cloud, and a lot of customers have that. Other customers have things where they're just trying to swap out one part of their application. They keep the compute somewhere and store somewhere else, or vice-versa. You have this whole, "Hey, I can rebuild things from scratch," and really leverage the cloud universe of AWS and the benefits.
What's really interesting is that a lot of companies can do all three at the same time with different applications. You don't really need to do them in any kind of order. Surprisingly, some companies will do them—take one of those design patterns in a way that will surprise you. I mentioned FINRA before, that's a great example.
Over five years ago, I remember we were having this discussion with FINRA because FINRA was just getting started. They were really looking at this lift and shift—do I do that, do I swap that apart. The mission of FINRA is to find instances of fraud within 24 hours of a transaction. In order to fulfill their mission, they actually had to go and rebuild an application from the start. They had to do the whole kit and caboodle.
The conversation I would have with people today is a little bit different but some of the bones are still there. We would say how do you want to structure your account and your buckets in the account. The first thing I would say is put block public access on your account for every bucket today and in the future that you never want to be public. What that setting will do—it's kind of a control that we offered and we launched at re:Invent is it'll make sure that any bucket created in the future associated with that account won't allow public access to anything in the bucket, it's incredibly important.
If you happen to have a need for having a public access bucket, for example, you're using a website content or whatever, then you can create a separate account, you can link it if you want to have all the reporting and the linked account benefits. You can create a separate account that is only restricted for certain amount of use and you don't have to have Block Public Access on it. For 99.9% of any usage of storage that you have internally, for data lake, or for your business, you have that protection with Block Public Access.
We used to say, Corey, and you know this, being a long-time S3 user, I used to say that you should randomize the first few characters of a prefix in order to help make sure that you get the best performance over time. Do you remember that?
Corey: Oh, yes and if you didn't do that you're going to see interesting performance bottlenecks as you scaled that we're challenging.
Mai-Lan: What we did in the last year, is that we raised our performance rates. What's interesting about our performance rate is that we don't have any throughput restrictions on a bucket or an account. Our performance rates are requests per second on a prefix.
Corey: I guess the secret behind this entire podcast recording, of course, is to come in here and get requests for weird edge case problems I have. Something that I've seen that recurs fairly commonly at large scale accounts is, historically there were hard limits on number of buckets per account and a result, people would wind up putting, in some cases, what are now billions of objects into a single S3 bucket. Since everyone's been using that bucket for five years, there's no real understanding of what's in that bucket. Until re:Invent, my answer to what to do there involved an awful lot of custom coding and awful lot of work that no one really wanted to do and it still was relatively unsatisfactory.
The new answer to that, to my understanding, is the idea of S3 Batch Operations. Can you tell us a little bit about that?
Mai-Lan: Yeah, for sure. It kind of goes back to this evolution of S3 that we started with, Corey, where S3, when it started was a very simple interface and we've kept a lot of that simplicity. But then, we kind of looked at what customers were doing and they were telling us what work they were doing with S3 and batch operations as a direct result of that.
We now have a lot of customers that have a lot of objects in their buckets. They were telling us that they were building applications to manage those objects. We thought to ourselves, if we got a lot of customers do that, we got to figure out a way to put that into our API, to absorb the work there.
I talked a little bit about best practices for transfer manager, that's built into the SDK. Things exponential backoff are built into the SDK. We thought to ourselves, how do we build in a bunch of the work, the infrastructure involved in taking one operation that you have to do across millions, if not billions, if not trillions of objects. How do you take that work and build it into the API?
That's what we did with batch operations. What we've done is we've launched with a few capabilities that you can do initially like, restores is a big one. The goal here is that when you use this, you can pass in a manifest of objects that you want to act against. You can use our inventory report. We run an inventory report at just like incredibly low cost. Anytime you want to know what's in your bucket, you just turn on inventory report, you won't even notice the charge for it, and you get a list of what's in your bucket.
You can use the inventory report or you can create a custom manifest and you pass it in to batch operations and you tell about operations what to do. Batch operations will handle retries, it'll audit what got done and it'll give you reports for what got done. We announced it at re:Invent and we are going to be launching NGA pretty shortly. It is what you want to use if you want to do anything to your storage in bulk. I think one of the really interesting things is that that applies to Lambda functions as well.
If, for example, you have a higher function that you want to do or higher level operation that you want to do. For example, you want to create a thumbnail out of an image, some people use it for their garbage collection, or their delete processing. Other people will use it for a content transformations, for articles, or things like that. They'll add metadata or whatever they want to do. The book is open, if you are a serverless programmer and you're using Lambda, you can write a Lambda function and you can just use batch operations to run that Lambda function across the corpus of your storage.
Corey: One thing that I also found that personally appealed to me during the most recent swath of storage announcements was the idea of compliance locks, either on a on a temporary basis or even account wide the department administrator couldn't release it. Suddenly, there's a much better story for regulated industries with WORM compliance. That seems to me like one of those transformative features for companies in the regulated space but if you're not one of those companies, it may have sailed completely past you. That feels like a manifestation of Amazon releasing specific features for specific customer segments that for most of us, are either going to be a transformative release or something that is going to go almost completely by the wayside. Is that a fair assessment of how Amazon views these things? Or is there a belief, for example, that something like this compliance lock option is something everyone should be using in the fullness of time?
Mai-Lan: I think it is interesting because it does convey a little bit of the mindset of how we build things. I will tell you, when we first looked at that feature and how we could build it. We could have just built it for the SEC regulation for WORM compliance, we could have done that. We actually didn't because our goal there was to make it more broadly applicable to anybody who wanted, essentially, control.
There's two modes there. You can use this new capability that we have in one of two modes. One of them is, as we said, for WORM compliance. The second way to use is it is really for retention where you can actually set up a policy where somebody under a certain administration role will be allowed to delete it over time, which is not the SEC compliant rule but it is a different mode that helps create a class of storage that you have in your company that nobody can delete, except for your compliance officer, as an example.
We had a lot of other customers saying, "Look, all data is not created, equal, usage is different but hey, access and permissions to delete needs to be different, too." I need a way to not manage that at a permissions level, I need to manage it at a policy level. That's how we ended up building this feature.
Corey: No litigation hold or something else that winds up of driving sudden shifts in data retention requirements.
Mai-Lan: Yeah and going back to a topic that you brought up earlier, Corey, a lot of that is, again, really listening and learning about usage. It's not just about how are the bytes stored that's like table stakes securely, durably etcetera. It's how are people using it and how do we make that safer, easier, cheaper, and better.
Corey: We're almost out of time. I want to thank you for taking the time out of your day to speak with me. But before we do, something that you have been a staunch advocate for in the past has been the idea of mentorship. That's been a recurring theme of a number of episodes at this podcast, where the ability to figure out to someone starting new in the industry. How do you wind up taking your first steps? Where do you go? What does mentorship look like?
The road that virtually all of us have walked to get to where we are is long since closed. The world changed, there are no data center jobs to speak of anymore the way that they once were. What advice would you have for people who find themselves in that position at the beginning of career who are wondering what the future looks like?
Mai-Lan: Yeah, it's a great question. I think it's an important one. I do a lot of mentoring and one of the common things that I tell just about everyone I mentor is, just don't be afraid of the bold ask. Because a lot of times, particularly when you're early on in your career, you can be a little intimidated by the ask. When you're in school, the bold ask is going into your advisors office or asking some professor to take you on for a project and that's kind of hard, right? But you get in the workforce and your bold ask is a little different. It's like, "Hey, can I run that project? Hey, I have something to say in this meeting.” How do you make sure that you feel like you can make the bold ask to go and be an owner?
A lot of times, you don't have to ask for that permission. You don't even know it but there's no ask here. You might be blocking yourself off from doing it because you feel like you have to ask, you have to earn that way to the table. A lot of what I talk to some of my mentees about is don't let yourself be blocked by an ask that you feel like you have to make and it's a hard one for you. Don't be afraid of the bold ask. Just go do it, occupy your space, put your elbows out.
This is an important thing to do and the thing that you'll realize when you do it is that people won't even know. That big bold ask that's built up in your head, you make it and people are, "Yeah, sure. Okay. Tell me how it goes." You know what I'm talking about, Corey.
Corey: I do and if someone had told me that when I was starting at my career, it would have shaved years off of what it took me to get to where I am now. There have been struggles that I would have been able to just surmount almost with the snap of the finger if I had contextualized it that way.
Mai-Lan: There's just so many internal dialogues going on, right? You just got to go and make it.
Corey: The voice whispering in your ear that you're not good enough is lying to you. And I think that's something that people tend to lose sight of.
Mai-Lan: I agree with you.
Corey: Thank you so much for taking the time to speak with me today.
Mai-Lan: For sure, thank you, Corey.
Corey: Mai-Lan Tomsen Bukovec, VP of S3 at AWS. I'm Corey Quinn, this is Screaming In The Cloud.
This has been this week's episode of screaming in the cloud. You can also find more of Corey at screaminginthecloud.com or wherever fine snark is sold.