Podcasts about serverless

  • 570PODCASTS
  • 1,897EPISODES
  • 40mAVG DURATION
  • 5WEEKLY NEW EPISODES
  • Nov 15, 2022LATEST

POPULARITY

20152016201720182019202020212022

Categories



Best podcasts about serverless

Show all podcasts related to serverless

Latest podcast episodes about serverless

Screaming in the Cloud
The Non-Magical Approach to Cloud-Based Development with Chen Goldberg

Screaming in the Cloud

Play Episode Listen Later Nov 15, 2022 40:13


About ChenChen Goldberg is GM and Vice President of Engineering at Google Cloud, where she leads the Cloud Runtimes (CR) product area, helping customers deliver greater value, effortlessly. The CR  portfolio includes both Serverless and Kubernetes based platforms on Google Cloud, private cloud and other public clouds. Chen is a strong advocate for customer empathy, building products and solutions that matter. Chen has been core to Google Cloud's open core vision since she joined the company six years ago. During that time, she has led her team to focus on helping development teams increase their agility and modernize workloads. Prior to joining Google, Chen wore different hats in the tech industry including leadership positions in IT organizations, SI teams and SW product development, contributing to Chen's broad enterprise perspective. She enjoys mentoring IT talent both in and outside of Google. Chen lives in Mountain View, California, with her husband and three kids. Outside of work she enjoys hiking and baking.Links Referenced: Twitter: https://twitter.com/GoldbergChen LinkedIn: https://www.linkedin.com/in/goldbergchen/ 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: Forget everything you know about SSH and try Tailscale. Imagine if you didn't need to manage PKI or rotate SSH keys every time someone leaves. That'd be pretty sweet, wouldn't it? With Tailscale SSH, you can do exactly that. Tailscale gives each server and user device a node key to connect to its VPN, and it uses the same node key to authorize and authenticate SSH.Basically you're SSHing the same way you manage access to your app. What's the benefit here? Built-in key rotation, permissions as code, connectivity between any two devices, reduce latency, and there's a lot more, but there's a time limit here. You can also ask users to reauthenticate for that extra bit of security. Sounds expensive?Nope, I wish it were. Tailscale is completely free for personal use on up to 20 devices. To learn more, visit snark.cloud/tailscale. Again, that's snark.cloud/tailscaleCorey: Welcome to Screaming in the Cloud, I'm Corey Quinn. When I get bored and the power goes out, I find myself staring at the ceiling, figuring out how best to pick fights with people on the internet about Kubernetes. Because, well, I'm basically sad and have a growing collection of personality issues. My guest today is probably one of the best people to have those arguments with. Chen Goldberg is the General Manager of Cloud Runtimes and VP of Engineering at Google Cloud. Chen, Thank you for joining me today.Chen: Thank you so much, Corey, for having me.Corey: So, Google has been doing a lot of very interesting things in the cloud, and the more astute listener will realize that interesting is not always necessarily a compliment. But from where I sit, I am deeply vested in the idea of a future where we do not have a cloud monoculture. As I've often said, I want, “What cloud should I build something on in five to ten years?” To be a hard question to answer, and not just because everything is terrible. I think that Google Cloud is absolutely a bright light in the cloud ecosystem and has been for a while, particularly with this emphasis around developer experience. All of that said, Google Cloud is sort of a big, unknowable place, at least from the outside. What is your area of responsibility? Where do you start? Where do you stop? In other words, what can I blame you for?Chen: Oh, you can blame me for a lot of things if you want to. I [laugh] might not agree with that, but that's—Corey: We strive for accuracy in these things, though.Chen: But that's fine. Well, first of all, I've joined Google about seven years ago to lead the Kubernetes and GKE team, and ever since, continued at the same area. So evolved, of course, Kubernetes, and Google Kubernetes Engine, and leading our hybrid and multi-cloud strategy as well with technologies like Anthos. And now I'm responsible for the entire container runtime, which includes Kubernetes and the serverless solutions.Corey: A while back, I, in fairly typical sarcastic form, wound up doing a whole inadvertent start of a meme where I joked about there being 17 ways to run containers on AWS. And then as that caught on, I wound up listing out 17 services you could use to do that. A few months went past and then I published a sequel of 17 more services you can use to run Kubernetes. And while that was admittedly tongue-in-cheek, it does lead to an interesting question that's ecosystem-wide. If I look at Google Cloud, I have Cloud Run, I have GKE, I have GCE if I want to do some work myself.It feels like more and more services are supporting Docker in a variety of different ways. How should customers and/or people like me—though, I am sort of a customer as well since I do pay you folks every month—how should we think about containers and services in which to run them?Chen: First of all, I think there's a lot of credit that needs to go to Docker that made containers approachable. And so, Google has been running containers forever. Everything within Google is running on containers, even our VMs, even our cloud is running on containers, but what Docker did was creating a packaging mechanism to improve developer velocity. So, that's on its own, it's great. And one of the things, by the way, that I love about Google Cloud approach to containers and Docker that yes, you can take your Docker container and run it anywhere.And it's actually really important to ensure what we call interoperability, or low barrier to entry to a new technology. So, I can take my Docker container, I can move it from one platform to another, and so on. So, that's just to start with on a containers. Between the different solutions, so first of all, I'm all about managed services. You are right, there are many ways to run a Kubernetes. I'm taking a lot of pride—Corey: The best way is always to have someone else run it for you. Problem solved. Great, the best kind of problems are always someone else's.Chen: Yes. And I'm taking a lot of pride of what our team is doing with Kubernetes. I mean, we've been working on that for so long. And it's something that you know, we've coined that term, I think back in 2016, so there is a success disaster, but there's also what we call sustainable success. So, thinking about how to set ourselves up for success and scale. Very proud of that service.Saying that, not everybody and not all your workloads you need the flexibility that Kubernetes gives you in all the ecosystem. So, if you start with containers your first time, you should start with Cloud Run. It's the easiest way to run your containers. That's one. If you are already in love with Kubernetes, we won't take it away from you. Start with GKE. Okay [laugh]? Go all-in. Okay, we are all in loving Kubernetes as well. But what my team and I are working on is to make sure that those will work really well together. And we actually see a lot of customers do that.Corey: I'd like to go back a little bit in history to the rise of Docker. I agree with you it was transformative, but containers had been around in various forms—depending upon how you want to define it—dating back to the '70s with logical partitions on mainframes. Well, is that a container? Is it not? Well, sort of. We'll assume yes for the sake of argument.The revelation that I found from Docker was the developer experience, start to finish. Suddenly, it was a couple commands and you were just working, where previously it had taken tremendous amounts of time and energy to get containers working in that same context. And I don't even know today whether or not the right way to contextualize containers is as sort of a lite version of a VM, as a packaging format, as a number of other things that you could reasonably call it. How do you think about containers?Chen: So, I'm going to do, first of all, a small [unintelligible 00:06:31]. I actually started my career as a system mainframe engineer—Corey: Hmm.Chen: And I will share that when you know, I've learned Kubernetes, I'm like, “Huh, we already have done all of that, in orchestration, in workload management on mainframe,” just to the side. The way I think about containers is as a—two things: one, it is a packaging of an application, but the other thing which is also critical is the decoupling between your application and the OS. So, having that kind of abstraction and allowing you to portable and move it between environments. So, those are the two things that are when I think about containers. And what technologies like Kubernetes and serverless gives on top of that is that manageability and making sure that we take care of everything else that is needed for you to run your application.Corey: I've been, how do I put this, getting some grief over the past few years, in the best ways possible, around a almost off-the-cuff prediction that I made, which was that in five years, which is now a lot closer to two, basically, nobody is going to care about Kubernetes. And I could have phrased that slightly more directly because people think I was trying to say, “Oh, Kubernetes is just hype. It's going to go away. Nobody's going to worry about it anymore.” And I think that is a wildly inaccurate prediction.My argument is that people are not going to have to think about it in the same way that they are today. Today, if I go out and want to go back to my days of running production services in anger—and by ‘anger,' I of course mean in production—then it would be difficult for me to find a role that did not at least touch upon Kubernetes. But people who can work with that technology effectively are in high demand and they tend to be expensive, not to mention then thinking about all of the intricacies and complexities that Kubernetes brings to the foreground, that is what doesn't feel sustainable to me. The idea that it's going to have to collapse down into something else is, by necessity, going to have to emerge. How are you seeing that play out? And also, feel free to disagree with the prediction. I am thrilled to wind up being told that I'm wrong it's how I learn the most.Chen: I don't know if I agree with the time horizon of when that will happen, but I will actually think it's a failure on us if that won't be the truth, that the majority of people will not need to know about Kubernetes and its internals. And you know, we keep saying that, like, hey, we need to make it more, like, boring, and easy, and I've just said like, “Hey, you should use managed.” And we have lots of customers that says that they're just using GKE and it scales on their behalf and they don't need to do anything for that and it's just like magic. But from a technology perspective, there is still a way to go until we can make that disappear.And there will be two things that will push us into that direction. One is—you mentioned that is as well—the talent shortage is real. All the customers that I speak with, even if they can find those great people that are experts, they're actually more interesting things for them to work on, okay? You don't need to take, like, all the people in your organization and put them on building the infrastructure. You don't care about that. You want to build innovation and promote your business.So, that's one. The second thing is that I do expect that the technology will continue to evolve and are managed solutions will be better and better. So hopefully, with these two things happening together, people will not care that what's under the hood is Kubernetes. Or maybe not even, right? I don't know exactly how things will evolve.Corey: From where I sit, what are the early criticisms I had about Docker, which I guess translates pretty well to Kubernetes, are that they solve a few extraordinarily painful problems. In the case of Docker, it was, “Well, it works on my machine,” as a grumpy sysadmin, the way I used to be, the only real response we had to that was, “Well. Time to backup your email, Skippy, because your laptop is going into production, then.” Now, you can effectively have a high-fidelity copy of production, basically anywhere, and we've solved the problem of making your Mac laptop look like a Linux server. Great, okay, awesome.With Kubernetes, it also feels, on some level, like it solves for very large-scale Google-type of problems where you want to run things across at least a certain point of scale. It feels like even today, it suffers from having an easy Hello World-style application to deploy on top of it. Using it for WordPress, or some other form of blogging software, for example, is stupendous overkill as far as the Hello World story tends to go. Increasingly as a result, it feels like it's great for the large-scale enterprise-y applications, but the getting started story of how do I have a service I could reasonably run in production? How do I contextualize that, in the world of Kubernetes? How do you respond to that type of perspective?Chen: We'll start with maybe a short story. I started my career in the Israeli army. I was head of the department and one of the lead technology units and I was responsible for building a PAS. In essence, it was 20-plus years ago, so we didn't really call it a PAS but that's what it was. And then at some point, it was amazing, developers were very productive, we got innovation again, again. And then there was some new innovation just at the beginning of web [laugh] at some point.And it was actually—so two things I've noticed back then. One, it was really hard to evolve the platform to allow new technologies and innovation, and second thing, from a developer perspective, it was like a black box. So, the developers team that people were—the other development teams couldn't really troubleshoot environment; they were not empowered to make decisions or [unintelligible 00:12:29] in the platform. And you know, when it was just started with Kubernetes—by the way, beginning, it only supported 100 nodes, and then 1000 nodes. Okay, it was actually not for scale; it actually solved those two problems, which I'm—this is where I spend most of my time.So, the first one, we don't want magic, okay? To be clear on, like, what's happening, I want to make sure that things are consistent and I can get the right observability. So, that's one. The second thing is that we invested so much in the extensibility an environment that it's, I wouldn't say it's easy, but it's doable to evolve Kubernetes. You can change the models, you can extend it you can—there is an ecosystem.And you know, when we were building it, I remember I used to tell my team, there won't be a Kubernetes 2.0. Which is for a developer, it's [laugh] frightening. But if you think about it and you prepare for that, you're like, “Huh. Okay, what does that mean with how I build my APIs? What does that mean of how we build a system?” So, that was one. The second thing I keep telling my team, “Please don't get too attached to your code because if it will still be there in 5, 10 years, we did something wrong.”And you can see areas within Kubernetes, again, all the extensions. I'm very proud of all the interfaces that we've built, but let's take networking. This keeps to evolve all the time on the API and the surface area that allows us to introduce new technologies. I love it. So, those are the two things that have nothing to do with scale, are unique to Kubernetes, and I think are very empowering, and are critical for the success.Corey: One thing that you said that resonates most deeply with me is the idea that you don't want there to be magic, where I just hand it to this thing and it runs it as if by magic. Because, again, we've all run things in anger in production, and what happens when the magic breaks? When you're sitting around scratching your head with no idea how it starts or how it stops, that is scary. I mean, I recently wound up re-implementing Google Cloud Distinguished Engineer Kelsey Hightower's “Kubernetes the Hard Way” because he gave a terrific tutorial that I ran through in about 45 minutes on top of Google Cloud. It's like, “All right, how do I make this harder?”And the answer is to do it on AWS, re-implement it there. And my experiment there can be found at kubernetesthemuchharderway.com because I have a vanity domain problem. And it taught me he an awful lot, but one of the challenges I had as I went through that process was, at one point, the nodes were not registering with the controller.And I ran out of time that day and turned everything off—because surprise bills are kind of what I spend my time worrying about—turn it on the next morning to continue and then it just worked. And that was sort of the spidey sense tingling moment of, “Okay, something wasn't working and now it is, and I don't understand why. But I just rebooted it and it started working.” Which is terrifying in the context of a production service. It was understandable—kind of—and I think that's the sort of thing that you understand a lot better, the more you work with it in production, but a counterargument to that is—and I've talked about it on this show before—for this podcast, I wind up having sponsors from time to time, who want to give me fairly complicated links to go check them out, so I have the snark.cloud URL redirector.That's running as a production service on top of Google Cloud Run. It took me half an hour to get that thing up and running; I haven't had to think about it since, aside from a three-second latency that was driving me nuts and turned out to be a sleep hidden in the code, which I can't really fault Google Cloud Run for so much as my crappy nonsense. But it just works. It's clearly running atop Kubernetes, but I don't have to think about it. That feels like the future. It feels like it's a glimpse of a world to come, we're just starting to dip our toes into. That, at least to me, feels like a lot more of the abstractions being collapsed into something easily understandable.Chen: [unintelligible 00:16:30], I'm happy you say that. When talking with customers and we're showing, like, you know, yes, they're all in Kubernetes and talking about Cloud Run and serverless, I feel there is that confidence level that they need to overcome. And that's why it's really important for us in Google Cloud is to make sure that you can mix and match. Because sometimes, you know, a big retail customer of ours, some of their teams, it's really important for them to use a Kubernetes-based platform because they have their workloads also running on-prem and they want to serve the same playbooks, for example, right? How do I address issues, how do I troubleshoot, and so on?So, that's one set of things. But some cloud only as simple as possible. So, can I use both of them and still have a similar developer experience, and so on? So, I do think that we'll see more of that in the coming years. And as the technology evolves, then we'll have more and more, of course, serverless solutions.By the way, it doesn't end there. Like, we see also, you know, databases and machine learning, and like, there are so many more managed services that are making things easy. And that's what excites me. I mean, that's what's awesome about what we're doing in cloud. We are building platforms that enable innovation.Corey: I think that there's an awful lot of power behind unlocking innovation from a customer perspective. The idea that I can use a cloud provider to wind up doing an experiment to build something in the course of an evening, and if it works, great, I can continue to scale up without having to replace, you know, the crappy Raspberry Pi-level hardware in my spare room with serious enterprise servers in a data center somewhere. The on-ramp and the capability and the lack of long-term commitments is absolutely magical. What I'm also seeing that is contributing to that is the de facto standard that's emerged of most things these days support Docker, for better or worse. There are many open-source tools that I see where, “Oh, how do I get this up and running?”“Well, you can go over the river and through the woods and way past grandmother's house to build this from source or run this Docker file.” I feel like that is the direction the rest of the world is going. And as much fun as it is to sit on the sidelines and snark, I'm finding a lot more capability stories emerging across the board. Does that resonate with what you're seeing, given that you are inherently working at very large scale, given the [laugh] nature of where you work?Chen: I do see that. And I actually want to double down on the open standards, which I think this is also something that is happening. At the beginning, we talked about I want it to be very hard when I choose the cloud provider. But innovation doesn't only come from cloud providers; there's a lot of companies and a lot of innovation happening that are building new technologies on top of those cloud providers, and I don't think this is going to stop. Innovation is going to come from many places, and it's going to be very exciting.And by the way, things are moving super fast in our space. So, the investment in open standard is critical for our industry. So, Docker is one example. Google is in [unintelligible 00:19:46] speaking, it's investing a lot in building those open standards. So, we have Docker, we have things like of course Kubernetes, but we are also investing in open standards of security, so we are working with other partners around [unintelligible 00:19:58], defining how you can secure the software supply chain, which is also critical for innovation. So, all of those things that reduce the barrier to entry is something that I'm personally passionate about.Corey: Scaling containers and scaling Kubernetes is hard, but a whole ‘nother level of difficulty is scaling humans. You've been at Google for, as you said, seven years and you did not start as a VP there. Getting promoted from Senior Director to VP at Google is a, shall we say, heavy lift. You also mentioned that you previously started with, I believe, it was a seven-person team at one point. How have you been able to do that? Because I can see a world in which, “Oh, we just write some code and we can scale the computers pretty easily,” I've never found a way to do that for people.Chen: So yes, I started actually—well not 7, but the team was 30 people [laugh]. And you can imagine how surprised I was when I joining Google Cloud with Kubernetes and GKE and it was a pretty small team, to the beginning of those days. But the team was already actually on the edge of burning out. You know, pings on Slack, the GitHub issues, there was so many things happening 24/7.And the thing was just doing everything. Everybody were doing everything. And one of the things I've done on my second month on the team—I did an off-site, right, all managers; that's what we do; we do off-sites—and I brought the team in to talk about—the leadership team—to talk about our team values. And in the beginning, they were a little bit pissed, I would say, “Okay, Chen. What's going on? You're wasting two days of our lives to talk about those things. Why we are not doing other things?”And I was like, “You know guys, this is really important. Let's talk about what's important for us.” It was an amazing it worked. By the way, that work is still the foundation of the culture in the team. We talked about the three values that we care about and how that will look like.And the reason it's important is that when you scale teams, the key thing is actually to scale decision-making. So, how do you scale decision-making? I think there are two things there. One is what you're trying to achieve. So, people should know and understand the vision and know where we want to get to.But the second thing is, how do we work? What's important for us? How do we prioritize? How do we make trade-offs? And when you have both the what we're trying to do and the how, you build that team culture. And when you have that, I find that you're set up more for success for scaling the team.Because then the storyteller is not just the leader or the manager. The entire team is a storyteller of how things are working in this team, how do we work, what you're trying to achieve, and so on. So, that's something that had been a critical. So, that's just, you know, from methodology of how I think it's the right thing to scale teams. Specifically, with a Kubernetes, there were more issues that we needed to work on.For example, building or [recoding 00:23:05] different functions. It cannot be just engineering doing everything. So, hiring the first product managers and information engineers and marketing people, oh my God. Yes, you have to have marketing people because there are so many events. And so, that was one thing, just you know, from people and skills.And the second thing is that it was an open-source project and a product, but what I was personally doing, I was—with the team—is bringing some product engineering practices into the open-source. So, can we say, for example, that we are going to focus on user experience this next release? And we're not going to do all the rest. And I remember, my team was like worried about, like, “Hey, what about that, and what about this, and we have—” you know, they were juggling everything together. And I remember telling them, “Imagine that everything is on the floor. All the balls are on the floor. I know they're on the floor, you know they're on the floor. It's okay. Let's just make sure that every time we pick something up, it never falls again.” And that idea is a principle that then evolved to ‘No Heroics,' and it evolved to ‘Sustainable Success.' But building things towards sustainable success is a principle which has been very helpful for us.Corey: This episode is sponsored in part by our friend at Uptycs. Attackers don't think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution that prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That's U-P-T-Y-C-S.com. My thanks to them for sponsoring my ridiculous nonsense.Corey: When I take a look back, it's very odd to me to see the current reality that is Google, where you're talking about empathy, and the No Heroics, and the rest of that is not the reputation that Google enjoyed back when a lot of this stuff got started. It was always oh, engineers should be extraordinarily bright and gifted, and therefore it felt at the time like our customers should be as well. There was almost an arrogance built into, well, if you wrote your code more like Google will, then maybe your code wouldn't be so terrible in the cloud. And somewhat cynically I thought for a while that oh Kubernetes is Google's attempt to wind up making the rest of the world write software in a way that's more Google-y. I don't think that observation has aged very well. I think it's solved a tremendous number of problems for folks.But the complexity has absolutely been high throughout most of Kubernetes life. I would argue, on some level, that it feels like it's become successful almost in spite of that, rather than because of it. But I'm curious to get your take. Why do you believe that Kubernetes has been as successful as it clearly has?Chen: [unintelligible 00:25:34] two things. One about empathy. So yes, Google engineers are brilliant and are amazing and all great. And our customers are amazing, and brilliant, as well. And going back to the point before is, everyone has their job and where they need to be successful and we, as you say, we need to make things simpler and enable innovation. And our customers are driving innovation on top of our platform.So, that's the way I think about it. And yes, it's not as simple as it can be—probably—yet, but in studying the early days of Kubernetes, we have been investing a lot in what we call empathy, and the customer empathy workshop, for example. So, I partnered with Kelsey Hightower—and you mentioned yourself trying to start a cluster. The first time we did a workshop with my entire team, so then it was like 50 people [laugh], their task was to spin off a cluster without using any scripts that we had internally.And unfortunately, not many folks succeeded in this task. And out of that came the—what you you call it—a OKR, which was our goal for that quarter, is that you are able to spin off a cluster in three commands and troubleshoot if something goes wrong. Okay, that came out of that workshop. So, I do think that there is a lot of foundation on that empathetic engineering and the open-source of the community helped our Google teams to be more empathetic and understand what are the different use cases that they are trying to solve.And that actually bring me to why I think Kubernetes is so successful. People might be surprised, but the amount of investment we're making on orchestration or placement of containers within Kubernetes is actually pretty small. And it's been very small for the last seven years. Where do we invest time? One is, as I mentioned before, is on the what we call the API machinery.So, Kubernetes has introduced a way that is really suitable for a cloud-native technologies, the idea of reconciliation loop, meaning that the way Kubernetes is—Kubernetes is, like, a powerful automation machine, which can automate, of course, workload placement, but can automate other things. Think about it as a way of the Kubernetes API machinery is observing what is the current state, comparing it to the desired state, and working towards it. Think about, like, a thermostat, which is a different automation versus the ‘if this, then that,' where you need to anticipate different events. So, this idea about the API machinery and the way that you can extend it made it possible for different teams to use that mechanism to automate other things in that space.So, that has been one very powerful mechanism of Kubernetes. And that enabled all of innovation, even if you think about things like Istio, as an example, that's how it started, by leveraging that kind of mechanism to separate storage and so on. So, there are a lot of operators, the way people are managing their databases, or stateful workloads on top of Kubernetes, they're extending this mechanism. So, that's one thing that I think is key and built that ecosystem. The second thing, I am very proud of the community of Kubernetes.Corey: Oh, it's a phenomenal community success story.Chen: It's not easy to build a community, definitely not in open-source. I feel that the idea of values, you know, that I was talking about within my team was actually a big deal for us as we were building the community: how we treat each other, how do we help people start? You know, and we were talking before, like, am I going to talk about DEI and inclusivity, and so on. One of the things that I love about Kubernetes is that it's a new technology. There is actually—[unintelligible 00:29:39] no, even today, there is no one with ten years experience in Kubernetes. And if anyone says they have that, then they are lying.Corey: Time machine. Yes.Chen: That creates an opportunity for a lot of people to become experts in this technology. And by having it in open-source and making everything available, you can actually do it from your living room sofa. That excites me, you know, the idea that you can become an expert in this new technology and you can get involved, and you'll get people that will mentor you and help you through your first PR. And there are some roles within the community that you can start, you know, dipping your toes in the water. It's exciting. So, that makes me really happy, and I know that this community has changed the trajectory of many people's careers, which I love.Corey: I think that's probably one of the most impressive things that it's done. One last question I have for you is that we've talked a fair bit about the history and how we see it progressing through the view toward the somewhat recent past. What do you see coming in the future? What does the future of Kubernetes look like to you?Chen: Continue to be more and more boring. There is the promise of hybrid and multi-cloud, for example, is only possible by technologies like Kubernetes. So, I do think that, as a technology, it will continue to be important by ensuring portability and interoperability of workloads. I see a lot of edge use cases. If you think about it, it's like just lagging a bit around, like, innovation that we've seen in the cloud, can we bring that innovation to the edge, this will require more development within Kubernetes community as well.And that's really actually excites me. I think there's a lot of things that we're going to see there. And by the way, you've seen it also in KubeCon. I mean, there were some announcements in that space. In Google Cloud, we just announced before, like, with customers like Wendy's and Rite Aid as well. So, taking advantage of this technology to allow innovation everywhere.But beyond that, my hope is that we'll continue and hide the complexity. And our challenge will be to not make it a black box. Because that will be, in my opinion, a failure pattern, doesn't help those kinds of platforms. So, that will be the challenge. Can we scope the project, ensure that we have the right observability, and from a use case perspective, I do think edge is super interesting.Corey: I would agree. There are a lot of workloads out there that are simply never going to be hosted in the cloud provider region, for a variety of reasons of varying validity, but it is the truth. I think that the focus on addressing customers where they are has been an emerging best practice for cloud providers and I'm thrilled to see Google leading the charge on that.Chen: Yeah. And you just reminded me, the other thing that we see also more and more is definitely AI and ML workloads running on Kubernetes, which is part of that, right? So, Google Cloud is investing a lot in making an AI/ML easy. And I don't know if many people know, but, like, even Vertex AI, our own platform, is running on GKE. So, that's part of seeing how do we make sure that platform is suitable for these kinds of workloads and really help customers do the heavy lifting.So, that's another set of workloads that are very relevant at the edge. And one of our customers—MLB, for example—two things are interesting there. The first one, I think a lot of people sometimes say, “Okay, I'm going to move to the cloud and I want to know everything right now, how that will evolve.” And one of the things that's been really exciting with working with MLB for the last four years is the journey and the iterations. So, they started somewhat, like, at one phase and then they saw what's possible, and then moved to the next one, and so on. So, that's one. The other thing is that, really, they have so much ML running at the stadium with Google Cloud technology, which is very exciting.Corey: I'm looking forward to seeing how this continues to evolve and progress, particularly in light of the recent correction we're seeing in the market where a lot of hype-driven ideas are being stress test, maybe not in the way we might have hoped that they would, but it'll be really interesting to see what shakes out as far as things that deliver business value and are clear wins for customers versus a lot of the speculative stories that we've been hearing for a while now. Maybe I'm totally wrong on this. And this is going to be a temporary bump in the road, and we'll see no abatement in the ongoing excitement around so many of these emerging technologies, but I'm curious to see how it plays out. But that's the beautiful part about getting to be a pundit—or whatever it is people call me these days that's at least polite enough to say on a podcast—is that when I'm right, people think I'm a visionary, and when I'm wrong, people don't generally hold that against you. It seems like futurist is the easiest job in the world because if you predict and get it wrong, no one remembers. Predict and get it right, you look like a genius.Chen: So, first of all, I'm optimistic. So usually, my predictions are positive. I will say that, you know, what we are seeing, also what I'm hearing from our customers, technology is not for the sake of technology. Actually, nobody cares [laugh]. Even today.Okay, so nothing needs to change for, like, nobody would c—even today, nobody cares about Kubernetes. They need to care, unfortunately, but what I'm hearing from our customers is, “How do we create new experiences? How we make things easy?” Talent shortage is not just with tech people. It's also with people working in the warehouse or working in the store.Can we use technology to help inventory management? There's so many amazing things. So, when there is a real business opportunity, things are so much simpler. People have the right incentives to make it work. Because one thing we didn't talk about—right, we talked about all these new technologies and we talked about scaling team and so on—a lot of time, the challenge is not the technology.A lot of time, the challenge is the process. A lot of time, the challenge is the skills, is the culture, there's so many things. But when you have something—going back to what I said before—how you unite teams, when there's something a clear goal, a clear vision that everybody's excited about, they will make it work. So, I think this is where having a purpose for the innovation is critical for any successful project.Corey: I think and I hope that you're right. I really want to thank you for spending as much time with me as you have. If people want to learn more, where's the best place for them to find you?Chen: So, first of all, on Twitter. I'm there or on LinkedIn. I will say that I'm happy to connect with folks. Generally speaking, at some point in my career, I recognized that I have a voice that can help people, and I've experienced that can also help people build their careers. I'm happy to share that and [unintelligible 00:36:54] folks both in the company and outside of it.Corey: I think that's one of the obligations on a lot of us, once we wanted to get into a certain position or careers to send the ladder back down, for lack of a better term. It's I've never appreciated the perspective, “Well, screw everyone else. I got mine.” The whole point the next generation should have it easier than we did.Chen: Yeah, definitely.Corey: Chen Goldberg, General Manager of Cloud Runtimes and VP of Engineering at Google. 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 rant of a comment talking about how LPARs on mainframes are absolutely not containers, making sure it's at least far too big to fit in a reasonably-sized Docker container.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.

cloudonaut
#58 [Hot off the Cloud] Neptune Serverless + WAF Bot Control + Private App Runner + Fault Injection Simulator

cloudonaut

Play Episode Listen Later Nov 8, 2022 33:35


Two brothers discussing all things AWS every week. Hosted by Andreas and Michael Wittig presented by cloudonaut.

AWS Developers Podcast
Episode 058 - Serverless and Well Architectured Frameworks with Kristi Perreault

AWS Developers Podcast

Play Episode Listen Later Nov 4, 2022 32:34


In this episode, Emily and Dave chat with Kristi Perreault, a Principal Software Engineer at Liberty Mutual, and an AWS Serverless Hero. Krisiti shares her journey to the cloud, thoughts on Serverless, building a sustainable application, the importance of well architected frameworks, and how she aids over 4,000 Liberty Mutual engineers to be more successful in their jobs. The trio also discusses the importance of creating an inclusive work environment for all. Both Emily and Kristi share their personal journeys as women in tech, actionable advice, and steps allies can take in support. Kristi's Twitter: https://twitter.com/kperreault95 Kristi on LinkedIn: https://www.linkedin.com/in/kristi-perreault/ Kristi on Medium: https://kristiperreault.medium.com Kristi on Dev.to: https://dev.to/kristiperreault Kristi's AWS Hero Page: https://aws.amazon.com/developer/community/heroes/kristi-perreault/ Serverless Days: https://serverlessdays.io/ Serverless Days Denver: https://www.meetup.com/serverlessdays-denver/ Women Who Code: https://www.womenwhocode.com/ How To Support Women in Tech: https://index.medium.com/how-to-support-women-in-tech-ea5b9de61fb4 Know My Name: A Memoir by Chanel Miller: https://www.amazon.com/Know-My-Name-Chanel-Miller-ebook/dp/B07SJPPTDL Serverless Applications Lens - AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html All Trails – Mobile App - iPhone: https://apps.apple.com/us/app/alltrails-hike-bike-run/id405075943 All Trails - Mobile App - Android: https://play.google.com/store/apps/details?id=com.alltrails.alltrails --------------------- 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

Real World Serverless with theburningmonk
#68: Event-driven architecture at PostNL with Luc van Donkersgoed

Real World Serverless with theburningmonk

Play Episode Listen Later Nov 2, 2022 45:19 Transcription Available


In this episode, I spoke with AWS Serverless Hero Luc van Donkersgoed about how PostNL is using serverless technologies and discussed the challenges of building event-driven architectures and how PostNL tackles problems such as schema validation and testing.Links from the episode:Build cloud-native apps with Serverless interaction testingIT vacancies at PostNLAWS Distro for OpenTelemtryAWS X-Ray vs LumigoMy upcoming Testing Serverless Architectures video courseFor more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.Want to step up your AWS game and learn how to build production-ready serverless applications? Check out my upcoming workshops and I will teach you everything I know.Opening theme song:Cheery Monday by Kevin MacLeodLink: https://incompetech.filmmusic.io/song/3495-cheery-mondayLicense: http://creativecommons.org/licenses/by/4.0

IoT For All Podcast
What is Serverless IoT? | EDJX's Benjamin Thomas & Delano Seymour | Internet of Things Podcast

IoT For All Podcast

Play Episode Listen Later Nov 1, 2022 28:58


The podcast begins with both guests introducing themselves and providing more information about EDJX before diving into mesh computing and serverless IoT. They then talk about serverless at the edge and their companies' offerings. The conversation then moves more high-level with discussion around challenges in development, the biggest drivers of growth, the evolution of serverless IoT, and advice for how developers can approach the onboarding process.Benjamin Thomas is the CEO of EDJX, the intelligent edge OS and computing platform that makes it easy to write, deploy, and execute IoT and other applications using serverless computing and an edge mesh network of micro-compute and storage nodes to minimize latency, eliminate expensive backhauling of data, accelerate content delivery, and rapidly deploy IoT sensors at the far edge. His diverse technology and business experience includes being an industry disrupter in the travel and veterinary services industry. In previous ventures, he managed large-scale offshore development teams, overseeing the development of over 100 software applications. Benjamin grew a chain of veterinary practices to $42 million in revenue and 450 employees through 28 acquisitions in 7 states. Benjamin was a nominee for Ernst and Young's Entrepreneur of the Year award. He holds a BS in Mechanical Engineering with Honors from Tulane University and an MS in Management from Stanford University.Delano Seymour is a visionary founder, pioneer, and disruptive innovator, with several technology patents to date. He is the former founder and President of a high revenue-generating Managed Services company headquartered in the Caribbean. Delano is also a global technology speaker at prestigious industry forums such as Cloud Expo Container & Microservices Summit, Red Hat Summit, and OpenShift Commons Briefings.EDJX is an intelligent Edge OS and computing platform that makes it easy to write, deploy and execute applications using serverless computing to increase responsiveness and security. EDJX's edge mesh network of micro-compute and storage nodes minimizes latency, eliminates expensive backhauling of data, accelerates content delivery, and rapidly deploys IoT sensors at the far edge. EDJX helps businesses handle the explosive demand for data processing to serve real-world edge computing applications, including industrial IoT, artificial intelligence, augmented reality, and robotics. EDJX is a privately held company based in Raleigh, NC.

You Can Be Anything
Episode 042: A Chat With Ateh Rosius – Serverless Developer & AWS Serverless Hero

You Can Be Anything

Play Episode Listen Later Oct 27, 2022 48:03


Rosius Ndimofor is an avid thinker, extreme problem solver, and full-stack mobile and web developer. He enjoys building applications for the cloud. He was introduced to Java programming back in 2008 and became Java certified in 2009. Since then, he has been contributing to the creation of both commercial and personal software. Today, he comes on the "You Can Be Anything Podcast" to share more light on his beginnings, life experiences, starting in tech, learning tech skills, and how anyone can transition into tech. We hope his story inspires you to become anything. Thanks.   Thanks for your support. You can connect with us on Facebook, Instagram, and YouTube, or send us an email at hello@youcanbeanythingpodcast.com Check out our website  www.youcanbeanythingpodcast.com for more resources and to learn more. Also, you can connect with Solange Che on Facebook (@Solange Che) and Instagram (@solangeche1). Thank you! Remember to Be Good To Each Other!

Screaming in the Cloud
The Man Behind the Curtain at Zoph with Victor Grenu

Screaming in the Cloud

Play Episode Listen Later Oct 25, 2022 28:28


About VictorVictor is an Independent Senior Cloud Infrastructure Architect working mainly on Amazon Web Services (AWS), designing: secure, scalable, reliable, and cost-effective cloud architectures, dealing with large-scale and mission-critical distributed systems. He also has a long experience in Cloud Operations, Security Advisory, Security Hardening (DevSecOps), Modern Applications Design, Micro-services and Serverless, Infrastructure Refactoring, Cost Saving (FinOps).Links Referenced: Zoph: https://zoph.io/ unusd.cloud: https://unusd.cloud Twitter: https://twitter.com/zoph LinkedIn: https://www.linkedin.com/in/grenuv/ 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: This episode is brought to us in part by our friends at Datadog. Datadog's SaaS monitoring and security platform that enables full stack observability for developers, IT operations, security, and business teams in the cloud age. Datadog's platform, along with 500 plus vendor integrations, allows you to correlate metrics, traces, logs, and security signals across your applications, infrastructure, and third party services in a single pane of glass.Combine these with drag and drop dashboards and machine learning based alerts to help teams troubleshoot and collaborate more effectively, prevent downtime, and enhance performance and reliability. Try Datadog in your environment today with a free 14 day trial and get a complimentary T-shirt when you install the agent.To learn more, visit datadoghq.com/screaminginthecloud to get. That's www.datadoghq.com/screaminginthecloudCorey: Managing shards. Maintenance windows. Overprovisioning. ElastiCache bills. I know, I know. It's a spooky season and you're already shaking. It's time for caching to be simpler. Momento Serverless Cache lets you forget the backend to focus on good code and great user experiences. With true autoscaling and a pay-per-use pricing model, it makes caching easy. No matter your cloud provider, get going for free at gomomento.co/screaming That's GO M-O-M-E-N-T-O dot co slash screamingCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the best parts about running a podcast like this and trolling the internet of AWS things is every once in a while, I get to learn something radically different than what I expected. For a long time, there's been this sort of persona or brand in the AWS space, specifically the security side of it, going by Zoph—that's Z-O-P-H—and I just assumed it was a collective or a whole bunch of people working on things, and it turns out that nope, it is just one person. And that one person is my guest today. Victor Grenu is an independent AWS architect. Victor, thank you for joining me.Victor: Hey, Corey, thank you for having me. It's a pleasure to be here.Corey: So, I want to start by diving into the thing that first really put you on my radar, though I didn't realize it was you at the time. You have what can only be described as an army of Twitter bots around the AWS ecosystem. And I don't even know that I'm necessarily following all of them, but what are these bots and what do they do?Victor: Yeah. I have a few bots on Twitter that I push some notification, some tweets, when things happen on AWS security space, especially when the AWS managed policies are updated from AWS. And it comes from an initial project from Scott Piper. He was running a Git command on his own laptop to push the history of AWS managed policy. And it told me that I can automate this thing using a deployment pipeline and so on, and to tweet every time a new change is detected from AWS. So, the idea is to monitor every change on these policies.Corey: It's kind of wild because I built a number of somewhat similar Twitter bots, only instead of trying to make them into something useful, I'd make them into something more than a little bit horrifying and extraordinarily obnoxious. Like there's a Cloud Boomer Twitter account that winds up tweeting every time Azure tweets something only it quote-tweets them in all caps and says something insulting. I have an AWS releases bot called AWS Cwoud—so that's C-W-O-U-D—and that winds up converting it to OwO speak. It's like, “Yay a new auto-scawowing growp.” That sort of thing is obnoxious and offensive, but it makes me laugh.Yours, on the other hand, are things that I have notifications turned on for just because when they announce something, it's generally fairly important. The first one that I discovered was your IAM changes bot. And I found some terrifying things coming out of that from time to time. What's the data source for that? Because I'm just grabbing other people's Twitter feeds or RSS feeds; you're clearly going deeper than that.Victor: Yeah, the data source is the official AWS managed policy. In fact, I run AWS CLI in the background and I'm doing just a list policy, the list policy command, and with this list I'm doing git of each policy that is returned, so I can enter it in a git repository to get the full history of the time. And I also craft a list of deprecated policy, and I also run, like, a dog-food initiative, the policy analysis, validation analysis from AWS tools to validate the consistency and the accuracy of the own policies. So, there is a policy validation with their own tool. [laugh].Corey: You would think that wouldn't turn up anything because their policy validator effectively acts as a linter, so if it throws an error, of course, you wouldn't wind up pushing that. And yet, somehow the fact that you have bothered to hook that up and have findings from it indicates that that's not how the real world works.Victor: Yeah, there is some, let's say, some false positive because we are running the policy validation with their own linter then own policies, but this is something that is documented from AWS. So, there is an official page where you can find why the linter is not working on each policy and why. There is a an explanation for each findings. I thinking of [unintelligible 00:05:05] managed policy, which is too long, and policy analyzer is crashing because the policy is too long.Corey: Excellent. It's odd to me that you have gone down this path because it's easy enough to look at this and assume that, oh, this must just be something you do for fun or as an aspect of your day job. So, I did a little digging into what your day job is, and this rings very familiar to me: you are an independent AWS consultant, only you're based out of Paris, whereas I was doing this from San Francisco, due to an escalatingly poor series of life choices on my part. What do you focus on in the AWS consulting world?Victor: Yeah. I'm running an AWS consulting boutique in Paris and I'm working for a large customer in France. And I'm doing mostly infrastructure stuff, infrastructure design for cloud-native application, and I'm also doing some security audits and [unintelligible 00:06:07] mediation for my customer.Corey: It seems to me that there's a definite divide as far as how people find the AWS consulting experience to be. And I'm not trying to cast judgment here, but the stories that I hear tend to fall into one of two categories. One of them is the story that you have, where you're doing this independently, you've been on your own for a while working specifically on this, and then there's the stories of, “Oh, yeah, I work for a 500 person consultancy and we do everything as long as they'll pay us money. If they've got money, we'll do it. Why not?”And it always seems to me—not to be overly judgy—but the independent consultants just seem happier about it because for better or worse, we get to choose what we focus on in a way that I don't think you do at a larger company.Victor: Yeah. It's the same in France or in Europe; there is a lot of consulting firms. But with the pandemic and with the market where we are working, in the cloud, in the cloud-native solution and so on, that there is a lot of demands. And the natural path is to start by working for a consulting firm and then when you are ready, when you have many AWS certification, when you have the experience of the customer, when you have a network of well-known customer, and you gain trust from your customer, I think it's natural to go by yourself, to be independent and to choose your own project and your own customer.Corey: I'm curious to get your take on what your perception of being an AWS consultant is when you're based in Paris versus, in my case, being based in the West Coast of the United States. And I know that's a bit of a strange question, but even when I travel, for example, over to the East Coast, suddenly, my own newsletter sends out three hours later in the day than I expect it to and that throws me for a loop. The AWS announcements don't come out at two or three in the afternoon; they come out at dinnertime. And for you, it must be in the middle of the night when a lot of those things wind up dropping. The AWS stuff, not my newsletter. I imagine you're not excitedly waiting on tenterhooks to see what this week's issue of Last Week in AWS talks about like I am.But I'm curious is that even beyond that, how do you experience the market? From what you're perceiving people in the United States talking about as AWS consultants versus what you see in Paris?Victor: It's difficult, but in fact, I don't have so much information about the independent in the US. I know that there is a lot, but I think it's more common in Europe. And yeah, it's an advantage to whoever ten-hour time [unintelligible 00:08:56] from the US because a lot of stuff happen on the Pacific time, on the Seattle timezone, on San Francisco timezone. So, for example, for this podcast, my Monday is over right now, so, so yeah, I have some advantage in time, but yeah.Corey: This is potentially an odd question for you. But I find an awful lot of the AWS documentation to be challenging, we'll call it. I don't always understand exactly what it's trying to tell me, and it's not at all clear that the person writing the documentation about a service in some cases has ever used the service. And in everything I just said, there is no language barrier. This documentation was written—theoretically—in English and I, most days, can stumble through a sentence in English and almost no other language. You obviously speak French as a first language. Given that you live in Paris, it seems to be a relatively common affliction. How do you find interacting with AWS in French goes? Or is it just a complete nonstarter, and it all has to happen in English for you?Victor: No, in fact, the consultants in Europe, I think—in fact, in my part, I'm using my laptop in English, I'm using my phone in English, I'm using the AWS console in English, and so on. So, the documentation for me is a switch on English first because for the other language, there is sometimes some automated translation that is very dangerous sometimes, so we all keep the documentation and the materials in English.Corey: It's wild to me just looking at how challenging so much of the stuff is. Having to then work in a second language on top of that, it just seems almost insurmountable to me. It's good they have automated translation for a lot of this stuff, but that falls down in often hilariously disastrous ways, sometimes. It's wild to me that even taking most programming languages that folks have ever heard of, even if you program and speak no English, which happens in a large part of the world, you're still using if statements even if the term ‘if' doesn't mean anything to you localized in your language. It really is, in many respects, an English-centric industry.Victor: Yeah. Completely. Even in French for our large French customer, I'm writing the PowerPoint presentation in English, some emails are in English, even if all the folks in the thread are French. So yeah.Corey: One other area that I wanted to explore with you a bit is that you are very clearly focused on security as a primary area of interest. Does that manifest in the work that you do as well? Do you find that your consulting engagements tend to have a high degree of focus on security?Victor: Yeah. In my design, when I'm doing some AWS architecture, my main objective is to design some security architecture and security patterns that apply best practices and least privilege. But often, I'm working for engagement on security audits, for startups, for internal customer, for diverse company, and then doing some accommodation after all. And to run my audit, I'm using some open-source tooling, some custom scripts, and so on. I have a methodology that I'm running for each customer. And the goal is to sometime to prepare some certification, PCI DSS or so on, or maybe to ensure that the best practice are correctly applied on a workload or before go-live or, yeah.Corey: One of the weird things about this to me is that I've said for a long time that cost and security tend to be inextricably linked, as far as being a sort of trailing reactive afterthought for an awful lot of companies. They care about both of those things right after they failed to adequately care about those things. At least in the cloud economic space, it's only money as opposed to, “Oops, we accidentally lost our customers' data.” So, I always found that I find myself drifting in a security direction if I don't stop myself, just based upon a lot of the cost work I do. Conversely, it seems that you have come from the security side and you find yourself drifting in a costing direction.Your side project is a SaaS offering called unusd.cloud, that's U-N-U-S-D dot cloud. And when you first mentioned this to me, my immediate reaction was, “Oh, great. Another SaaS platform for costing. Let's tear this one apart, too.” Except I actually like what you're building. Tell me about it.Victor: Yeah, and unusd.cloud is a side project for me and I was working since, let's say one year. It was a project that I've deployed for some of my customer on their local account, and it was very useful. And so, I was thinking that it could be a SaaS project. So, I've worked at [unintelligible 00:14:21] so yeah, a few months on shifting the product to assess [unintelligible 00:14:27].The product aim to detect the worst on AWS account on all AWS region, and it scan all your AWS accounts and all your region, and you try to detect and use the EC2, LDS, Glue [unintelligible 00:14:45], SageMaker, and so on, and attach a EBS and so on. I don't craft a new dashboard, a new Cost Explorer, and so on. It's it just cost awareness, it's just a notification on email or Slack or Microsoft Teams. And you just add your AWS account on the project and you schedule, let's say, once a day, and it scan, and it send you a cost of wellness, a [unintelligible 00:15:17] detection, and you can act by turning off what is not used.Corey: What I like about this is it cuts at the number one rule of cloud economics, which is turn that shit off if you're not using it. You wouldn't think that I would need to say that except that everyone seems to be missing that, on some level. And it's easy to do. When you need to spin something up and it's not there, you're very highly incentivized to spin that thing up. When you're not using it, you have to remember that thing exists, otherwise it just sort of sits there forever and doesn't do anything.It just costs money and doesn't generate any value in return for that. What you got right is you've also eviscerated my most common complaint about tools that claim to do this, which is you build in either a explicit rule of ignore this resource or ignore resources with the following tags. The benefit there is that you're not constantly giving me useless advice, like, “Oh, yeah, turn off this idle thing.” It's, yeah, that's there for a reason, maybe it's my dev box, maybe it's my backup site, maybe it's the entire DR environment that I'm going to need at little notice. It solves for that problem beautifully. And though a lot of tools out there claim to do stuff like this, most of them really failed to deliver on that promise.Victor: Yeah, I just want to keep it simple. I don't want to add an additional console and so on. And you are correct. You can apply a simple tag on your asset, let's say an EC2 instances, you apply the tag in use and the value of, and then the alerting is disabled for this asset. And the detection is based on the CPU [unintelligible 00:17:01] and the network health metrics, so when the instances is not used in the last seven days, with a low CPU every [unintelligible 00:17:10] and low network out, it comes as a suspect. [laugh].[midroll 00:17:17]Corey: One thing that I like about what you've done, but also have some reservations about it is that you have not done with so many of these tools do which is, “Oh, just give us all the access in your account. It'll be fine. You can trust us. Don't you want to save money?” And yeah, but I also still want to have a company left when all sudden done.You are very specific on what it is that you're allowed to access, and it's great. I would argue, on some level, it's almost too restrictive. For example, you have the ability to look at EC2, Glue, IAM—just to look at account aliases, great—RDS, Redshift, and SageMaker. And all of these are simply list and describe. There's no gets in there other than in Cost Explorer, which makes sense. You're not able to go rummaging through my data and see what's there. But that also bounds you, on some level, to being able to look only at particular types of resources. Is that accurate or are you using a lot of the CloudWatch stuff and Cost Explorer stuff to see other areas?Victor: In fact, it's the least privilege and read-only permission because I don't want too much question for the security team. So, it's full read-only permission. And I've only added the detection that I'm currently supports. Then if in some weeks, in some months, I'm adding a new detection, let's say for Snapshot, for example, I will need to update, so I will ask my customer to update their template. There is a mechanisms inside the project to tell them that the template is obsolete, but it's not a breaking change.So, the detection will continue, but without the new detection, the new snapshot detection, let's say. So yeah, it's least privilege, and all I need is the get-metric-statistics from CloudWatch to detect unused assets. And also checking [unintelligible 00:19:16] Elastic IP or [unintelligible 00:19:19] EBS volume. So, there is no CloudWatching in this detection.Corey: Also, to be clear, I am not suggesting that what you have done is at all a mistake, even if you bound it to those resources right now. But just because everyone loves to talk about these exciting, amazing, high-level services that AWS has put up there, for example, oh, what about DocumentDB or all these other—you know, Amazon Basics MongoDB; same thing—or all of these other things that they wind up offering, but you take a look at where customers are spending money and where they're surprised to be spending money, it's EC2, it's a bit of RDS, occasionally it's S3, but that's a lot harder to detect automatically whether that data is unused. It's, “You haven't been using this data very much.” It's, “Well, you see how the bucket is labeled ‘Archive Backups' or ‘Regulatory Logs?'” imagine that. What a ridiculous concept.Yeah. Whereas an idle EC2 instance sort of can wind up being useful on this. I am curious whether you encounter in the wild in your customer base, folks who are having idle-looking EC2 instances, but are in fact, for example, using a whole bunch of RAM, which you can't tell from the outside without custom CloudWatch agents.Victor: Yeah, I'm not detecting this behavior for larger usage of RAM, for example, or for maybe there is some custom application that is low in CPU and don't talk to any other services using the network, but with this detection, with the current state of the detection, I'm covering large majority of waste because what I see from my customer is that there is some teams, some data scientists or data teams who are experimenting a lot with SageMaker with Glue, with Endpoint and so on. And this is very expensive at the end of the day because they don't turn off the light at the end of the day, on Friday evening. So, what I'm trying to solve here is to notify the team—so on Slack—when they forgot to turn off the most common waste on AWS, so EC2, LTS, Redshift.Corey: I just now wound up installing it while we've been talking on my dedicated shitposting account, and sure enough, it already spat out a single instance it found, which yeah was running an EC2 instance on the East Coast when I was just there, so that I had a DNS server that was a little bit more local. Okay, great. And it's a T4g.micro, so it's not exactly a whole lot of money, but it does exactly what it says on the tin. It didn't wind up nailing the other instances I have in that account that I'm using for a variety of different things, which is good.And it further didn't wind up falling into the trap that so many things do, which is the, “Oh, it's costing you zero and your spend this month is zero because this account is where I dump all of my AWS credit codes.” So, many things say, “Oh, well, it's not costing you anything, so what's the problem?” And then that's how you accidentally lose $100,000 in activate credits because someone left something running way too long. It does a lot of the right things that I would hope and expect it to do, and the fact that you don't do that is kind of amazing.Victor: Yeah. It was a need from my customer and an opportunity. It's a small bet for me because I'm trying to do some small bets, you know, the small bets approach, so the idea is to try a new thing. It's also an excuse for me to learn something new because building a SaaS is a challenging.Corey: One thing that I am curious about, in this account, I'm also running the controller for my home WiFi environment. And that's not huge. It's T3.small, but it is still something out there that it sits there because I need it to exist. But it's relatively bored.If I go back and look over the last week of CloudWatch metrics, for example, it doesn't look like it's usually busy. I'm sure there's some network traffic in and out as it updates itself and whatnot, but the CPU peeks out at a little under 2% used. It didn't warn on this and it got it right. I'm just curious as to how you did that. What is it looking for to determine whether this instance is unused or not?Victor: It's the magic [laugh]. There is some intelligence artif—no, I'm just kidding. It just statistics. And I'm getting two metrics, the superior average from the last seven days and the network out. And I'm getting the average on those metrics and I'm doing some assumption that this EC2, this specific EC2 is not used because of these metrics, this server average.Corey: Yeah, it is wild to me just that this is working as well as it is. It's just… like, it does exactly what I would expect it to do. It's clear that—and this is going to sound weird, but I'm going to say it anyway—that this was built from someone who was looking to answer the question themselves and not from the perspective of, “Well, we need to build a product and we have access to all of this data from the API. How can we slice and dice it and add some value as we go?” I really liked the approach that you've taken on this. I don't say that often or lightly, particularly when it comes to cloud costing stuff, but this is something I'll be using in some of my own nonsense.Victor: Thanks. I appreciate it.Corey: So, I really want to thank you for taking as much time as you have to talk about who you are and what you're up to. If people want to learn more, where can they find you?Victor: Mainly on Twitter, my handle is @zoph [laugh]. And, you know, on LinkedIn or on my company website, as zoph.io.Corey: And we will, of course, put links to that in the [show notes 00:25:23]. Thank you so much for your time today. I really appreciate it.Victor: Thank you, Corey, for having me. It was a pleasure to chat with you.Corey: Victor Grenu, independent AWS architect. 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 insulting comment that is going to cost you an absolute arm and a leg because invariably, you're going to forget to turn it off when you're done.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.

PurePerformance
How to fail at Serverless (without even trying) with Kam Lasater

PurePerformance

Play Episode Listen Later Oct 24, 2022 48:33


Serverless and other emerging technologies hide the complexity of the underlying runtimes from developers. This is great for productivity but can make it really hard when troubleshooting behavior that needs deeper insight into those runtimes, platforms or frameworks.In this episode we hear from Kam Lasater, Founder of Cyclic Software. Kam has run into several walls while he was implementing solutions from scratch using Serverless technologies as well as other popular cloud services. He recently presented a handful of those scenarios at DevOpsDays Boston 2022.Tune in and learn from Kam as he walks us through two of those challenges he covered during his DevOpsDays talk. If you want to learn more make sure to watch the full talk on YouTube: https://www.youtube.com/watch?v=xB9vsSl93mE If you want to learn more from or about Kam check out the following links:YouTube video from DevOpsDays Boston: https://www.youtube.com/watch?v=xB9vsSl93mECyclic Website: https://www.cyclic.sh/Cyclic Blog: https://www.cyclic.sh/blog/Twitter: https://twitter.com/seekayelPersonal Website: https://kamlasater.com/LinkedIn: https://www.linkedin.com/in/kamlasater/

The Cloudcast
Examining SuperCloud 3.0

The Cloudcast

Play Episode Listen Later Oct 23, 2022 26:04


Let's take a look at the evolution of “SuperCloud”, and if it's a trend, an architecture, an application model, or something else all together. SHOW: 662CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:CloudZero - Cloud Cost Intelligence for Engineering TeamsCDN77 - CDN Focused on VOD and SecurityCDN77 - ask for a free trial with no duration or traffic limits.SHOW NOTES:2022 Look Ahead to SuperCloud (Eps.586)SuperCloud 3.0 Definition (Wikibon)Supercloudifragilisticexpialidocious VI: The Nightmare ContinuesThe emergence of Cloud 3.0 and independent vendor exclusion NAMING IS IMPORTANT, BUT SOMETIMES NEW CONCEPTS ARE HARD TO NAMEWhen something new comes along, do we spend more time talking about the name or the value of the new concept? Does anyone remember “Serverless”?WHAT IS SUPERCLOUD, AND WHY MIGHT IT BE IMPORTANTMulti-Cloud is a real thing (for various reasons), but Multi-Cloud-App is an anomaly.Maybe it's a SuperApp, instead of a SuperCloudClouds, Politics, InsuranceWhat happens if applications “span” availability zones? Span regions? Can SuperCloud be a thing for the application, or mostly the data?The cost of moving data makes these types of applications very difficult to build and manage.Load-balancing, DNS, CDNsFEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet

Cloud Security Today
What Serverless Can Do For You

Cloud Security Today

Play Episode Listen Later Oct 21, 2022 32:17 Transcription Available


What Serverless Can Do For You? With Mark GouldEpisode SummaryOn this episode, Cloud Security Engineer at Manhattan Associates, Mark Gould, joins Matt to talk about serverless computing. Mark is a Cybersecurity specialist, with a focus on the Google Cloud Platform, and is a Certified Google Architect.Today, Mark talks about serverless computing, the security risk to consider, and working with DevOps teams. What are the top three metrics to start with for automation and security? Hear about cloud automation, Mark's NSG alerting system, and his greatest accomplishments in recent years. Timestamp Segments·       [01:22] About Mark.·       [02:49] About Manhattan Associates.·       [04:46] How does cloud fit in?·       [06:16] Automation in the cloud.·       [09:03] Modernization at Manhattan Associates.·       [10:18] Serverless computing.·       [14:39] Security risks with using serverless functions.·       [17:58] Mark's NSG alerting system.·       [21:27] Three metrics for automation and security.·       [23:33] What should security teams be doing differently when working with DevOps?·       [25:43] What is Mark most proud of?·       [27:45] How does Mark continue to learn?·       [30:31] Is Manhattan Associates hiring? Notable Quotes·       “You definitely have to pick what kind of processes you want to automate and make sure that you're willing to put in the work to maintain them.”·       “Sometimes serverless isn't always the cheapest option.”·       “Leaders are learners.” Relevant LinksManhattan Associates:           https://www.manh.comLinkedIn:         https://www.linkedin.com/in/mark-gould-15a7a3149Comprehensive, full-stack cloud security Secure infrastructure, apps and data across hybrid and multi-cloud environments with Prisma Cloud.

cloudonaut
#55 Serverless ETL with Athena and Airflow | Builder's Diary Vol. 2

cloudonaut

Play Episode Listen Later Oct 19, 2022 50:33


Wed, 19 Oct 2022 08:17:25 +0000 https://podcast.cloudonaut.io/55-serverless-etl-with-athena-and-airflow-builders-diary-vol-2 399de3e4db8f3cf6f6759123e2e00a40 Get insights into the day-to-day challenges of builders. In this issue, Peter Reitz from our partner tecRacer talks about how to build Serverless ETL pipelines with Athena and Airflow. Learn how to extract data from data stored on S3, transform and enrich the data, transform it into a format optimized for data analytics and upload the data to S3 for further processing. Would you like to join Peters's team to solve real-world problems with the help of data analytics and machine learning powered by AWS? tecRacer is hiring a Cloud Consultant focusing on Machine Learning and Data Analytics. Apply now! 55 full no Andreas Wittig and Michael Wittig focusing on AWS Cloud

Gestalt IT
The Future of Datacenter is Serverless

Gestalt IT

Play Episode Listen Later Oct 18, 2022 31:57


In this episode, Craig Rodgers, Chris Reed, and Chris Hayner join Stephen Foskett to consider the end of the server itself. © Gestalt IT, LLC for Gestalt IT: The Future of Datacenter is Serverless

AWS Podcast
#551: Deep Dive Into SageMaker Serverless Inference

AWS Podcast

Play Episode Listen Later Oct 17, 2022 16:15 Very Popular


Today Simon is joined by Rishabh Ray Chaudhury, Sr. Product Manager, to learn more about SageMaker Serverless Inference. We will dive deep into some of the customer use cases that Serverless Inference solves, key benefits of the feature, and how customers can leverage this SageMaker feature to reduce machine learning inference costs. Read the blog - https://go.aws/3rUkP3i See the documentation - https://go.aws/3gbjvqh

airhacks.fm podcast with adam bien
From a NetBeans Champion to a Friend of the openJDK

airhacks.fm podcast with adam bien

Play Episode Listen Later Oct 16, 2022 54:32


An airhacks.fm conversation with Geertjan Wielenga (@GeertjanW) about: ZX Spectrum 48k, Pascal and Basic programming at high school, studying law in South Africa, writing documentation at Sun Microsystems for netbeans, Ludovic Champenois on "#153 Java, Serverless, Google App Engine, gVisor, Kubernetes", working for Sun Microsystems in Prague, mike's blog, GlassFish Grizzly, NetBeans RCP, monitoring oil platforms with NetBeans RCP, Victor Orozco on: "#192 Innovation, Clouds, Kubernetes, Standards and Java", NetBeans certification and knowledge sharing, the great performance of NetBeans 15, the Swing Application Framework and JSR-296 and JSR-295, JSR 296: Swing Application Framework, JDeveloper used NetBeans as platform, from Oracle to Apache NetBeans, the challenges of opensourcing code, Geertjan Wielenga on twitter: @GeertjanW

The Changelog
Taking Postgres serverless

The Changelog

Play Episode Listen Later Oct 14, 2022 84:14 Very Popular


This week we're talking about serverless Postgres! We're joined by Nikita Shamgunov, co-founder and CEO of Neon. With Neon, truly serverless PostgreSQL is finally here. Neon isn't Postgres compatible…it actually is Postgres! Neon is also open source under the Apache License 2.0. We talk about what a cloud native serverless Postgres looks like, why developers want Postgres and why of the top 5 databases only Postgres is growing (according to DB-Engines Ranking), we talk about how they separated storage and compute to offer autoscaling, branching, and bottomless storage, we also talk about their focus on DX — where they're getting it right and where they need to improve. Neon is invite only as of the recording and release of this episode, but near the end of the show Nikita shares a few ways to get an invite and early access.

Changelog Master Feed
Taking Postgres serverless (The Changelog #510)

Changelog Master Feed

Play Episode Listen Later Oct 14, 2022 84:14


This week we're talking about serverless Postgres! We're joined by Nikita Shamgunov, co-founder and CEO of Neon. With Neon, truly serverless PostgreSQL is finally here. Neon isn't Postgres compatible…it actually is Postgres! Neon is also open source under the Apache License 2.0. We talk about what a cloud native serverless Postgres looks like, why developers want Postgres and why of the top 5 databases only Postgres is growing (according to DB-Engines Ranking), we talk about how they separated storage and compute to offer autoscaling, branching, and bottomless storage, we also talk about their focus on DX — where they're getting it right and where they need to improve. Neon is invite only as of the recording and release of this episode, but near the end of the show Nikita shares a few ways to get an invite and early access.

Cloud Champions
29. Emanuele Rampichini (Head of Engineering di Spreaker)

Cloud Champions

Play Episode Listen Later Oct 12, 2022 57:13


Da un server on-premises fino a serverless, passando per EC2 e Kubernetes, la storia di Spreaker, una delle più grandi piattaforme di podcasting al mondo, e di come il cloud e un costante focus sulla maturità del team siano stati fondamentali per riuscire a soddisfare le necessità di un business in costante evoluzione.

AWS на русском
022. Что же нового вышло в AWS с конца весны?

AWS на русском

Play Episode Listen Later Oct 11, 2022 33:41


Прошло довольно много времени с момента последнего новостного выпуска, а значит, свежих апдейтов подоспело немало! Что же нового вышло в AWS с конца весны? Подборка материалов и актуальной информации о последних релизах: Новый AWS регион в ОАЭ, а также новость о том, какие регионы в очереди на открытие; Новые инстансы в AWS m6id, c6id, r6id, r6a; Инстансы с 3-м поколением гравитонов (Amazon EC2 C7g) вышли в GA; Cost Management практики - Cost Allocation Tags в EKS и что такое KubeCost; Консолидация нагрузки в Karpenter-е; Всё Serverless с re:Invent теперь GA: Amazon MSK Serverless Now Generally Available–No More Capacity Planning for Your Managed Kafka Clusters Amazon EMR Serverless Now Generally Available – Run Big Data Applications without Managing Servers Amazon Redshift Serverless – Now Generally Available with New Capabilities Amazon SageMaker Serverless Inference – Machine Learning Inference without Worrying about Servers. Если у вас есть вопросы, предложения или темы для будущих подборок, пишите мне в Linkedin - https://www.linkedin.com/in/vedmich/ или телеграмм https://t.me/VictorVedmich

ZipRadio Podcast Powered by Synerzip
Enterprise Modernization and Serverless Automation With AWS

ZipRadio Podcast Powered by Synerzip

Play Episode Listen Later Oct 10, 2022 33:28


In this episode, we talk to expert solution architects from Amazon Web Services about enterprise modernization and serverless automation. The conversation starts by understanding the meaning of enterprise modernization, and then shifts towards the definition of serverless automation. We later dive into the scope, considerations and advantages of serverless automation.

Alexa's Input (AI)
All Things Serverless and Knative with Evan Anderson (Part 1)

Alexa's Input (AI)

Play Episode Listen Later Oct 9, 2022 48:32


Evan Anderson, Senior Staff Engineer at VMWare, joins me on this episode to discuss the meaning of "serverless", his work experience at Google, the development of projects like Kubernetes and Knative, his thoughts around the cloud, managing an open-source project, and much more! Evan graduated with a degree in Computer Science from Dartmouth College. He worked at Google for 15 years and left as a Senior Staff Software Engineer. He now works at VMWare as a Senior Staff Engineer and manages the open-source project Knative. Links: Evan's twitter, linkedin, Knative's YouTube You can support this podcast on the anchor page. Make sure to subscribe and follow Alexa's Input Twitter account to get notified when a new podcast episode comes out. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/alexagriffith/support

GOTO - Today, Tomorrow and the Future
Driving Innovation with Kubernetes & Java • Ana-Maria Mihalceanu & Eric Johnson

GOTO - Today, Tomorrow and the Future

Play Episode Listen Later Oct 7, 2022 32:45 Transcription Available


This interview was recorded at GOTO Amsterdam 2022 for GOTO Unscripted.gotopia.techRead the full transcription of this interview hereAna-Maria Mihalceanu - Developer Advocate at Red Hat & Java ChampionEric Johnson - Principal Developer Advocate for Serverless at AWSDESCRIPTIONTechnology can advance faster if we share our knowledge. That's the mission of a developer advocate. Ana-Maria Mihalceanu, developer advocate at Red Hat, talked to Eric Johnson, principal developer advocate at AWS, about her passion for learning, sharing knowledge, Java and Kubernetes. Discover what a Kubernetes operator is and when to use it vs Terraform.RECOMMENDED BOOKSBrendan Burns, Joe Beda & Kelsey Hightower • Kubernetes: Up and RunningMarkus Eisele & Natale Vinto • Modernizing Enterprise JavaKevlin Henney & Trisha Gee • 97 Things Every Java Programmer Should KnowBurns, Villalba, Strebel & Evenson • Kubernetes Best PracticesAdzic & Korac • Running ServerlessScott Patterson • Learn AWS Serverless ComputingPeter Sbarski • Serverless Architectures on AWSTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.Dev InterruptedWhat the smartest minds in engineering are thinking about, working on and investing in.Listen on: Apple Podcasts Spotify

Makers.dev
90 100% user growth and profitable

Makers.dev

Play Episode Listen Later Oct 6, 2022 70:52


Chris gets another customer for acornchat, which is 100% user growth! Christian is thinking about marketing for FileInbox using SEO, youtube, a new feature, and more.  00:00 Intro  05:55 2nd Acorn Chat user  09:18 Buying Google ads seems hard  16:35 Winning $5k from Kaggle  21:54 Twitter recommendations  30:09 FileInbox SEO changes  38:04 Youtube is underused for SaaS  45:34 File sending feature as a marketing channel  52:11 Serverless transition - using less memory  58:04 Doing more consulting  01:03:51 Making cabinets   Timestamps created with https://clips.marketing by @cgenco   Twitter recommendations:   Massimo: https://twitter.com/rainmaker1973  WeRateDogs: https://twitter.com/dog_rates  PUNS: https://twitter.com/thepunnyworld

Adventures in DevOps
Serverless Platforms and WASM with Connor Hicks - DevOps 134

Adventures in DevOps

Play Episode Listen Later Oct 6, 2022 51:55


Today on the show, Jonathan and Will talk with Connor Hicks, founder of Suborbital, a serverless platform powered by WebAssembly.  They discuss how WebAssembly works, running WASM on the “edge” network, Suborbital's capabilities, and everything in-between. In this episode… WebAssembly on the server The “edge” and edge computing Security, performance, portability WASM in the cloud limitations Virtualized sandboxes Alternatives to edge computing Writing in other languages  What is the learning curve of the security model? Suborbital's capabilities and language support  Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs LinksLinkedIn: Connor HicksPicks Connor- Arm VMs on Compute | Compute Engine Documentation | Google Cloud Jonathan– Boldly Go Jonathan– 14-inch IPS HD computer monitor Will– Crypto Steel Wallet

Software Engineering Daily
Open-source Serverless Postgres with Nikita Shamgunov

Software Engineering Daily

Play Episode Listen Later Oct 5, 2022 47:12 Very Popular


PostgreSQL is a free and open-source relational database management system. Postgres-based databases are widespread and are used by a variety of organizations, from Reddit to the International Space Station, and Postgres databases are a common offering from cloud providers such as AWS, Alibaba Cloud, and Heroku. Neon is a serverless open-source alternative to AWS Aurora The post Open-source Serverless Postgres with Nikita Shamgunov appeared first on Software Engineering Daily.

Podcast – Software Engineering Daily
Open-source Serverless Postgres with Nikita Shamgunov

Podcast – Software Engineering Daily

Play Episode Listen Later Oct 5, 2022 53:28


PostgreSQL is a free and open-source relational database management system. Postgres-based databases are widespread and are used by a variety of organizations, from Reddit to the International Space Station, and Postgres databases are a common offering from cloud providers such as AWS, Alibaba Cloud, and Heroku. Neon is a serverless open-source alternative to AWS Aurora The post Open-source Serverless Postgres with Nikita Shamgunov appeared first on Software Engineering Daily.

FSJam Podcast
Episode 80 - Eleventy with Ben Myers

FSJam Podcast

Play Episode Listen Later Oct 4, 2022 41:01


We need your vote to win a Jam stack Jammie! So, go to https://fsjam.org/vote. There will also be previous guests in other categories, so make sure you vote for them too!-------------------In this episode we discuss the fundamentals of Eleventy, how to approach web development from a conservationist's point of view, and utilizing Eleventy Serverless for deferred, on-demand rendering.Ben Myers Homepage Twitter GitHub Twitch Some Antics showmy.chat Eleventy Homepage Twitter GitHub Discord Links Fullstack Accessibility with Ben Myers (FSJam31) Slinkity with Ben Holmes (FSJam49) Eleventy Data Cascade Documentation I Finally Understand Eleventy's Data Cascade events.lunch.dev Eleventy Serverless A First Look at Eleventy Serverless with Zach Leatherman (Some Antics) Modern CSS with Stephanie Eckles (FSJam63) Incremental Static Regeneration Distributed Persistent Rendering Understanding Rendering in the Jamstack by Brian Rinaldi Eleventy Glossary Learn Eleventy From Scratch by Andy Bell Amit Sheen Codepens THE Eleventy Meetup Full Time Open Source Development for Eleventy, Sponsored by Netlify Transcript[Pre-show Clip]BenWhen I was on Learn with Jason talking about Eleventy Serverless, I actually spent a fair amount of time talking about... "hey, Eleventy doesn't work for every use case." There are certain websites you have in mind that Eleventy would not be a good fit for. That's okay, that just means it's better suited for other kinds of sites. I think there is this instinct in Jamstack communities to try to kludge Jamstack into a fundamentally un-Jamstacky problem space.ChrisWhat do you mean? Gatsby is the best for everything and we should have never moved off Gatsby and there's no need for Svelte or Solid or anything like that. Gatsby, it did everything.[Opening Theme Song]AnthonyBen Myers, welcome back.BenHey! It's good to be back.AnthonyYou were on an earlier episode, 30-something, talking about web accessibility. You are a web developer and accessibility advocate at Microsoft. Today, we're going to be talking to you about Eleventy cause Eleventy is a project that I know you're really passionate about. We've had others on the show talk about it a little bit, especially Ben Holmes who is building a meta framework on top of Eleventy called Slinkity. But, today we're going to be talking about Eleventy proper. What it is, why people are excited about it, and what kind of stuff they're building with it. BenI'm thrilled, I absolutely love Eleventy as a tool and it's one of those things that's been an absolute privilege to get to introduce people to. Fair disclosure! I totally have not introduced people to it through a podcast medium, so this is gonna be very interesting. Super excited to chat about it with y'all.AnthonyWhy don't we first start with what Eleventy is. I think if anyone has heard about it, they know that it's a static site generator. They may have heard that it's based a bit on Jekyll, so if you can talk a little bit about what it does and what you would build with it.BenYeah, so I find that simply saying, "Jekyll but JavaScript" is enough for some people to just get it. I will say that the fact that it is powered by JavaScript makes it more approachable than other static site generators for many people because JavaScript is the language of the web. If you're doing front end development, JavaScript is something you're very likely to be very familiar with. A static site generator that leverages JavaScript, specifically the Node.js ecosystem, is a very compelling sell for a lot of people. But, I should definitely back up and explain the bigger picture.You described it as a static site generator in the vein of Jekyll. I think that's absolutely, absolutely fair. But personally, I don't have experience with Jekyll. That's not something that really helps me understand what it is. The simplest way to think of Eleventy is, it is a tool that will take content, typically in a format such as markdown. It'll take that content, it'll just convert it to some pure, raw, boring, fantastic HTML (or other assets). That is, I think, the simplest way to think of it. You've got some content, maybe it's blog posts, maybe it's documentation pages. Maybe it's a landing page for some product. Some content that is mostly static and you want some output, typically HTML.That is what Eleventy is and what it's really, really good at. What Eleventy isn't, is a tool for building highly dynamic interactive experiences. For those, you might still consider a client side web application framework such as React or Vue. Eleventy simply isn't as interested in addressing those kinds of websites and I think that's totally fair. But if you've got something that could be expressed in static HTML, Eleventy is possibly a very good project for you.AnthonyI actually first started learning about Eleventy for a big reason cause of you, Ben. We were building out the lunch.dev calendar with it. That was a really interesting project because we were trying to create like an events calendar. What we did is we had a Git repo that was building the static site and then we had markdown files for the individual events. Then the individual events would be transformed into little cards on the front end. If you wanna talk a little bit about why you picked Eleventy specifically for building that cause I think Chan also, the reason why we went with that was cause you were really passionate about, we wanted to learn more about it. So I'd be curious about the thought process behind that.BenAn event calendar like that is, if you think about it, nothing but a bunch of articles. At the time, we were not heavily invested in doing anything interactive with that calendar. We just needed a place to stick a bunch of descriptions and details of different events going on, different links that we could send people to. That is, again, something that is very well suited for that kind of static markup. When you think about a lot of web application frameworks, a common criticism that some folks in various web dev spaces will point to, is that web app frameworks can be quite large and bloated.That means if you are building your site with those, your end user very likely will have to download all of that and construct an experience from that. Whereas, you could get more or less the same experience but very, very lightweight. I think that lightweight websites are fundamentally good and responsible. I try to take a very conservation mindset to the web. I like to only use what I need and I apply this to users resources such as their data. If they're out and about on their mobile phone and they're using their data plan, chances are good that they could have a really slow connection and they could have data caps.I think that if we don't need to send them an entire web app framework, we probably shouldn't send them a web app framework. That is, I think, not being the best steward of their resources. They're gonna have a slower chunkier experience as a result. So, why did I choose Eleventy for this project? It's because the project, at least as we were thinking of it at the time, didn't need anything more than that. We just wanted some lightweight HTML pages out there on the web that could build quickly, that anyone could add to.Eleventy is really based around this concept of a template. A template is a content file written in a language such as Markdown or HTML and sometimes with templating languages such as Liquid or Nunjucks that Eleventy builds into a page or pages of HTML (or sometimes other static assets). It's weird because there always feels like there needs to be some asterisks. But broadly, think of a template as a content file that gets transformed into some output pages.The nice thing is Markdown for most developers is a fairly ergonomic experience. That meant that if people wanted to add things to that site, they didn't have to worry about the whole instrumentation and orchestration of the entire project. They could contribute simply a Markdown file and that was really nice. Eleventy also has built into it this concept called the data cascade which I think is one of the most crucial things to understand about Eleventy. It's also one of the things that took me the longest time to wrap my head around. When you're in a template, again a content file, you can use template syntax.Eleventy allows you the opportunity to expose variables essentially in that template syntax that you can either print out onto the page as part of the content or you can transform or operate on them in different ways. It's data, it's variables that you have access to. Eleventy has this amazing order of operations for how it lets you aggregate that data. So you can say, "oh, I've got some data that will be made available to every template of my site." Or, "I've got data that's available to every template that uses a certain layout." Or "I've got data that applies to every template in a given directory or its sub directories." Or, "I have data that corresponds exactly to one template."The lovely thing about this is, it exactly follows the mental model you would hope for something like that. It is powered by co-location. Data that applies much more specifically to an individual template will have a higher precedence over data that corresponds globally. This mental model (once you start playing with it) allows for some really, really powerful configuration of your website. You can almost afford to set it and then forget it which I think is incredibly powerful. You could set some sensible defaults at the global level, such as maybe "every blog post uses this blog post layout that I've defined."Then one blog post you could override that and use a different layout, maybe to accomplish some art direction. You've got a very special blog post that you want to have a special layout. You can change that data as you go. That kind of configuration (once you start wrapping your head around the order of operations) is incredibly powerful and flexible. At the same time, it's magic enough that you can bring new people into the project and they don't have to worry about any of it. I think that is super cool.AnthonySomething that was interesting that came up while we were working on it was, we ended up in a situation where we had to rebuild certain things at certain times. Because the way events work, there'll be an event upcoming then there'll be an event that has passed. You don't want to have stale events still on the homepage. We ended up setting up a cron job type thing with a GitHub Action.But I think that this is the type of thing that now, today if we had been building that there would be other ways to do that. Not even mentioning the new scheduled jobs functions that Netlify just added. But, what I was curious to get more into was the serverless bit. There is now Eleventy Serverless, and you've actually been on the forefront of this. You did a stream with Zach when this first came out and you've been building stuff out with it this whole time.We talked with Stephanie Eckles a little bit about it and I'm really curious to get your take on it cause we've talked about serverless a ton of times here at Redwood it was built on serverless. We love serverless - well I love serverless, I don't know if Chris loves serverless - but I'd love to hear what is Eleventy Serverless and why was it built?BenEleventy Serverless is an opt-in build mode for Eleventy. Typically with Eleventy, everything is pre-rendered. You have a build step, you run probably `npm run build` if we're being honest. Eleventy kicks in and picks up all your templates and then converts them into HTML files. Once they're built, they're built. If data changes behind the scenes, such as data that was fueled by an API, you don't get any updates to that because there's nothing in the HTML linking that data like real data in any sort of backend. It's just pure HTML.This meant that Eleventy has historically been very limited. Eleventy could only reflect what was true at build time. Eleventy Serverless is this new opt-in build mode for Eleventy, where you can say certain templates are built whenever you request them. Again, non-Eleventy people should probably read that as either "certain pages are built when you request them", or I prefer to think of it as "certain routes are built when you request them." I think that framing gets really, really powerful because you can use Eleventy's data cascade, you can use Eleventy's front matter and templating languages.All the stuff that you absolutely love about Eleventy, you can use but in this on-demand way, this on request way. You create a page as you request it and if you're using, for instance, Netlify's on-demand builders, you can then cache that page. It's as if you had built that page in the build step. This is hugely powerful for a couple of reasons. I use this demonstration when I go on people's streams to talk about Eleventy Serverless. It's a color contrast checker. Take two Hex codes and display in this pretty format, the color contrast ratio. If you have two Hex codes, which are six digits long each, then that is - I want to say 2.75 times 10 to the 14th contrast ratio.I don't wanna build that. I don't want my dev server building that. I don't want my Netlify high build minutes building that, that's incredibly wasteful. I love to defer building those kinds of things until they're needed, because chances are the vast majority of those contrast ratios will never see the light of day. Very few of the ratios on that site will ever be explored, so why build them? Eleventy Serverless is a great way to defer building a large data set that folks might not ever look at. You also don't have to cache by default. Eleventy Serverless built pages don't cache. You have to use specific things like on-demand builders to cache.But what that means is that you can have up to date data. During the on request build you can hit an API and you can get the latest, greatest up-to-datest data. I think that is incredibly powerful. That is something that we haven't really had in Eleventy before. But at the end of the day, what gets sent over the wire is still an incredibly lightweight HTML page. It's not a whole client side page that's holding in a large framework. You don't have to worry about things like loading spinners because all the fetching is done server-side. You don't have to worry about things like authentication because all the fetching is done server-side.You get to take advantage of everything that you love about serverless functions and everything that you love about Eleventy. I've also brought up a couple times that this is opt-in. I really love this because you aren't turning your whole site suddenly into a quote unquote "serverless site." You first opt-in by installing the serverless plugin and then you still have to opt-in on a template by template basis. The core of your website, the main pages that guaranteed people are gonna hit (like your landing page, about page, and stuff like that) are still built during the build step and are still totally cached.They're still available for search engines to crawl and all of that. It's just that this one subsection of your site is now served on-demand. I think that that is super exciting. Another benefit of Eleventy Serverless routes is that you can take advantage of arguments passed in the URL. You have parameters in the path, or you could have query parameters, for instance. This allows for some really dynamic experiences all. Anthony, you've alluded to, I've got this project that I built that is designed really to test what I believe is the absolute limit of Eleventy Serverless.This product is showmy.chat. Anyone who's been in the streaming biz will know that it's very common for Twitch streamers to use websites as part of their stream layout. A very common use case for this is showing your chat bot as part of your stream so that folks can see who's interacting with the stream. It's really exciting, "look at me, Mom, I'm famous. I'm on my favorite Twitch streamers stream." Doing anything like that requires some understanding of web development and WebSockets to be able to read from the chat. This is not something I feel like people should not have to worry about.So, I built this site, showmy.chat. It allows you to put in your channel name as well as set a couple of other properties, configure a couple of extra values there. It will generate using Eleventy Serverless a page that has all of the WebSocket logic, the action to display the chat, and all of the theming all set in place for you. You get this on-demand themed chat that responds to the arguments that you passed in through the query parameters. Do I think that Eleventy Serverless was the right tool for that job? I'm not entirely sure.I've actually been kind of considering maybe looking and seeing if I could have done the same thing, but maybe more flexibly using something like SvelteKit. But I think that it's incredibly exciting that Eleventy, which has been this kind of beloved pre-build tool now affords you this extra flexibility where just because you wanted a page that always had dynamic stuff or the latest information, you don't have to like opt into a completely different framework. Now, you can still say within the Eleventy ecosystem that you love.ChrisThat was a lot. I've literally just been sitting here just like absorbing it all in. I feel like a mega React, Chad, when I say, "Yeah, but you didn't say any of the buzzwords. SSG, ISR, SSR..."AnthonyI think DPR would be one of them technically, right? Distributed persistent rendering?ChrisYeah, haha.BenThe Venn diagram of all of these words is a very pretty butterfly and also inscrutable to anyone outside of the space. For folks at home who are playing buzzword bingo, it's Eleventy's implementation of distributed persistent rendering, or sometimes not distributed persistent rendering, Brian Rinaldi calls it deferred rendering. That's the term I like. It's deferred rendering. Everyone's got their own different take depending on whether they're a framework or whether they're a CDN. It's deferred rendering that's most similar to - I think Gatsby now has, I forget what they're calling it now.ChrisI think they're calling it deferred... incremental deferred rendering? Something like that.Ben MyersThis is exactly why I'm just using Brian's term of deferred rendering. If you're looking at this and going, "What's Eleventy's version of incremental static regeneration" or something like that, the closest thing is Eleventy Serverless. What is distributed persistent rendering? It's Eleventy Serverless hooked up to on-demand builders. That's what we're talking about. Hopefully that helps for people who are hoping to play buzzword bingo. The crux of it is you hit a route and Eleventy is run in the serverless function to create a page for you in basically real time.ChrisThe reason I say all the buzzwords is because sometimes they help define where it sits in the market, and sometimes they really do not. And this is where we talk about like functionality is obviously what really makes people understand what all these terms. Things like Next have this, Gatsby have this. For example, you build a website, let's say an e-commerce store, really easy and you add a new product. Does that product then just get rendered onto the website using like a webhook, or does that product only show if that specific URL is then entered? Because then Serverless knows to run and make that page?BenServerless is still in its infancy, but it would really depend on your implementation. I know Zach is still working on having serverless routes that have been created, but then saved can now get added to like what Eleventy calls collections (which are arrays of templates). You could be able to then display it on the rest of the site. Truthfully, I haven't done a whole lot with that. I think it would depend a lot on your implementation. It's in the moment the on request (your server function that's handling that) is looking for any arguments that you supply it in the URL. Either through the structure of the URL itself or through query parameters. You're probably passing in a SKU or some other identifier in there. It would look up some known database or API and be able to render that for you.ChrisThis is actually what I've personally seen with all these different types of rendering methods is that you chuck out the complete build, they add a new product and go, "it's not in the store." I'm like, "well it is on the store," if you know the URL, but you need to go to the URL for it to appear on the rest of the store. Cause that means the website now knows about it. It's like, how do you explain that to someone not technical? They need to know the URL to go to the right product to then appear on the rest of the website. It's like, "I thought this was meant to save millions and time on all these things." It's still a really complicated subject. One of the really big things that I wanted to ask is, what Serverless is sending down the pipe back to the client is not rehydrated JavaScript or JavaScript JSON, it's just HTML?BenYes. Just pure boring, lovely, fantastic, delightful HTML. Which means that it's gonna be fairly lightweight. Really, the way to think about this is, "this is how the web used to work and in many places still does." This is what we now call server rendering. Except you don't have to own a persistent server and you're very likely not doing anything with sustained sessions or anything like that. But the meat of, "I go talk to a server and I ask for a page and the server builds me that page on the fly," it's that, that's what's going on. I'm waving my hands doing jazz hands - imagine sparkles around this - it's now **Jamstack**! That's what it is. But it's bringing that kind of server functionality into a tool (into a framework, whatever you wanna call it) that previously has been prebuilt.You create a directory of HTML files and then that directory of HTML files is yours to do whatever you want with. You could FTP that into some server and just host that directly. You could FTP that into a CDN. Or you could do what I do, which is I have a Git based workflow hooked up to a CDN (in this case, Netlify). Every time I push to my repo, Netlify rebuilds but you don't have to have any of that instrumentation and orchestration. You could just upload some boring old HTML to a server and host that. This provides the same lightweight end user experience where you're getting just HTML. It's not HTML that we then rehydrate down the road and replace your entire page with this app behind the scenes that hopefully you won't notice. It's just HTML, it's lightweight, it's easy to cache.It's a little friendlier for search engines to optimize. When all you need is static HTML on a page and not a whole lot of dynamic interactive stuff, it's fantastic. It's glorious. I think the performance thing is an interesting conversation. I don't know if y'all know this. But right now we are in the middle of a pandemic and this means businesses have taken measures around this pandemic. There have been a small handful of times I have gone out to eat at a restaurant. On the tables, instead of giving me menus, there are table tents that have QR codes I can scan to pull up their menu. This, to me, is an example of a wonderful idea to meet user's needs that typically fails miserably in the execution.When I scan the QR code, it pulls up the restaurant's website and the restaurant has used some site builder or something else that sends over gobs and gobs of JavaScript. A whole framework likely or at the very least probably jQuery, sending over a whole lot of stuff. I don't know if y'all have this experience, but every restaurant I seem to go to seems to have poor internet connection there. I don't have great connection there; I don't have great reception. It takes me, like, 20 seconds where there's just this spinner and then I get to see a list of foods, which is mostly text. Sometimes there's pictures but the pictures are strictly optional. That feels to me like no one quite anticipated this pandemic (restaurants least of all) and rearchitecting your website is an expensive process that you can't just say, "oh, just remake your website with faster stuff."But we are several years into this now. Folks haven't looked at this and gone, "huh, those slow websites at our own restaurant to pull up our own menu, that's an area of opportunity for improvement there." Especially considering that when people are out and about, they're often in those kind of reception dead zones, such as a restaurant. They're operating off of finite data caps. They don't need gizmos and widgets and all sorts of interactive stuff. They just want to see what kind of food they can buy at your restaurant. There are times where having tools that make it really easy and flexible to just serve some boring, static HTML is exactly what your users need. Having that developer experience to make that easier is just gorgeous.ChrisYes, but I have two counterpoints.BenI'm ready to hear them.ChrisOne, "But JavaScript. I can write my CSS in JavaScript. I can write my HTML in JavaScript. I can just write JavaScript" and two, "Hey, you're a captive audience in a restaurant. Of course, they want you to sit there a little bit longer."BenWell, I mean, I think both of those arguments are very fair. But I think that too often we look at JavaScript as this great enabler and don't think of it as also a responsibility and a possible point of failure. Here's an example I sometimes use because I think documentation sites are a fantastic use case for Eleventy. I would like you to envision we're building a documentation site for some library we've made. As is the custom, we want to show how many GitHub stars this library. In the React ecosystem, it's fairly commonplace to set up a fetch to the GitHub API and display that. But what if the GitHub API is down? Well, I sure hope you set up some error boundaries and stuff like that.What if the GitHub API isn't down but it's really sluggish? Well, I certainly hope that you set up loading states. You have a lot of complexity around a part of the page that honestly no one cares about. You incur risk and you incur complexity over such a minor part of the page. I think that sometimes that stuff is incredibly valuable and stuff to consider and to consider how do we do this responsibly? Of course, yes, we could work around the foot guns. We could build a robust, resilient experience. But I think it's also interesting sometimes to ask, "how critical is this really?" Could we get away with having the result of how many stars our GitHub project has? Could we get away with having that be just hard coded texts in the built HTML that gets updated with a nightly built? Is that acceptable in some cases?No, it won't be, but in many cases it totally could be. You say, "oh, we've got JavaScript" and I say, "sure, but it might be more resilient in the backend." We don't have to worry about the costs and the risks and the complexity around doing all this stuff client side. As for a captive audience, I mean sure, but no one's gonna look at that and go, "ah yes, this restaurant was very fancy and stuff like that and I sure did feel very fancy waiting on my phone to pull up this menu in the middle of this steak restaurant going, 'it'll load, I promise. Do I need to refresh this another few times?'" It's all about different experiences and there is no one size solution that fits everything.ChrisYeah, I would've walked out the restaurant if the website was made in PHP. Just not for me. I don't care how rare you like your steak, this ain't for me! Um... no, all jokes aside, Eleventy Serverless looks really, really cool. I think one of the things that is really cool about it is, what it's spitting out is HTML. So many times when it comes to like, if you even think about Next's implementation or Gatsby, do I even know what it's spitting out? Kind of... to what I understand, it's just JSON. It spits out a massive JSON chunk that then gets stored in the HTML file that then gets rehydrated into the client. To what I understand! When you see those messages in Next.js saying, "Hey, your ISSG step is a bit too big," it's because you are literally dumping a massive JSON object into a script tag for Next.js to read later. If you didn't know.Ben MyersI don't want bash on those tools. I think there's absolutely a time and a place for them. But there's a time and a place for boring old HTML as well. And Eleventy... amazing.ChrisAnd I think what's the most amazing thing about all this is that we're still very early. It's still all very early. Even what Next.js is doing, who you could say have been doing SSG for the longest time. We're still so early when we talk about things like frameworks like Marko who have been in the industry for like 10 years. Everything is still so early in this area. The more capabilities that we have with less abstraction, I think the better. I think what's really interesting is what you just said about it's opt-in, not automatically there. It still works as expected, but if you want to add this, then you get it.So many times when it comes to things like say Next.js or Gatsby, I use next Next.js all day every day, so I don't mind bashing it. Do I even know how much JavaScript it sends to the client by default? Well, I hope it's not a lot. What we tend to forget is when I say about the question, "I know JavaScript, I could just write everything," is that I've made an abstraction line that is so high because it's all in JavaScript that so much performance can be potentially lost. You are technically compiling down CSS, HTML, JavaScript by default. What Eleventy is doing is just saying, "Look, you know HTML, you know CSS. Just send that down the wire and that is good enough for 80% of use cases like a blog or documentation."BenAnd now with Serverless, you compliment the sites that are already built with static. A fantastic example, and I wanna give a shout out to both Brian Robinson and Stephanie Eckles who have done this kind of stuff. You can have your blog and the meat of your blog is all built statically ahead of time during a pre-build step. Great, using serverless you could add a search bar to that site. Now your search pages are generated serverless based on your search query. But the meat of your website is still that static, cached, search engine friendly version of your site so it's all additive.ChrisThat's what makes it really good. So much of the ecosystem right now is taking, like, your Ford Rapture by default. You're not starting with the smallest car you possibly can. It's like, "we got the biggest engine to do the school trip in." It's not like, "let's start with a really small city car," it's like, "take everything and just use it."BenAbsolutely.AnthonyOne of the other things I wanted to get into is, I know that you've been working a lot on adding to the Eleventy documentation. You've written a ton of blog posts about Eleventy. I think for the most part, when people want to explain the data cascade to people, your blog post is kind of the canonical example that is usually linked to. I would be curious, when you were looking at the Eleventy docs, where did you see areas that you felt you could add value?BenOne pull request that actually got merged in not long ago was I defined a bunch of terms because I was looking around for a definition of, for instance, the word "template." The definition that I eventually ended up adding to the site was the one that I gave y'all. "A content file, typically in a language such as HTML and Markdown that gets processed by a template language and gets built as output." I had the opportunity to add that to the site because I actually couldn't find anything like that anywhere on the site. I think that the Eleventy documentation right now is fantastic at showing you the breadth of Eleventy's API.But a room for opportunity I see is, onboarding new people to Eleventy. As it stands, the getting started guide as you build a template and then run Eleventy to build a site using that template, and then it kind of just goes, "Tada! Welcome to Eleventy!" I would love to see more resources from the ecosystem, but especially more resources in the core Eleventy documentation around how to take that getting started guide and build a fully fledged application that you could host something pro on. So that's a room for growth, I think. I think that is going to require kind of some more explicit step-by-step walkthroughs.I think that's also going to require a bit more tying pieces together, like painting a bigger picture of that. Which is why, for instance, I wrote that data cascade post. Eleventy has some great pages about each step of the data cascade. But painting that as one big picture - with the sense of when should you use one step or method versus when should you use another step or method - that was something that I felt was missing. that's something that I'm hoping to contribute more and more. I think it's a bit of a slow process. You don't wanna boil the ocean. You don't want to contribute every update all at once. This is something that I'm doing in a bit of my free time just here and there. Maybe I'll add a page or I'll add to a page that already exists but provide a bit more of the context in (what I hope is) a beginner, newcomer, friendly way to help them really understand why does this fit into the bigger picture of an Eleventy project.This is a sentiment I've heard a couple times in the Eleventy space and I don't wanna bash on the Eleventy docs. I do think that they are great and again, they reflect the breadth of Eleventy's API. But this is something that, right now, there is a need for. People are writing blog posts and making videos that rise to that need. If you're listening to this and you, yourself do Eleventy (or if you're learning Eleventy) I would say right now the community needs you. The community could really benefit from you writing about your experiences and the things you learned. The real practical step by step process of how you built the thing that you've built whether that's on your own blog post or on your own YouTube channel or maybe it's in some way contributed to the documentation.I have no official affiliation with Eleventy, but this is something that I'm seeing more and more that folks should benefit from. That is the encouragement I would give. I think this is what we need to see. Eleventy just hit 1.0 recently and that marks it as a mature product. I would love to see us figure out more and more ways to bring people into the fold. I myself learned Eleventy through Andy Bell's course "Learn Eleventy from Scratch," which used to be a paid course. It's now open and free, but no longer being updated. I think more resources like that, which take you from the docs (which can sometimes be very API focused) to something that is instead methodological in its design. I think it's something that Eleventy could benefit from.AnthonyI would use the term explanatory.ChrisOne of the favorite things that I love, something you said earlier that I wish all frameworks said is as simply this. We can do everything, but we are not good at everything. You should use this for X and Y type of websites and if it's not X or Y, go look at something else. And you said documentation and blogs and homepages, that's what Eleventy is really good at. Don't go try build a dashboard in it.BenAbsolutely and it's like, it could be done and I think that there is value in experimenting. Using a thing far beyond what it was meant to do is something I see a lot with the CSS space. Amit Sheen's work is using CSS to create hyper realistic 3D animations. This is so far beyond the realm of what anyone ever intended of CSS. But we learned something as a community from pushing CSS to its limits. We learned techniques that we can use in the day to day. So it's not to say you can't build hyper interactive dashboards with Eleventy. You can certainly learn some things from that. But if you're trying to publish, if you're trying to deploy to production and you're trying to have a resilient app - those kinds of things - probably Eleventy isn't on the table for you and that's okay.But I've definitely had this moment where I'll be working someone individually through Eleventy to rebuild their blog. They'll be coming from like a React mindset. Suddenly I show them how they could create something that looks identical to their blog but as HTML. There's that moment that clicks where they've been using a tool that wasn't intended for the. Now, they have a tool that was actually meant for that kind of thing, and it unlocks something in them. That is, I think, a huge takeaway. There's no one size fits all, but that means that the one size that fits all that you're thinking of, isn't a one size fits all.ChrisVery true. Building blogs with Next and Gatsby, it's pretty overkill when you could just send sweet, sweet HTML.BenMm-hmm.AnthonyYeah. I was really happy that you were working on the docs cause I know I've struggled with the docs and I know others have as well. But as you said, just bashing the docs doesn't solve anything or make anyone feel good. Especially when Zach spent so much of his own, free time creating this project. When you see things like that, contribute back. Especially if you're someone who's in a position to help with things like documentation and explanation. That's really awesome, that's very much the spirit of open source, so I'm happy you did that.BenI think in general, people benefit from having multiple possible explanations for things. If Zach is the only person writing documentation, then everything is going to be oriented around how Zach understands things. Zach has a lot of great context into the inner workings of Eleventy, as well as the inner workings of the web. But Zach is not everyone. I'm not everyone. The two of y'all aren't everyone, right? Bringing more people to the table documentation wise, means we can get a better diversity of explanations that can work better for a wider diversity of people who are coming to this project. That is awesome.AnthonyIs there anything else about Eleventy you want to talk about before we wrap it?BenWe touched a bit on how it's HTML and I think that part itself is really huge. I feel like I've become a more robust developer as a result because I can't just rely on a component to do things for me. I have to think about, what is the best markup for this and what are the scripts that I have to write to make this work robustly? I've been very fortunate that Eleventy has improved me as a developer and I'm super, super excited to see how much the community is growing. It feels like it's exploded in popularity recently, I think in part to the Learn Eleventy from Scratch Course by Andy Bell and I think in part due to things like The Eleventy meetup that have been organized by Sia Karamalegos, Stephanie Eckles, and Thomas Semmler.There's a lot more community outreach and stuff like that. I'm just incredibly excited to see this project grow. It just received full-time open source funding from Netlify, which means Zach is now paid to work on Eleventy full time. Already we've seen some longstanding pull requests get merged in that have enabled different things. The more people we could get in on this project, the more cool things we can build. Absolutely dive into Eleventy. See what you can build and see what you can break. See how you can make something that you previously might have wanted a whole framework for. See if you can build something lightweight, robust, semantic, performant, and just see what a different way to build is.AnthonyYep. And if you hit any roadblocks, check out Slinkity.BenThere we go. Yes.AnthonyGo ahead and let our listeners know where they can find more about Eleventy or more about yourself.BenYeah, so if you want to learn about Eleventy, the documentation can be found at their website, which is 11ty.dev. Eleventy kind of has two spellings. It's a whole thing. I'm sure the link will be in the show notes. There's multiple links on there to find the documentation. Poke around, see if you can find the Easter eggs there because it's delightful. The documentation button is incredible. If you wanna find me out and about on the web, I'm on Twitter at BenDMyers. Again, I'm sure that link will be in the show notes. And I host a weekly Twitch show, which Anthony has been a part of four times now.I think he was the inaugural guest and he's still the person who's been on the most times. It's called Some Antics. Every week I bring on a guest from around the web development and web design industry to teach me something about building a great user experience for the web in a hands on way with a focus on accessibility and/or core web technologies. You can find that at twitch.tv/someanticsdev. That's S-O-M-E-A-N-T-I-C-S-D-E-V, someanticsdev. I look forward to hearing from y'all. I look forward to seeing what y'all build, what y'all make, what y'all are learning, what you're doing. My cat has just jumped off the bed in a clunky, noisy way.AnthonyTuna wants to be on the show.BenYes. I think that probably means he is done with this podcast as well.AnthonyThank you so much, Ben. It's always a pleasure getting to speak with you.BenLikewise!AnthonyWe appreciate your time and hope to have you back soon.BenSee y'all later.[Post-show Clip]ChrisI remember back in the Gatsby days when you'd have 10,000 pages. You're like, "I just wanna rebuild just that one page!"BenYep. Even Eleventy beat them to that punch.ChrisWow, I should learn more about Eleventy.BenIt's almost as though we need a podcast episode about it.AnthonyOkay, that's our pre-show clip. Perfect. Okay, let's do it. Ready?BenYes sir.

The MongoDB Podcast
Ep 130 Serverless with MongoDB and Google Cloud Run

The MongoDB Podcast

Play Episode Listen Later Sep 27, 2022 21:43


In this episode, Mike Lynn chats to Abi from Google and Mira from MongoDB to talk about all things serverless and full stack application development in the cloud. They speak about the main reasons to use serverless and why you should use serverless technologies for your development. Topics covered include Docker, Containers, Jib (for building Java Docker images), environment variables, development vs production environments, how to connect to MongoDB, security, and when to consider developing for serverless (hint - when there's significant need for scaling, reducing maintenance and freeing up developers!!) Tune in to listen to what Abi and Mira have to share.

Ditching Hourly
Paul Swail - Getting Paid To Uncover Value With Roadmapping Engagements

Ditching Hourly

Play Episode Listen Later Sep 27, 2022 43:02


Serverless expert Paul Swail joined me on Ditching Hourly to share how he uses paid diagnostic engagements to help land large projects without the pressure of conducting a single sales interview. Paul's Links: https://serverlessfirst.com/ https://twitter.com/paulswail

Remotely Interesting
039: The Jamstack Revisited - A Modern Context

Remotely Interesting

Play Episode Listen Later Sep 26, 2022 44:09


Welcome to Remotely Interesting brought to you by Netlify. The Jamstack definition is a lot different than it was when it first released, so let's talk about where the Jamstack is today and how people can get involved with special guest Domitrius Clark!

AWS Developers Podcast
Episode 053 - Developing for Observability and Sustainability with Danilo Poccia - Part 2

AWS Developers Podcast

Play Episode Listen Later Sep 23, 2022 25:46


In this episode, Dave continues his chat with Danilo Poccia, Chief Evangelist, EMEA at Amazon Web Services. Amazon Web Services is focused on powering all operations with 100% renewable energy by 2025 and committed to achieving Amazon's goal of net-zero carbon by 2040. In this second part, Danilo shares specific guidance for developers around using storage and compute services, instance types, data retention, open-source libraries, and more to help maximize sustainability in their modern applications. You can listen to part one of this conversation in Episode 052. Danilo on Twitter: https://twitter.com/danilop Danilo on LinkedIn: https://www.linkedin.com/in/dpoccia/ Danilo's Website: https://www.danilop.net/ [CODE] Rust – Rayon, Data-parallelism Library: https://docs.rs/rayon/latest/rayon/ [CODE] Rust – Tokio, Async runtime for Rust: https://tokio.rs/ [GIT] Firecracker - Secure and Fast microVMs for Serverless: https://github.com/firecracker-microvm/firecracker [GIT] simdjson Library – Fast Parsing of Files in JSON: https://github.com/simdjson/simdjson [PORTAL] AWS Bottlerocket - Linux-based OS Purpose-built to Run Containers https://aws.amazon.com/bottlerocket/ [PORTAL] AWS Customer Carbon Footprint Tool: https://aws.amazon.com/aws-cost-management/aws-customer-carbon-footprint-tool/ [PORTAL] AWS Graviton Processor: https://aws.amazon.com/ec2/graviton/ [PORTAL] AWS Inferentia - High Performance ML Inference Chip: https://aws.amazon.com/machine-learning/inferentia/ [PORTAL] Sustainability at AWS and Across Amazon: https://aws.amazon.com/sustainability [PORTAL] Sustainability Resources: https://aws.amazon.com/sustainability/resources [PORTAL] Sustainability in the Cloud: https://sustainability.aboutamazon.com/environment/the-cloud [YOUTUBE] AWS re:Invent 2021 - Architecting for Sustainability: https://youtu.be/3-Zq2W1-odU [YOUTUBE] AWS re:Invent 2021 - Sustainability in AWS Global Infrastructure: https://youtu.be/Dmz45WhXENs 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

Adventures in DevOps
Observability and Serverless Intelligence Platforms with Aviad Mor - DevOps 132

Adventures in DevOps

Play Episode Listen Later Sep 22, 2022 52:47


Aviad Mor is the CTO and co-founder of Lumigo, a serverless intelligence platform that helps developers understand and troubleshoot serverless applications.  Today on the show, Jonathan Hall interviews Aviad to discuss observability within DevOps and the future of serverless. In this episode… Observability and Lumigo Linux Kernel MRTG tool Managing distributed systems What is “serverless”? Tracing optimization Onboarding with Lumigo Black boxes and Kubernetes Observability tools  Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs Links Lumigo - Serverless Monitoring and Troubleshooting Platform Monitoring Cloud Native Microservices - Lumigo LinkedIn: Aviad Mor Twitter: @AviadMor Picks Aviad- Islands in the Stream Jonathan- A World Without Email: Reimagining Work in an Age of Communication Overload

COMPRESSEDfm
085 | Casual Conversations on Github Copilot, Frameworks, Desk Setups, Serverless, and More

COMPRESSEDfm

Play Episode Listen Later Sep 21, 2022 46:02


In this episode, James and Amy answer questions from the audience about Github Copilot, modern frameworks, Serverless vs Express.js, PlanetScale vs Supabase vs Firebase, and more!SponsorsZEALZEAL is a computer software agency that delivers “the world's most zealous” and custom solutions. The company plans and develops web and mobile applications that consistently help clients draw in customers, foster engagement, scale technologies, and ensure delivery.ZEAL believes that a business is “only as strong as” its team and cares about culture, values, a transparent process, leveling up, giving back, and providing excellent equipment. The company has staffers distributed throughout the United States, and as it continues to grow, ZEAL looks for collaborative, object-oriented, and organized individuals to apply for open roles.For more information visit codingzeal.comVercelVercel combines the best developer experience with an obsessive focus on end-user performance. Their platform enables frontend teams to do their best work. It is the best place to deploy any frontend app. Start by deploying with zero configuration to their global edge network. Scale dynamically to millions of pages without breaking a sweat.For more information, visit Vercel.comDatoCMSDatoCMS is a complete and performant headless CMS built to offer the best developer experience and user-friendliness in the market. It features a rich, CDN-powered GraphQL API (with realtime updates!), a super-flexible way to handle dynamic layouts and structured content, and best-in-class image/video support, with progressive/LQIP image loading out-of-the-box."For more information, visit datocms.comShow Notes00:00:00 - Intro00:02:16 - Github Copilot Controversy00:15:08 - Sponsor: DatoCMS00:16:02 - Thoughts on Next JS,Redwood, Remix, and More00:23:27 - Sponsor: ZEAL00:24:22 - Desk Cable Management 00:30:25 - Serverless vs Express.js00:34:50 - Prisma and PlanetScale00:37:17 - Sponsor:  Vercel00:38:24 - Script for YouTube Images00:39:42 - PlanetScale vs Firebase vs Supabase

Screaming in the Cloud
Azul and the Current State of the Java Ecosystem with Scott Sellers

Screaming in the Cloud

Play Episode Listen Later Sep 20, 2022 36:35


About ScottWith more than 28 years of successful leadership in building high technology companies and delivering advanced products to market, Scott provides the overall strategic leadership and visionary direction for Azul Systems.Scott has a consistent proven track record of vision, leadership, and success in enterprise, consumer and scientific markets. Prior to co-founding Azul Systems, Scott founded 3dfx Interactive, a graphics processor company that pioneered the 3D graphics market for personal computers and game consoles. Scott served at 3dfx as Vice President of Engineering, CTO and as a member of the board of directors and delivered 7 award-winning products and developed 14 different graphics processors. After a successful initial public offering, 3dfx was later acquired by NVIDIA Corporation.Prior to 3dfx, Scott was a CPU systems architect at Pellucid, later acquired by MediaVision. Before Pellucid, Scott was a member of the technical staff at Silicon Graphics where he designed high-performance workstations.Scott graduated from Princeton University with a bachelor of science, earning magna cum laude and Phi Beta Kappa honors. Scott has been granted 8 patents in high performance graphics and computing and is a regularly invited keynote speaker at industry conferences.Links Referenced:Azul: https://www.azul.com/ 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: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest on this promoted episode today is Scott Sellers, CEO and co-founder of Azul. Scott, thank you for joining me.Scott: Thank you, Corey. I appreciate the opportunity in talking to you today.Corey: So, let's start with what you're doing these days. What is Azul? What do you folks do over there?Scott: Azul is an enterprise software and SaaS company that is focused on delivering more efficient Java solutions for our customers around the globe. We've been around for 20-plus years, and as an entrepreneur, we've really gone through various stages of different growth and different dynamics in the market. But at the end of the day, Azul is all about adding value for Java-based enterprises, Java-based applications, and really endearing ourselves to the Java community.Corey: This feels like the sort of space where there are an awful lot of great business cases to explore. When you look at what's needed in that market, there are a lot of things that pop up. The surprising part to me is that this is the direction that you personally went in. You started your career as a CPU architect, to my understanding. You were then one of the co-founders of 3dfx before it got acquired by Nvidia.You feel like you've spent your career more as a hardware guy than working on the SaaS side of the world. Is that a misunderstanding of your path, or have things changed, or is this just a new direction? Help me understand how you got here from where you were.Scott: I'm not exactly sure what the math would say because I continue to—can't figure out a way to stop time. But you're correct that my academic background, I was an electrical engineer at Princeton and started my career at Silicon Graphics. And that was when I did a lot of fantastic and fascinating work building workstations and high-end graphics systems, you know, back in the day when Silicon Graphics really was the who's who here in Silicon Valley. And so, a lot of my career began in the context of hardware. As you mentioned, I was one of the founders of graphics company called 3dfx that was one of, I think, arguably the pioneer in terms of bringing 3d graphics to the masses, if you will.And we had a great run of that. That was a really fun business to be a part of just because of what was going on in the 3d world. And we took that public and eventually sold that to Nvidia. And at that point, my itch, if you will, was really learning more about the enterprise segment. I'd been involved with professional graphics with SGI, I had been involved with consumer graphics with 3dfx.And I was fascinated just to learn about the enterprise segment. And met a couple people through a mutual friend around the 2001 timeframe, and they started talking about this thing called Java. And you know, I had of course heard about Java, but as a consumer graphics guy, didn't have a lot of knowledge about it or experience with it. And the more I learned about it, recognized that what was going on in the Java world—and credit to Sun for really creating, obviously, not only language, but building a community around Java—and recognized that new evolutions of developer paradigms really only come around once a decade if then, and was convinced and really got excited about the opportunity to ride the wave of Java and build a company around that.Corey: One of the blind spots that I have throughout the entire world of technology—and to be fair, I have many of them, but the one most relevant to this conversation, I suppose, is the Java ecosystem as a whole. I come from a background of being a grumpy Unix sysadmin—because I've never met a happy one of those in my entire career—and as a result, scripting languages is where everything that I worked with started off. And on the rare occasions, I worked in Java shops, it was, “Great. We're going to go—here's a WAR file. Go ahead and deploy this with Tomcat,” or whatever else people are going to use. But basically, “Don't worry your pretty little head about that.”At most, I have to worry about how to configure a heap or whatnot. But it's from the outside looking in, not having to deal with that entire ecosystem as a whole. And what I've seen from that particular perspective is that every time I start as a technologist, or even as a consumer trying to install some random software package in the depths of the internet, and I have to start thinking about Java, it always feels like I'm about to wind up in a confusing world. There are a number of software packages that I installed back in, I want to say the early-2010s or whatnot. “Oh, you need to have a Java runtime installed on your Mac,” for example.And okay, going through Oracle site, do I need the JRE? Do I need the JDK? Oh, there's OpenJDK, which kind of works, kind of doesn't. Amazon got into the space with Corretto, which because that sounds nothing whatsoever, like Java, but strange names coming from Amazon is basically par for the course for those folks. What is the current state of the Java ecosystem, for those of us who have—basically the closest we've ever gotten is JavaScript, which is nothing alike except for the name.Scott: And you know, frankly, given the protection around the name Java—and you know, that is a trademark that's owned by Oracle—it's amazing to me that JavaScript has been allowed to continue to be called JavaScript because as you point out, JavaScript has nothing to do with Java per se.Corey: Well, one thing they do have in common I found out somewhat recently is that Oracle also owns the trademark for JavaScript.Scott: Ah, there you go. Maybe that's why it continues.Corey: They're basically a law firm—three law firms in a trench coat, masquerading as a tech company some days.Scott: Right. But anyway, it is a confusing thing because you know, I think, arguably, JavaScript, by the numbers, probably has more programmers than any other language in the world, just given its popularity as a web language. But to your question about Java specifically, it's had an evolving life, and I think the state where it is today, I think it's in the most exciting place it's ever been. And I'll walk you through kind of why I believe that to be the case.But Java has evolved over time from its inception back in the days when it was called, I think it was Oak when it was originally conceived, and Sun had eventually branded it as Java. And at the time, it truly was owned by Sun, meaning it was proprietary code; it had to be licensed. And even though Sun gave it away, in most cases, it still at the end of the day, it was a commercially licensed product, if you will, and platform. And if you think about today's world, it would not be conceivable to create something that became so popular with programmers that was a commercially licensed product today. It almost would be mandated that it would be open-source to be able to really gain the type of traction that Java has gained.And so, even though Java was really garnering interest, you know, not only within the developer community, but also amongst commercial entities, right, everyone—and the era now I'm talking about is around the 2000 era—all of the major software vendors, whether it was obviously Sun, but then you had Oracle, you had IBM, companies like BEA, were really starting to blossom at that point. It was a—you know, you could almost not find a commercial software entity that was not backing Java. But it was still all controlled by Sun. And all that success ultimately led to a strong outcry from the community saying this has to be open-source; this is too important to be beholden to a single vendor. And that decision was made by Sun prior to the Oracle acquisition, they actually open-sourced the Java runtime code and they created an open-source project called OpenJDK.And to Oracle's credit, when they bought Sun—which I think at the time when you really look back, Oracle really did not have a lot of track record, if you will, of being involved with an open-source community—and I think when Oracle acquired Sun, there was a lot of skepticism as to what's going to happen to Java. Is Oracle going to make this thing, you know, back to the old days, proprietary Oracle, et cetera? And really—Corey: I was too busy being heartbroken over Solaris at that point to pay much attention to the Java stuff, but it felt like it was this—sort of the same pattern, repeated across multiple ecosystems.Scott: Absolutely. And even though Sun had also open-sourced Solaris, with the OpenSolaris project, that was one of the kinds of things that it was still developed very much in a closed environment, and then they would kind of throw some code out into the open world. And no one really ran OpenSolaris because it wasn't fully compatible with Solaris. And so, that was a faint attempt, if you will.But Java was quite different. It was truly all open-sourced, and the big difference that—and again, I give Oracle a lot of credit for this because this was a very important time in the evolution of Java—that Oracle, maintained Sun's commitment to not only continue to open-source Java but most importantly, develop it in the open community. And so, you know, again, back and this is the 2008, ‘09, ‘10 timeframe, the evolution of Java, the decisions, the standards, you know, what goes in the platform, what doesn't, decisions about updates and those types of things, that truly became a community-led world and all done in the open-source. And credit to Oracle for continuing to do that. And that really began the transition away from proprietary implementations of Java to one that, very similar to Linux, has really thrived because of the true open-source nature of what Java is today.And that's enabled more and more companies to get involved with the evolution of Java. If you go to the OpenJDK page, you'll see all of the not only, you know, incredibly talented individuals that are involved with the evolution of Java, but again, a who's who in pretty much every major commercial entities in the enterprise software world is also somehow involved in the OpenJDK community. And so, it really is a very vibrant, evolving standard. And some of the tactical things that have happened along the way in terms of changing how versions of Java are released still also very much in the context of maintaining compatibility and finding that careful balance of evolving the platform, but at the same time, recognizing that there is a lot of Java applications out there, so you can't just take a right-hand turn and forget about the compatibility side of things. But we as a community overall, I think, have addressed that very effectively, and the result has been now I think Java is more popular than ever and continues to—we liken it kind of to the mortar and the brick walls of the enterprise. It's a given that it's going to be used, certainly by most of the enterprises worldwide today.Corey: There's a certain subset of folk who are convinced the Java, “Oh, it's this a legacy programming language, and nothing modern or forward-looking is going to be built in it.” Yeah, those people generally don't know what the internal language stack looks like at places like oh, I don't know, AWS, Google, and a few others, it is very much everywhere. But it also feels, on some level, like, it's a bit below the surface-level of awareness for the modern full-stack developer in some respects, right up until suddenly it's very much not. How is Java evolving in a cloud these days?Scott: Well, what we see happening—you know, this is true for—you know, I'm a techie, so I can talk about other techies. I mean as techies, we all like the new thing, right? I mean, it's not that exciting to talk about a language that's been around for 20-plus years. But that doesn't take away from the fact that we still all use keyboards. I mean, no one really talks about what keyboard they use anymore—unless you're really into keyboards—but at the end of the day, it's still a fundamental tool that you use every single day.And Java is kind of in the same situation. The reason that Java continues to be so fundamental is that it really comes back to kind of reinventing the wheel problem. Are there are other languages that are more efficient to code in? Absolutely. Are there other languages that, you know, have some capabilities that the Java doesn't have? Absolutely.But if you have the ability to reinvent everything from scratch, sure, go for it. And you also don't have to worry about well, can I find enough programmers in this, you know, new hot language, okay, good luck with that. You might be able to find dozens, but when you need to really scale a company into thousands or tens of thousands of developers, good luck finding, you know, everyone that knows, whatever your favorite hot language of the day is.Corey: It requires six years experience in a four-year-old language. Yeah, it's hard to find that, sometimes.Scott: Right. And you know, the reality is, is that really no application ever is developed from scratch, right? Even when an application is, quote, new, immediately, what you're using is frameworks and other things that have written long ago and proven to be very successful.Corey: And disturbing amounts of code copied and pasted from Stack Overflow.Scott: Absolutely.Corey: But that's one of those impolite things we don't say out loud very often.Scott: That's exactly right. So, nothing really is created from scratch anymore. And so, it's all about building blocks. And this is really where this snowball of Java is difficult to stop because there is so much third-party code out there—and by that, I mean, you know, open-source, commercial code, et cetera—that is just so leveraged and so useful to very quickly be able to take advantage of and, you know, allow developers to focus on truly new things, not reinventing the wheel for the hundredth time. And that's what's kind of hard about all these other languages is catching up to Java with all of the things that are immediately available for developers to use freely, right, because most of its open-source. That's a pretty fundamental Catch-22 about when you start talking about the evolution of new languages.Corey: I'm with you so far. The counterpoint though is that so much of what we're talking about in the world of Java is open-source; it is freely available. The OpenJDK, for example, says that right on the tin. You have built a company and you've been in business for 20 years. I have to imagine that this is not one of those stories where, “Oh, all the things we do, we give away for free. But that's okay. We make it up in volume.” Even the venture capitalist mindset tends to run out of patience on those kinds of timescales. What is it you actually do as a business that clearly, obviously delivers value for customers but also results in, you know, being able to meet payroll every week?Scott: Right? Absolutely. And I think what time has shown is that, with one very notable exception and very successful example being Red Hat, there are very, very few pure open-source companies whose business is only selling support services for free software. Most successful businesses that are based on open-source are in one-way shape or form adding value-added elements. And that's our strategy as well.The heart of everything we do is based on free code from OpenJDK, and we have a tremendous amount of business that we are following the Red Hat business model where we are selling support and long-term access and a huge variety of different operating system configurations, older Java versions. Still all free software, though, right, but we're selling support services for that. And that is, in essence, the classic Red Hat business model. And that business for us is incredibly high growth, very fast-moving, a lot of that business is because enterprises are tired of paying the very high price to Oracle for Java support and they're looking for an open-source alternative that is exactly the same thing, but comes in pure open-source form and with a vendor that is as reputable as Oracle. So, a lot of our businesses based on that.However, on top of that, we also have value-added elements. And so, our product that is called Azul Platform Prime is rooted in OpenJDK—it is OpenJDK—but then we've added value-added elements to that. And what those value-added elements create is, in essence, a better Java platform. And better in this context means faster, quicker to warm up, elimination of some of the inconsistencies of the Java runtime in terms of this nasty problem called garbage collection which causes applications to kind of bounce around in terms of performance limitations. And so, creating a better Java is another way that we have monetized our company is value-added elements that are built on top of OpenJDK. And I'd say that part of the business is very typical for the majority of enterprise software companies that are rooted in open-source. They're typically adding value-added components on top of the open-source technology, and that's our similar strategy as well.And then the third evolution for us, which again is very tried-and-true, is evolving the business also to add SaaS offerings. So today, the majority of our customers, even though they deploy in the cloud, they're stuck customer-managed and so they're responsible for where do I want to put my Java runtime on building out my stack and cetera, et cetera. And of course, that could be on-prem, but like I mentioned, the majority are in the cloud. We're evolving our product offerings also to have truly SaaS-based solutions so that customers don't even need to manage those types of stacks on their own anymore.Corey: On some level, it feels like we're talking about two different things when we talk about cloud and when we talk about programming languages, but increasingly, I'm starting to see across almost the entire ecosystem that different languages and different cloud providers are in many ways converging. How do you see Java changing as cloud-native becomes the default rather than the new thing?Scott: Great question. And I think the thing to recognize about, really, most popular programming languages today—I can think of very few exceptions—these languages were created, envisioned, implemented if you will, in a day when cloud was not top-of-mind, and in many cases, certainly in the case of Java, cloud didn't even exist when Java was originally conceived, nor was that the case when you know, other languages, such as Python, or JavaScript, or on and on. So, rethinking how these languages should evolve in very much the context of a cloud-native mentality is a really important initiative that we certainly are doing and I think the Java community is doing overall. And how you architect not only the application, but even the Java runtime itself can be fundamentally different if you know that the application is going to be deployed in the cloud.And I'll give you an example. Specifically, in the world of any type of runtime-based language—and JavaScript is an example of that; Python is an example of that; Java is an example of that—in all of those runtime-based environments, what that basically means is that when the application is run, there's a piece of software that's called the runtime that actually is running that application code. And so, you can think about it as a middleware piece of software that sits between the operating system and the application itself. And so, that runtime layer is common across those languages and those platforms that I mentioned. That runtime layer is evolving, and it's evolving in a way that is becoming more and more cloud-native in it's thinking.The process itself of actually taking the application, compiling it into whatever underlying architecture it may be running on—it could be an x86 instance running on Amazon; it could be, you know, for example, an ARM64, which Amazon has compute instances now that are based on an ARM64 processor that they call Graviton, which is really also kind of altering the price-performance of the compute instances on the AWS platform—that runtime layer magically takes an application that doesn't have to be aware of the underlying hardware and transforms that into a way that can be run. And that's a very expensive process; it's called just-in-time compiling, and that just-in-time compilation, in today's world—which wasn't really based on cloud thinking—every instance, every compute instance that you deploy, that same JIT compilation process is happening over and over again. And even if you deploy 100 instances for scalability, every one of those 100 instances is doing that same work. And so, it's very inefficient and very redundant. Contrast that to a cloud-native thinking: that compilation process should be a service; that service should be done once.The application—you know, one instance of the application is actually run and there are the other ninety-nine should just reuse that compilation process. And that shared compiler service should be scalable and should be able to scale up when applications are launched and you need more compilation resources, and then scaled right back down when you're through the compilation process and the application is more moving into the—you know, to the runtime phase of the application lifecycle. And so, these types of things are areas that we and others are working on in terms of evolving the Java runtime specifically to be more cloud-native.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: This feels like it gets even more critical when we're talking about things like serverless functions across basically all the cloud providers these days, where there's the whole setup, everything in the stack, get it running, get it listening, ready to go, to receive a single request and then shut itself down. It feels like there are a lot of operational efficiencies possible once you start optimizing from a starting point of yeah, this is what that environment looks like, rather than us big metal servers sitting in a rack 15 years ago.Scott: Yeah. I think the evolution of serverless appears to be headed more towards serverless containers as opposed to serverless functions. Serverless functions have a bunch of limitations in terms of when you think about it in the context of a complex, you know, microservices-based deployment framework. It's just not very efficient, to spin up and spin down instances of a function if that actually is being—it is any sort of performance or latency-sensitive type of applications. If you're doing something very rarely, sure, it's fine; it's efficient, it's elegant, et cetera.But any sort of thing that has real girth to it—and girth probably means that's what's driving your application infrastructure costs, that's what's driving your Amazon bill every month—those types of things typically are not going to be great for starting and stopping functional instances. And so, serverless is evolving more towards thinking about the container itself not having to worry about the underlying operating system or the instance on Amazon that it's running on. And that's where, you know, we see more and more of the evolution of serverless is thinking about it at a container-level as opposed to a functional level. And that appears to be a really healthy steady state, so it gets the benefits of not having to worry about all the underlying stuff, but at the same time, doesn't have the downside of trying to start and stop functional influences at a given point in time.Corey: It seems to me that there are really two ways of thinking about cloud. The first is what I think a lot of companies do their first outing when they're going into something like AWS. “Okay, we're going to get a bunch of virtual machines that they call instances in AWS, we're going to run things just like it's our data center except now data transfer to the internet is terrifyingly expensive.” The more quote-unquote, “Cloud-native” way of thinking about this is what you're alluding to where there's, “Here's some code that I wrote. I want to throw it to my cloud provider and just don't tell me about any of the infrastructure parts. Execute this code when these conditions are met and leave me alone.”Containers these days seem to be one of our best ways of getting there with a minimum of fuss and friction. What are you seeing in the enterprise space as far as adoption of those patterns go? Or are we seeing cloud repatriation showing up as a real thing and I'm just not in the right place to see it?Scott: Well, I think as a cloud journey evolves, there's no question that—and in fact it's even silly to say that cloud is here to stay because I think that became a reality many, many years ago. So really, the question is, what are the challenges now with cloud deployments? Cloud is absolutely a given. And I think you stated earlier, it's rare that, whether it's a new company or a new application, at least in most businesses that don't have specific regulatory requirements, that application is highly, highly likely to be envisioned to be initially and only deployed in the cloud. That's a great thing because you have so many advantages of not having to purchase infrastructure in advance, being able to tap into all of the various services that are available through the cloud providers. No one builds databases anymore; you're just tapping into the service that's provided by Azure or AWS, or what have you.And, you know, just that specific example is a huge amount of savings in terms of just overhead, and license costs, and those types of stuff, and there's countless examples of that. And so, the services that are available in the cloud are unquestioned. So, there's countless advantages of why you want to be in the cloud. The downside, however, the cloud that is, if at the end of the day, AWS, Microsoft with Azure, Google with GCP, they are making 30% margin on that cloud infrastructure. And in the days of hardware, when companies would actually buy their servers from Dell, or HP, et cetera, those businesses are 5% margin.And so, where's that 25% going? Well, the 25% is being paid for by the users of cloud, and as a result of that, when you look at it purely from an operational cost perspective, it is more expensive to run in the cloud than it is back in the legacy days, right? And that's not to say that the industry has made the wrong choice because there's so many advantages of being in cloud, there's no doubt about it. And there should be—you know, and the cloud providers deserve to take some amount of margin to provide the services that they provide; there's no doubt about that. The question is, how do you do the best of all worlds?And you know, there is a great blog by a couple of the partners in Andreessen Horowitz, they called this the Cloud Paradox. And the Cloud Paradox really talks about the challenges. It's really a Catch-22; how do you get all the benefits of cloud but do that in a way that is not overly taxing from a cost perspective? And a lot of it comes down to good practices and making sure that you have the right monitoring and culture within an enterprise to make sure that cloud cost is a primary thing that is discussed and metric, but then there's also technologies that can help so that you don't have to even think about what you really don't ever want to do: repatriating, which is about the concept of actually moving off the cloud back to the old way of doing things. So certainly, I don't believe repatriation is a practical solution for ongoing and increasing cloud costs. I believe technology is a solution to that.And there are technologies such as our product, Azul Platform Prime, that in essence, allows you to do more with less, right, get all the benefits of cloud, deploy in your Amazon environment, deploy in your Azure environment, et cetera, but imagine if instead of needing a hundred instances to handle your given workload, you could do that with 50 or 60. Tomorrow, that means that you can start savings and being able to do that simply by changing your JVM from a standard OpenJDK or Oracle JVM to something like Platform Prime, you can immediately start to start seeing the benefits from that. And so, a lot of our business now and our growth is coming from companies that are screaming under the ongoing cloud costs and trying to keep them in line, and using technology like Azul Platform Prime to help mitigate those costs.Corey: I think that there is a somewhat foolish approach that I'm seeing taken by a lot of folks where there are some companies that are existentially anti-cloud, if for no other reason than because if the cloud wins, then they don't really have a business anymore. The problem I see with that is that it seems that their solution across the board is to turn back the clock where if I'm going to build a startup, it's time for me to go buy some servers and a rack somewhere and start negotiating with bandwidth providers. I don't see that that is necessarily viable for almost anyone. We aren't living in 1995 anymore, despite how much some people like to pretend we are. It seems like if there are workloads—for which I agree, cloud is not necessarily an economic fit, first, I feel like the market will fix that in the fullness of time, but secondly, on an individual workload belonging in a certain place is radically different than, “Oh, none of our stuff should live on cloud. Everything belongs in a data center.” And I just think that companies lose all credibility when they start pretending that it's any other way.Scott: Right. I'd love to see the reaction of the venture capitalists' face when an entrepreneur walks in and talks about how their strategy for deploying their SaaS service is going to be buying hardware and renting some space in the local data center.Corey: Well, there is a good cost control method, if you think about it. I mean very few engineers are going to accidentally spin up an $8 million cluster in a data center a second time, just because there's no space left for it.Scott: And you're right; it does happen in the cloud as well. It's just, I agree with you completely that as part of the evolution of cloud, in general, is an ever-improving aspect of cost and awareness of cost and building in technologies that help mitigate that cost. So, I think that will continue to evolve. I think, you know, if you really think about the cloud journey, cost, I would say, is still in early phases of really technologies and practices and processes of allowing enterprises to really get their head around cost. I'd still say it's a fairly immature industry that is evolving quickly, just given the importance of it.And so, I think in the coming years, you're going to see a radical improvement in terms of cost awareness and technologies to help with costs, that again allows you to the best of all worlds. Because, you know, if you go back to the Dark Ages and you start thinking about buying servers and infrastructure, then you are really getting back to a mentality of, “I've got to deploy everything. I've got to buy software for my database. I've got to deploy it. What am I going to do about my authentication service? So, I got to buy this vendor's, you know, solution, et cetera.” And so, all that stuff just goes away in the world of cloud, so it's just not practical, in this day and age I think, to think about really building a business that's not cloud-native from the beginning.Corey: I really want to thank you for spending so much time talking to me about how you view the industry, the evolution we've seen in the Java ecosystem, and what you've been up to. If people want to learn more, where's the best place for them to find you?Scott: Well, there's a thing called a website that you may not have heard of, it's really cool.Corey: Can I build it in Java?Scott: W-W-dot—[laugh]. Yeah. Azul website obviously has an awful lot of information about that, Azul is spelled A-Z-U-L, and we sometimes get the question, “How in the world did you name a company—why did you name it Azul?”And it's kind of a funny story because back in the days of Azul when we thought about, hey, we want to be big and successful, and at the time, IBM was the gold standard in terms of success in the enterprise world. And you know, they were Big Blue, so we said, “Hey, we're going to be a little blue. Let's be Azul.” So, that's where we began. So obviously, go check out our site.We're very present, also, in the Java community. We're, you know, many developer conferences and talks. We sponsor and run many of what's called the Java User Groups, which are very popular 10-, 20-person meetups that happen around the globe on a regular basis. And so, you know, come check us out. And I appreciate everyone's time in listening to the podcast today.Corey: No, thank you very much for spending as much time with me as you have. It's appreciated.Scott: Thanks, Corey.Corey: Scott Sellers, CEO and co-founder of Azul. 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 entire copy of the terms and conditions from Oracle's version of the JDK.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.

Les Cast Codeurs Podcast
LCC 285 - De mal en pis - partie 2

Les Cast Codeurs Podcast

Play Episode Listen Later Sep 16, 2022 50:38


Dans cette partie 2, nous discutons le changement d'étage gratuit chez Heroku, les vagues de licenciement dans le monde technologique, le carrière de contributeur individuel et le cloud souverain. Et on vous parle de division de nombres entier dans la rubrique débutant. Enregistré le 9 septembre 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–285.mp3 News Infrastructure NVidia interdit de vendre ses processeurs d'intelligence artificiels les plus puissants en Chine https://www.reuters.com/technology/nvidia-says-us-has-imposed-new-license-requirement-future-exports-china–2022–08–31/ Le gouvernement Américain a mis en place la restriction (export control) 10% des ventes en Chine pour NVidia Après 23ans un internaute arrête d'utiliser son propre serveur e-mail et il explique pourquoi cela est devenu impossible https://t.co/TQ61y45MXT?ssr=true Sa raison: l'impossibilité d'avoir un service fiable. Les services de gestion d'e-mails sont désormais dans les mains de quelques gros acteurs (Google, Microsoft,..) qui déploient à coup d'algorithmes des filtres pour mettre en spam les e-mails indésirables Ces derniers sont obscures et peuvent être stupides en blacklistant des blocs entiers d'IPs L'internaute demande aux acteurs de se réveiller avant que les politiciens s'en mêlent (pour le pire …) Cela demande aussi la mise en place de protocoles plus avancés comme DMARC Pour des adresses “casual” comme celles des cast codeurs, c'est maintenant passage à la caisse et 3 à 5 euros par mois et pas adresse email c'est plus que la valeur de ces emails “casual” Cloud Heroku annonce la fin de son étage gratuit https://techcrunch.com/2022/08/25/heroku-announces-plans-to-eliminate-free-plans-blaming-fraud-and-abuse/?guccounter=2&guce_referrer=aHR0cHM6Ly90LmNvLw&guce_referrer_sig=AQAAACIpHvzb3Pb2gtgt8Dm99CWGUhbEkdTgLVDgKwMNNmDI9UITQyNX64GA2LB6rQGNX2EreLoiRvxTqSUls5V_F8x6Cv_xGrfXtaIROP_Jiv45UUO1ODBIno3j7vHC4gokKVLqsZ948CmCfzG2bF03DL-uhbZqYuGXvxTfdsioTbjg heroic éliminé sont plan gratuit dénonçant des abus apres 10 ans pousser vers du paid plan, qui va aussi faire partir des gens et questionner ceux qui avaient un modèle économique base sur ce plan gratuit 28 novembre et aussi efface les comptes inactifs depuis 1 an beaucoup de fraude et d'abus vont garder des plans low cost et des plans étudiants au delà des abuseurs, les plans gratuits étaient utilises pour tester les apps avant leur déploiement Outillage Polices de caractères pour la programmation https://www.programmingfonts.org/#firacode J'aime bien Fira Code moi :slightly_smiling_face: Ce site permet de choisir parmi 111 polices différentes, pour pouvoir les comparer et choisir celle qu'on préfère Mickael Istria pointe sur une video expliquant les nouveautés autour d'Eclipse https://www.youtube.com/watch?v=zDJtVYAJwyY c'est très visuel, â regarder Code snippet Content assis plus rapide Support des concepts récents de Java comme sealed classes dans les quick fix Etc Utiliser git blame malgré les reformattages https://michaelheap.com/git-ignore-rev/ fichier listant les revisions pour ignorer certains sha1 et le changement d'avant est pris Une page concise des quelques façons de sortir d'un problème avec Git (langage coloré) https://ohshitgit.com/ On a toujours quelquye chose a apprendre ; celle qui nettoie la branche principale, je ne connaissais pas. Architecture Les tendances vu pas les éditeurs de InfoQ dans le devops et le cloud https://www.infoq.com/articles/devops-and-cloud-trends–2022/?utm_source=twitter&utm_medium=link&utm_campaign=calendar commenter les 4 vagues et ce qu'il y a dedans Data observability : live qualité de data etc Serverless everything: scale to 0 ; même les bases de données (soit parce que infra partagée soit via un scale down réveille par access à une gateway FinOps: contrôle des cours comme on optimisait pour les œufs eBPF pour injection de code et WASM pour le service mesh ingress (attention WASM dans envoy ne pas pas ton bon vieux Netty) Protection de la supply chain (encore faible en solutions) Low code no code mature pour moins besoin d'ingénieurs ou approche plus légère Developer experience qui influence les decisions Méthodologies Discussion sur la carrière contributeur individuel https://touilleur-express.fr/2022/07/17/devenir-staff-engineer/ exemple de ce que fait doctolib senior c'est le premier niveau d'autonomie et d'aisance ensuite, soit vous voulez coacher vo pairs (manager), soit contributeur individuel ce qui est demandé c'est le leadership (donc l'impact sur la societe et l'organisation) et ca demande une taille de societe minimale technique, communication, marketing d'idée occuper le role avant d'être reconnu (c'est assez classique ; ce qui change c'est le formalisme de la liste des competences attendues entre les boites) et on code moins car coder seul a moins de levier equivalence track technique/leadership et track managériales avec des ponts. Souvent d'arrète avant les VP et autre executive leadership (matrice de Radford) Premotion case avec promotion committee (2 fois pas an) Assez classique de paires un leadership avec un manager pour qu'ils s'épaulent mutuellement staff vs principal peut aussi etre du a l'impact cumulé de la personne et des principals peuvent aider sur une partie plus « bas niveau » / concrete de l'orga ou des projects grace a son experience et ses connexions au dela de son équipe actuelle des exemples de situations de travail du staff engineer https://touilleur-express.fr/2022/07/20/vis-ma-vie-de-staff-principal-engineer/ Loi, société et organisation https://twitter.com/smlpth/status/1551943751714603013?s=21&t=JhmioeiqlY8wFbzjry6b8Q encore un licenciement de masse. 10% chez Shopify. Pas mal d'aides pour faire passer la pilule (congés payés, aide à trouver un nouveau job…) ils ont fait le pari que post covid les gens resteraient à acheter en ligne mais c'est revenu aux volumes d'avant crise et inflation n'aident pas Annonce à l'américaine avec e-mail direct et arrêt du travail le lendemain Paye pendant quelques temps et support Un article sur les licenciements dans la tech des GAFAM et des startups https://www.lefigaro.fr/secteur/high-tech/la-grande-inquietude-des-salaries-de-la-tech-face-a-la-vague-de-licenciements–20220819 recession, résultats décevants, krach boursier (perte 1/4 de leur valeur) recerrement des politiques budgétaires, donc les projets semi viables ne le sont plus 88k licenciement en trois mois vs 5000 en 1 an en 2021: gros mois juin ->août Apple, Microsoft, Amazon, TikTok, Shopify, Snapchat, Netflix (–40% bourse), SoudnCloud (–20% d'effectif) L'argent facile arrête le cycle d'hyper acquisition et de facilite a l'hyper inflation des sociétés tech car impossibilité de lever des fonds startup ont du mal a garder les clients acquis en 1 donc recentrage et chute des activités non rentables fidélisation de l'employé vs aller chercher la meilleur offre comme un mercenaire Le Cloud de Confiance sous le coup du Cloud act américain ? https://www.nextinpact.com/lebrief/69865/les-clouds-confiance-bleu-et-s3ns-seront-bien-soumis-au-cloud-act-americain Alors attention, parce que Next Impact fait un peu dans le sensationnalisme https://twitter.com/pchapuis/status/1565775842675933188?t=y5S63FbOSbtH4FK_1meECQ&s=19 Avec cette interprétation, même Clever Cloud, utilisant du matériel américain, serait soumis au Cloud Act étude demandée par le ministère de la justice des pays bas le cloud act s'applique quand le fournisseur de cloud européen utilise du hardware ou logiciel américain (e.g. cloud de confiance Bleu et S3ns) muraille de chine en refusant tout client américain et en employant zero américain. mais c'est si le logiciel américain a accès aux données (routeur Cisco en decrypté etc), Stockage sans la clef cote client, etc le contrat MS serait « ring fencé » contre le cloud act mais peu d'infos Rubrique débutant Comment faire une division de deux entiers dans un flottant ? https://www.baeldung.com/java-integer-division-float-result Une division d'entier ramène que le quotient Et un entier Retourne un double au un des opérandes est un double, puis float, puis long. Donc il faut d'aster une des opérandes en float et pouf Conférences Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

PodRocket - A web development podcast from LogRocket
PodRocket presents: All things serverless with Compressed.fm

PodRocket - A web development podcast from LogRocket

Play Episode Listen Later Sep 15, 2022 62:21


We'll be back with our PodRocket episodes tomorrow but today, we're bringing you a guest episode with James and Amy from Compressed.fm — a weekly podcast focused on web development and design with a little bit of zest. This podcast was born out of a passion for teaching shared by the two co-hosts, Amy Dutton and James Quick. In this episode, James and Amy talk about everything serverless and how it fits into modern web development. They discuss serverless functions, edge functions, hosting platforms (Netlify, Vercel, and Cloudflare), frameworks and tools, benefits, and more. Links https://www.compressed.fm Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr).

Tech Leader Talk
The Power of Combining Blockchain with Serverless Infrastructures – Tim Wagner

Tech Leader Talk

Play Episode Listen Later Sep 15, 2022 33:48


Is your company leveraging the latest data sharing and data storage technologies? On today's episode, I am talking with Tim Wagner.  Tim is the CEO of Vendia, which provides a platform that combines next generation blockchain with a serverless infrastructure. Tim is passionate about growing teams within organizations and innovating problems related to data sharing.  He also has technical knowledge in programming languages, modern databases, and algorithm design. On today's episode, Tim and I discuss the power of combining serverless architectures with blockchain technologies.  We also discuss the value of transparency in your organization and growing strong teams. “If you're going to build a blockchain technology that services millions of customers, you need access to enough silicon to do that.” – Tim Wagner Today on the Tech Leader Talk podcast: - Current data sharing and data storage trends - The importance of transparency in your business - Tips for growing strong teams - The power of combining blockchain with serverless infrastructures - The growth of multi-cloud systems   Connect with Tim Wagner: LinkedIn:  https://www.linkedin.com/in/timawagner/ Website:  https://www.vendia.net/ Twitter:  https://twitter.com/timallenwagner Thanks for listening! Be sure to get your free copy of Steve's latest book, Cracking the Patent Code, and discover his proven system for identifying and protecting your most valuable inventions. Get the book at https://stevesponseller.com/book.

Screaming in the Cloud
The Future of Serverless with Allen Helton

Screaming in the Cloud

Play Episode Listen Later Sep 15, 2022 39:06


About AllenAllen is a cloud architect at Tyler Technologies. He helps modernize government software by creating secure, highly scalable, and fault-tolerant serverless applications.Allen publishes content regularly about serverless concepts and design on his blog - Ready, Set Cloud!Links Referenced: Ready, Set, Cloud blog: https://readysetcloud.io Tyler Technologies: https://www.tylertech.com/ Twitter: https://twitter.com/allenheltondev Linked: https://www.linkedin.com/in/allenheltondev/ 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: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I wind up stumbling into corners of the internet that I previously had not traveled. Somewhat recently, I wound up having that delightful experience again by discovering readysetcloud.io, which has a whole series of, I guess some people might call it thought leadership, I'm going to call it instead how I view it, which is just amazing opinion pieces on the context of serverless, mixed with APIs, mixed with some prognostications about the future.Allen Helton by day is a cloud architect at Tyler Technologies, but that's not how I encountered you. First off, Allen, thank you for joining me.Allen: Thank you, Corey. Happy to be here.Corey: I was originally pointed towards your work by folks in the AWS Community Builder program, of which we both participate from time to time, and it's one of those, “Oh, wow, this is amazing. I really wish I'd discovered some of this sooner.” And every time I look through your back catalog, and I click on a new post, I see things that are either I've really agree with this or I can't stand this opinion, I want to fight about it, but more often than not, it's one of those recurring moments that I love: “Damn, I wish I had written something like this.” So first, you're absolutely killing it on the content front.Allen: Thank you, Corey, I appreciate that. The content that I make is really about the stuff that I'm doing at work. It's stuff that I'm passionate about, stuff that I'd spend a decent amount of time on, and really the most important thing about it for me, is it's stuff that I'm learning and forming opinions on and wants to share with others.Corey: I have to say, when I saw that you were—oh, your Tyler Technologies, which sounds for all the world like, oh, it's a relatively small consultancy run by some guy presumably named Tyler, and you know, it's a petite team of maybe 20, 30 people on the outside. Yeah, then I realized, wait a minute, that's not entirely true. For example, for starters, you're publicly traded. And okay, that does change things a little bit. First off, who are you people? Secondly, what do you do? And third, why have I never heard of you folks, until now?Allen: Tyler is the largest company that focuses completely on the public sector. We have divisions and products for pretty much everything that you can imagine that's in the public sector. We have software for schools, software for tax and appraisal, we have software for police officers, for courts, everything you can think of that runs the government can and a lot of times is run on Tyler software. We've been around for decades building our expertise in the domain, and the reason you probably haven't heard about us is because you might not have ever been in trouble with the law before. If you [laugh] if you have been—Corey: No, no, I learned very early on in the course of my life—which will come as a surprise to absolutely no one who spent more than 30 seconds with me—that I have remarkably little filter and if ten kids were the ones doing something wrong, I'm the one that gets caught. So, I spent a lot of time in the principal's office, so this taught me to keep my nose clean. I'm one of those squeaky-clean types, just because I was always terrified of getting punished because I knew I would get caught. I'm not saying this is the right way to go through life necessarily, but it did have the side benefit of, no, I don't really engage with law enforcement going throughout the course of my life.Allen: That's good. That's good. But one exposure that a lot of people get to Tyler is if you look at the bottom of your next traffic ticket, it'll probably say Tyler Technologies on the bottom there.Corey: Oh, so you're really popular in certain circles, I'd imagine?Allen: Super popular. Yes, yes. And of course, you get all the benefits of writing that code that says ‘if defendant equals Allen Helton then return.'Corey: I like that. You get to have the exception cases built in that no one's ever going to wind up looking into.Allen: That's right. Yes.Corey: The idea of what you're doing makes an awful lot of sense. There's a tremendous need for a wide variety of technical assistance in the public sector. What surprises me, although I guess it probably shouldn't, is how much of your content is aimed at serverless technologies and API design, which to my way of thinking, isn't really something that public sector has done a lot with. Clearly I'm wrong.Allen: Historically, you're not wrong. There's an old saying that government tends to run about ten years behind on technology. Not just technology, but all over the board and runs about ten years behind. And until recently, that's really been true. There was a case last year, a situation last year where one of the state governments—I don't remember which one it was—but they were having a crisis because they couldn't find any COBOL developers to come in and maintain their software that runs the state.And it's COBOL; you're not going to find a whole lot of people that have that skill. A lot of those people are retiring out. And what's happening is that we're getting new people sitting in positions of power and government that want innovation. They know about the cloud and they want to be able to integrate with systems quickly and easily, have little to no onboarding time. You know, there are people in power that have grown up with technology and understand that, well, with everything else, I can be up and running in five or ten minutes. I cannot do this with the software I'm consuming now.Corey: My opinion on it is admittedly conflicted because on the one hand, yeah, I don't think that governments should be running on COBOL software that runs on mainframes that haven't been supported in 25 years. Conversely, I also don't necessarily want them being run like a seed series startup, where, “Well, I wrote this code last night, and it's awesome, so off I go to production with it.” Because I can decide not to do business anymore with Twitter for Pets, and I could go on to something else, like PetFlicks, or whatever it is I choose to use. I can't easily opt out of my government. The decisions that they make stick and that is going to have a meaningful impact on my life and everyone else's life who is subject to their jurisdiction. So, I guess I don't really know where I believe the proper, I guess, pace of technological adoption should be for governments. Curious to get your thoughts on this.Allen: Well, you certainly don't want anything that's bleeding edge. That's one of the things that we kind of draw fine lines around. Because when we're dealing with government software, we're dealing with, usually, critically sensitive information. It's not medical records, but it's your criminal record, and it's things like your social security number, it's things that you can't have leaking out under any circumstances. So, the things that we're building on are things that have proven out to be secure and have best practices around security, uptime, reliability, and in a lot of cases as well, and maintainability. You know, if there are issues, then let's try to get those turned around as quickly as we can because we don't want to have any sort of downtime from the software side versus the software vendor side.Corey: I want to pivot a little bit to some of the content you've put out because an awful lot of it seems to be, I think I'll call it variations on a theme. For example, I just read some recent titles, and to illustrate my point, “Going API First: Your First 30 Days,” “Solutions Architect Tips how to Design Applications for Growth,” “3 Things to Know Before Building A Multi-Tenant Serverless App.” And the common thread that I see running through all of these things are these are things that you tend to have extraordinarily strong and vocal opinions about only after dismissing all of them the first time and slapping something together, and then sort of being forced to live with the consequences of the choices that you've made, in some cases you didn't realize you were making at the time. Are you one of those folks that has the wisdom to see what's coming down the road, or did you do what the rest of us do and basically learn all this stuff by getting it hilariously wrong and having to careen into rebound situations as a result?Allen: [laugh]. I love that question. I would like to say now, I feel like I have the vision to see something like that coming. Historically, no, not at all. Let me talk a little bit about how I got to where I am because that will shed a lot of context on that question.A few years ago, I was put into a position at Tyler that said, “Hey, go figure out this cloud thing.” Let's figure out what we need to do to move into the cloud safely, securely, quickly, all that rigmarole. And so, I did. I got to hand-select team of engineers from people that I worked with at Tyler over the past few years, and we were basically given free rein to learn. We were an R&D team, a hundred percent R&D, for about a year's worth of time, where we were learning about cloud concepts and theory and building little proof of concepts.CI/CD, serverless, APIs, multi-tenancy, a whole bunch of different stuff. NoSQL was another one of the things that we had to learn. And after that year of R&D, we were told, “Okay, now go do something with that. Go build this application.” And we did, building on our theory our cursory theory knowledge. And we get pretty close to go live, and then the business says, “What do you do in this scenario? What do you do in that scenario? What do you do here?”Corey: “I update my resume and go work somewhere else. Where's the hard part here?”Allen: [laugh].Corey: Turns out, that's not a convincing answer.Allen: Right. So, we moved quickly. And then I wouldn't say we backpedaled, but we hardened for a long time before the—prior to the go-live, with the lessons that we've learned with the eyes of Tyler, the mature enterprise company, saying, “These are the things that you have to make sure that you take into consideration in an actual production application.” One of the things that I always pushed—I was a manager for a few years of all these cloud teams—I always push do it; do it right; do it better. Right?It's kind of like crawl, walk, run. And if you follow my writing from the beginning, just looking at the titles and reading them, kind of like what you were doing, Corey, you'll see that very much. You'll see how I talk about CI/CD, you'll see me how I talk about authorization, you'll see me how I talk about multi-tenancy. And I kind of go in waves where maybe a year passes and you see my content revisit some of the topics that I've done in the past. And they're like, “No, no, no, don't do what I said before. It's not right.”Corey: The problem when I'm writing all of these things that I do, for example, my entire newsletter publication pipeline is built on a giant morass of Lambda functions and API Gateways. It's microservices-driven—kind of—and each microservice is built, almost always, with a different framework. Lately, all the new stuff is CDK. I started off with the serverless framework. There are a few other things here and there.And it's like going architecting, back in time as I have to make updates to these things from time to time. And it's the problem with having done all that myself is that I already know the answer to, “What fool designed this?” It's, well, you're basically watching me learn what I was, doing bit by bit. I'm starting to believe that the right answer on some level, is to build an inherent shelf-life into some of these things. Great, in five years, you're going to come back and re-architect it now that you know how this stuff actually works rather than patching together 15 blog posts by different authors, not all of whom are talking about the same thing and hoping for the best.Allen: Yep. That's one of the things that I really like about serverless, I view that as a giant pro of doing Serverless is that when we revisit with the lessons learned, we don't have to refactor everything at once like if it was just a big, you know, MVC controller out there in the sky. We can refactor one Lambda function at a time if now we're using a new version of the AWS SDK, or we've learned about a new best practice that needs to go in place. It's a, “While you're in there, tidy up, please,” kind of deal.Corey: I know that the DynamoDB fanatics will absolutely murder me over this one, but one of the reasons that I have multiple Dynamo tables that contain, effectively, variations on the exact same data, is because I want to have the dependency between the two different microservices be the API, not, “Oh, and under the hood, it's expecting this exact same data structure all the time.” But it just felt like that was the wrong direction to go in. That is the justification I use for myself why I run multiple DynamoDB tables that [laugh] have the same content. Where do you fall on the idea of data store separation?Allen: I'm a big single table design person myself, I really like the idea of being able to store everything in the same table and being able to create queries that can return me multiple different types of entity with one lookup. Now, that being said, one of the issues that we ran into, or one of the ambiguous areas when we were getting started with serverless was, what does single table design mean when you're talking about microservices? We were wondering does single table mean one DynamoDB table for an entire application that's composed of 15 microservices? Or is it one table per microservice? And that was ultimately what we ended up going with is a table per microservice. Even if multiple microservices are pushed into the same AWS account, we're still building that logical construct of a microservice and one table that houses similar entities in the same domain.Corey: So, something I wish that every service team at AWS would do as a part of their design is draw the architecture of an application that you're planning to build. Great, now assume that every single resource on that architecture diagram lives in its own distinct AWS account because somewhere in some customer, there's going to be an account boundary at every interconnection point along the way. And so, many services don't do that where it's, “Oh, that thing and the other thing has to be in the same account.” So, people have to write their own integration shims, and it makes doing the right thing of putting different services into distinct bounded AWS accounts for security or compliance reasons way harder than I feel like it needs to be.Allen: [laugh]. Totally agree with you on that one. That's one of the things that I feel like I'm still learning about is the account-level isolation. I'm still kind of early on, personally, with my opinions in how we're structuring things right now, but I'm very much of a like opinion that deploying multiple things into the same account is going to make it too easy to do something that you shouldn't. And I just try not to inherently trust people, in the sense that, “Oh, this is easy. I'm just going to cross that boundary real quick.”Corey: For me, it's also come down to security risk exposure. Like my lasttweetinaws.com Twitter shitposting thread client lives in a distinct AWS account that is separate from the AWS account that has all of our client billing data that lives within it. The idea being that if you find a way to compromise my public-facing Twitter client, great, the blast radius should be constrained to, “Yay, now you can, I don't know, spin up some cryptocurrency mining in my AWS account and I get to look like a fool when I beg AWS for forgiveness.”But that should be the end of it. It shouldn't be a security incident because I should not have the credit card numbers living right next to the funny internet web thing. That sort of flies in the face of the original guidance that AWS gave at launch. And right around 2008-era, best practices were one customer, one AWS account. And then by 2012, they had changed their perspective, but once you've made a decision to build multiple services in a single account, unwinding and unpacking that becomes an incredibly burdensome thing. It's about the equivalent of doing a cloud migration, in some ways.Allen: We went through that. We started off building one application with the intent that it was going to be a siloed application, a one-off, essentially. And about a year into it, it's one of those moments of, “Oh, no. What we're building is not actually a one-off. It's a piece to a much larger puzzle.”And we had a whole bunch of—unfortunately—tightly coupled things that were in there that we're assuming that resources were going to be in the same AWS account. So, we ended up—how long—I think we took probably two months, which in the grand scheme of things isn't that long, but two months, kind of unwinding the pieces and decoupling what was possible at the time into multiple AWS accounts, kind of, segmented by domain, essentially. But that's hard. AWS puts it, you know, it's those one-way door decisions. I think this one was a two-way door, but it locked and you could kind of jimmy the lock on the way back out.Corey: And you could buzz someone from the lobby to let you back in. Yeah, the biggest problem is not necessarily the one-way door decisions. It's the one-way door decisions that you don't realize you're passing through at the time that you do them. Which, of course, brings us to a topic near and dear to your heart—and I only recently started have opinions on this myself—and that is the proper design of APIs, which I'm sure will incense absolutely no one who's listening to this. Like, my opinions on APIs start with well, probably REST is the right answer in this day and age. I had people, like, “Well, I don't know, GraphQL is pretty awesome.” Like, “Oh, I'm thinking SOAP,” and people look at me like I'm a monster from the Black Lagoon of centuries past in XML-land. So, my particular brand of strangeness side, what do you see that people are doing in the world of API design that is the, I guess, most common or easy to make mistakes that you really wish they would stop doing?Allen: If I could boil it down to one word, fundamentalism. Let me unpack that for you.Corey: Oh, please, absolutely want to get a definition on that one.Allen: [laugh]. I approach API design from a developer experience point of view: how easy is it for both internal and external integrators to consume and satisfy the business processes that they want to accomplish? And a lot of times, REST guidelines, you know, it's all about entity basis, you know, drill into the appropriate entities and name your endpoints with nouns, not verbs. I'm actually very much onto that one.But something that you could easily do, let's say you have a business process that given a fundamentally correct RESTful API design takes ten API calls to satisfy. You could, in theory, boil that down to maybe three well-designed endpoints that aren't, quote-unquote, “RESTful,” that make that developer experience significantly easier. And if you were a fundamentalist, that option is not even on the table, but thinking about it pragmatically from a developer experience point of view, that might be the better call. So, that's one of the things that, I know feels like a hot take. Every time I say it, I get a little bit of flack for it, but don't be a fundamentalist when it comes to your API designs. Do something that makes it easier while staying in the guidelines to do what you want.Corey: For me the problem that I've kept smacking into with API design, and it honestly—let me be very clear on this—my first real exposure to API design rather than API consumer—which of course, I complain about constantly, especially in the context of the AWS inconsistent APIs between services—was when I'm building something out, and I'm reading the documentation for API Gateway, and oh, this is how you wind up having this stage linked to this thing, and here's the endpoint. And okay, great, so I would just populate—build out a structure or a schema that has the positional parameters I want to use as variables in my function. And that's awesome. And then I realized, “Oh, I might want to call this a different way. Aw, crap.” And sometimes it's easy; you just add a different endpoint. Other times, I have to significantly rethink things. And I can't shake the feeling that this is an entire discipline that exists that I just haven't had a whole lot of exposure to previously.Allen: Yeah, I believe that. One of the things that you could tie a metaphor to for what I'm saying and kind of what you're saying, is AWS SAM, the Serverless Application Model, all it does is basically macros CloudFormation resources. It's just a transform from a template into CloudFormation. CDK does same thing. But what the developers of SAM have done is they've recognized these business processes that people do regularly, and they've made these incredibly easy ways to satisfy those business processes and tie them all together, right?If I want to have a Lambda function that is backed behind a endpoint, an API endpoint, I just have to add four or five lines of YAML or JSON that says, “This is the event trigger, here's the route, here's the API.” And then it goes and does four, five, six different things. Now, there's some engineers that don't like that because sometimes that feels like magic. Sometimes a little bit magic is okay.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: I feel like one of the benefits I've had with the vast majority of APIs that I've built is that because this is all relatively small-scale stuff for what amounts to basically shitposting for the sake of entertainment, I'm really the only consumer of an awful lot of these things. So, I get frustrated when I have to backtrack and make changes and teach other microservices to talk to this thing that has now changed. And it's frustrating, but I have the capacity to do that. It's just work for a period of time. I feel like that equation completely shifts when you have published this and it is now out in the world, and it's not just users, but in many cases paying customers where you can't really make those changes without significant notice, and every time you do you're creating work for those customers, so you have to be a lot more judicious about it.Allen: Oh, yeah. There is a whole lot of governance and practice that goes into production-level APIs that people integrate with. You know, they say once you push something out the door into production that you're going to support it forever. I don't disagree with that. That seems like something that a lot of people don't understand.And that's one of the reasons why I push API-first development so hard in all the content that I write is because you need to be intentional about what you're letting out the door. You need to go in and work, not just with the developers, but your product people and your analysts to say, what does this absolutely need to do, and what does it need to do in the future? And you take those things, and you work with analysts who want specifics, you work with the engineers to actually build it out. And you're very intentional about what goes out the door that first time because once it goes out with a mistake, you're either going to version it immediately or you're going to make some people very unhappy when you make a breaking change to something that they immediately started consuming.Corey: It absolutely feels like that's one of those things that AWS gets astonishingly right. I mean, I had the privilege of interviewing, at the time, Jeff Barr and then Ariel Kelman, who was their head of marketing, to basically debunk a bunch of old myths. And one thing that they started talking about extensively was the idea that an API is fundamentally a promise to your customers. And when you make a promise, you'd better damn well intend on keeping it. It's why API deprecations from AWS are effectively unique whenever something happens.It's the, this is a singular moment in time when they turn off a service or degrade old functionality in favor of new. They can add to it, they can launch a V2 of something and then start to wean people off by calling the old one classic or whatnot, but if I built something on AWS in 2008 and I wound up sleeping until today, and go and try and do the exact same thing and deploy it now, it will almost certainly work exactly as it did back then. Sure, reliability is going to be a lot better and there's a crap ton of features and whatnot that I'm not taking advantage of, but that fundamental ability to do that is awesome. Conversely, it feels like Google Cloud likes to change around a lot of their API stories almost constantly. And it's unplanned work that frustrates the heck out of me when I'm trying to build something stable and lasting on top of it.Allen: I think it goes to show the maturity of these companies as API companies versus just vendors. It's one of the things that I think AWS does [laugh]—Corey: You see the similar dichotomy with Microsoft and Apple. Microsoft's new versions of Windows generally still have functionalities in them to support stuff that was written in the '90s for a few use cases, whereas Apple's like, “Oh, your computer's more than 18-months old? Have you tried throwing it away and buying a new one? And oh, it's a new version of Mac OS, so yeah, maybe the last one would get security updates for a year and then get with the times.” And I can't shake the feeling that the correct answer is in some way, both of those, depending upon who your customer is and what it is you're trying to achieve.If Microsoft adopted the Apple approach, their customers would mutiny, and rightfully so; the expectation has been set for decades that isn't what happens. Conversely, if Apple decided now we're going to support this version of Mac OS in perpetuity, I don't think a lot of their application developers wouldn't quite know what to make of that.Allen: Yeah. I think it also comes from a standpoint of you better make it worth their while if you're going to move their cheese. I'm not a Mac user myself, but from what I hear for Mac users—and this could be rose-colored glasses—but is that their stuff works phenomenally well. You know, when a new thing comes out—Corey: Until it doesn't, absolutely. It's—whenever I say things like that on this show, I get letters. And it's, “Oh, yeah, really? They'll come up with something that is a colossal pain in the ass on Mac.” Like, yeah, “Try building a system-wide mute key.”It's yeah, that's just a hotkey away on windows and here in Mac land. It's, “But it makes such beautiful sounds. Why would you want them to be quiet?” And it's, yeah, it becomes this back-and-forth dichotomy there. And you can even explain it to iPhones as well and the Android ecosystem where it's, oh, you're going to support the last couple of versions of iOS.Well, as a developer, I don't want to do that. And Apple's position is, “Okay, great.” Almost half of the mobile users on the planet will be upgrading because they're in the ecosystem. Do you want us to be able to sell things those people are not? And they're at a point of scale where they get to dictate those terms.On some level, there are benefits to it and others, it is intensely frustrating. I don't know what the right answer is on the level of permanence on that level of platform. I only have slightly better ideas around the position of APIs. I will say that when AWS deprecates something, they reach out individually to affected customers, on some level, and invariably, when they say, “This is going to be deprecated as of August 31,” or whenever it is, yeah, it is going to slip at least twice in almost every case, just because they're not going to turn off a service that is revenue-bearing or critical-load-bearing for customers without massive amounts of notice and outreach, and in some cases according to rumor, having engineers reach out to help restructure things so it's not as big of a burden on customers. That's a level of customer focus that I don't think most other companies are capable of matching.Allen: I think that comes with the size and the history of Amazon. And one of the things that they're doing right now, we've used Amazon Cloud Cams for years, in my house. We use them as baby monitors. And they—Corey: Yea, I saw this I did something very similar with Nest. They didn't have the Cloud Cam at the right time that I was looking at it. And they just announced that they're going to be deprecating. They're withdrawing them for sale. They're not going to support them anymore. Which, oh at Amazon—we're not offering this anymore. But you tell the story; what are they offering existing customers?Allen: Yeah, so slightly upset about it because I like my Cloud Cams and I don't want to have to take them off the wall or wherever they are to replace them with something else. But what they're doing is, you know, they gave me—or they gave all the customers about eight months head start. I think they're going to be taking them offline around Thanksgiving this year, just mid-November. And what they said is as compensation for you, we're going to send you a Blink Cam—a Blink Mini—for every Cloud Cam that you have in use, and then we are going to gift you a year subscription to the Pro for Blink.Corey: That's very reasonable for things that were bought years ago. Meanwhile, I feel like not to be unkind or uncharitable here, but I use Nest Cams. And that's a Google product. I half expected if they ever get deprecated, I'll find out because Google just turns it off in the middle of the night—Allen: [laugh].Corey: —and I wake up and have to read a blog post somewhere that they put an update on Nest Cams, the same way they killed Google Reader once upon a time. That's slightly unfair, but the fact that joke even lands does say a lot about Google's reputation in this space.Allen: For sure.Corey: One last topic I want to talk with you about before we call it a show is that at the time of this recording, you recently had a blog post titled, “What does the Future Hold for Serverless?” Summarize that for me. Where do you see this serverless movement—if you'll forgive the term—going?Allen: So, I'm going to start at the end. I'm going to work back a little bit on what needs to happen for us to get there. I have a feeling that in the future—I'm going to be vague about how far in the future this is—that we'll finally have a satisfied promise of all you're going to write in the future is business logic. And what does that mean? I think what can end up happening, given the right focus, the right companies, the right feedback, at the right time, is we can write code as developers and have that get pushed up into the cloud.And a phrase that I know Jeremy Daly likes to say ‘infrastructure from code,' where it provisions resources in the cloud for you based on your use case. I've developed an application and it gets pushed up in the cloud at the time of deploying it, optimized resource allocation. Over time, what will happen—with my future vision—is when you get production traffic going through, maybe it's spiky, maybe it's consistently at a scale that outperforms the resources that it originally provisioned. We can have monitoring tools that analyze that and pick that out, find the anomalies, find the standard patterns, and adjust that infrastructure that it deployed for you automatically, where it's based on your production traffic for what it created, optimizes it for you. Which is something that you can't do on an initial deployment right now. You can put what looks best on paper, but once you actually get traffic through your application, you realize that, you know, what was on paper might not be correct.Corey: You ever noticed that whiteboard diagrams never show the reality, and they're always aspirational, and they miss certain parts? And I used to think that this was the symptom I had from working at small, scrappy companies because you know what, those big tech companies, everything they build is amazing and awesome. I know it because I've seen their conference talks. But I've been a consultant long enough now, and for a number of those companies, to realize that nope, everyone's infrastructure is basically a trash fire at any given point in time. And it works almost in spite of itself, rather than because of it.There is no golden path where everything is shiny, new and beautiful. And that, honestly, I got to say, it was really [laugh] depressing when I first discovered it. Like, oh, God, even these really smart people who are so intelligent they have to have extra brain packs bolted to their chests don't have the magic answer to all of this. The rest of us are just screwed, then. But we find ways to make it work.Allen: Yep. There's a quote, I wish I remembered who said it, but it was a military quote where, “No battle plan survives impact with the enemy—first contact with the enemy.” It's kind of that way with infrastructure diagrams. We can draw it out however we want and then you turn it on in production. It's like, “Oh, no. That's not right.”Corey: I want to mix the metaphors there and say, yeah, no architecture survives your first fight with a customer. Like, “Great, I don't think that's quite what they're trying to say.” It's like, “What, you don't attack your customers? Pfft, what's your customer service line look like?” Yeah, it's… I think you're onto something.I think that inherently everything beyond the V1 design of almost anything is an emergent property where this is what we learned about it by running it and putting traffic through it and finding these problems, and here's how it wound up evolving to account for that.Allen: I agree. I don't have anything to add on that.Corey: [laugh]. Fair enough. I really want to thank you for taking so much time out of your day to talk about how you view these things. If people want to learn more, where is the best place to find you?Allen: Twitter is probably the best place to find me: @AllenHeltonDev. I have that username on all the major social platforms, so if you want to find me on LinkedIn, same thing: AllenHeltonDev. My blog is always open as well, if you have any feedback you'd like to give there: readysetcloud.io.Corey: And we will, of course, put links to that in the show notes. Thanks again for spending so much time talking to me. I really appreciate it.Allen: Yeah, this was fun. This was a lot of fun. I love talking shop.Corey: It shows. And it's nice to talk about things I don't spend enough time thinking about. Allen Helton, cloud architect at Tyler Technologies. 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 comment that I will reject because it was not written in valid XML.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.