Podcasts about docker

About SterenSteren is a Group Product Manager at Google Cloud. He is part of the serverless team, leading Cloud Run. He is also working on sustainability, leading the Google Cloud Carbon Footprint product.Steren is an engineer from École Centrale (France). Before joining Google, he was CTO of a startup building connected objects and multi device solutions.Links Referenced: previous episode: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/google-cloud-run-satisfaction-and-scalability-with-steren-giannini/ Google Cloud Region Picker: https://cloud.withgoogle.com/region-picker/  Google Cloud regions: https://cloud.google.com/sustainability/region-carbon  TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.Corey: This episode is sponsored in part by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today was recently on the show. Steren Giannini is the product lead for Google Cloud Run, and we talked about that in a previous episode. If you haven't listened to it, you might wish to go back and listen to it, but it's not a prerequisite for what we're about to talk about today. Because apparently Google still does it's 20% time, and one of the things that Steren decided to do—because, you know, everyone needs a hobby—you decided to go ahead and start the Google Cloud Carbon Footprint, which is—well, Steren, thanks for coming back. What the hell is that?Steren: Thanks for having me back on the show. So yes, we started with Cloud Carbon Footprint, and this is a product that now has launched publicly, available to every Google Cloud customer right out of the box of the Google Cloud Console.Corey: I should also point out, because people always wonder and it's the first thing I always check, yes, this one is free. I'm trying to imagine a scenario which you charge for this and I wasn't incensed by it, and I can't. So, good work, you aren't charging anything for it. Good job. Please continue.Steren: So, Google Cloud Carbon Footprint helps a Google Cloud customer understand and reduce their gross carbon emissions linked to their Google cloud usage. So yeah, what do we mean by carbon emission? Just so that we are all on the same page, these are the greenhouse gases that are emitted due to the activity of using Google Cloud that are notably responsible for climate change. And we report them in equivalent of carbon dioxide—CO2—and you know, the shortcut is just to say ‘carbon.' Corey: Now, I'm going to start with something relatively controversial. It's an opinion I have around this sort of thing. And I should also disclaim, I am not in any way, shape, or form, disputing the climate change as caused by humans is real. It is. If you don't believe that, please go listen to something else, maybe Infowars. I don't know and I don't care. I just don't want you around.Now, the problem that I have with this is, on some level, it feels like a cloud provider talking to its customers about their carbon footprint is, on some level, shifting the onus of responsibilities in some way away from the cloud provider and onto the customer. Now, I freely admit that this is a nuanced topic, but how do you view this?Steren: What I mentioned is that we are exposing to customer their gross carbon emissions, but what about their net carbon emissions? Well, Google Cloud customers, net operational carbon emissions are simply zero. Why? Because if you open Google's environmental report, you will see that Google is purchasing as much renewable energy globally for the year as it is using. So, that means that on a yearly basis worldwide, every kilowatt hour of electricity has been matched with renewable energy.And you know, this Google has been doing since 2017. Since 2007, Google was already matching its carbon footprint with carbon offsets. But 2017, Google went beyond and is matching the purchase of the electricity with renewable energy. So, in a sense, your net operational emissions are zero.Now, that's not sufficient for our customers. They have some reporting obligations; they need to know before this renewable matching, what were their gross emissions? And they also need to know what are their emissions coming from, not only the electricity usage, but maybe the data center or manufacturing. And this is all of what we expose in Google Cloud Carbon Footprint.  They are before offset, before renewable energy matching.And you're right also to say that this is not only the customer's problem, and indeed, Google itself has set a goal to get to a hundred percent carbon-free electricity for every hour in every location. The big goal for 2030 is that at every hour, every location, the electricity comes from carbon-free sources. This is very ambitious and never done before, of course, at the scale of Google, but this is the next goal for Google.Corey: The challenge that I have—in the abstract—with cloud providers, more or less, shaming customers—not to say that's what you're doing here—about their carbon usage and their carbon footprint is, okay, I appreciate that this is everyone's problem, and yes, it is something that we should be focusing on extensively. The counterargument is that I don't recall ever getting a meeting invite to a Google or Amazon or Microsoft or Oracle negotiation with any of your power bills or power companies or power sourcing. I have no input whatsoever as a customer on those things. And, on some level, it's “Ooh, you're causing a particular amount of carbon to be used by your usage of these services.” Like, well, at some level, it feels like that is more of a you thing than a me thing.And I want to be clear, I'm speaking more in the abstract to the industry rather than the specifics of Google Cloud, not to unfairly put you in the position of having to speak for everyone.Steren: No, but you're right. If you were to do nothing, Google is constantly working hard to sign more power purchase agreements with some renewable energy sources or optimizing its data centers. Google Cloud data centers are one of the most optimized data centers in the industry with a power usage effectiveness of 1.1, which is basically saying that the energy that is used to power the facility over the energy used to actually power the server is 1.1. So, not that much loss in between.So, all of that to say, Google Cloud and Google are working very hard anyway to reduce Google Cloud's carbon footprints and the carbon footprint of Google Cloud customers. So, if you were to do nothing, the charts that you're seeing on Google Cloud Carbon Footprint should trend to zero. But in the meantime, you know, that's not the case, so that's why we show the data. And, like, many customers want to know or have the obligation to report on this data.Corey: One of the challenges that I see—and I believe this might even be related to the carbon footprint tool you have built out on top of Google Cloud—is when I am looking at… at where to place something—first, let me just say the region experience is wildly different than I'm used to with AWS. In the AWS universe, every region is basically its own island; it is very difficult to get a holistic view between regions. Google Cloud does not have that approach. There are advantages and disadvantages to both. I'm not passing any particular value judgment—for once—on this topic in this context. But where do I want to spin something up? And I have a dropdown of the regions that I can put it in. And some of these now have a green leaf next to them and others do not. I'm going to go out on a limb and assume you had a hand in this somewhere.Steren: Exactly. That's something I worked on with the team. So, you will see on the Google Cloud Console location selectors on the Google Cloud location page, on the Google Cloud documentation, you will see a small low CO2 indicator next to some regions. And this indicator is basically saying that this region meets some criteria of high carbon-free energy percentage or low grid carbon intensity. So, you don't need to go into the details; you just need to know that if you see this small leaf, that means that for a given workload, the emissions in that particular region will be way lower than on another region which doesn't have the leaf.Often at Google, when we do a change we A/B test it. We A/B tested those small low CO2 indicators because, you know, that's a console-wide change so we want to make sure that it's worth is. And well, it turns out that for people who were in the experiment—so people will be seeing the leaf—among new Google Cloud users, they were 50% more likely to pick a low-carbon region when the leaf was displayed. And among all users, it was 19%. So, you see how just by surfacing the information, we were able to significantly influence customers' behavior towards reducing their carbon emissions.And, you know, if you ask me, I think picking the cleanest region is probably one of the simplest action you can take—if possible, of course—to reduce your gross carbon emissions because, you know, they don't require to change your architecture or your infrastructure; it just requires you to make the right choice in the first place. And just by letting people know that some regions are emitting much less carbon than others we basically allow them to reduce their footprint.Corey: A question I have is that as you continue to move up the stack, one of the things that Google has done extraordinarily well is the global network. And we talked previously about how I run the snark.cloud URL shortener in Google Cloud. That is homed out of us-central1 as far as regions go. But given that thing is effectively stateless, it just talks to Google Sheets for its source of truth, but then just runs a Docker invocation on every request, cool, I can see a scenario in which that becomes much more of a global service.In other words, if you can run that in pops in every region around the world on some level, there is no downside, from my perspective, on doing that. What I'm wondering then, as a result of that, is as you start seeing the evolution of services becoming more and more global, instead of highly region-specific, does that change the way that we should be thinking potentially about carbon footprint and regional selection? Or is that too much of a niche edge case to really be top of radar right now?Steren: Oh, there are many things to talk about here. The first one is that you might be hinting at something that Google is already doing, which is location shifting of workloads in order to optimize power usage, and, you know of course, carbon emissions. So, Google itself is already doing that. For example, I guess, to process YouTube videos, that can be done, not necessarily right away and that can be done in the location in which, for example, the sun is shining. So, there are some very interesting things that can be done if you allow the workloads to be run in not necessarily a specific region.Now, that being said, I think there are many other things that people consider when they pick a region. First, well, maybe they have some data locality constraints, right? This is very much the case in European countries where the data must stay in a given region, by law. Second, well, maybe they care about the price. And as you probably know, [laugh] the price of cloud providers is not the same in every region.Corey: I've noticed that and in fact, I was going to get into that as our next transition, but you've just opened Pandora's Box early. It's great to have the carbon-friendly indicator next to the region, but I also want number of dollar signs next to it as well. Like in AWS-land, do you have the tier one regions where everything is the lowest price: us-east-1, us-west-2, and a few others escaped me from time to time, where Managed NAT Gateways are really expensive. And then you go under some others and they get even more expensive, somehow. Like, talk about pushing the bounds of cloud economics. It's astonishing to me.Steren: Yes. And so—Corey: Because I want that display, on some level—Steren: Exactly.Corey: —as a customer, in many cases.Steren: So, there is price, there is carbon, but of course, you know, if you are serving web requests, there is probably also latency that you care about, right? Even if—for example, Finland is very low carbon. You might not host your workloads in Finland if you want to serve US customers. So, in a sense, there are many dimensions to optimize when you pick a region. And I just sent you a link to something that I built, which is called Google Cloud Region Picker.It's basically a tool with three sliders. First one is carbon footprint; you tell us how much you care about that. Hopefully, you put it to the right. The second one is lower price. So, how much do you want the tool to optimize to lower your bill? And third one is latency, and then you tell us where your users are coming from and if you care about latency.Because some workloads are not subject to latency requirements. Like, if you do batch jobs, well, that doesn't serve a user request, so that can be done asynchronously at a later time or in a different place. And what this tool does is that it takes your inputs and it basically tells you which Google Cloud region is the best fit for you. And if you use it, you will see it has very small symbols like three dollars for the most expensive regions, one dollar for the least expensive ones, three leaves for the greenest regions, and zero leaves for the non-green one.Corey: This is awesome. I'm a little bit disappointed that I hadn't seen this before. This is a thing of beauty.Steren: Yeah. Again, done by me as a 20%. [laugh]. And, you know, the goal is to educate, like, of course, it's way more complex. Like, you know that price optimization is way more complex than a slider, but the goal of this tool is to educate and to give a first result. Like, okay, if you are in France and care about carbon, then go here. If you are in Oregon, go here. And so, many parameters that this tool help you optimize in a very simple way.Corey: One of the challenges I think I get into when I look at this across the board, is that you have a couple of very different ends on a confusing spectrum, by which I mean that one of the things I would care about from a region picker, for example, is there sufficient capacity in that region for the things I want to run. At my scale of things where right now on Google Cloud I run a persistent VM that hangs out all the time, and I run some Google Cloud Run stuff. Great. If you have capacity problems with either one of those, are you really a cloud?But then we have other folks who are spinning up tens or hundreds of thousands of a very particular instance type in a very specific region. That's the sort of thing that requires a bit more in the way of capacity planning and the rest. So, I have to imagine for those types of use cases, this tool is insufficient. The obvious reason, of course, if you're spinning up that much of anything, for God's sake, reach out and talk to your account manager before trying to do it willy-nilly but yes.Steren: That's exactly right. So, as I said, this tool is simplified tool to give, like, the vast majority of users a sense of where to put their workloads. But of course, if you're a very big enterprise customer who is going to sign a very big deal with Google Cloud, talk to your account manager because if you do need a lot of capacity, Google Cloud might need to plan for it. And not every regions have the same capacity and we are always working with our customers to make sure we direct them in the right place and have enough capacity. A real-life example of a very high profile Google Cloud customer was that they were selecting a region without knowing its carbon impact, and when we started to disclose the carbon characteristics of Google Cloud regions—which is another link we can send to the audience—this customer realized that the region they selected—you know, maybe because it was close to their user base—was really not the most carbon friendly.So, they decided to switch to another one. And if we take an example, if you take Las Vegas, it has a carbon-free energy percentage of 20%. So, that basically means that on average, 20% of the time, the electricity comes from carbon-free sources. If you are to move to Oregon, this same workload, Oregon has a carbon-free energy percentage of 90%. So, you can see how just by staying on the West Coast, moving from Las Vegas to Oregon, you have drastically reduced your carbon emissions. And your bill, by the way because it turns out Oregon is one of the cheapest Google Cloud Data Center. So, you see how just being aware of those numbers led some very important customers who care about sustainability to make some fundamental choices when it comes to the regions they select.Corey: I guess that leads to my big obvious question, where I wind up pulling up my own footprint in Google Cloud—again, I don't run much there—and apparently over the last year, I've had something on the order of two kilograms of carbon. Great. It feels like for this scale, I almost certainly burn more carbon than that just searching Google for carbon-related questions about where to place things. So, for my use case, this is entirely academic. You can almost run my workloads based upon, I don't know, burning baby seals or something, and the ecological footprint does not materially change.Then we go to the other extreme end of the spectrum with the hundreds of thousands of instances, where this stuff absolutely makes a significant and massive difference. My question is, when should people begin thinking about the carbon footprint of their cloud workload at what point of scale?Steren: So, as you said, a good order of magnitude is one transatlantic flight is a thousand kilogram of equivalent CO2. So, you see how just by flying once, you're already, like, completely overshadowing your Google Cloud carbon footprint. But that's because you are not using a lot of Google Cloud resources. Overall, you know, I think your question is basically the same as when should individuals try to optimize reducing their carbon footprint? And here I always recommend there are tons of things you can optimize.Start by the most impactful ones. And impactful means an action will have a lot of impact in reducing the footprint, but also the footprint reduction will be significant by itself. And two kilograms of CO2, yes indeed, it is very low, but if you start reaching out into the thousands of kilograms of CO2 that starts to represent, like, one flight, for example. So, you should definitely care about it. And as I said, some actions might be rather easy, like picking the right region might be something you can do pretty easily for your business and then you will see your carbon emissions being divided by, you know, sometimes five.This episode is sponsored in part by our friends at Lambda Cloud. They offer GPU instances with pricing that's not only scads better than other cloud providers, but is also accessible and transparent. Also, check this out, they get a lot more granular in terms of what's available. AWS offers NVIDIA A100 GPUs on instances that only come in one size and cost $32/hour. Lambda offers instances that offer those GPUs as single card instances for $1.10/hour. That's 73% less per GPU. That doesn't require any long term commitments or predicting what your usage is gonna look like years down the road. So if you need GPUs, check out Lambda. In beta, they're offering 10TB of free storage and, this is key, data ingress and egress are both free. Check them out at lambdalabs.com/cloud. That's l-a-m-b-d-a-l-a-b-s.com/cloud.Corey: I want to challenge your assertion, incidentally. You say that I'm not using a whole lot of Google Cloud resources. I disagree. I use roughly a dozen different Google Cloud resources tied together for some of these things, but they're built on serverless design patterns, which means that they scale to nothing. I'm not sitting there with an idle VM—except that one—that is existing on a persistent basis.For example, I look at the things that show up on the top five list. Compute Engine is number one, Cloud Run, Cloud Logging, Cloud Storage, and App Engine are the rest that are currently being used. I think there's a significant untold story around the idea of building in a serverless way for climate purposes.Steren: Yes. So, maybe for those who are not aware of what you are seeing on the dashboard, so when you open this Google Cloud Carbon Footprint tool on the Cloud Console, you saw a breakdown of your yearly carbon footprint and monthly carbon footprint across a few dimensions. The first one is the regions because as we said, this matters a lot; like, the regions have a lot of impact. The second one are the month; of course, you can see over time, how you're trending. The third one is a concept called Google Cloud Project, which is, for those who are not aware, it's a way to group Google Cloud resources into buckets.And the third one is Google Cloud services. So, what you described here is, which of your services emits the most and therefore which ones should you optimize first? Like, again, to go back to impactful actions. And to your point, yes, it is very interesting that if you use products which auto-scale, basically, the carbon attributed to you, the customer, will really follow this auto-scaling behavior. Compare that to a virtual machine that is always on, burning some CPU for almost nothing because you have a server that doesn't process requests. That is wasting, in a sense, resources.So, what you describe here is very interesting, which is basically the most optimized products you're going to pick, the less waste you're going to have. Now, I also want to be careful because comparing one CPU hour of Cloud Run and one CPU hour of Compute Engine is not comparing apples to apples. Why? Because when you use Cloud Run, I'm not sure if you know, but you are using a regional product. So, a product which has built-in redundancy, which is safe in case of one zone going down in a region.But that means the Cloud Run infrastructure has to provision a little bit more machines than if it was a zonal product. While Compute Engine, your virtual machine lives in one zone and there is only one machine for you. So, you see how we should also be careful comparing products with other products because fundamentally, they are not offering the same value and they are not running on the same infrastructure. But overall, I think you are correct to say that, you know, avoiding waste, using auto-scaling products, is a good way to reduce your footprint.Corey: I do want to ask—and this is always a delicate topic because you're talking about cultural things—how much headwind did you have internally at Google when you had the idea to start exposing this? How difficult was it to bring this to fruition?Steren: I think we are lucky that our leadership cares about reducing carbon emissions and understood that our customers needed our help to understand their cloud emissions. Like, many customers before we had this tool, we're trying to some kind of estimate their cloud emissions. And it was—you know, Google Cloud was a black box for them. They did not have access to what you said, to some data that only Google has access to.And you know, to build that tool, we are using energy measurement of every machine in every data center. We are using, you know, customer-wide resource usage. And that is something that we use to divide the footprint among customers. So, there is some data used to compute those numbers that only Google Cloud has access to. And indeed, you're correct; it required some executive approval which we received because many of our leaders believe that, you know, this is the right thing to do, and this is helping customers towards the same goal as Google, which is being net-zero and carbon-free.Many of our customers have made some sustainability commitments, and they need our help to meet those goals. So yeah, we did receive approval, first to share the per-region characteristics. This was already, you know, a first in the industry where a cloud provider disclosed that not every region is equal and some are emitting more carbon than others. And second, another approval which was to disclose a per customer carbon footprint, which is broken down by service, project, region, using some, you know, if you touch a little bit on the methodology, you know, it uses energy consumption, resource usage, and carbon intensity coming from a partner of ours to compute, basically, a per customer footprint.Corey: My question for you is, on some level, given that Google is already committed to being net-zero across the board for all of its usage, why do customers care? Why should they care? Effectively, haven't you made that entirely something that is outside of their purview? You've solved the problem, either way.Steren: This is where we should explore it a bit more the kinds of carbon emissions that exist. For a customer, their emissions linked to the cloud usage is all considered the indirect emissions. This, in the Greenhouse Gas Protocol Standard, this is called Scope 3. So, our Google Cloud emissions are the customers' Scope 3 emissions; they are all indirect for them. But those indirect emissions, what I mentioned as being net-zero are the emissions coming from electricity usage.So, to power those data centers, those data centers are located in certain electricity grids. Those electricity grids might be using energy sources that emit more or less carbon, right? Simply put, if in a given place, the electricity comes from coal, it will be emitting a lot of carbon compared to when electricity comes from solar, for example. So, you see how the location itself determines the carbon intensity. And these are the emissions coming from electricity usage, right?So, these are neutralized by Google purchasing as much renewable energy. But there are also types of emissions. For example, when a data center loses connection to the grid, we startup diesel generators. Those diesel generators will directly emit carbon. This is called Scope 1 emissions.And finally, there is the carbon emissions that are coming from the manufacturing of those servers, of those data centers. And this is called Scope 3 emissions. And the goal of Google is for the emissions coming from electricity to be always coming from carbon-free sources. So, this is a change that we've recently released to Google Cloud Carbon Footprint, which is now we also break down your emissions by scope. So, they are all Scope 3 for you, the customer, they are all indirect emissions for you, the customer, but now those indirect emissions, you can see how much is coming from diesel generators, how much is coming from electricity consumption, and how much is coming from manufacturing of the data center, and other, like, upstream, downstream activities. And yeah, overall, this is something that customers do need to report on.Corey: I think that's very fair. I do want to thank you for taking so much time to speak with me. And instead of the usual question I'd like to ask here of where can people go to find out more because we have a bunch of links for that, instead, I want to ask something a little bit different here, which is, what are the takeaways that customers or prospective customers should really have around their carbon footprint when it comes to cloud?Steren: So, I would recommend our audience to consider carbon emissions in your cloud infrastructure decisions. And my advice is, first, move to the cloud. Like, we've talked that Google Cloud has very well-optimized data centers. Like, your cloud gross carbon emissions are anyway going to be much lower than any on-premise carbon emissions. And by the way, if you use Google Cloud, your net operational emissions are zero.Second action is pick the region with the lowest carbon impact. Like we discussed that this is probably a low-effort action, if possible, that will have a lot of impact on your gross carbon emissions. And you know, if you want to go further, try to schedule those workloads when the electricity is the greenest, you know, when the sun is shining, the wind is blowing, for example, or try to schedule those workloads in regions which have the lowest impact. And yeah, Google Cloud gives you all the tools to do that, the tools to optimize your region selection, and the tools to report and reduce your gross carbon emissions. We haven't talked about it, but Google Cloud Carbon Footprint will even send you some proactive recommendations of things to do to reduce your emissions.For example, if you have a project, a machine that you forgotten, Google Cloud Carbon Footprint, will recommend you to delete it and we'll tell you how much carbon you would save by deleting it, as well as dollar, of course.Corey: It's funny because I feel like there's a definite alignment between my view of cloud economics and the carbon perspective on this, which is step one, everyone wins if you turn things off when you're not using them. What a concept. I sometimes try and take it too far of, ‘turn off all of production because your company's terrible.' Yeah, it turns out, that doesn't work super well. But the idea of step one, turn it off, especially when you're not using it. And if you're never using it, why would you want to pay for it? That becomes a very clear win for everyone involved. I think that in the fullness of time, economics are what are going to move the needle on driving further adoption about this. I have to guess that you see the same thing from where you are?Steren: Yes, very often working to reduce your carbon footprint is also working to reduce your bill. And we've also observed—not always—but some correlation between regions that have the lowest carbon impact and regions that are the cheapest. So, in a sense, this region selection, optimizing for price and carbon is often optimizing for the same thing. It's not always true, but it is often true.Corey: I really want to thank you for spending so much time to talk with me about this. This has definitely giving me a lot of food for thought, and I have to imagine that this will not be our last conversation around the topic.Steren: Well, thanks for having me. And I'm very happy to talk to you in the podcast, of course.Corey: Steren Giannini, product lead for Google Cloud Carbon Footprint and Google Cloud Run. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry screed about how climate change isn't real as you sit there wondering why it's 120 degrees in March.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Bret is joined by Nirmal Mehta, a Principal Specialist Solution Architect at AWS, and a Docker Captain, to discuss Karpenter, an autoscaling solution launched by AWS in 2021. Karpenter simplifies Kubernetes infrastructure by automating node scaling up and down, giving you "the right nodes at the right time."Autoscaling, particularly for Kubernetes, can be quite a complex project when you first start. Bret and Nirmal discuss how Karpenter works, how it can help or complement your existing setup, and how autoscaling generally works.Streamed live on YouTube on June 9, 2022.Unedited live recording of this show on YouTube (Ep #173). Includes demos.★Topics★Starship Shell PromptBret's favorite shell setupKarpenterKarpenter release blogK8s Scheduling ConceptsOther types of autoscalers:Horizontal Pod AutoscalerVertical Pod AutoscalerCluster Autoscaler★Nirmal Mehta★Nirmal on TwitterNirmal on LinkedIn★Join my Community★Best coupons for my Docker and Kubernetes coursesChat with us on our Discord Server Vital DevOpsHomepage bretfisher.com ★ Support this podcast on Patreon ★

Baruch Sadogursky (Chief Sticker Officer at JFrog) joins Natalie & Johnny to lament the current state of dependency management in Go and other languages. They discuss the problems dependency managers face, possible technical mitigations like SBOMs, people problems that will never be solved by tech, and take questions from listeners in the #gotimefm channel of Gophers Slack.

This hour we focus on your feedback, Kubernetes, audio interfaces, and of course your weekly Linux headlines! -- During The Show -- 00:50 FreeCAD Thank You FreeCAD 03:00 Caller Matrix Bridge Hosting Bridges can break when cooperation is required on the other end 12:00 Kubernetes? - Tyler Grunt Work Kubernetes Crash Course (https://blog.gruntwork.io/a-crash-course-on-kubernetes-a96c3891ad82) Red Hat - Steve Ovens (https://www.redhat.com/sysadmin/users/steve-ovens) Kubernetes dropped Docker shim for CNI OpenShift (https://docs.openshift.com/) MiniKube (https://minikube.sigs.k8s.io/docs/) Mini Shift (https://github.com/MiniShift/minishift#documentation) OKD (UpStream OpenShift) (https://www.okd.io/) Steve's How Containers Work (https://www.redhat.com/sysadmin/building-container-namespaces) 24:26 News Wire OpenPGL Path Guiding Library Phoronix (https://www.phoronix.com/news/Intel-OpenPGL) MoonRay Renderer Open Source For U (https://www.opensourceforu.com/2022/08/dreamworks-animation-to-launch-moonray-renderer-as-open-source-software/) Hollywood Reporter (https://www.hollywoodreporter.com/business/digital/dreamworks-animation-release-renderer-open-source-software-1235192426/) VISTA 2.0 Open Source For U (https://www.opensourceforu.com/2022/08/the-latest-self-driving-car-algorithm-from-mit-is-open-source/) CMU auton-survival Mark Teck Post (https://www.marktechpost.com/2022/08/07/cmu-researchers-open-source-auton-survival-a-comprehensive-python-code-repository-of-user-friendly-machine-learning-tools-for-working-with-censored-time-to-event-data/) LLNL GridDS LLNL.GOV (https://www.llnl.gov/news/open-source-data-science-toolkit-energy-gridds) Godot 3.5 Gaming On Linux (https://www.gamingonlinux.com/2022/08/open-source-game-development-advances-with-godot-engine-35-out-now/) NanoScale Atomic Force Microscope Hackster.io (https://www.hackster.io/news/this-4-000-open-source-high-speed-atomic-force-microscope-is-a-nanoscale-imaging-marvel-69e5786fd824) CIFS/SMB3 just in time for Linux 6.0 Phoronix (https://www.phoronix.com/news/Linux-6.0-SM3-Client-Perf-MC) Elastic Search Alternative Manticore Search (https://manticoresearch.com/blog/manticore-alternative-to-elasticsearch/) New Ransomeware Targeting Linux Systems Info Security Magazine (https://www.infosecurity-magazine.com/news/gwisinlocker-ransomware-linux/) Bleeping Computer (https://www.bleepingcomputer.com/news/security/new-gwisinlocker-ransomware-encrypts-windows-and-linux-esxi-servers/) New IoT Malware RapperBot The Hacker News (https://thehackernews.com/2022/08/new-iot-rapperbot-malware-targeting.html) Tails 5.3.1 Emergency Release TorProject (https://forum.torproject.net/t/tails-5-3-1-is-out-2022-08-02/4184) 26:28 Audio Interfaces? - Thor Lexicon Alpha Change the Default Sample Rate on Pipewire (ArchWiki) (https://wiki.archlinux.org/title/PipeWire#Changing_the_default_sample_rate) 30:16 Bluray Playback on old computer? - William Amazon Link (https://www.amazon.com/Blu-ray-ThinkPad-Workstation-Optical-Replacement/dp/B081XLNX3H/?tag=minddripmedia-20) Ebay Link 1 (https://www.ebay.com/itm/151236944357) Ebay Link 2 (https://www.ebay.com/itm/293675206709) BUS Speed may limit the drive bay Don't buy T series parts for a E series Why use optical media? MakeMKV (https://makemkv.com/) Big Buck Bunny (https://peach.blender.org/) 38:00 Linux Delta Website? - Lou How did you create the Linux Delta website Noah didn't build Linux Delta Brad Wilson KhronoSync (https://khronosync.com/) Linux Delta website code (https://gitlab.com/altispeed/mdm/dev/linux-delta) 39:50 Thornbill Asks Is Invoice Ninja still the recommended solution for invoicing? Noah's Frustrations 43:20 Pick of the Week DICOM Viewer Weasis (https://nroduit.github.io/en/) History of DICOM What is DICOM DCM4CHEE (PACS) GitHub (https://github.com/dcm4che/dcm4chee-arc-light) Atlassian EE2 Overview (https://dcm4che.atlassian.net/wiki/spaces/ee2/overview) J4Care.com (https://www.j4care.com/dcm4che.html) -- The Extra Credit Section -- For links to the articles and material referenced in this week's episode check out this week's page from our podcast dashboard! This Episode's Podcast Dashboard (http://podcast.asknoahshow.com/298) Phone Systems for Ask Noah provided by Voxtelesys (http://www.voxtelesys.com/asknoah) Join us in our dedicated chatroom #GeekLab:linuxdelta.com on Matrix (https://element.linuxdelta.com/#/room/#geeklab:linuxdelta.com) -- Stay In Touch -- Find all the resources for this show on the Ask Noah Dashboard Ask Noah Dashboard (http://www.asknoahshow.com) Need more help than a radio show can offer? Altispeed provides commercial IT services and they're excited to offer you a great deal for listening to the Ask Noah Show. Call today and ask about the discount for listeners of the Ask Noah Show! Altispeed Technologies (http://www.altispeed.com/) Contact Noah live [at] asknoahshow.com -- Twitter -- Noah - Kernellinux (https://twitter.com/kernellinux) Ask Noah Show (https://twitter.com/asknoahshow) Altispeed Technologies (https://twitter.com/altispeed) Special Guest: Steve Ovens.

Max, Dominik und Jochen unterhalten sich diesmal über Ansible. Dass Ansible selbst in Python geschrieben ist, macht es für Python-Entwickler wie uns natürlich besonders interessant. "Infrastructure as code" machen inzwischen ja irgendwie auch alle - bleibt nur die Frage, ob man Terraform von Ansible aus aufrufen sollte, oder umgekehrt

Video content can be found here: https://www.youtube.com/channel/UC0BAd8tPlDqFvDYBemHcQPQ/

Our award winning worthy survey game show is back, this time Mat Ryer hosts it live on stage at GopherCon Europe 2022! Go Time's Natalie Pistunovich joins forces with Ronna Steinberg & Robert Burke to battle it out with V Körbes, Tamir Bahar & Konrad Richie. Let's see who can better guess what the GopherCon Europe gophers had to say!

The real story behind the "Massive GitHub Malware attack," significant updates for the Steam Deck, and the inside scoop on Lenovo's big Linux ambitions.

Our award winning worthy survey game show is back, this time Mat Ryer hosts it live on stage at GopherCon Europe 2022! Go Time's Natalie Pistunovich joins forces with Ronna Steinberg & Robert Burke to battle it out with V Körbes, Tamir Bahar & Konrad Richie. Let's see who can better guess what the GopherCon Europe gophers had to say!

The one and only Kelsey Hightower drops by the recording studios at Spotify's global HQ in Stockholm to chat with host Dave Zolotusky about what it's like being a software developer today: did it get harder or easier? Hear Dave and Kelsey talk about what happens when tech becomes more accessible to more people, Kelsey's role models and who he looks to for inspiration, when is the appropriate time to talk to your daughter about Docker containers, what comes after “move fast & break things”, what makes a good engineering culture — and how to recognize one when you're interviewing. Plus, being a minimalist and how many pairs of pants do you really need. Along with being a principal engineer and longtime developer advocate at Google Cloud, Kelsey is a legendary conference speaker, creator of Kubernetes The Hard Way, famous for never shying away from the hard topics on Twitter, mentor and role model to many, and one of the most respected voices in the engineering community today. We were very glad to nerd out with him. You can find more Kelsey here: @kelseyhightower on Twitter Kubernetes The Hard Way “From McDonald's to Google: How Kelsey Hightower became one of the most respected people in cloud computing” by Tom Krazit (Protocol, October 2020) Read what else we're nerding out about on the Spotify Engineering Blog: engineering.atspotify.com You should follow us on Twitter @SpotifyEng and on LinkedIn!

Florent Biville maintains the official Go driver at graph database company, neo4j. We talk about the challenges and benefits of constantly learning new languages, interviewing at large companies, consulting life, and the importance of building trust through consistency. Connect with Florent:Twitter: https://twitter.com/fbivilleWebsite: https://florent.biville.net GitHub: https://github.com/fbiville Mentioned in today's episode:neo4j: https://neo4j.comGo Driver Documentation: https://neo4j.com/developer/go/ Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses: https://ardanlabs.com/education/ Live Events: https://www.ardanlabs.com/live-training-events/ Blog: https://www.ardanlabs.com/blog Github: https://github.com/ardanlabs 

Round 20 of the 2022 AFL Season was a cracker and after another nine games, we are still yet to lock in the top four and final eight. Jamie and Peps deep-dive into the Docker's shocker against Melbourne, the Lions MCG nightmare continuing, Essendon's false economy, Gold Coast's Brownlow swooper, the hooped premiership favourite, the perfect ten, our new segment intro (it is awesome), and much more. https://www.afl.com.au/news/811806/richmond-tigers-hero-noah-cumberland-earns-nab-afl-rising-star-nomination-after-five-goal-haul (Richmond Tigers hero Noah Cumberland earns NAB AFL Rising Star nomination after five-goal haul) https://www.abc.net.au/news/2022-07-30/how-geelong-and-collingwood-have-built-their-nine-wins-in-a-row/101269558 (Why Geelong and Collingwood are the form teams of the AFL going into round 20 - ABC News) Hosted By Christopher Pepper and Jamie Wallis Check out Lace Out's https://www.facebook.com/laceoutpodcast/ (Facebook page) Broadcasting LIVE every Tuesday night @ 8.30 pm (AEST) Look out for our Tipped Out episodes: Our Tips, Every Week! #itshowiwantmyfooty #laceout #afl

Bret is joined by Laura Tacho, an engineering leadership coach, to discuss measuring your team's performance with DevOps metrics (DORA) and the new SPACE framework. Team Performance is one of Bret's favorite topics, and it should be everyone's concern.Laura and Bret discuss soft skills, how to implement DORA DevOps metrics, the new SPACE framework, as well as common pitfalls people make when attempting to implement those measurements. Streamed live on YouTube on June 2, 2022.Unedited live recording of this show on YouTube (Ep #172).★Topics★Laura's course on High-Performing Software TeamsDORA (DevOps Research and Assessment)DORA MetricsDORA DevOps Quick CheckSPACE frameworkGoodhart's lawDeveloper ExperienceDevOps HandbookAccelerate Book★Laura Tacho★Laura's homepage and NewsletterLaura on TwitterLaura on the GitHub blog★Join my Community★Best coupons for my Docker and Kubernetes coursesChat with us on our Discord Server Vital DevOpsHomepage bretfisher.com★ Support this podcast on Patreon ★

In part two, Dave chats again with Francesco Pochetti, Senior Machine Language Engineer at Bolt, and an AWS Machine Learning Hero. In this episode, Francesco dives deep in the ML tools on AWS, starting with the tools such as NVIDIA Triton and TensorRT, and how to improve processing time for Computer Vision. He also covers Amazon SageMaker, and many other AWS ML services as well as deploying ML models using Docker in the best way possible. If you missed it, you could listen to part one of this conversation in Episode 045. Francesco on Twitter: https://twitter.com/Fra_Pochetti Dave on Twitter: https://twitter.com/thedavedev Francesco's Website: https://francescopochetti.com/ Francesco's LinkedIn: https://www.linkedin.com/in/francescopochetti/ Francesco's GitHub: https://github.com/FraPochetti [BLOG] Blurry faces: Training, Optimizing and Deploying a segmentation model on Amazon SageMaker with NVIDIA TensorRT and NVIDIA Triton - https://francescopochetti.com/blurry-faces-a-journey-from-training-a-segmentation-model-to-deploying-tensorrt-to-nvidia-triton-on-amazon-sagemaker/ [BLOG] Machine Learning and Developing inside a Docker Container in Visual Studio Code https://francescopochetti.com/developing-inside-a-docker-container-in-visual-studio-code/ [BLOG] Deploying a Fashion-MNIST web app with Flask and Docker: https://francescopochetti.com/deploying-a-fashion-mnist-web-app-with-flask-and-docker/ [BLOG] IceVision meets AWS: detect LaTeX symbols in handwritten math and deploy with Docker on Lambda: https://francescopochetti.com/icevision-meets-aws-detect-latex-symbols-in-handwritten-math-and-deploy-with-docker-on-lambda/ [DOCS] Amazon Rekognition - https://aws.amazon.com/rekognition/ [DOCS] Amazon SageMaker - https://aws.amazon.com/sagemaker/ [DOCS] Amazon Textract - https://aws.amazon.com/textract/ [DOCS] Deploy fast and scalable AI with NVIDIA Triton Inference Server in Amazon SageMaker https://aws.amazon.com/blogs/machine-learning/deploy-fast-and-scalable-ai-with-nvidia-triton-inference-server-in-amazon-sagemaker/ [GIT] Nvidia Triton Inference Server: https://github.com/triton-inference-server/server/ [GIT] Blurry faces: Training, Optimizing and Deploying a segmentation model on Amazon SageMaker with NVIDIA TensorRT and NVIDIA Triton - https://github.com/FraPochetti/KagglePlaygrounds/tree/master/triton_nvidia_blurry_faces Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud

Go 1.18 was a major release where we saw the introduction of generics into the language as well as other notables such as fuzzing and workspaces. With Go 1.19 slated to come out next month, one has to wonder what's next. Are we in store to be blown away by new and major features like we saw in 1.18? Not exactly but there are still lots of improvements to be on the lookout for. Joining Mat & Johnny to touch on some of the most interesting ones is Carl Johnson, himself a contributor to the 1.19 release.

Go 1.18 was a major release where we saw the introduction of generics into the language as well as other notables such as fuzzing and workspaces. With Go 1.19 slated to come out next month, one has to wonder what's next. Are we in store to be blown away by new and major features like we saw in 1.18? Not exactly but there are still lots of improvements to be on the lookout for. Joining Mat & Johnny to touch on some of the most interesting ones is Carl Johnson, himself a contributor to the 1.19 release.

Source: the Analytics Engineering Podcast: https://roundup.getdbt.com/p/aaron-katz-clickhouse (2mins in)Feedback/Discuss on Twitter: https://twitter.com/swyx/status/1552835669373894656Survey Fill out our 2022 Survey! https://forms.gle/g2s1Np9wS5qmrKSRA! Survey context: https://mixtape.swyx.io/episodes/swyx-mixtape-survey-refactor-and-deadpool-swyx More on ClickhouseOur previous episode on Clickhouse: https://twitter.com/swyx/status/1502129209111576577HN comments on Clickhouse: https://news.ycombinator.com/item?id=28595419I'd like to thank the creators of ClickHouse as i hope they are reading here. We've been using it since 2019 in a single server setup with billions of rows. No problems at all. And query speeds that seem unreal compared to MySQL and pg.https://news.ycombinator.com/item?id=26316401 Also wanted to share my overall positive experience with Clickhouse.UPSIDES* started a 3-node cluster using the official Docker images super quickly* ingested billions of rows super fast* great compression (of course, depends on your data's characteristics)* features like https://clickhouse.tech/docs/en/engines/table-engines/merget... are amazing to see* ODBC support. I initially said "Who uses that??", but we used it to connect PostgreSQL and so we can keep the non-timeseries data in PostgreSQL but still access PostgreSQL tables in Clickhouse (!)* you can go the other way too: read Clickhouse from PostgreSQL (see https://github.com/Percona-Lab/clickhousedb_fdw, although we didn't try this)* PRs welcome, and quickly reviewed. (We improved the ODBC UUID support)* code quality is pretty high.DOWNSIDES* limited JOIN capabilities, which is expected from a timeseries-oriented database like Clickhouse. It's almost impossible to implement JOINs at this kind of scale. The philosophy is "If it won't be fast as scale, we don't support it"* not-quite-standard SQL syntax, but they've been improving it* limited DELETE support, which is also expected from this kind of database, but rarely used in the kinds of environments that CH usually runs in (how often do people delete data from ElasticSearch?)It's really an impressive piece of engineering. Hats off to the Yandex crew.moreI'd like to add an upside which is:Totally great and simple on a single node.I looked at a bunch of analytical databases and had a lot that started with "so here's a basic 10 node cluster". Clickhouse installed and worked instantly with decent but not "big" data with no hassle. A hundred million rows with lots of heavy text blobs and a lot of columns, that kind of thing. Happily dealt with triple nested joins over that, and with billions of entries in arrays on those columns didn't bat an eye.https://news.ycombinator.com/item?id=29098637 This has been my experience with ClickHouse as well...that is, you can basically close your eyes while writing the schema and still maintain to get extremely impressive performance.That being said, ClickHouse also has a ton of clever levers you can pull to squeeze out better performance and compression which aren't used by default, such as using Delta/DoubleDelta CODECs with LZ4/ZSTD compression, etc. Not to mention, MATERIALIZED VIEWs and/or the relatively newer feature MergeTree Projections[1]

How do beginners learn Go? This episode is meant to engage both non-Go users that listen to sister podcasts here on Changelog, or any Go-curious programmers out there, as well as encourage those that have started to learn Go and want to level up beyond the basics. On this episode we're aiming to answer questions about how to learn Go, identify resources that are available, and where you can go to continue your learning journey.

How do beginners learn Go? This episode is meant to engage both non-Go users that listen to sister podcasts here on Changelog, or any Go-curious programmers out there, as well as encourage those that have started to learn Go and want to level up beyond the basics. On this episode we're aiming to answer questions about how to learn Go, identify resources that are available, and where you can go to continue your learning journey.

Steve Wade is a founding engineer at KSOC Labs, a cloud-native SaaS platform built to remediate Kubernetes security risks in real time. We talk about the struggles around playing professional soccer, the importance of saying yes to opportunities, finding fulfillment in your career, and LOTS of Kubernetes chat.Connect with Steve:Twitter: https://twitter.com/swade1987Website: https://www.stevenwade.co.uk/GitHub: https://github.com/swade1987Mentioned in today's episode:KSOC Labs: https://www.ksoc.com/Cuelang: https://cuelang.org/Kelsey Hightower on healthz: https://vimeo.com/173610242Want more from Ardan Labs? You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!Online Courses: https://ardanlabs.com/education/Live Events: https://www.ardanlabs.com/live-training-events/Blog: https://www.ardanlabs.com/blogGithub: https://github.com/ardanlabs

#168: At DockerCon 2022, Docker announced a number of improvements to Docker Desktop, including extensions and Docker Desktop for Linux. What is it going to take for Viktor to install Docker Desktop on his machine again?   YouTube channel: https://youtube.com/devopsparadox/   Books and Courses: Catalog, Patterns, And Blueprints https://www.devopstoolkitseries.com/posts/catalog/   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/   Connect with us at: https://www.devopsparadox.com/contact/

Cet épisode marathon sera découpé en deux morceaux pour éviter à vos oreilles une écoute marathon. Cette deuxième partie couvre des sujets d'architecture et de loi société et organisation ainsi que les conférences à venir. Logging, Migration Java 8 vers 11, Xerox Park, (manque de) sécurité, courbes elliptiques, sondage développeurs. Enregistré le 8 juillet 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–282.mp3 News Architecture Pour ou contre le logging Contre puis pour tous les langages et plateformes utilisent les logs debugging, tracing, journaling, monitoring, and printing errors impact sur les performances (allocation supérieure sur un log que sur le code métier log = mémoire, CPU (GC), I/O risque de securité (dépendances et fonctionnalités sans besoin) format des log: pour lecture humaine main volume impose traitement automatique log level la bonne abstraction (souvent trop et pas ce que l'on veut à la fois debugging -> utiliser un debugger ; journaling -> event sourcing ou solution dédiée ; tracing > open tracing ; monitoring -> monitoring solution via metrics et health check bons usages de logging: en dev (println), fin de jobs automatiques, erreurs non récupérables ou innatendues, pas les erreurs utilisateur (logger les erreurs qui cachent un bug), dans les container, Sébastien utilise System.out et System.err vu que les logs sont gérés par la plateforme la réponse pour maintenant les logs peuvent etre structurés performance, on peut éviter les concatenations de String (parameterized logging), memory allocation est bien meilleure depuis 2012 (e.g. Shenandoah), vu des problèmes dans des cas plus rare de genre MDC.getCopyOfContextMap disk I/O: ok mais disque cape a 200 MiB/s donc bon…: si c;est le cas, sépare I/O log du reste (disque vs network par exemple) gros fan de logs structures via JSON ; log line sur console et JSON en fichier log plus de manière conditionelle tracing théoriquement bon mais limite dans son contexte métier et peu d'infos passables system.out problème de scalabilité d'usage, etc et appel blocant println (async usage n'est pas bon) LinkedIn et sa migration de Java 8 à 11 1000 apps sur 320k hosts Migration Java 8 vers 11 avec en vue G1 regardé depuis 2018 Jetty, Hadoop, Play, Samza: focalisé sur Jetty Mettre a jour le système de build, 2. Faire des tests de performance 3. Automatiser la migration mise. a jour vers gradle 5 G1 80% des applis CMS 20% pris 20 apps representatives focalisé sur les applications avec les tailles de piles les plus grosses de équipera jusquà 200% plus de latence et throughput: zones G1, Shenandoah et ZGC automatisé la migration du reste et tourné les builds de tests qui ont identifié les problèmes de migration quelques problèmes: suppression de certaines classes Java EE, changement du type de classloader par défaut, casting de classe plus stricte ils ont utilisé -release 8 et ont limité les usages des features Java 11 les options de CLI de la JVM ont beaucoup changé LinkedIn fait du microsercices ce qui veut dire que beaucoup de repositories sont liés à d'autre par un graphe de dépendance: euh c'est pas le principe des microservices d'éviter ça??? mise a jour de 500 librairies 3/4 de l'année Quelques challenges vus La JVM respecte groups et donc moins de thread GC sont crées aussi ils pouvaient piquer des cycles CPUs avant et plus maintenant Java 11 a un usage de mémoire hors pile plus important reduction de latence p99 par 10% et le throughput par 20% sans changer le type de GC C'est un bon retour qui sent le type de développement de la vrai vie Méthodologies Un article sur Xerox park et comment ils ont inventé le futur article de 1985 Xerox achète un constructeur de mainframe, et ils ont crée un lab de recherche pour aider les usages Macintosh et la souris et les fenêtres, les cartes météos colorées, imprimante laser, réseaux d'ordinateurs, lasers semi-conducteurs qui lisent les disques optiques, langages de programmation structurés developer l'architecture de l'information project proposes et faite en bottom up PARC construisait ses propres hardware ce qui a créer des inventions et qui devaient etre construits pour 100 utilisateurs (scale) recherche en construisant concrètement, pas en papier théorique académique bit map, distributed computing, email, frame buffer, LAN, object oriented programming Cree Alto un ordinateur « personnel » qui a permis aux chercheurs de tester leurs idées, beaucoup en avaient un. donc ils ont du inventer le LAN et Ethernet (packet) via une personne avec passe de radio amateur (medium partagé et non reliable premier projet distribué. (Un protocole d'impression) antialiasing : ils amélioraient en testant pour de vrai un gars a construit un proto de souris pour prouver que les curseurs étaient plus efficace: tests avec des dans la rue et IO a perdu :D concept de modal (insert, delete) vers comportement non modal, plus simple pour l'utilisateur small talk: un langage si simple qu'un enfant peut l'utiliser (simulation based programming) overlapping windows ont été développées en small talk autre groupe strong type system Xerox ne savait pas convertir ces recherches en produits et les amener sur le marcher (sauf l'imprimante laser) Sécurité Travis CI fuit encore des mots de passe permet d'accéder au compte privé des développeurs open source qui ont mis en place travisCI c'est la quatrième fois token offre accès lecture et écriture aux repos risque d'attaque de supply chain tokens github, AWS ou DockerHub apr exemple mais aussi les bases de données utilisées dans la CI via l'API TravisCI HDMI peut-être un vecteur d'attaque et d'infection de vos ordinateurs Un hack d'un adaptateur HDMI peut potentiellement infecter un video-projecteur, et qui à son tour pourra réinfecter les prochains ordinateurs qui s'y connecteront Cet article propose de construire une sorte de connecteur qui sert de firewall HDMI pour éviter ce genre d'infection il y a des préservatifs USB aussi qui ne laissent passer que la puissance et pas les données Un guide pour protéger son macOS Une suite de conseils comme de faire une installation toute fraiche, de mettre les mises à jour logicielle automatiques, n'autoriser que les applications signées, appliquer le chiffrement du disque… Mais aussi utiliser par exemple un gestionnaire de mot de passe, éviter les extensions de navigateur, faire tourner un firewall Et des liens vers des guides de sécurités plus avancés un truc que je n'ai pas fait mais qui me tente c'est un outbound firewall comme little snitch ou lulu Comment choisir un algorithme de courbes elliptiques un article qui détaille le pour et le contre de certaines courbes elliptiques cas d'usage, notamment gouvernemental faiblesses (timing attaques etc) pour les curieux mais la première courbe citée est celle la plus utilisée en ce moment Loi, société et organisation Stackoverflow sort son sondage sur les développeurs 70% apprennent a coder en ligne (les plus de 45 ans dans les bouquins) stackoverflow derrière la doc technique puis les blogs ; video 60% des gens ; podcast 7,21% damn! presque 60% ont moins de 10 ans d'expérience ; si t'es pas VP ou CxO a 17 ans d'expérience, tu as raté ta vie 9% cloud infra engineers 22% ont neuro atypiques Docker passe dans la catégorie outil fondamental (69% d'usage) les frameworks 3D genre Unity 3D ou Unreal Engine sont des outils que des non développeurs pro apprennent Rust technologie la plus aimée, Rust et Python en plus demandées Java 6eme position mais 4ème pour ceux qui apprenent Angular.is en framework le plus redouté / react.is le plus demandé Docker et Kube sont les plus aimés et demandé indépendants on augmenté de 5% et 4% pour les temples pleins 85% des dev sont dans une orga partiellement distancié le 62% des devs pro cherchent des réponses pendant plus de 30 minutes par jour, 25% 11h Azure prend la deuxième place des cloud, OVH 3,7% Spring framework le plus populaire de Java VSCode 74%, IntelliJ 28%, vim 23%, Eclipse 12%, EMacs 4,5% pleins d'outils asynchrone (tickets etc) que je ne connais pas salaires ont augmenté de 23% en median JavaScript change de licence open source toujours la licence Ecma international license, assez restrictive qui interdit le fork, mais avec certaines provisions pour l'intégration et la reproduction mais aussi une nouvelle licence dérivée de la W3C Document & Software License, un peu plus ouverte, qui permet d'intégrer et s'intégrer plus facilement avec les autres standards du Web Conférences de la part de Youen Cette année Codeurs en Seine, c'est le 17 novembre et le cfp est ouvert N'hésitez pas à amener un peu de JVM dans l'appel à orateur. (ca commence à se faire rare). Pour rappel : codeurs en seine c'est 1000 personnes autour des métiers du développement dans une des plus grande salle de Rouen, le kindarena. Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/

Guests: Dr. Albert Orbinati (Assistant Professor and Program Director of the Human Resources Management program at Champlain College) and Alisa Avelar (Vice President of People at Docker and Professor of Human Resources Management at Champlain College) We are back with Part 2 of our conversation with Champlain College's Dr. Albert Orbinati and Alisa Avelar, as we look at the potential challenges and roadblocks facing teams that are now working in different workplace formats. So what can HR leaders do to help overcome these challenges? Listen as we answer this question and learn what Albert and Alisa are most excited for in the future of HR.

Bret is joined by the co-creators of the Argo project and co-founders of Akuity - Hong Wang and Jesse Suen - to discuss the state of Argo and their new Akuity offering for Argo CD in the Cloud.Chances are, you've heard of one or more of the Argo projects. They include Argo Workflows, Argo CD, Argo Events, and Argo roll-outs. Argo is one of those Kubernetes projects that is so common for teams to choose that it's nearly an assumption that every team is using one of their tools in a cluster or two. Hong Wang and Jessie Suen helped co-create the Argo project years back at Intuit and have now co-founded a growing startup called Akuity. The company is focusing on making the Argo products better and creating SaaS offerings for the Argo tools. In this episode, we get a perspective on where the Argo tools came from and what the team behind it is doing. Streamed live on YouTube on May 26, 2022.Unedited live recording of this show on YouTube (Ep #171).★Topics★Argo CD homepageAkuity homepageAkuity news on more fundingArgo CD in the cloudArgoCon in SeptemberDeclarative setup of Argo CD★Twitter Links★ArgoAkuityJesse SuenHong Wang★Join my Community★Best coupons for my Docker and Kubernetes coursesChat with us on our Discord Server Vital DevOpsHomepage bretfisher.com★ Support this podcast on Patreon ★

Ben and Matt compare container technologies like Docker to virtual machines, and discuss the tradeoffs when deploying applications. Matt explains the scary things that can happen when you share a VM with strangers. A visitor enters through the couch.

Another great use case for Docker containers with interactive R-Markdown reports, a recap of RStudio's presence at the Appsilon Shiny conference, and building an interactive point-and-click game with Shiny. Episode Links This week's curator: Jonathan Carroll (@carroll_jono (https://twitter.com/carroll_jono)) Containerizing Interactive R Markdown Documents (https://hosting.analythium.io/containerizing-interactive-r-markdown-documents/) RStudio Recap From the Appsilon Shiny Conference (https://www.rstudio.com/blog/rstudio-recap-from-the-appsilon-shiny-conference/) How to build an interactive point-and-click game with {Shiny} (https://www.youtube.com/watch?v=4-6jDDCADvU) Entire issue available at rweekly.org/2022-W28 (https://rweekly.org/2022-W28.html) Supplement Resources Appsilon Shiny Conference playlist: https://www.youtube.com/playlist?list=PLexAKolMzPcrYjGA1PULfm7-P12qjKmPb R Workflow by Frank Harrell: http://hbiostat.org/rflow/ Albert's video on styling a Quarto blog with CSS: https://www.youtube.com/watch?v=ErRX8plZpQE

In this episode, Dave chats with Francesco Pochetti, Senior Machine Language Engineer at Bolt, and an AWS Machine Learning Hero. Francesco covers his career start as a chemist, his journey into a career of Data Science, and how Computer Vision technology is handling some of the most difficult Machine Learning problems today. Francesco on Twitter: https://twitter.com/Fra_Pochetti Dave on Twitter: https://twitter.com/thedavedev Francesco's Website: https://francescopochetti.com/ Francesco's LinkedIn: https://www.linkedin.com/in/francescopochetti/ Francesco's GitHub: https://github.com/FraPochetti [BLOG] Blurry faces: Training, Optimizing and Deploying a segmentation model on Amazon SageMaker with NVIDIA TensorRT and NVIDIA Triton: https://francescopochetti.com/blurry-faces-a-journey-from-training-a-segmentation-model-to-deploying-tensorrt-to-nvidia-triton-on-amazon-sagemaker/ [BLOG] Machine Learning and Developing inside a Docker Container in Visual Studio Code: https://francescopochetti.com/developing-inside-a-docker-container-in-visual-studio-code/ [BLOG] Deploying a Fashion-MNIST web app with Flask and Docker: https://francescopochetti.com/deploying-a-fashion-mnist-web-app-with-flask-and-docker/ [BLOG] IceVision meets AWS: detect LaTeX symbols in handwritten math and deploy with Docker on Lambda: https://francescopochetti.com/icevision-meets-aws-detect-latex-symbols-in-handwritten-math-and-deploy-with-docker-on-lambda/ [DOCS] Amazon Rekognition: https://aws.amazon.com/rekognition/ [DOCS] Amazon SageMaker: https://aws.amazon.com/sagemaker/ [DOCS] Amazon Textract: https://aws.amazon.com/textract/ [DOCS] Deploy fast and scalable AI with NVIDIA Triton Inference Server in Amazon SageMaker: https://aws.amazon.com/blogs/machine-learning/deploy-fast-and-scalable-ai-with-nvidia-triton-inference-server-in-amazon-sagemaker/ [GIT] Nvidia Triton Inference Server: https://github.com/triton-inference-server/server/ [GIT] Blurry faces: Training, Optimizing and Deploying a segmentation model on Amazon SageMaker with NVIDIA TensorRT and NVIDIA Triton: https://github.com/FraPochetti/KagglePlaygrounds/tree/master/triton_nvidia_blurry_faces Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud

Ian Miell is a partner at consultancy Container Solutions, and an author of books on Bash, Git, Terraform and Docker. He explains to Craig how writing - whether runbooks, blog posts, training courses, or “real” books, can help you learn and make your team more effective. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod Chatter of the week Hot hot hot Small pools and larger pools News of the week Gateway API goes to Beta Episode 104, with Bowei Du Istio support for Gateway API SMI community gets behind Gateway API Kyverno and Keptn move to incubation Episode 119, with Alois Reitbauer Tau T2A Arm VMs now on Google Compute Engine GKE support for Tau T2A Arm nodes Kubeshop acquires BotKube Exploiting Authentication in AWS IAM Authenticator for Kubernetes by Gafnit Amiga New Vulnerabilities in Kubernetes NGINX Ingress Controller CNCF sponsors audit of KubeEdge KubeEdge security threat model Audit report Red Hat announces new CEO Google Cloud announces new Distinguished Engineer Episode 185, with Clayton Coleman Links from the interview Zwischenzugs Business Value, Soccer Canteens, Engineer Retention, and the Bricklayer Fallacy Zwischenzug and zugzwang in chess Ian’s books: Learn Bash The Hard Way Learn Git The Hard Way Learn Terraform The Hard Way All three in a bundle Docker in Practice Tcl Why are enterprises so slow? Erlang Episode 164, with Daniel Walsh ‘AWS vs K8s' is the new ‘Windows vs Linux' The Runbooks Project ITIL Consultancy: Episode 183, with Steve Wade Why it’s great to be a consultant Container Solutions Finance topologies: Team Topologies by Manuel Pais and Matthew Skelton If You Want To Transform IT, Start With Finance Conway’s Law Ian Miell on Twitter

About ChrisChris Short has been a proponent of open source solutions throughout his over two decades in various IT disciplines, including systems, security, networks, DevOps management, and cloud native advocacy across the public and private sectors. He currently works on the Kubernetes team at Amazon Web Services and is an active Kubernetes contributor and Co-chair of OpenGitOps. Chris is a disabled US Air Force veteran living with his wife and son in Greater Metro Detroit. Chris writes about Cloud Native, DevOps, and other topics at ChrisShort.net. He also runs the Cloud Native, DevOps, GitOps, Open Source, industry news, and culture focused newsletter DevOps'ish.Links Referenced: DevOps'ish: https://devopsish.com/ EKS News: https://eks.news/ Containers from the Couch: https://containersfromthecouch.com opengitops.dev: https://opengitops.dev ChrisShort.net: https://chrisshort.net Twitter: https://twitter.com/ChrisShort TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, 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: Welcome to Screaming in the Cloud. I'm Corey Quinn. Coming back to us since episode two—it's always nice to go back and see the where are they now type of approach—I am joined by Senior Developer Advocate at AWS Chris Short. Chris, been a few years. How has it been?Chris: Ha. Corey, we have talked outside of the podcast. But it's been good. For those that have been listening, I think when we recorded I wasn't even—like, when was season two, what year was that? [laugh].Corey: Episode two was first pre-pandemic and the rest. I believe—Chris: Oh. So, yeah. I was at Red Hat, maybe, when I—yeah.Corey: Yeah. You were doing Red Hat stuff, back when you got to work on open-source stuff, as opposed to now, where you're not within 1000 miles of that stuff, right?Chris: Actually well, no. So, to be clear, I'm on the EKS team, the Kubernetes team here at AWS. So, when I joined AWS in October, they were like, “Hey, you do open-source stuff. We like that. Do more.” And I was like, “Oh, wait, do more?” And they were like, “Yes, do more.” “Okay.”So, since joining AWS, I've probably done more open-source work than the three years at Red Hat that I did. So, that's kind of—you know, like, it's an interesting point when I talk to people about it because the first couple months are, like—you know, my friends are like, “So, are you liking it? Are you enjoying it? What's going on?” And—Corey: Do they beat you with reeds? Like, all the questions people have about companies? Because—Chris: Right. Like, I get a lot of random questions about Amazon and AWS that I don't know the answer to.Corey: Oh, when I started telling people, I fixed Amazon bills, I had to quickly pivot that to AWS bills because people started asking me, “Well, can you save me money on underpants?” It's I—Chris: Yeah.Corey: How do you—fine. Get the prime credit card. It docks 5% off the bill, so there you go. But other than that, no, I can't.Chris: No.Corey: It's—Chris: Like, I had to call my bank this morning about a transaction that I didn't recognize, and it was from Amazon. And I was like, that's weird. Why would that—Corey: Money just flows one direction, and that's the wrong direction from my employer.Chris: Yeah. Like, what is going on here? It shouldn't have been on that card kind of thing. And I had to explain to the person on the phone that I do work at Amazon but under the Web Services team. And he was like, “Oh, so you're in IT?”And I'm like, “No.” [laugh]. “It's actually this big company. That—it's a cloud company.” And they're like, “Oh, okay, okay. Yeah. The cloud. Got it.” [laugh]. So, it's interesting talking to people about, “I work at Amazon.” “Oh, my son works at Amazon distribution center,” blah, blah, blah. It's like, cool. “I know about that, but very little. I do this.”Corey: Your son works in Amazon distribution center. Is he a robot? Is normally my next question on that? Yeah. That's neither here nor there.So, you and I started talking a while back. We both write newsletters that go to a somewhat similar audience. You write DevOps'ish. I write Last Week in AWS. And recently, you also have started EKS News because, yeah, the one thing I look at when I'm doing these newsletters every week is, you know what I want to do? That's right. Write more newsletters.Chris: [laugh].Corey: So, you are just a glutton for punishment? And, yeah, welcome to the addiction, I suppose. How's it been going for you?Chris: It's actually been pretty interesting, right? Like, we haven't pushed it very hard. We're now starting to include it in things. Like we did Container Day; we made sure that EKS news was on the landing page for Container Day at KubeCon EU. And you know, it's kind of just grown organically since then.But it was one of those things where it's like, internally—this happened at Red Hat, right—when I started live streaming at Red Hat, the ultimate goal was to do our product management—like, here's what's new in the next version thing—do those live so anybody can see that at any point in time anywhere on Earth, the second it's available. Similar situation to here. This newsletter actually is generated as part of a report my boss puts together to brief our other DAs—or developer advocates—you know, our solutions architects, the whole nine yards about new EKS features. So, I was like, why can't we just flip that into a weekly newsletter, you know? Like, I can pull from the same sources you can.And what's interesting is, he only does the meeting bi-weekly. So, there's some weeks where it's just all me doing it and he ends up just kind of copying and pasting the newsletter into his document, [laugh] and then adds on for the week. But that report meeting for that team is now getting disseminated to essentially anyone that subscribes to eks.news. Just go to the site, there's a subscribe thing right there. And we've gotten 20 issues in and it's gotten rave reviews, right?Corey: I have been a subscriber for a while. I will say that it has less Chris Short personality—Chris: Mm-hm.Corey: —to it than DevOps'ish does, which I have to assume is by design. A lot of The Duckbill Group's marketing these days is no longer in my voice, rather intentionally, because it turns out that being a sarcastic jackass and doing half-billion dollar AWS contracts can not to be the most congruent thing in the world. So okay, we're slowly ameliorating that. It's professional voice versus snarky voice.Chris: Well, and here's the thing, right? Like, I realized this year with DevOps'ish that, like, if I want to take a week off, I have to do, like, what you did when your child was born. You hired folks to like, do the newsletter for you, or I actually don't do the newsletter, right? It's binary: hire someone else to do it, or don't do it. So, the way I structured this newsletter was that any developer advocate on my team could jump in and take over the newsletter so that, you know, if I'm off that week, or whatever may be happening, I, Chris Short, am not the voice. It is now the entire developer advocate team.Corey: I will challenge you on that a bit. Because it's not Chris Short voice, that's for sure, but it's also not official AWS brand voice either.Chris: No.Corey: It is clearly written by a human being who is used to communicating with the audience for whom it is written. And that is no small thing. Normally, when oh, there's a corporate newsletter; that's just a lot of words to say it's bad. This one is good. I want to be very clear on that.Chris: Yeah, I mean, we have just, like, DevOps'ish, we have sections, just like your newsletter, there's certain sections, so any new, what's new announcements, those go in automatically. So, like, that can get delivered to your inbox every Friday. Same thing with new blog posts about anything containers related to EKS, those will be in there, then Containers from the Couch, our streaming platform, essentially, for all things Kubernetes. Those videos go in.And then there's some ecosystem news as well that I collect and put in the newsletter to give people a broader sense of what's going on out there in Kubernetes-land because let's face it, there's upstream and then there's downstream, and sometimes those aren't in sync, and that's normal. That's how Kubernetes kind of works sometimes. If you're running upstream Kubernetes, you are awesome. I appreciate you, but I feel like that would cause more problems and it's worse sometimes.Corey: Thank you for being the trailblazers. The rest of us can learn from your misfortune.Chris: [laugh]. Yeah, exactly. Right? Like, please file your bugs accordingly. [laugh].Corey: EKS is interesting to me because I don't see a lot of it, which is, probably, going to get a whole lot of, “Wait, what?” Moments because wait, don't you deal with very large AWS bills? And I do. But what I mean by that is that EKS, until you're using its Fargate expression, charges for the control plane, which rounds to no money, and the rest is running on EC2 instances running in a company's account. From the billing perspective, there is no difference between, “We're running massive fleets of EKS nodes.” And, “We're managing a whole bunch of EC2 instances by hand.”And that feels like an interesting allegory for how Kubernetes winds up expressing itself to cloud providers. Because from a billing perspective, it just looks like one big single-tenant application that has some really strange behaviors internally. It gets very chatty across AZs when there's no reason to, and whatnot. And it becomes a very interesting study in how to expose aspects of what's going on inside of those containers and inside of the Kubernetes environment to the cloud provider in a way that becomes actionable. There are no good answers for this yet, but it's something I've been seeing a lot of. Like, “Oh, I thought you'd be running Kubernetes. Oh, wait, you are and I just keep forgetting what I'm looking at sometimes.”Chris: So, that's an interesting point. The billing is kind of like, yeah, it's just compute, right? So—Corey: And my insight into AWS and the way I start thinking about it is always from a billing perspective. That's great. It's because that means the more expensive the services, the more I know about it. It's like, “IAM. What is that?” Like, “Oh, I have no idea. It's free. How important could it be?” Professional advice: do not take that philosophy, ever.Chris: [laugh]. No. Ever. No.Corey: Security: it matters. Oh, my God. It's like you're all stars. Your IAM policy should not be. I digress.Chris: Right. Yeah. Anyways, so two points I want to make real quick on that is, one, we've recently released an open-source project called Carpenter, which is really cool in my purview because it looks at your Kubernetes file and says, “Oh, you want this to run on ARM instance.” And you can even go so far as to say, right, here's my limits, and it'll find an instance that fits those limits and add that to your cluster automatically. Run your pod on that compute as long as it needs to run and then if it's done, it'll downsize—eventually, kind of thing—your cluster.So, you can basically just throw a bunch of workloads at it, and it'll auto-detect what kind of compute you will need and then provision it for you, run it, and then be done. So, that is one-way folks are probably starting to save money running EKS is to adopt Carpenter as your autoscaler as opposed to the inbuilt Kubernetes autoscaler. Because this is instance-aware, essentially, so it can say, like, “Oh, your massive ARM application can run here,” because you know, thank you, Graviton. We have those processors in-house. And you know, you can run your ARM64 instances, you can run all the Intel workloads you want, and it'll right size the compute for your workloads.And I'll look at one container or all your containers, however you want to configure it. Secondly, the good folks over at Kubecost have opencost, which is the open-source version of Kubecost, basically. So, they have a service that you can run in your clusters that will help you say, “Hey, maybe this one notes too heavy; maybe this one notes too light,” and you know, give you some insights into Kubernetes spend that are a little bit more granular as far as usage and things like that go. So, those two projects right there, I feel like, will give folks an optimal savings experience when it comes to Kubernetes. But to your point, it's just compute, right? And that's really how we treat it, kind of, here internally is that it's a way to run… compute, Kubernetes, or ECS, or any of those tools.Corey: A fairly expensive one because ignoring entirely for a second the actual raw cost of compute, you also have the other side of it, which is in every environment, unless you are doing something very strange or pre-funding as a one-person startup in your spare time, your payroll costs will it—should—exceed your AWS bill by a fairly healthy amount. And engineering time is always more expensive than services time. So, for example, looking at EKS, I would absolutely recommend people use that rather than rolling their own because—Chris: Rolling their own? Yeah.Corey: —get out of that engineering space where your time is free. I assure you from a business context, it is not. So, there's always that question of what you can do to make things easier for people and do more of the heavy lifting.Chris: Yeah, and to your rather cheeky point that there's 17 ways to run a container on AWS, it is answering that question, right? Like those 17 ways, like, how much of this do you want to run yourself, you could run EKS distro on EC2 instances if you want full control over your environment.Corey: And then run IoT Greengrass core on top within that cluster—Chris: Right.Corey: So, I can run my own Lambda function runtime, so I'm not locked in. Also, DynamoDB local so I'm not locked into AWS. At which point I have gone so far around the bend, no one can help me.Chris: Well—Corey: Pro tip, don't do that. Just don't do that.Chris: But to your point, we have all these options for compute, and specifically containers because there's a lot of people that want to granularly say, “This is where my engineering team gets involved. Everything else you handle.” If I want EKS on Spot Instances only, you can do that. If you want EKS to use Carpenter and say only run ARM workloads, you can do that. If you want to say Fargate and not have anything to manage other than the container file, you can do that.It's how much does your team want to manage? That's the customer obsession part of AWS coming through when it comes to containers is because there's so many different ways to run those workloads, but there's so many different ways to make sure that your team is right-sized, based off the services you're using.Corey: I do want to change gears a bit here because you are mostly known for a couple of things: the DevOps'ish newsletter because that is the oldest and longest thing you've been doing the time that I've known you; EKS, obviously. But when prepping for this show, I discovered you are now co-chair of the OpenGitOps project.Chris: Yes.Corey: So, I have heard of GitOps in the context of, “Oh, it's just basically your CI/CD stuff is triggered by Git events and whatnot.” And I'm sitting here going, “Okay, so from where you're sitting, the two best user interfaces in the world that you have discovered are YAML and Git.” And I just have to start with the question, “Who hurt you?”Chris: [laugh]. Yeah, I share your sentiment when it comes to Git. Not so much with YAML, but I think it's because I'm so used to it. Maybe it's Stockholm Syndrome, maybe the whole YAML thing. I don't know.Corey: Well, it's no XML. We'll put it that way.Chris: Thankfully, yes because if it was, I would have way more, like, just template files laying around to build things. But the—Corey: And rage. Don't forget rage.Chris: And rage, yeah. So, GitOps is a little bit more than just Git in IaC—infrastructure as Code. It's more like Justin Garrison, who's also on my team, he calls it infrastructure software because there's four main principles to GitOps, and if you go to opengitops.dev, you can see them. It's version one.So, we put them on the website, right there on the page. You have to have a declared state and that state has to live somewhere. Now, it's called GitOps because Git is probably the most full-featured thing to put your state in, but you could use an S3 bucket and just version it, for example. And make it private so no one else can get to it.Corey: Or you could use local files: copy-of-copy-of-this-thing-restored-parentheses-use-this-one-dot-final-dot-doc-dot-zip. You know, my preferred naming convention.Chris: Ah, yeah. Wow. Okay. [laugh]. Yeah.Corey: Everything I touch is terrifying.Chris: Yes. Geez, I'm sorry. So first, it's declarative. You declare your state. You store it somewhere. It's versioned and immutable, like I said. And then pulled automatically—don't focus so much on pull—but basically, software agents are applying the desired state from source. So, what does that mean? When it's—you know, the fourth principle is implemented, continuously reconciled. That means those software agents that are checking your desired state are actually putting it back into the desired state if it's out of whack, right? So—Corey: You're talking about agents running it persistently on instances, validating—Chris: Yes.Corey: —a checkpoint on a cron. How is this meaningfully different than a Puppet agent running in years past? Having spent I learned to speak publicly by being a traveling trainer for Puppet; same type of model, and in fact, when I was at Pinterest, we wound up having a fair bit—like, that was their entire model, where they would have—the Puppet's code would live in an S3 bucket that was then copied down, I believe, via Git, and then applied to the instance on a schedule. Like, that sounds like this was sort of a early days GitOps.Chris: Yeah, exactly. Right? Like so it's, I like to think of that as a component of GitOps, right? DevOps, when you talk about DevOps in general, there's a lot of stuff out there. There's a lot of things labeled DevOps that maybe are, or maybe aren't sticking to some of those DevOps core things that make you great.Like the stuff that Nicole Forsgren writes about in books, you know? Accelerate is on my desk for a reason because there's things that good, well-managed DevOps practices do. I see GitOps as an actual implementation of DevOps in an open-source manner because all the tooling for GitOps these days is open-source and it all started as open-source. Now, you can get, like, Flux or Argo—Argo, specifically—there's managed services out there for it, you can have Flux and not maintain it, through an add-on, on EKS for example, and it will reconcile that state for you automatically. And the other thing I like to say about GitOps, specifically, is that it moves at the speed of the Kubernetes Audit Log.If you've ever looked at a Kubernetes audit log, you know it's rather noisy with all these groups and versions and kinds getting thrown out there. So, GitOps will say, “Oh, there's an event for said thing that I'm supposed to be watching. Do I need to change anything? Yes or no? Yes? Okay, go.”And the change gets applied, or, “Hey, there's a new Git thing. Pull it in. A change has happened inGit I need to update it.” You can set it to reconcile on events on time. It's like a cron or it's like an event-driven architecture, but it's combined.Corey: How does it survive the stake through the heart of configuration management? Because before I was doing all this, I wasn't even a T-shaped engineer: you're broad across a bunch of things, but deep in one or two areas, and one of mine was configuration management. I wrote part of SaltStack, once upon a time—Chris: Oh.Corey: —due to a bunch of very strange coincidences all hitting it once, like, I taught people how to use Puppet. But containers ultimately arose and the idea of immutable infrastructure became a thing. And these days when we were doing full-on serverless, well, great, I just wind up deploying a new code bundle to the Lambdas function that I wind up caring about, and that is a immutable version replacement. There is no drift because there is no way to log in and change those things other than through a clear deployment of this as the new version that goes out there. Where does GitOps fit into that imagined pattern?Chris: So, configuration management becomes part of your approval process, right? So, you now are generating an audit log, essentially, of all changes to your system through the approval process that you set up as part of your, how you get things into source and then promote that out to production. That's kind of the beauty of it, right? Like, that's why we suggest using Git because it has functions, like, requests and issues and things like that you can say, “Hey, yes, I approve this,” or, “Hey, no, I don't approve that. We need changes.” So, that's kind of natively happening with Git and, you know, GitLab, GitHub, whatever implementation of Git. There's always, kind of—Corey: Uh, JIF-ub is, I believe, the pronunciation.Chris: JIF-ub? Oh.Corey: Yeah. That's what I'm—Chris: Today, I learned. Okay.Corey: Exactly. And that's one of the things that I do for my lasttweetinaws.com Twitter client that I build—because I needed it, and if other people want to use it, that's great—that is now deployed to 20 different AWS commercial regions, simultaneously. And that is done via—because it turns out that that's a very long to execute for loop if you start down that path—Chris: Well, yeah.Corey: I wound up building out a GitHub Actions matrix—sorry a JIF-ub—actions matrix job that winds up instantiating 20 parallel builds of the CDK deploy that goes out to each region as expected. And because that gets really expensive with native GitHub Actions runners for, like, 36 cents per deploy, and I don't know how to test my own code, so every time I have a typo, that's another quarter in the jar. Cool, but that was annoying for me so I built my own custom runner system that uses Lambda functions as runners running containers pulled from ECR that, oh, it just runs in parallel, less than three minutes. Every time I commit something between I press the push button and it is out and running in the wild across all regions. Which is awesome and also terrifying because, as previously mentioned, I don't know how to test my code.Chris: Yeah. So, you don't know what you're deploying to 20 regions sometime, right?Corey: But it also means I have a pristine, re-composable build environment because I can—Chris: Right.Corey: Just automatically have that go out and the fact that I am making a—either merging a pull request or doing a direct push because I consider main to be my feature branch as whenever something hits that, all the automation kicks off. That was something that I found to be transformative as far as a way of thinking about this because I was very tired of having to tweak my local laptop environment to, “Oh, you didn't assume the proper role and everything failed again and you broke it. Good job.” It wound up being something where I could start developing on more and more disparate platforms. And it finally is what got me away from my old development model of everything I build is on an EC2 instance, and that means that my editor of choice was Vim. I use the VS Code now for these things, and I'm pretty happy with it.Chris: Yeah. So, you know, I'm glad you brought up CDK. CDK gives you a lot of the capabilities to implement GitOps in a way that you could say, like, “Hey, use CDK to declare I need four Amazon EKS clusters with this size, shape, and configuration. Go.” Or even further, connect to these EKS clusters to RDS instances and load balancers and everything else.But you put that state into Git and then you have something that deploys that automatically upon changes. That is infrastructure as code. Now, when you say, “Okay, main is your feature branch,” you know, things happen on main, if this were running in Kubernetes across a fleet of clusters or the globe-wide in 20 regions, something like Flux or Argo would kick in and say, “There's been a change to source, main, and we need to roll this out.” And it'll start applying those changes. Now, what do you get with GitOps that you don't get with your configuration?I mean, can you rollback if you ever have, like, a bad commit that's just awful? I mean, that's really part of the process with GitOps is to make sure that you can, A, roll back to the previous good state, B, roll forward to a known good state, or C, promote that state up through various environments. And then having that all done declaratively, automatically, and immutably, and versioned with an audit log, that I think is the real power of GitOps in the sense that, like, oh, so-and-so approve this change to security policy XYZ on this date at this time. And that to an auditor, you just hand them a log file on, like, “Here's everything we've ever done to our system. Done.” Right?Like, you could get to that state, if you want to, which I think is kind of the idea of DevOps, which says, “Take all these disparate tools and processes and procedures and culture changes”—culture being the hardest part to adopt in DevOps; GitOps kind of forces a culture change where, like, you can't do a CAB with GitOps. Like, those two things don't fly. You don't have a configuration management database unless you absolutely—Corey: Oh, you CAB now but they're all the comments of the pull request.Chris: Right. Exactly. Like, don't push this change out until Thursday after this other thing has happened, kind of thing. Yeah, like, that all happens in GitHub. But it's very democratizing in the sense that people don't have to waste time in an hour-long meeting to get their five minutes in, right?Corey: DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, confidence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud slash C-H-R-O-N-O-S-P-H-E-R-E.Corey: So, would it be overwhelmingly cynical to suggest that GitOps is the means to implement what we've all been pretending to have implemented for the last decade when giving talks at conferences?Chris: Ehh, I wouldn't go that far. I would say that GitOps is an excellent way to implement the things you've been talking about at all these conferences for all these years. But keep in mind, the technology has changed a lot in the, what 11, 12 years of the existence of DevOps, now. I mean, we've gone from, let's try to manage whole servers immutably to, “Oh, now we just need to maintain an orchestration platform and run containers.” That whole compute interface, you go from SSH to a Docker file, that's a big leap, right?Like, you don't have bespoke sysadmins; you have, like, a platform team. You don't have DevOps engineers; they're part of that platform team, or DevOps teams, right? Like, which was kind of antithetical to the whole idea of DevOps to have a DevOps team. You know, everybody's kind of in the same boat now, where we see skill sets kind of changing. And GitOps and Kubernetes-land is, like, a platform team that manages the cluster, and its state, and health and, you know, production essentially.And then you have your developers deploying what they want to deploy in when whatever namespace they've been given access to and whatever rights they have. So, now you have the potential for one set of people—the platform team—to use one set of GitOps tooling, and your applications teams might not like that, and that's fine. They can have their own namespaces with their own tooling in it. Like, Argo, for example, is preferred by a lot of developers because it has a nice UI with green and red dots and they can show people and it looks nice, Flux, it's command line based. And there are some projects out there that kind of take the UI of Argo and try to run Flux underneath that, and those are cool kind of projects, I think, in my mind, but in general, right, I think GitOps gives you the choice that we missed somewhat in DevOps implementations of the past because it was, “Oh, we need to go get cloud.” “Well, you can only use this cloud.” “Oh, we need to go get this thing.” “Well, you can only use this thing in-house.”And you know, there's a lot of restrictions sometimes placed on what you can use in your environment. Well, if your environment is Kubernetes, how do you restrict what you can run, right? Like you can't have an easily configured say, no open-source policy if you're running Kubernetes. [laugh] so it becomes, you know—Corey: Well, that doesn't stop some companies from trying.Chris: Yeah, that's true. But the idea of, like, enabling your developers to deploy at will and then promote their changes as they see fit is really the dream of DevOps, right? Like, same with production and platform teams, right? I want to push my changes out to a larger system that is across the globe. How do I do that? How do I manage that? How do I make sure everything's consistent?GitOps gives you those ways, with Kubernetes native things like customizations, to make consistent environments that are robust and actually going to be reconciled automatically if someone breaks the glass and says, “Oh, I need to run this container immediately.” Well, that's going to create problems because it's deviated from state and it's just that one region, so we'll put it back into state.Corey: It'll be dueling banjos, at some point. You'll try and doing something manually, it gets reverted automatically. I love that pattern. You'll get bored before the computer does, always.Chris: Yeah. And GitOps is very new, right? When you think about the lifetime of GitOps, I think it was coined in, like, 2018. So, it's only four years old, right? When—Corey: I prefer it to ChatOps, at least, as far as—Chris: Well, I mean—Corey: —implementation and expression of the thing.Chris: —ChatOps was a way to do DevOps. I think GitOps—Corey: Well, ChatOps is also a way to wind up giving whoever gets access to your Slack workspace root in production.Chris: Mmm.Corey: But that's neither here nor there.Chris: Mm-hm.Corey: It's yeah, we all like to pretend that's not a giant security issue in our industry, but that's a topic for another time.Chris: Yeah. And that's why, like, GitOps also depends upon you having good security, you know, and good authorization and approval processes. It enforces that upon—Corey: Yeah, who doesn't have one of those?Chris: Yeah. If it's a sole operation kind of deal, like in your setup, your case, I think you kind of got it doing right, right? Like, as far as GitOps goes—Corey: Oh, to be clear, we are 11 people and we do have dueling pull requests and all the rest.Chris: Right, right, right.Corey: But most of the stuff I talk about publicly is not our production stuff, so it really is just me. Just as a point of clarity there. I've n—the 11 people here do not all—the rest of you don't just sit there and clap as I do all the work.Chris: Right.Corey: Most days.Chris: No, I'm sure they don't. I'm almost certain they don't clap… for you. I mean, they would—Corey: No. No, they try and talk me out of it in almost every case.Chris: Yeah, exactly. So, the setup that you, Corey Quinn, have implemented to deploy these 20 regions is kind of very GitOps-y, in the sense that when main changes, it gets updated. Where it's not GitOps-y is what if the endpoint changes? Does it get reconciled? That's the piece you're probably missing is that continuous reconciliation component, where it's constantly checking and saying, “This thing out there is deployed in the way I want it. You know, the way I declared it to be in my source of truth.”Corey: Yeah, when you start having other people getting involved, there can—yeah, that's where regressions enter. And it's like, “Well, I know where things are so why would I change the endpoint?” Yeah, it turns out, not everyone has the state of the entire application in their head. Ideally it should live in—Chris: Yeah. Right. And, you know—Corey: —you know, Git or S3.Chris: —when I—yeah, exactly. When I think about interactions of the past coming out as a new DevOps engineer to work with developers, it's always been, will developers have access to prod or they don't? And if you're in that environment with—you're trying to run a multi-billion dollar operation, and your devs have direct—or one Dev has direct access to prod because prod is in his brain, that's where it's like, well, now wait a minute. Prod doesn't have to be only in your brain. You can put that in the codebase and now we know what is in your brain, right?Like, you can almost do—if you document your code, well, you can have your full lifecycle right there in one place, including documentation, which I think is the best part, too. So, you know, it encourages approval processes and automation over this one person has an entire state of the system in their head; they have to go in and fix it. And what if they're not on call, or in Jamaica, or on a cruise ship somewhere kind of thing? Things get difficult. Like, for example, I just got back from vacation. We were so far off the grid, we had satellite internet. And let me tell you, it was hard to write an email newsletter where I usually open 50 to 100 tabs.Corey: There's a little bit of internet out Californ-ie way.Chris: [laugh].Corey: Yeah it's… it's always weird going from, like, especially after pandemic; I have gigabit symmetric here and going even to re:Invent where I'm trying to upload a bunch of video and whatnot.Chris: Yeah. Oh wow.Corey: And the conference WiFi was doing its thing, and well, Verizon 5G was there but spotty. And well, yeah. Usual stuff.Chris: Yeah. It's amazing to me how connectivity has become so ubiquitous.Corey: To the point where when it's not there anymore, it's what do I do with myself? Same story about people pushing back against remote development of, “Oh, I'm just going to do it all on my laptop because what happens if I'm on a plane?” It's, yeah, the year before the pandemic, I flew 140,000 miles domestically and I was almost never hamstrung by my ability to do work. And my only local computer is an iPad for those things. So, it turns out that is less of a real world concern for most folks.Chris: Yeah I actually ordered the components to upgrade an old Nook that I have here and turn it into my, like, this is my remote code server, that's going to be all attached to GitHub and everything else. That's where I want to be: have Tailscale and just VPN into this box.Corey: Tailscale is transformative.Chris: Yes. Tailscale will change your life. That's just my personal opinion.Corey: Yep.Chris: That's not an AWS opinion or anything. But yeah, when you start thinking about your network as it could be anywhere, that's where Tailscale, like, really shines. So—Corey: Tailscale makes the internet work like we all wanted to believe that it worked.Chris: Yeah. And Wireguard is an excellent open-source project. And Tailscale consumes that and puts an amazingly easy-to-use UI, and troubleshooting tools, and routing, and all kinds of forwarding capabilities, and makes it kind of easy, which is really, really, really kind of awesome. And Tailscale and Kubernetes—Corey: Yeah, ‘network' and ‘easy' don't belong in the same sentence, but in this case, they do.Chris: Yeah. And trust me, the Kubernetes story in Tailscale, there is a lot of there. I understand you might want to not open ports in your VPC, maybe, but if you use Tailscale, that node is just another thing on your network. You can connect to that and see what's going on. Your management cluster is just another thing on the network where you can watch the state.But it's all—you're connected to it continuously through Tailscale. Or, you know, it's a much lighter weight, kind of meshy VPN, I would say, if I had to sum it up in one sentence. That was not on our agenda to talk about at all. Anyways. [laugh]Corey: No, no. I love how many different topics we talk about on these things. We'll have to have you back soon to talk again. I really want to thank you for being so generous with your time. If people want to learn more about what you're up to and how you view these things, where can they find you?Chris: Go to ChrisShort.net. So, Chris Short—I'm six-four so remember, it's Short—dot net, and you will find all the places that I write, you can go to devopsish.com to subscribe to my newsletter, which goes out every week. This year. Next year, there'll be breaks. And then finally, if you want to follow me on Twitter, Chris Short: at @ChrisShort on Twitter. All one word so you see two s's. Like, it's okay, there's two s's there.Corey: Links to all of that will of course be in the show notes. It's easier for people to do the clicky-clicky thing as a general rule.Chris: Clicky things are easier than the wordy things, yes.Corey: Says the Kubernetes guy.Chris: Yeah. Says the Kubernetes guy. Yeah, you like that, huh? Like I said, Argo gives you a UI. [laugh].Corey: Thank you [laugh] so much for your time. I really do appreciate it.Chris: Thank you. This has been fun. If folks have questions, feel free to reach out. Like, I am not one of those people that hides behind a screen all day and doesn't respond. I will respond to you eventually.Corey: I'm right here, Chris. Come on, come on. You're calling me out in front of myself. My God.Chris: Egh. It might take a day or two, but I will respond. I promise.Corey: Thanks again for your time. This has been Chris Short, senior developer advocate at AWS. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice and if it's YouTube, click the thumbs-up button. Whereas if you've hated this podcast, same thing, smash the buttons five-star review and leave an insulting comment that is written in syntactically correct YAML because it's just so easy to do.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Your hemispheric hosts are joined by Anthony Agius from online newsletter The Sizzle, who explains his work and the importance of different news sources in tech. Not to mention, we properly announce the winner of Arcadia June 2022 and Andrew shares his advanced theory for improving your chances of finding a soulmate. ✍️

A conversation with Ronna Steinberg, who was an OOP developer for many years, and now is a Go Google Developer Expert. Ronna has been thinking about Go and OOP for awhile, asking herself whether or not Go is an object oriented programming language. Tune in to find out her answer and hear some of the options gophers have for object oriented design.