ModernOps with Beth Long: AWS for Big and Little Companies

Lee: 00:00:00

Today and modern digital business. I'm starting a new series on the podcast. The series is called ModernOps. I'll be hosting this series along with a good friend of mine, Beth Long, who is the head of product at jeli.io, an incident analysis company. This will be our first of a series of episodes. In this first episode, we will be talking about how the experience of using the cloud varies for large companies versus small companies. Are you ready? Let's go. My co-host for this series is Beth Long. Beth is head of product at jeli.io, an incident analysis and management platform that combines comprehensive data from multiple sources to help identify problems and proactive solutions. Beth and I worked together a New Relic where Beth was heavily involved in a product operational management of a highly scaled and fast-growing application. Beth has a strong background in IT operations. Given my cloud and IT management expertise and her IT operations expertise, Beth and I joined together to create the series of episodes we called ModernOps. We recorded this content back in the spring of 2021, right in the middle of the pandemic, but we never published it, until now. In this first episode, Beth and I are talking about AWS and how using their offerings and services changes based on whether you're a small company or a larger, more established company or an enterprise. I hope you enjoy.

Beth: 00:02:07

So what made me think about this in initially is that when I worked at New Relic, I was on the build and deploy tools team. We worked somewhat directly with AWS. There were things that, that we owned and managed and got pulled into, but also watched a lot of other teams that, that owned a lot more surface area in AWS. I got interested in thinking about two, two different aspects of this question. One is. How organizations that are operating at different scales, think about actually using the, the AWS offerings and, and the sorts of things that they're going to be drawn to. And then also some of the, some of the organizational constraints that can influence the decision about how to use AWS services. So in the first category, thinking about things like: if you are already in a data center and you're looking at moving into the cloud, you're going to have a progression that you're gonna be moving through. And if you have a lot of services, you're going to need to make a jump to a more fully featured cloud environment. Whereas if you're a very small organization and you're spinning up brand new services, you can try things out incrementally, and there's a much different path into the cloud. And that's one thing that intrigues me. And I know you've talked about cloud transformation a fair bit.

Lee: 00:03:43

Yeah. And that's actually a good point. One of the things I actually did a course for O'Reilly on is planning for a cloud migration. And one of the things I talk about in there is the critical mass, right? You know how much you need a certain amount to move to the cloud at once yet you don't wanna move anything until you've tested something. And so how do you make that transition? And, and actually one of the things I found when I did some research and talking to do different customers about this is a lot of companies that when they first started using the cloud, they didn't do it with a project and with a critical mass, what they did is they had, team Y off in the corner, the nomad team that always did things a little bit cockeyed anyway. They went off and they decided to try something new in the cloud and just did it and tried it and had some success or some failures and, and management kind of turns a, a blind eye to those teams because they always do good stuff and see what happens. And sometimes what happens is they are the ones that create enough of a critical mass that makes it acceptable. And, and often they're the group that turns into the Cloud Center of Excellence. They won't call it that necessarily, but that's really what it is. That the group that, Hey, you we're, we now decided that we're gonna bring all of our applications to the cloud and everyone go talk to those guys. They know how to do it. It's not necessarily the best formula for success. But a lot of the larger companies will end up doing things that way. So in many ways, it's like the startup model where it's like a, let's just test it out and see what happens. And we can make some mistakes, not a problem, but not every company does that. They, the companies need that maverick team for that model to work. And in a lot of company cultures there isn't that maverick mentality. and for those companies, like you say, it's then a matter of, okay, you have to do a leap of faith and a leap of faith is something, those sorts of companies just really aren't familiar with and how to make happen. So that's always a challenge. So how so in a company like jeli.io where, you know, you didn't have the migration, right? You just all into the cloud from the very beginning.

Beth: 00:06:06

Right

Lee: 00:06:06

was it different than that?

Beth: 00:06:10

Yeah. So with Jeli.io, first of all, there's the, the matter of just there's the, the factors of both size and timing, the fact that we were starting to build our services out in 2019, 2020, when the cloud was already yeah. It was already established and we could just, just walk right into it. But yeah, the, with jelly, the decision process was like, We're very small. We don't have a team, a big team of infrastructure engineers to even run things them, themselves. And so AWS, let us go much faster because, obviously, we were able, able to just walk up and provision something with a click of a button. And so it was a matter of, okay, what's the smallest footprint that we can have just because we're, we're bootstrapping our entire product and how can we, what's sort of the most tried and true off the shelf thing that we can build in AWS. And so as we started to mature, We would expand what we were doing in AWS, but we had, uh, a lot more optionality in what we were building because we were able to select from this wide set of managed services. And we knew that with just two or three engineers, We could still consider, for example, we're not deploying on Kubernetes yet, but we can talk about it because we don't have to have full expertise on this entire technology. We need to have enough expertise to manage the managed service.

Lee: 00:07:58

So AWS lets you limit your expertise in certain areas. And still allow you to move forward. Yeah. And I can relate to that too. And even a smaller company standpoint. In about 2004, I came up with this idea for what it wasn't called SaaS then, but the SaaS application for managing boy scout websites. And I built that application and actually turned it into a full ended up, building it into a corporation and had real revenue, taxes and all that sort of stuff. It ended up being a, a pretty, pretty big thing, not enough that I could do full time, but it was, it was a big thing. But over the course of many years, that grew up into that. But when I first started, it was like, it was a server that was in my home that was connected to my home internet, that I had to do an upgrade on to make sure I had enough bandwidth and hope they didn't yell at me too much. That's the way it started. And I had to do, I had to know a whole lot about a whole lot of things just to get that up and running. There's just no choice. And then this whole idea of being able. Buy a server or rent a server from some managed provider that would sell me one server was a fantastic idea. And once I could afford that one server, this would all be great. It was, you know, a very small setting, but you know, then when the cloud started, it was like, oh, this solves everything. This makes everything so much better. And that's one of the reasons I got very interested in AWS and ultimately went to work at AWS. The, the whole idea that all of those things that were hard for me to do that took all this time and energy to do. And I was before that, I was at another startup that also had the same problem. They said they had the server rack in the back room and hoped it didn't have a power outage because I wasn't that good of a battery backup and all that sort of stuff. And, and imagine how much easier that would have been if the cloud was prevalent then and how to do that startup, then you jump forward then to. to nowadays in the types of situation that for instance like Jeli.io is in, and it's so much easier because you don't have to worry about any of that. You say, I need one of these and these and click buttons to get them and pay for them, et cetera. I, I'm also working with some other startups now and in my current role that are in the same situation where it's like, they're trying to decide what they want their operations budget to be. And imagine being able to say that sentence, they want to, they're gonna figure out, decide how large they want their startup operations budget to be, but they essentially can do that. They they're making the trade outs of what type of footprint they wanna have for their first deployment versus how much they wanna invest in. And then they can relatively easily, because it's just a sheer matter of changing a slider of how many servers in each area and all that sort of stuff. That's a whole lot different situation than it used to be and makes it a whole lot easier for companies like, like Jeli.io to get going. Now, how does that differ then from New Relic now there's New Relic as a startup, which was pre-cloud and then there's New Relic as it currently is, which involves both cloud and non-cloud offerings. And I'd love to get your perspective on both sides of that.

Beth: 00:11:19

That's such a great question. And as you've been talking, it it's occurred to me that when I, when we first started talking, we were comparing the scale of the organization, but then what I really was honing in on had less to do with scale and more to do with age and the age of the services themselves. And you mentioned a few minutes ago, you're with AWS, you're essentially outsourcing expertise.

Lee: 00:11:50

Right

Beth: 00:11:50

The fact that when you've got a mature set of services, they're intimately coupled with the kinds of infrastructure that they're built on. And so moving that is, is into a different kind of infrastructure ecosystem is, can be very challenging.

Lee: 00:12:08

One of the things that I worked through in. So when did you start with New Relic?

Beth: 00:12:14

I started in very beginning of 2017.

Lee: 00:12:20

17. So you were there, three...

Beth: 00:12:23

Three and a half. Almost four years. Yeah. Okay.

Lee: 00:12:26

I was there about three years before that, so I was there a little bit over seven years. So yeah, when I started there, I was like employee number 98 or something like that. Yeah. the, the Portland office. Was lunchroom, a couple of offices and everyone, just, everyone sat around the lunch, the one lunch table for lunch every day, I've heard the stories. That was what the culture was. It was a great sounds. Great. I loved the early new Relic culture. It was a fantastic culture. Yeah. And so it was very much smaller sort of company. but back then it was, the cloud wasn't even a vocabulary item, even though the cloud obviously was big. I was, I moved to New Relic after leaving AWS and spending three, four years at AWS and doing lots of things. So it wasn't, the cloud didn't exist or wasn't established, but it wasn't part of, of the vocabulary of New Relic. New Relic was all about. We need. We're a heavy infrastructure centric company because data intake is everything and there's no way anybody could satisfy those needs for us. Other than ourselves, we need custom database servers that could handle the load to handle all of this data intake. The vocabulary of the cloud wasn't part of the vocabulary of New Relic at the time, it just wasn't there. Everything had to be, you know, tuned and, and the, we didn't have stock database drivers. We didn't have stock servers. We tuned them. We went to the servers in Chicago. We made sure they were tuned exactly the way we wanted to and connected the network exactly the way we wanted to. We felt that level of control over the hardware was critical to get the performance out of the, the hardware investment that we had in order to make things happen. And I remember having conversations with Lew very early on back when well, when insights was first starting to become a possibility for a product wasn't the product yet. But, and I, and one of the concerns he had was he didn't know how to size it. He didn't know how many servers to need. And I started talking to him about dynamic allocation and how to build out in the cloud and make all this happen. And he's, he was really intrigued by that, but it hadn't even entered his vocabulary to consider until then. And then they did, he did some calculations and did some. That and his, the conclusion was no, we can't make that work for performance reasons. It's just not gonna be there. And later on, of course it changed his mind on that, but it's interesting that the mindset there was just so non-cloud at all it, because everything had to be tuned. And so the data center was everything. The data center was value and that the data center was an asset to the company. And that was the mindset. I don't think there's very many companies now and I certainly would bet that Jeli.io is one of these companies that would ever say a statement that the data center is an asset.

Beth: 00:15:38

Exactly. And you're bringing up some of the things that, that, that are real differences that aren't necessarily about the age of your services and whether they're already on legacy hardware. One of the, obviously one of the huge differences between Jeli.io and a company like New Relic is the scale of not just the services, but the scale of, uh, the data that's that's flowing in is certainly New Relic's data ingestion is just staggering,

Lee: 00:16:11

astronomical

Beth: 00:16:11

it's astronomical, but then also a more mature organization. It's not just about the services being services and infrastructure being more mature. It's about the expectations and the, even the sales cycle. So new Relic's scale of data ingestion and the maturity of the expectations of the customer mean that when you're quote unquote outsourcing expertise to the cloud, I think one of the differences is, what we're building at jelly. We really can trust AWS. They're providing us with the level of control that we need over our infrastructure. At a place like New Relic, you need to develop a whole new expertise, which is how to manage all as, as deep down as you can. What's happening on your cloud infrastructure, which is a new kind of expertise, versus managing your own racks and machines in the data center. And so you have to develop this new set of expectations and tools and controls because when something goes wrong, you need to be able to troubleshoot in a whole new way in the cloud.

Lee: 00:17:30

Right. Right.

Beth: 00:17:30

So I think that is a big difference. And one thing that bigger organizations are thinking about whereas an organization like Jeli.io, we really can just for the scale of what we're currently doing and for the, the kinds of work that we need, our cloud services to provide us, we can just trust that a little bit more blindly, as opposed to New Relic, where you're dealing as you're talking about when you've got, uh, you're moving a bunch of data into containerized databases that are hosted in the cloud as part of your interim, your interim solution to getting fully into AWS managed data stores. There's a lot there that you need. You need extra expertise in house to be able to deal with that. When things go awry, when the performance problems crop up.

Lee: 00:18:24

And not to, you know, discount the Jeli.io customer versus the New Relic customer,. But when. You have a glitch that causes a problem. When you have five customers or 10 customers, it's very different than you when you have 5,000 or 10,000,

Beth: 00:18:46

exactly

Lee: 00:18:47

customers. And, and when those customers pay you large checks, you know, it's a very different situation. And so it's very scary to make any sort of operational change at any sort of complexity in an organization like New Relic. But it's a lot easier to do it in an organization like Jeli.io or Muskrat Software, which is the name of my scout manage company or any of those sorts of, of places. It's Hey, let's try this blam. You can do that and get away with it because the expectation is acceptable. That if there is a problem, the risk, the risk reward ratio is very different. The, the risk is very low, relatively speaking. What can go wrong is. Is is bad, but has less impact, but what can go, right and the value is huge. With an organization like New Relic. It's the exact opposite, tiny little things can cause cost major amounts of money, either in the form of real dollars or in lost revenue for lost opportunities or lost customers, whatever. So the risk is much, much higher and the rewards therefore have to be equally better, but often are more incremental and it's harder to see those benefits. So by far, it's obviously it's easier to consider a cloud-based solution when you're starting from scratch as a small startup. I don't think we're telling anybody anything new by saying that. I hope you enjoyed modern ops with my co-host Beth Long. ModernOps will be a regular series that will appear occasionally on Modern Digital Business. If you enjoyed this episode, let me know. So we can make sure to include more conversations like this in future episodes. You can reach me via the links in the show notes, or sign up for more content at leeatchison.com/follow.