Do you need data captured that let you know when things don’t look quite right? Need to identify issues before they become major problems for your organization? Turn to Threat Stack, which has Cloud issues of its own, and helps its customers with their Cloud issues.
Today, I’m talking to Pete Cheslock, who runs technical operations at Threat Stack, which handles security monitoring, alerting, and remediation. The company uses Amazon Web Services (AWS), but its customer base can run anywhere.
Some of the highlights of the show include:
Challenges Threat Stack experienced with AWS and how it dealt with them
Threat Stack helps companies improve their security posture in AWS
Security shouldn’t be an issue, if providers do their job; shared responsibility
Education is needed about what matters regarding security, avoiding mistakes
Cloud is still so new; not many people have abroad experience managing it
Scanning customer accounts against best practices to identify risks
Threat Stack’s scanning tool is worthwhile, but most tools lack judgement and perspective
Threat Stack offers context between host- and Cloud-based events; tying data together is the secret sauce
You shouldn’t have to pay a bunch of money to have a robust security system
Good operations is good security; update, patch, track, and perform other tasks
Lack of validation about what services are going to be a successful or not
Vendor Lock-in: Understand your choices when building your system
Pervasiveness and challenge of containerization and Kubernetes
Cloud reduces cycle time and effort to bring a product to market
Amazon is a game changer with what it allows you to do and solve problems
Full Episode Transcript:
Corey: This week’s episode of Screaming In The Cloud is generously sponsored by DigitalOcean. I’m going to argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as an added service at varying degrees of maturity. Others bias for, “Hey, we heard there’s some money to be made in the cloud space. Can you give us some of it?”
DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they’re using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access, and IP addresses. DigitalOcean makes it all simple, “In 60 seconds, you have root access to a Linux box with an IP,” that’s a direct quote albeit with profanity about other providers taken out.
DigitalOcean also offers fixed-price offerings. You always know what you’re going to wind up paying this month, so you don’t wind up having a minor heart issue when the bill comes in. Their services are also understandable, without spending three months going to cloud school. You don’t have to worry about going very deep to understand what you’re doing. Its click a button or making API call, and you receive a cloud resource. They also include very understandable monitoring and alerting.
Lastly, they’re not exactly what I would call small-time. Over 150,000 businesses are using them today. Go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try that. That’s do.co/screaming. Thanks again to DigitalOcean for their support to Screaming In The Cloud.
Corey: Welcome to Screaming In The Cloud. I’m Corey Quinn. I’m joined this time by Pete Cheslock who runs technical operations at a company called Threat Stack. Welcome to the show, Pete.
Pete: Thank you. I am happy to be here and I guess somewhat happy I have to talk to you.
Corey: Yeah, that’s generally what we call a mixed bag.
You and I first met at one of the many conferences that you and I both, more or less, shoved ourselves into. We give a talk that at least is, in theory, vaguely related to what the conference purports to be about. I get at there and scream about Docker in weird ways. You’ve gotten up and told stories about a sunken shipwreck in Stockholm at the Vasa.
Somehow we managed to tie these ridiculous things back to, I guess, the feeling of the moment in the tech space.
Pete: Yeah. I think it’s most impressive that we’re somehow able to talk about 17th century ships and pooping unicorns and have them relate to modern software engineering practices.
Corey: What was also interesting to me is that you are sort of standing two worlds in your professional life.
The one end, you work at Threat Stack, which is a company that handles security, monitoring, alerting, and remediation. Is it AWS or is it across multiple providers these days?
Pete: We run entirely on AWS. We’re really all-in with the Amazon. They’re so far ahead of everyone out there. It seems kind of silly to leverage other providers at this point. But for our customer base, they can run really anywhere which always been the compelling point of Threat Stack.
We were monitoring things at the workload level, the host level. You could be running bare metal servers, the preserverless world, or you could be right in cloud. You could have Azure—systems anywhere and we're able to kind of capture that data and start giving you some anomaly detection and letting you know when things don’t look quite right. Hopefully, trying to identify issues before they become real big problems in your organization.
Corey: You’re in this somewhat strange phase where you not only are a service provider, companies, trying out figure out this whole cloud thing. But as you’ve mentioned, you’re also a heavy consumer of it which puts you in something of a strange place.
On one hand, you’re helping other people work through their various cloud challenges. On the other, you have cloud challenges of your own. It’s one of those—learn on one hand, teach on the other, type of moments.
Beyond that, you’re also one of those people that I’ve—when I was starting my own consulting business, you were on the shortlist of people that I’ve reached out to—to talk about interesting challenges in the AWS space, what you were seeing, how you’ve dealt with them in the past. I’ve got to say, in my perspective, it was like going to cloud school.
Pete: I appreciate that. I think I have been extremely fortunate and lucky to be really in the right place at the right time. I got into Amazon, cloud services back in 2009 when Amazon was still a fraction of what it is today.
I worked for a company called Sonian who’s now been acquired by Barracuda. What they were doing at that time was email archiving and their big thing was in the cloud—leveraging, S3, leveraging those core pieces of Amazon technology. We were extremely early into the cloud space to the point that we were one of the largest consumers of EBS and of S3 in the early days of Amazon. The storage of all these emails’ for compliance reasons.
I’ve been pretty lucky to be part of Amazon from the early days. Kind of having to grow up as the cloud grew up means there’s a lot of open source technologies that came out of that company, a lot of businesses that came out of that company, basing a design as a way to help to people with how you manage your stuff in the cloud. It’s a much different model than it was 10 years ago, 20 years ago. There’s no more data centers.
I always kind of joked, it’s like the cloud security model is the—the old world is the hard candy shell in the soft nougaty center of network security where you block everything in the edge. Now, we’re in a totally different space where workloads run all over the place. Your boundaries are no longer as well-defined as they once were.
Corey: To some extent and admittedly, I’m picking on Amazon here, more so than the rest, because they’ve been around far longer than their competitors have. It feels like to some extent, it’s the common denominator that everyone can relate to, to some extent. The bulk of experience is there, yours is as well.
It feels to me like your business, which is helping companies improve their security posture in AWS and mine which is helping wade through the AWS bills are both cottage industries built around cloud companies, in an ideal world should not exist. Neither you nor I should have a business here if the providers were focusing on these from a different perspective. Agree? Disagree?
Pete: You know, it’s so interesting because I look at some of the things that Amazon announces and their features that they’re adding. They’re not really products that Amazon is announcing. They’re just features because you have to tie them together to really make sense of them. Amazon has been dipping their toes in the security space for really as long as Threat Stack has been around because customers are really trying to understand more of just what’s happening in my environment, what’s happening on my servers.
One of the biggest challenges that we’ve actually had to deal with and I would imagine a lot of other cloud-based or cloud native security companies deal with is a lot of just kind of user education. My guess is it’s a very similar challenge that you deal with as well, is a lot of times, trying to educate people of why this is important or why this matters. I guess in the security space, it’s a little bit easier only because of all of the breaches, different types of attacks, and vulnerabilities that have popped up, are I think making people much more aware of security.
But a lot of times, people just don’t really know where to start, which really was the thing that really drove me to come to Threat Stack is—it didn’t seem like there was really anyone in the market that was truly solving this problem.
Even Amazon has their very well-known Shared Responsibility Model where they essentially say, “We have your security from the physical infrastructure and up. But if it happens inside of your account or virtual machine, good luck, have fun.” I think they’ve been getting a pushback on that which is why you see services like CloudTrail and the new audit service they did a while ago. I think there’s Macie, a couple of other more security guard duty and few of the other security services. I guess the challenge that they have and a lot of people have is just, “Okay, here are some individual things but how does that all tie together to actually let me know what’s happening or what to do. Am I getting better?”
I think that’s the thing that we’re trying to solve at Threat Stack at least is telling companies, “Hey, here’s how you should get better at being more secure or having a better security posture.” It feels very similar to—a lot of the conversations that we had five-plus years ago around DevOps, automation, and people trying to teach others, “Hey, here’s how you can improve, how you build systems with this tools or that tools or things with that nature.”
Corey: The challenge with a lot of these things is that you see some many companies trying to do relatively complex things. They’re just figuring if the providers are going to handle the rest of it for you too. I can’t say that they’re wrong to do this. In the security front, for example, Amazon makes it extremely easy in some ways to shoot yourself in the foot from a security perspective. They're a couple clicks and a consul away from exposing S3 stuff unnecessarily.
I recently discovered a bunch of public RDS snapshots. People’s database are just being stored publicly. It winds up being in an area—yes, in an ideal world, someone should be able to not do these things. They should have enough knowledge of the platform to avoid making the silly mistakes.
On the other, there’s so much surface area and so many things to be aware of, that I’m afraid, is not just practical.
Pete: I think you’re totally right. That’s kind of the inherent challenge of building on the cloud. One, it’s still so new. There’s not that many people who can really claim to have brought experience in managing it. At least over long periods of time, it just hasn’t been around long enough.
We have interviewed countless people for just growing my team in infrastructure engineering and the experience level of people running things on Amazon is pretty wildly different. You have everything from customer’s running workloads kind of the Netflix way of fully immutable infrastructure and auto scaling systems. Then, you have other people who are kind of pointing, clicking, through the Amazon UIs in order to improve systems and manage things. They might be using cloud but there’s little difference between what those engineers are doing and what we used to do 20 years ago, racking and stacking servers in the data center.
Your point on that is very easy to really shoot yourself in the foot with Amazon or cloud services in general, it’s very poignant. We’ve heard a lot of announcements and breaches due to S3 buckets and things like that.
I give Amazon a lot credit. They’re getting better about informing their customers when they make a bad decision but it’s usually after the facts.
The other trick too and something that I was pretty excited about a couple of years ago when we released some new features in our product is where we can just start continually scanning our customers accounts against best practices, things that were Amazon’s best practices or CIS benchmarks. We would just scan your account and we would scan it every few hours and we will just return back to you a score. Okay, you’re 78%. That would allow customers a way of saying like, “Okay, this is where I am today. Now, I at least know where my risk points are.”
Then in that report, we could go back to the customers area. “Here’s how you get to 80%. Here’s some of the things you could make impact on.”
I think that’s the thing that at least if you’re using a raw provider, you missed out on that. There really isn’t anyone to hold your hand along the way unless you’re spending many millions of dollars with Amazon. I think it’s a challenge to really get someone who can help you show the way in building out systems, maybe securely or properly. There’s still a lot of education that’s required.
Corey: Absolutely. I’ve been going back to the S3 bucket issue that you just mentioned. There are valid used cases for having S3 buckets being publicly exposed. You want to serve web content from them. For one reason or another, you don’t want to put a CDN like CloudFront in front of it, that’s a reasonable used case. A lot of automated tools will flag this, “Hey, red alarm, this bucket is publicly exposed.” Yes, it’s a bunch of static files that I want the world to be able to get. I know what I’m doing.
I have two AWS related bits of art in my home office. The first is a map behind me that has a pin in it, it’s a map of the world that has pins everywhere there’s an AWS region or CloudFront edge location because I’m very sad.
The other is a second monitor that has an on-going real time feed of open S3 buckets as their certificates get renewed. It’s fascinating to look at that one form time to time and I spot check it from time to time. The vast majority are things that there’s no problem in the world to expose publicly. It’s one of those things that just makes sense.
There’s a challenge in that sense. I don’t envy your position because on the one hand, if a customer has an open S3 bucket, that is the sort of thing they can wind them in the headlines. On the other, only if it contains certain data. How do you tell the difference between the two?
Macie, the new Amazon service that launched at re:Invent is a neat idea but I wound up running the numbers for what it costs. It’s $5 per gigabyte of S3 data that that it processes. I have customers that their first months' bill will be a north of $100,000,000. That point, it doesn’t matter what you do. It’s not going to cost, justify itself in that context.
We’re still looking to find the right answers and find the path here. I think that building a scanning type tool in this space is a great step. I think Threat Stack does a commendable job of this more so than most do. But we’re still in the position of these tools, lack judgment and they lack perspective to understand the greater context behind their findings.
Pete: I think one of the challenges of the old guard of security products in a lot of ways is, a lot of it had to do with signature-based detection. Just think of your old school antivirus were all signature-based. They were designed to have a research team that would be testing, identifying signatures, and pushing them down to your antivirus client and things like that.
As people rein in bare metal systems and data centers again with that hard crunchy exterior and nougaty center of network security, they would do various endpoint detection on those servers but it was still pretty antiquated because you had servers whose lives would be measured in years or god forbid, decades of uptime or availability.
In the cloud world, in the Amazon world, servers with up times measured in seconds, minutes, days, as far more common for a lot of companies.
One of the things that was really in the early days that initial proc design was the concept of behaviour-based detection. We care less about individual events that are happening. We actually hear more about the behaviors that a large number of events represent.
When Amazon announced the CloudTrail service, we thought that was great. You got a full API audit log of your CloudTrail data. But of course, true to Amazon form, you turn it on and it dumps a bunch of data into S3. Analysis and alertness is really on you, which meant a lot of customers never looked at it.
What we’re able to do is, we were pretty excited by that because we already have an engine that runs on host and is monitoring for every system call, log in and file access. In addition, we are consuming in your CloudTrail events, which show API access and things in that nature. We can start showing you context between host space events and cloud-based events so that you can start getting more information about these series of event together had a lot more meaning like I see a DNS record changed while I see some system provision or I see a host opens a connection outbound to an IP address we’ve never seen before. You know, show me the last or the top five IP addresses that I connect outbound to and try to correlate them to other systems being accessed.
There’s just a lot of data that exists out there. Tying it all together I think that’s really the secret sauce to get the context like you’re talking about so that you can tell, are these systems that got provisioned in Asia Pacific Data Centre—are they mining Bitcoin? Or is that one of my engineering teams that’s incorrectly configured something?
You would have to troll through quite a bit of data to get that answer faster. But if you were collecting data from all these different sources, you can get to the answer much faster. If it is kind of a malicious activity, you can take action on that pretty quickly.
Corey: The challenge too is, you alluded to this a few minutes ago, I have a client that is effectively a household name to some extent. One thing that’s interesting about working in their environment, as a consultant, this should come as no surprise to anyone and if does we have separate problems, I don’t have full access to all of the things in their environment nor should I. But whenever I run into one of the boundary areas of permissions when I’m doing work on their account. Then API call fails, I get a message from a bot that tells me, “Hey, your user account just tried to do this thing. Was it you? Yes or no?” If I say “no” or if I ignored it, it escalates to their security team. If I say “yes” it says, “Cool. Thanks for letting me know. Confirm it on a two factor code system please.”
That was fascinating to me and it works surprisingly well except when I’m not at my desk and I didn’t noticed notification come through and I come back and there’s now a security person standing at my desk. That tends to be something of a challenge. This is a neat idea and I love the concept. I have a vague idea of what they’re spending for this type of system. It’s out of reach for relatively small teams. You shouldn’t have to hire an entire team of people to build out a bespoken robust security operation. This should be something that grows with you. There shouldn’t be this level of pay to play in this base.
I understand that your answer to this is, “Hey, that’s why we have this thing. You can buy. Pay money to Threat Stack, receive security.” But the reality is more nuance than that and it’s still one of those areas that I don’t think that, especially at the lower end of the budget and this company’s scale size, that there’s a great answer.
Incidentally, my business software’s in this exact same problem as well. Hundreds of millions year-end spend, companies have teams that work on their analysis and optimization of their cost at very small scales. I can’t do much with for those companies. It’s, “Okay, you’re spending $40 a month on your Amazon bill and you wanted to get it down to $30. Okay. My consulting engagement will pay for itself and only 200 short years. Awesome, let’s get started,” Is not really something that’s going to be compelling to them.
There is a price umbrella regardless of what your market is in this space. There’s going to be some segment of the market that you’re not able to accurately serve. How do you approach that philosophically?
Pete: One of the things that I definitely agree with you is that, we see companies of almost every type and size. As we’ve grown, I don’t spend as much time with the customers in the pre and post sales as I used to. We got many more people here than from when I started. I still do work with kind of sales, marketing, and things like that to hear more about or companies that are using us in their challenges.
One side, the thing that I always advocate for is to have the very inexpensive option for people to get started with Threat Stack. Maybe that is, “I’m on Amazon and I just want to know, I want to scan all my Amazon resources and tell me how good I’m doing.” That was a service that we ended up adding a few years ago where for a couple of $100 a month you could scan a bunch of Amazon accounts and just say to yourself, “Cool, I am protected.” It’s like generally accepted cloud principles—not quite the accounting GAAP level but getting close.
As company’s maturity model grows, how they respond to new applications changes as well because when we started—I started Threat Stack, there were eight of us. We didn’t have a dedicated security team. We all kind of did our own fair share and try to help out along the way.
But our security maturity, internally, actually improved and matured as a lot of the other parts of our business matured, where we have a dedicated security officer and a dedicated security team. It’s interesting that we also use Threat Stack to protect Threat Stack. We actually used our product and use it to help make us safer and keep our customers’ data safe from prying eyes.
In a lot of ways, there’s things that people can do that can always improve their security posture. A line that we often say around here, it’s said by others and I have no idea who came up with it but it is, “Good operations is good security.” Is having a good operational process means you inherently more secure. Updating systems, patching systems, having good access control policies, tracking changes, maybe using fancy things like source control, or building and provisioning systems using tools like Puppet and Chef, or monitoring your systems and health of the systems with time series databases and things like that.
We recently wrote an ebook to help SaaS companies understand how to improve their security. As I read through it, so much of it was like, these is the exact same things you should do if you are any other business. But really, these are the same steps that every company should take just to improve their operational expertise.
Of course, as you grow, you start requiring independent teams to start focusing on things. I will say that the open source world around capturing and storing events coming off of systems has matured dramatically. You can provision a Graylog implementation or an ELK stack and start consuming in audit events off of your servers if you really want to know what’s going on or to use those to consume CloudTrail events off of your Amazon account, whereas 10 years ago that was a lot harder to do. I guess I would say I’m hopeful for the future that there are places in which people can get started if they want some information.
But of course, overtime, I say this is someone who uses a lot of hosting services is that eventually I get to the point where I can’t provide that service internally better than some third party provider. Hiring people is so challenging. What I’m going to do instead is I’m going to pay for that. I’m going to buy my way out of this problem because hiring a team to go and build and manage that is going to be much more expensive and time consuming than just going to a provider who is arguably an expert on that space—whether it’s monitoring, or to factor out an occasion management, or single sign-on, or whatever really.
I guess, the one beauty of the world we live in, there are providers out there like Amazon who are experts in running managing systems. I can’t run bare metal systems better than Amazon so why bother? Let’s leverage them instead.
Corey: Right. Part of the challenge too with the pace of innovation—the number of new services that they released—it seems like talking about security in a cloud context or billing in a cloud context, these seem like safe areas to be a service provider around. Because we’ve been down this road collectively enough that these are not new concepts if you’ve been involved with it for a while. You know where the sharp edges are and you’ve seen what happens when people get it disastrously or hilariously wrong.
Whereas, with some of the new offerings that wind up being dropped out on a whim, you find that their stories where, it’s difficult to have any experience with these things. Amazon released this new services two weeks ago and now our company is going to be a service provider around that one thing.
On the one hand, okay but you’re effectively two weeks ahead of the rest of the industry at most on this. And two, Amazon doesn’t hold still. When a new service tends to come out, a lot of the problems within the launch day tend to disappear or be significantly improved over the following months.
To some extent, there’s a challenge at least for people looking for new and emerging markets. For people who are trying to figure out a niche in the space to position themselves in. It’s tempting on some level to look at some new AWS service that just came out. Terrific, great. You jump on that, you offer a consultancy around it, you build up a whole series of websites, you build out a bunch of white papers, you have business cards printed, etcetera. Then find out service wasn’t real. Something I tweeted about as a joke because I thought it would be funny.
There’s not enough validation in the market as to what things are going to be a hit and what things aren’t. I do feel for people who are in the process of starting up consultancy is to show other folks the way around some of these things.
I’m just worried that it may be premature. That said, I’m an old school Ops person. I tend to be extremely conservative with respect to things that earn money. I tend to be one of the last people you’ll know who’ll switch to a new file systems. Who will try new operating system? At this point, I can’t really imagine what picking up all of my personal stuff and moving it to another cloud provider would even begin to look like.
Pete: The biggest joke or scam, whatever you want to call it, is the concept of vendor lock-in. Every time someone says, "We can’t use something on Amazon because of vendor lock-in," I just laugh. We can’t store 10 petabytes of data on S3 because of vendor lock-in.
If you want that data off you can get it anytime. Pretty sure that’s what Dropbox did. They moved off way more data than that. They had no issue with vendor lock-in. At the end of the day, you have to understand the choices that you make when you start building your systems in these various places.
The thing on Amazon I always find to be funny is everything, correct me if I’m wrong, every service they ever announced and launched, I’m pretty sure still runs. Even services of which I’m sure if you talk to an Amazon person over drinks they would tell you, "You should never ever use that server." They’re still running in Amazon happily—SimpleDB, wow, how did I know you'd say SimpleDB.
Corey: Because it’s the only one they’d done this.
Pete: That is a scenario. In some ways, when they announce a new service, it’s a feature—it’s not a product. It’s just another feature that you can leverage. You have to tie in together the rest of the things. In a lot of ways, when they announce something it’s pretty minimal. It’s that true, minimal, valuable, product.
The very first version of Lambda, people were excited because it was interesting in what you can do with it. But no one was en masse moving to a serverless. Now it’s been a few years and there’s more support for it but no one is still en masse moving to. It has its place and its function and it’s interesting. I think the next big place where we’re going to see that is in the containerization and Kubernetes world. Dockers are nothing new, containers are nothing new. But the pervasiveness of Kubernetes is what’s new. I think that’s going to be the big challenge for really everything with an operations. Far more than people think serverless is going to take over all of our jobs.
I think if anything, what does the role of operations look like in a Kubernetes world. My argument is it’s going to look like exactly how operation should look, which is operations is a service organization that builds tools to enable other teams to do what they need to do. If an operations team and that’s pretty much the team I had built out here in Threat Stack. Our team builds out the tools and infrastructure to support other teams to get their job done. In my mind, our Kubernetes lord and savior that we can standardized upon become very good at managing that platform and really letting the engineers use it and leverage it for application employments.
Putting more ownership and accountability on them to get to where they need and do their job effectively. The challenge is going to be in this new world, how do you monitor it? How do you determine if it is acting correctly? Is it secure? What does security even mean in Kubernetes and the Docker rise container world.
The very least is it keeps us all employed for another 5 or 10 years while we try to figure out what it all means.
Corey: You’re right. I think it moves very quickly. I think that this is any merging space. I think that there are going to be sharp edges for a long time. I think a lot of the excitement around new products and services that get released is not fully baked. It didn’t spring fully form from the forehead of some god like a software engineer, it’s a minimum viable product as you said. It's something that winds up serving as a glimpse of what it could grow into. Sometimes those things come to fruition and sometimes they don’t.
In the early days, EC2 was a living nightmare to work with. Now, its click button receive server.
Pete: Yeah, the early days—oh my, I just remember so many bugs running, early versions of Ubuntu on Amazon. They were great until they didn’t. Ubuntu’s 10.4, you can just have to run it. You didn’t have to run a non-LTS release that in 6 months later would no longer get security updates because the one that did get security updates didn’t function.
Corey: Exactly. That’s part of the challenge too. This is hard stuff. It’s easy to sit here in my comfortable home office where if with my personal Amazon bill of $7 a month and cast stone to somebody’s large companies and the cloud providers themselves for the way they do things.
Come to find out, people like me are generally not their target market for a lot of these things. They look for people who are actually good at things. Doing exciting things and throwing large piles of money into the space—I’m not that. I’m more or less a freeloader on a lot of these companies that are doing things that actually make money. It helps at times to remember that.
On the other, by doing weird off the wall things, it starts to give companies a glimpse of what’s possible. I think to some extent, we’re also seeing cloud reduce the cycle time of what it takes to have an off-the-wall idea come to fruition.
Pete: I think that, the biggest part is the time and effort it takes to bring a product to a market was far lower than it ever was. Honestly, when I think about things like serverless, that works serverless where you can MVP an idea in functions. Granted you scale some huge amount of request on them. I have no idea and I’d love to talk to someone who has. I think the phenomenal place to test out new ideas at a very low cost, you have to go buy servers and data center space and all the other stuff.
In the Threat Stack world, we’ve been scaling on Amazon for the past four years now. Starting with a dozen servers somewhere. Now we’re running significantly more than that. The thing that I love most about it is they’re innovating so fast that usually around the time I’m ready for that feature to come out like cross Region VPC Peering, which was announced. I said to myself, “It’s finally out.”
The next big thing to me is honestly, they’re hosting Kubernetes service. Also, their bare metal service. They’re not the first one to do bare metal servers. There’s people that do it way better than they do but what’s interesting is it’s just another instant size. You can run that inside of an auto scaling group. Now, I say to myself, "Shoot, if I could run the Kubernetes service and use the bare metal service and get really full access to these hosts inside of the primitives of Amazon: IAM roles, KMS, and all of the features you get with the normal easy to win instance. That’s actually what the game changer is. It’s not bare metal. It's what it allows you to do with an existing infrastructure.
I think that’s what Amazon is always very good at. This whole thing is just an iteration. They’re iterating upon things that they did years ago trying to hopefully provide solutions for people’s problems in running systems.
Honestly, they do a great job of it. I’ve been using it from very nearly the beginning. At a time, I worked for a company where we were deploying into multi-clouds and even then the next closest cloud might be something like an Azure or maybe Google. But even then, there’s still a far cry from what many businesses require out of a provider.
I continued to be all-in on Amazon for all of its worth, for all of its paying. I’ve been in the industry long enough that I don’t want to rack servers anymore and I don’t want to have to work with my finance team to have to capitalize millions of dollars of physical boxes that may not get deployed for 6 months. I want to go provision some systems or help teams actually provide a product to a customer and know how to think about all that other complexity.
Corey: I could not agree with you more. Thank you so much for joining me today.
Before we go, if people want to hear other pearls of your sage wisdom, where can they find you?
Pete: That is a great question. I have yet to actually determine if I’m going to be attending conferences this year. But I imagine, I will make it to at least one or two DevOps days because they’re just great events that I love to be a part of.
For anyone that wants to check out any of the talks that we spoke about today, like the Vasa, you can go to my website pete.wtf, which is on wonderful Amazon. Thank you for their hosting. I got a link on there. You can check out my talks. I usually put them online just so that I can save me from my own recollection.
I think my hope is to essentially share the story this year about how do we do the DevOps at Threat Stack. We went from zero to a very large number of systems, in people, in scale. I feel like we’re doing DevOps the way it was meant to be done.
Hopefully, once I actually submit some proposals, I’ll be able to tell that story at the next interview.
Corey: I look forward to hearing them. Thank you for joining me once again.
I’m Corey Quinn, this is Screaming In The Cloud.