Live Chat Session with AWS Container Experts

We'll need about a minute. And I'll let you know when we're going. Okay.

Welcome, everyone. We're here with AWS and Containers on the Couch, it's all on you guys. Well.

Hello, hello. Hey there. Wow, it's another day and another Containers from the Couch session.

So, you know, maybe we should. First, start with just talking about what is Containers from the Couch, Brent? Yeah, yeah, I feel like maybe there's an audience here that hasn't seen it.

We have at AWS, a daily show that's every day but Friday. So I don't know if that's technically a daily Show or not, but close enough. And every day we tackle something container related.

And, you know, all this week we've been talking about Container Registries. For example, we talked about NCR and today we talked about Docker Hub and a Docker Registry. And, you know, just it's all about running Containers and and keeping it simple and trying to trying to show how easy it is to run containers on AWS.

So you definitely want to join us. We do this live every day, noon Pacific Time. You can find us at Containers from the Couch dot com, also YouTube dot com slash containers from the couch and twitch dot TV slash AWS containers.

Did I get all those right? I, I think so. And we have some some folks in the chat saying hello.

So just a hello to Malvika, Miguel. Hello. Hello.

And so let's just do you know what do we start with a quick round of introductions, because I think that's important too. So I'll start with myself since I'm talking. My name is Adam Keller and I'm a developer advocate at AWS and I work on the container services team.

So as Brent mentioned, Brent and I host a show, Containers from the Couch, but we do a whole lot more than that. But we love talking about containers and we love talking about containers in AWS. So hopefully we'll get to talk about that in the next few minutes ago.

Mikhail, I think you should go next. I'm sure it's my pleasure. And hello everyone.

My name is Mikhail Shapirov. I'm a partner solutions srchitect and so my domain is Containers. It's basically covers EKS, ECS, APP MESH and ECR and container registries and all the system around it.

And I've been with AWS for quite a while now and as a development engineer, as a solutions architect, I'm quite familiar with this ecosystem. So it's important for me to be part of the show. Awesome.

Yeah. And it's good to have you. As Adam said, I'm Brent Langston and I'm also a developer advocate on the container services team.

And, you know, containers solve so many problems that I've had in the past that I just I love talking about them. So I think that's why it's such a natural fit to do a daily show and and to just talk about stuff, because, you know, prior to AWS, I was a builder. I helped build at Spotify.

I helped build Oscar Health, I helped build Tumblr. And, you know, so we kept running into all of these problems, running micro services at scale. This was even before Docker was Docker was around to help us.

And so when I when I saw Docker, when I saw containers start to become popular and start to really, you know, make their way into the into the discussion, it just made so much sense to me. It solves so many of my problems. And, you know, today it's all about orchestration.

Right? Everyone wants to talk about, you know, running either ECS or Kubernetes user. Am I am I using Fargate or am I running stuff on EC2 instances.

And and that's great. Having some historical perspective is really, really handy to have to understand. Like, why are we where we are today and what are these tools actually solving for us?

And yeah, it's it's been awesome. So definitely, definitely through your questions in the chat. We'd love to we'd love to just let's just have a discussion.

Let's just talk about what did you see today? What do you have more questions about? I know today there was a lot of a lot of discussion about GitOps.

We you know, we did GitOps several years ago before before that word was even a word. And today's tooling is so much better than what we had back then. But just, you know, the idea of putting all of your infrastructure, declaring it as code and storing it in Git and then triggering automation off of it, git push making making that wall, that isolation boundary.

You know, the git repo is awesome. It's revolutionary and I know there's still a ton of organizations out there that aren't doing it that way, so what questions do you have about that? And I know there was a ton of discussion about security and defense in depth.

And so what questions do you have, you know, there? So, yeah, just throw your questions in chat. And, you know, I just wanted to chime in on the GitOps piece.

And really, when you talk about the problems that it solves, if we look back and listen enterprises, when the larger the enterprise generally, they're slower to move. Right. There's a lot of processes in place.

But when you look at how large enterprises work, there's a change management process. There's a lot that goes into approving something before approving code before it even gets released. Right.

It's a lot of people out with something with GitOps. You can take that process of, you know, these change meetings, know change advisory boards. And literally your approval no longer has to be in some system.

And you have to tell three people to tell the one person to click a button or your approval. Is that code that get commit. And when you approve and merge your changes, they go.

That's right. Absolutely. It shifts that from being a JIRA ticket.

That still might be misinterpreted to being like literally this is the code. Here's the diff. Do you approve?

And if yes, then that code is going to go out. There's no misunderstanding it. So say we did get a question.

So this is from Brett. Brett, Philip, forgive me if I pronounce anything incorrectly. "So hi, guys.

" That's a good question. I love the idea of getting over to the platform first and then breaking it down over time, breaking your services down over time, because frankly, those two actions can be done independently of each other and potentially by different teams. So the teams will have to work together.

But your development teams, you know, the traditional developers, those are the ones that are going to be breaking the micro or service or breaking the service down into micro services and the traditional operators. Those are the ones that are going to be working on containerization, tooling and deployments and and things like that. So the work all has to be done and it's just a matter of picking the order.

But the work can be done in parallel. So moving things over and breaking it down can kind of happen at the same time. I don't know.

What do you think, Mikhail? Absolutely. I think that's that's a great point, that not only that it's independent, it can be done in parallel things from that.

The other part is that, you know, frequently it was viewed as a lift and shift type activity to move something from the VMware to AWS. Currently we also have an option to try to slightly replatform it with tools like App2Container that was released recently. There is an option for you to, like, discover dependencies, automatically create docker field for an operator and that container put it into a registry and actually deployed almost.

If it is a monolith, then let it be a monolith and running from there, getting some of the advantages of maybe a little bit better density, maybe a little bit better interaction with the whole ecosystem, with other apps. So I think we have a number of options in this regard. And I definitely encourage to just start moving your workloads first and getting all the benefits of AWS.

And you brought up something that, you know, I kind of, I don't know, harp on sometimes behind the scenes. But maybe this is an unpopular opinion. I don't know.

But your monolith doesn't always have to be broken down into micro services. You know, like if it's think about the motivation, why why do you do that? Why is that such a popular thing to do?

And the answer is almost always will, because it's so complex. I go and change code over here and it breaks something over there. Well, if your monolith is fairly static, you're you know, you're your team is fairly static.

They're all experts on it. Don't change it. Just leave it the way it is.

Containerize it the way it is. And then as new features come in, you know, build micro services from there, you know, make those new features, a new service. What do you think of them.

Yeah. Thank you. And I that's a great point.

And you know, listen, it's very easy to, you know, speak about a monolith in a negative way. Listen, it's but the truth is that monolith is what got you to where you are today, right? Yeah, I've had a lot of success with that.

So it's not a bad thing. But I do as as Mikhail and as Brent said, "try" like just try. There's nothing stopping you from moving this to a container and trying and there's tools out there like App2Container to help accelerate that process.

And, you know, there's the concept of the strangler method. So as you add new services, perfect. Break them out into their own micro services.

And then if you have a load balancer, something in front, you root based on path, whatever that routing algorithm is, but you slowly root out and you strangle your monolith until it's down to nothing. That's right. Yeah.

Yeah. So I think these are the ways in as Brent said, as you build new services, just don't put them in the monolith, break them out. So I love that and.

Oh, go ahead. Sorry. I was just going to say, like I, I know some of my startups from the past still have Ruby running, still have Rales apps running and and, you know, those are monoliths.

They started as monoliths and now they're doing a fraction of the functionality that they used to do because we went down the micro services path. But there's no reason to rewrite them anymore. You know, they're they're so tiny and so inconsequential that let's just leave them the way the way they are.

And and, you know, someday when we all have, you know, that mythical time that we think we're going to have someday, then we'll get around to that'll be a fun hobby, you know, to go and rewrite whatever is left. But, yeah, just leave leave things the way they are. And, you know, man, the bad things of monoliths are they're difficult to understand.

They're complicated to work in and scaling them is. Yeah, yeah. It's the scaling part.

That's the that's the real advantage that micro services bring to the table. And, you know, you're going to get that over time as you start to write your new features as their own independent services. So if you're fairly static, just keep it as a monolith.

It's totally fine. I think it's a great point with respect to static versus dynamic, if you expect and if you're looking for a more prescriptive guidance, then I would say your code base is very dynamic. You want to probably get on board multiple distributed development teams and they all change it at the same time, then probably worth investing into breaking it down to microcircuits or something that is more manageable.

If it is static and it works and it scales for you and you don't really anticipate any drastic change in that, then probably you can keep going and just address the new features in a new way. I totally agree. I know I'm interrupting you, Adam, go ahead.

No, it's OK. There was a talk on on Conways law. And I think, again, it always comes back to the organization.

And this is what Mikhail just, you know, but like went off of my head, the light bulb. But at the end of the day, if you have you build a bunch of micro services, but you have just one team that's managing all these micro services, it may be not as as smooth of a transition. So it's important to model your your business and how you operate after how you're going to build and deploy your software.

Exactly. I can't say. Yeah, I mean, you said that very well, because when you look at, you know, some of the some of the large startups of the past that I've worked at or heck, just look inside AWS we have service teams and those service teams build micro services.

But ultimately the way we communicate with other teams is through APIs. So we aren't sitting there trying to like, you know, pull in their code base and do things or anything like that. No, we're reaching out over an API and we're talking to them and we're utilizing their service.

And so that's all organized exactly the way our internal teams are organized. Right. So it all comes down to how are your humans organized?

And if you're a single developer, right. A monolith, you know, that's totally fine. Shove it in a container and make it, you know, easy to scale and launch it out on the farm gate if you if you want to.

But but definitely, you know, don't don't give yourself a breakdown. Trying to remember how your thousand plus micro services all work together. Very, very good points.

So Brent did have a follow up, now I'm not sure if I fully understand. So, Brett, if you could maybe elaborate a little bit, but he said good way of looking at it. Thanks.

Also curious if there yet exists a Kubernetes maturity model. So does anyone. Maybe, maybe.

I just don't understand. I don't know what that would mean the same. I think we could probably talk a little bit about the Kubernetes life cycle.

Maybe, you know, there's a there's a new version of Kubernetes what is it, Mikhail, about every nine months or so. And I think they just I think they just announced they're supporting is it a year now or 18 months maybe. I can't remember what the support model just moved up to.

But, you know, as Kubernetes gets to be more mature, they're able to sort of offer support a little bit longer. And support means, you know, back fix, back reporting, bug fixes and stuff like that. So so maybe that's the maturity model, you know, with that little you know, I think that it's probably very hard to talk about Kubernetes maturity model when it's driven by the community.

And probably what is is that organization maturity model in terms of adoption of Kubernetes . And that has a lot of stages. Frankly, we actually have a maturity model for our consulting partners to which.

So, like, do you have CI. Do you have a CI/CD? Is it fully automatic to fly GitOps?

What kind of processes you have? And when it comes to Kubernetes, a lot of that is just, you know, manifested and magnified, I would say a lot of the implied declarative, infrastructures, codes, and things of that nature. And we do have those models to tell the truth.

They're probably a little bit internal at this point. But I do see that we can great enterprises by those practices and processes that they adopt. I like your your questions there, your sort of gating, you know, ways of figuring out where someone lands.

I would even throw one more in how many times or how many Kubernetes upgrades have you performed and how did you perform them? You know, like that's that's something that you don't do it very often. And when you do it, it's..

it has been a chore. It's getting easier, obviously. But, you know, like, do you build a new cluster and cut traffic over or do you upgrade in place?

You know, have you gone up three versions? Do you go up successive versions? You know, like there's there's some interesting stuff that comes into play even with just that.

But, yeah, that's it's an interesting discussion. And I do want to add. So so Brent did add some more context.

You know, some companies seem to be dipping their toes in Kubernetes, while others have mature practices, skills to leverage the advanced benefits. And I just want to say you have to start somewhere, right? I mean, and I think it's important to to practice like game days where you practice upgrading in place and or different strategies and learn ultimately this is going to come just through hands on experience as you built.

But start small. Don't... if you're not super deep and versed in Kubernetes by no means should you be just moving everything today.

Right. Start small. Right.

And iterate over this. Learn from from starting small and then you grow and from there. Do you guys agree with that.

Does that make sense. One hundred percent and even more. What do you start with?

Like don't move your databases, you know, to manage services directly to the that. Yeah, exactly. You know, start with start with the easy things, the ephemeral, APIs, and stuff like that, you know, and you don't even have to move all of them or you don't even have to move all of one of them.

You know, you can run a percentage of your traffic into your your classic cluster and then, you know, another percentage of your traffic into your Kubernetes cluster. And you can just see, like how does auto scaling work for me. And how does a deployment happen and what happens?

And do I throw five hundreds when when I'm rotating out my containers, you know, like you can figure all that stuff out without having to have a huge risk that you're taking on by just sending everything there. So, yeah, take small steps, figure out, you know, I always even back up a second and I say just. What problem is the solving, what problem do I have and Kubernetes solves some really common problems?

They're usually problems around scaling around deployment, tooling their problems around like, you know, containerization solves problems around having the right dependencies in the right places. So, you know, if those are problems that you're suffering from, you know, or maybe you have them solved for one language, but now you need to bring in a different language. And now you'd have to go reinvent all that tooling for that new language and then do it again the next time a new development team wants a third language.

You know, these are the kinds of things that might lead you down the Kubernetes path. And if and if that's your situation, then, yeah, absolutely. Go down that path.

Well, I would like to add one more thing than I thought. I think one of the very great points, but if, for instance, they meant like from the software engineering perspective, my application isn't mature enough for Kubernetes. And then there we can probably just talk about the 12 factor model, which is fairly established and pretty old or cloud native development principles.

What how do you deal with state resiliency patterns, things of that nature and all of them kind of makes sense and probably possible to create the more more precise model soldiers that you know. Yeah. Is it mature enough for Kubernetes?

That's true. That's true. I remember early in the early days of us breaking our monolith down into micro services, 12 factor was was definitely like the the starting point for us.

Just getting, you know, our app to read its config from the environment instead of from a config file like that was that was day one and took it. It took a while. I listen, it's even.

But that's such a great point. Mikhail is you have to... it's not just your operators like the software...

If you have beautiful micro services, but they're all pointing to one gigantic database that is your bottleneck. Well, you could have a problem there. Like so it's beyond that's a great it's it's an all hands on deck effort.

It's not just one team. Here's Kubernetes. Now, let's throw this here.

You have to evolve like there's an ocean that comes with that. I mean, you even need to say like you need buy in from the team like this is you're saying it's a team effort. And I'm agreeing and I'm saying that, yeah, it needs to be like a team desire, you know, and there might be some on the team that are a little bit resistant.

But, you know, maybe you can get them on board and help them understand why we're, you know, heaping on all of this extra work that that, you know, it's up front work. It's it's stuff that, you know, you wouldn't have to do if you weren't moving to Kubernetes. So it's extra work.

But at the same time, it's worthwhile because it's going to help you move faster down the road. Totally. So we there are many more questions coming in, so I did want to kind of we talked about GitOps.

I think I think we're good on the GitOps. Let's talk a little bit about maybe security in the Kubernetes space and, you know, EKS, and just in general. So, you know, Brent, you've said it.

We say this a lot. We talk about defense in depth. So it doesn't just start on the perimeter.

Right. You have to secure all the way in. Yeah.

So a question came. So I think I'm going to jump to the question before we continue down here, OK. So this is from Rakesh, "What is the best way to monitor Kubernetes workload and application APM?

" I'm going to give Mikhail I know you're going to have a terrific answer, so I'm going to give my really generic answer first and then and then I'm going to hand it over to you. Let them slam dunk it. Exactly.

Exactly. So I know at AWS, one of my favorite ways to do this today is to introduce service mesh and app mesh specifically. And part of that part of the reasoning for doing that is because it integrates envoy at the pod level and on voyages, has a really rich set of...

of abilities when it comes to emitting metrics and integrating with with other things. And so once you have that, you can actually then integrate to xray. And I know...

Was it Rakesh? Mentioned APM and you know, I know there are better APM companies. I probably shouldn't say it quite like that.

But there are there are companies dedicated to being APM companies. Right. And so you can integrate with those two.

But if you just want like a quick test, a quick experience, you can turn on xray within app mesh. And suddenly without changing a line of your code, you have, you know, essentially instrumented the connections between all of your micro services. And then if you feel like going further, then you can dove into your code and start instrumenting your code to admit to xray also.

But Mikhail, I know you probably there are some other other partners that that have even better solutions for sure. I would like to say it's a terrific answer. I thing if you're looking to add monitoring and performance and tracing in a very noninvasive way, then app mesh is probably the best.

And yeah, you can drill down and create those xray segments within your code later on if you want to, but just do nothing. Adding app mesh on top is a variable, so to say, aspect oriented way of doing it in the modern world. When we used to do aspects that are right and code, now we're actually flying anyways and different processes like container's on top of at the same time you can, you know, being part of the database development itself.

I mean, we deploy on the AKS or Kubernetes is as well in Containers just from AWS internally. That's very different view I have to tell what it is? We're using it and in production as well, and we use cloud watch metrics and monitoring and alerts based on performance metrics as well.

And that's most of the time is sufficient to get enough performance indication of what's going on and to troubleshoot with language logs and things of that nature. Plus, xray is obviously our own tool as well. You can achieve quite a bit.

There are multiple partners in the APS and some of them are really good. And you can take a look at Diamond Trace, Dynamics that you can talk about more... Datadog.

Datadog,for sure. New Relic, yeah. New Relic was my go to back in the day.

I loved New Relic and how it would essentially auto instrument my code just by pulling in their library. It was amazing. But yeah, I mean, like there are a ton of choices out there that can give you some really great perspective on your application and how it runs.

And it's really all about just, you know, what's what's closest to your fingertips. Where do you want to start an experiment but do experiment, you know, try try some different stuff out and see, you know, if it scratches your need well enough. Yeah, and there's, of course, open source, too, right, there's Jaegar.

I mean, there's there's a slew of other open source tools out there. If you look at the CNCF landscape, you can and that that map can be very overwhelming. Man, I remember looking at that map thinking, oh, this is cute.

The little road, the little trail. And I can, like, check things out along the way. And today, when you look at it, it's like an eye test.

And there's so many choices and so many options available to you. It's it's awesome. Yeah.

And, you know, I think this is probably a good time to mention that we do have there's a workshop on AWS EKS Workshop dot com, where you can actually run through guided examples of how to incorporate. A lot a lot of the features that are available in the company's ecosystem, you can do through this workshop and Brent has said this a million times, I'm going to steal his thunder. But the nice thing is with EKS workshop is it's...

This is not the majority of the content and there can be used on vanilla Kubernetes. So does it have to be EKS. I will say EKS is, from an experience perspective, a lot less overhead from a management perspective.

Right. So you don't have to worry about managing the cluster and think about all those things. So, yeah, obviously we want you to run EKS and we think it's you know, we want that to be the best experience that that you'll ever have, you know, and that's what we work for.

That's what we strive for. But that said, you know, setting up stateful storages is basically the same wherever wherever you happen to be or running, you know, learning about Helm charts, that's going to work the same everywhere. So I'd say maybe like 80 to 85 percent of the content on EKS Workshop dot com.

Is vanilla Kubernetes is specific? So it's you can you can learn about Kubernetes is right there and not have to get too bogged down with AWS specifics. Yeah, so I think we're kind of butting up against our time limit here, but I suppose maybe let's just end with some some parting words.

We can each, you know, say something. What do you think? Yeah, I'd say just keep...

keep on learning, keep on containing, and keep on automating. You know, I think today was an awesome day, full of tons of great advice. So reach out to us.

You know, we're on Twitter. I'm @Brentcontained. So definitely reach out to us with any questions you might think of down the road.

And otherwise, just keep going. Very exciting, very exciting times. Now, I have to say, this is just amazing to watch the pace of innovation, how things change, not only try, but also try to participate in open source.

And you can always run it on. With free to air, whatever it is, it's very easy compared to how it was like a couple decades ago. I mean, it's just a completely different story.

And I hope you will enjoy that experience along with us. Yes, and then just yeah, so thank you. Thank you guys for for doing this.

And this was really fun. Catch us on Containers from the Couch, dot com. We really do talk all things Containers.

And I just want to pair off of what both of you said is this is a field that's constantly evolving. So how it works today could be very different in a year and. That's Right.

It may seem overwhelming, but just know that as you abstract the layers below you, you know, as you see like AWS, we try to continuously make it easier and easier for you to run containers at scale without having to think about all the overhead. So we encourage you to just keep on on chugging away and know that things are constantly getting better. So thank you, everybody.

It was it was great to be here. Thank you everybody.