Podcasts about building microservices

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereSarah Wells - Independent Consultant & Author & Author of "Enabling Microservice Success"Sam Newman - Microservices Expert & Author of "Building Microservices" & "Monolith to Microservices"RESOURCESSarahhttps://www.sarahwells.devhttps://twitter.com/sarahjwellshttps://linkedin.com/in/sarahjwells1Samhttps://twitter.com/samnewmanhttps://www.linkedin.com/in/samnewmanhttp://samnewman.iohttp://samnewman.io/bloghttps://github.com/snewmanDESCRIPTIONSam Newman talks to Sarah Wells about her new book "Enabling Microservice Success." Sarah Wells, an independent consultant with extensive experience from working at the "Financial Times," shares insights on engineering leadership, culture, and the practicalities of implementing microservices.They discuss challenges like out of hours support, the importance of organizational culture, and lessons learned from early microservice adoption.Sarah and Sam highlight the necessity of a thoughtful approach to microservices, emphasizing team autonomy and resilience.RECOMMENDED BOOKSSarah Wells • Enabling Microservice SuccessSam Newman • Monolith to MicroservicesSam Newman • Building MicroservicesSimon Brown • Software Architecture for Developers Vol. 2Ronnie Mitra & Irakli Nadareishvili • Microservices: Up and RunningTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Este conteúdo é um trecho do nosso episódio: “#167 Building Microservices: dos livros à prática”. Nele, Cassiano Nunes, Engenheiro de Software, traz dicas sobre como determinar quando é mais estratégico utilizar microsserviços e a arquitetura monolítica em um sistema. Dê o play e ouça agora!" Quer enviar uma dúvida ou ideia para o Entre Chaves? Mande uma mensagem para o nosso Linkedin ou pelo email entrechaves@dtidigital.com.br. Sua resposta pode aparecer em um dos nossos episódios!

In this episode, we discuss how to prepare for talks, taking 3 months long vacations and the future of the tech industry in 2024. Guests Djalal Ahmed El Azzabi Notes 0:00:00 - Introduction and welcoming 0:04:00 - Taking 3 months long vacations with Ahmed El Azzabi 0:27:30 - Writing ebooks, and articles, and improving your writing skills. 0:56:00 - QAs 1:13:00 - New financial lows in Morocco. 1:20:00 - How to prepare for talks. 1:39:00 - Apple Vision Pro thoughts 1:42:30 - QAs 2:21:04 - GeeksBlaBla Picks 2:30:00 - Conclusion and goodbye. Links https://remote.ma/ https://remote.ma/legal/ Building Microservices, 2nd Edition James Clear Newsletter TickTick Prepared and Presented by Youssouf El Azizi

Você já esteve em contato com a criação de microsserviços? Venha conhecer mais sobre essa arquitetura que mudou a forma como grandes empresas constroem e escalam seus produtos de forma a separar etapas do processo em processos menores. Nosso convidado aborda diversas características desses processos, e nos conta sobre sua experiência com a teoria do livro sendo aplicada na prática do dia a dia. Venha conosco em mais um entre chaves aprender sobre esse tema tão relevante para o desenvolvimento de softwares. Dê o play já!     Apresentação: Fernanda Vieira e Lucas Campregher   Pessoas convidadas: Cassiano Nunes

The hosts  ▻Christian Weichel, Chief Technology Officer at GitpodPauline Narvas, Head of Community at Gitpod Our guest  ▻Sarah WellsTwitter: https://twitter.com/sarahjwellsLinkedIn: https://www.linkedin.com/in/sarahjwells1/Things mentioned ▻Start with Why: How Great Leaders Inspire Everyone to Take Actionby Simon SinekHow to Measure Anything: Finding the Value of Intangibles in Business 3rd Edition by Douglas W. Hubbard Conway's law Let's chat some more! ▻ Gitpod Discord Community Start a Gitpod workspace! DevX Conf

If you enjoyed this video, here are additional resources to look at:Coursera + Duke Specialization: Building Cloud Computing Solutions at Scale Specialization: https://www.coursera.org/specializations/building-cloud-computing-solutions-at-scalePython, Bash, and SQL Essentials for Data Engineering Specialization: https://www.coursera.org/specializations/python-bash-sql-data-engineering-dukeAWS Certified Solutions Architect - Professional (SAP-C01) Cert Prep: 1 Design for Organizational Complexity:https://www.linkedin.com/learning/aws-certified-solutions-architect-professional-sap-c01-cert-prep-1-design-for-organizational-complexity/design-for-organizational-complexity?autoplay=trueO'Reilly Book: Practical MLOps: https://www.amazon.com/Practical-MLOps-Operationalizing-Machine-Learning/dp/1098103017O'Reilly Book: Python for DevOps: https://www.amazon.com/gp/product/B082P97LDW/Pragmatic AI: An Introduction to Cloud-based Machine Learning: https://www.amazon.com/gp/product/B07FB8F8QP/Pragmatic AI Labs Book: Python Command-Line Tools: https://www.amazon.com/gp/product/B0855FSFYZPragmatic AI Labs Book: Cloud Computing for Data Analysis: https://www.amazon.com/gp/product/B0992BN7W8Pragmatic AI Book: Minimal Python: https://www.amazon.com/gp/product/B0855NSRR7Pragmatic AI Book: Testing in Python: https://www.amazon.com/gp/product/B0855NSRR7Subscribe to Pragmatic AI Labs YouTube Channel: https://www.youtube.com/channel/UCNDfiL0D1LUeKWAkRE1xO5QSubscribe to 52 Weeks of AWS Podcast: https://52-weeks-of-cloud.simplecast.comView content on noahgift.com: https://noahgift.com/View content on Pragmatic AI Labs Website: https://paiml.com/

Janis, Dominik und Jochen unterhalten sich über Microservices. Letztes hatten wir ja schon so ein bisschen darüber gesprochen und daraufhin hat sich Janis gemeldet und gefragt, ob wir da nicht mal eine komplette Sendung mit ihm drüber machen wollen. Wollten wir natürlich :).   Und hier noch die Antwort auf alle Fragen im Bereich Softwareentwicklung Shownotes Unsere E-Mail für Fragen, Anregungen & Kommentare: hallo@python-podcast.de News aus der Szene Okta breach PYPL PopularitY of Programming Language Meta donates $300,000 to the Python Software Foundation | Łukasz Langa - #Programming GitHub Issues Migration: status update Cython is 20! Neue Programmiersprachen: vlang | zig April: PyCon DE & PyData Berlin 2022 Juli: EuroPython September: DjangoCon EU 2022 Werbung Ailio sucht Mitarbeiter | Anfragen bitte an diese Mailadresse: business@ailio.de Microservices BoundedContext / Single source of truth Buch: Building Microservices, 2nd Edition Sam Newman on Information Hiding, Ubiquitous Language, UI Decomposition and Building Microservices Sam Newman: Monolith to Microservices (InfoQ Podcast) Folge 99 - Sam Newman - Monolith to Microservices ELK-Stack Apache Kafka Buch: Software Architecture with Python MonolithFirst Benchmark Caddy / Nginx / Uvicorn Benchmarking nginx vs caddy vs uvicorn for serving static files Uvicorn / uvloop Picks bpytop / glances Kafka Connect

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

What is DAPR, and why do you want it? Carl and Richard talk to Paul Yuknewicz about how DAPR helps you build better microservices by dealing with all the plumbing. We all need messaging, security, logging, and other services to make microservices work - and there are a ton of SDKs and libraries out there to help. DAPR helps glue all those pieces together with a nice layer of abstraction to make it easier for your tool selections to work!

What is DAPR, and why do you want it? Carl and Richard talk to Paul Yuknewicz about how DAPR helps you build better microservices by dealing with all the plumbing. We all need messaging, security, logging, and other services to make microservices work - and there are a ton of SDKs and libraries out there to help. DAPR helps glue all those pieces together with a nice layer of abstraction to make it easier for your tool selections to work!

What is DAPR, and why do you want it? Carl and Richard talk to Paul Yuknewicz about how DAPR helps you build better microservices by dealing with all the plumbing. We all need messaging, security, logging, and other services to make microservices work - and there are a ton of SDKs and libraries out there to help. DAPR helps glue all those pieces together with a nice layer of abstraction to make it easier for your tool selections to work!Support this podcast at — https://redcircle.com/net-rocks/donations

What is DAPR, and why do you want it? Carl and Richard talk to Paul Yuknewicz about how DAPR helps you build better microservices by dealing with all the plumbing. We all need messaging, security, logging, and other services to make microservices work - and there are a ton of SDKs and libraries out there to help. DAPR helps glue all those pieces together with a nice layer of abstraction to make it easier for your tool selections to work!Support this podcast at — https://redcircle.com/net-rocks/donations

In this episode of the InfoQ podcast Charles Humble talks to Sam Newman, an independent consultant focusing on microservices, cloud and CD, about the 2nd edition of Newman's book Building Microservices, published by O'Reilly. They discuss information hiding; ideas from Domain Driven Design including aggregates, bounded contexts and ubiquitous language; UI decomposition; and team structure drawing on ideas from Team Topologies. Read a transcript of this interview: https://bit.ly/3lXqBxx Subscribe to our newsletters: - The InfoQ weekly newsletter: bit.ly/24x3IVq - The Software Architects' Newsletter [monthly]: https://www.infoq.com/software-architects-newsletter/ Upcoming Virtual Events - https://events.infoq.com/ InfoQ Live: https://live.infoq.com/ - October 19, 2021 QCon Plus online conference: https://plus.qconferences.com/ - November 1-12, 2021 Follow InfoQ: - Twitter: https://twitter.com/infoq - LinkedIn: https://www.linkedin.com/company/infoq/ - Facebook: https://www.facebook.com/InfoQdotcom/ - Instagram: @infoqdotcom - Youtube: https://www.youtube.com/infoq

Nic Jackson is a Principal Developer Advocate for HashiCorp. He's also the author of the book Building Microservices with Go and an avid speaker on all things microservices. We learn about his first job in tech performing data collection for an environmental agency and how that sparked his interest in computer science. Nic would go on to work with many cutting-edge technologies but what he realized he enjoys most is helping others. Connect with Nic:TwitterYouTube channelLinkedInjackson.nic@gmail.comMentioned in today's episode:HashiCorpRazorFishjQueryWant more from Ardan Labs?You can learn Go, Kubernetes, Docker & more through our video training, live events, or through our blog!

About Julian WoodJulian Wood is a Senior Developer Advocate for the AWS Serverless Team. He loves helping developers and builders learn about, and love, how serverless technologies can transform the way they build and run applications at any scale. Julian was an infrastructure architect and manager in global enterprises and start-ups for more than 25 years before going all-in on serverless at AWS.Twitter: @julian_woodAll things Serverless @ AWS: ServerlessLandServerless Patterns CollectionServerless Office Hours – every Tuesday 10am PTLambda ExtensionsLambda Container ImagesWatch this episode on YouTube: https://youtu.be/jtNLt3Y51-gThis episode sponsored by CBT Nuggets and Lumigo.TranscriptJeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today I'm joined by Julian Wood. Hey Julian, thanks for joining me.Julian: Hey Jeremy, thank you so much for inviting me.Jeremy: Well, I am super excited to have you here. I have been following your work for a very long time and of course, big fan of AWS. So you are a Serverless Developer Advocate at AWS, and I'd love it if you could just tell the listeners a little bit about your background, so they get to know you a bit. And then also, sort of what your role is at AWS.Julian: Yeah, certainly. Well, I'm Julian Wood. I am based in London, but yeah, please don't let my accent fool you. I'm actually originally from South Africa, so the language purists aren't scratching their heads anymore. But yeah, I work within the Serverless Team at AWS, and hopefully do a number of things. First of all, explain what we're up to and how our sort of serverless things work and sort of, I like to sometimes say a bit cheekily, basically help the world fall in love with serverless as I have. And then also from the other side is to be a proxy and sort of be the voice of builders, and developers and whoever's building service applications, and be their voices internally. So you can also keep us on our toes to help build the things that will brighten your days.And just before, I've worked for too many years probably, as an infrastructure racker, stacker, architect, and manager. I've worked in global enterprises babysitting their Windows and Linux servers, and running virtualization, and doing all the operations kind of stuff to support that. But, I was always thinking there's a better way to do this and we weren't doing the best for the developers and internal customers. And so when this, you know in inverted commas, "serverless way" of things started to appear, I just knew that this was going to be the future. And I could happily leave the server side to much better and cleverer people than me. So by some weird, auspicious alignment of the stars, a while later, I managed to get my current dream job talking about serverless and talking to you.Jeremy: Yeah. Well, I tell you, I think a lot of serverless people or people who love serverless are recovering ops and infrastructure people that were doing racking and stacking. Because I too am also recovering from that and I still have nightmares.I thought that it was interesting too, how you mentioned though, developer advocacy. It's funny, you work for a specific company, AWS obviously, but even developer advocacy in general, who is that for? Who are you advocating for? Are you advocating for the developers to use the service from the company? Are you advocating for the developers so that the company can provide the services that they actually need? Interesting balance there.Julian: Yeah, it's true. I mean, the honest answer is we don't have great terms for this kind of role, but yeah, I think primarily we are advocating for the people who are developing the applications and on the outside. And to advocate for them means we've got to build the right stuff for them and get their voices internally. And there are many ways of doing that. Some people raise support requests and other kind of things, but I mean, sometimes some of our great ideas come from trolling Twitter, or yes, I know even Hacker News or that kind of thing. But also, we may get responses from 10 different people about something and that will formulate something in our brain and we'll chat with other kind of people. And that sort of starts a thing. It's not just necessarily each time, some good idea in Twitter comes in, it gets mashed into some big surface database that we all pick off.But part of our job is to be out there and try and think and be developers in whatever backgrounds we come from. And I mean, I'm not a pure software developer where I've come from, and I come, I suppose, from infrastructure, but maybe you'd call that a bit of systems engineering. So yeah, I try and bring that background to try and give input on whatever we do, hopefully, the right stuff.Jeremy: Right. Yeah. And then I think part of the job too, is just getting the information out there and getting the examples out there. And trying to create those best practices or at least surface those best practices, and encourage the community to do a lot of that work and to follow that. And you've done a lot of work with that, obviously, writing for the AWS blog. I know you have a series on the Serverless Lens and the Well-Architected Framework, and we can talk about that in a little while. But I really want to talk to you about, I guess, just the expansion of serverless over the last couple of years.I mean, it was very narrowly focused, probably, when it first came out. Lambda was ... FaaS as a whole new concept for a lot of people. And then as this progressed and we've gotten more APIs, and more services and things that it can integrate with, it just becomes complex and complicated. And that's a good thing, but also maybe a bad thing. But one of the things that AWS has done, and I think this is clearly in reaction to the developers needing it, is the ability to extend what you can do with a Lambda function, right? I mean, the idea of just putting your code in there and then, boom, that's it, that's all you have to do. That's great. But what if you do need access to lifecycle hooks? Or what if you do want to manipulate the underlying runtime or something like that? And AWS, I think has done a great job with that.So maybe we can start there. So just about the extensibility of Lambda in general. And one of the new things that was launched recently was, and recently, I don't know what was it? Seven months ago at this point? I'm not even sure. But was launched fairly recently, let's say that, is Lambda Extensions, and a couple of different flavors of that as well. Could you kind of just give the users an over, the users, wow, the listeners an overview of what Lambda Extensions are?Julian: I could hear the ops background coming in, talking about our users. Yeah. But I mean, from the get-go, serverless was always a terrible term because, why on earth would you name something for what it isn't? I mean, you know? I remember talking to DBAs, talking about noSQL, and they go, "Well, if it's not SQL, then what is it?" So we're terrible at that, serverless as well. And yeah, Lambda was very constrained when it came out. Lambda was never built being a serverless thing, that's what was the outcome. Sometimes we focus too much on the tools rather than the outcome. And the story is S3, just turning 15. And the genesis of Lambda was being an event trigger for S3, and people thought you'd upload something to S3, fire off a Lambda function, how cool is that? And then obviously the clever clubs at the time were like, "Well, hang on, let's not just do this for S3, let's do this for a whole bunch of kind of things."So Lambda was born out of that, as that got that great history, which is created an arc sort of into the present and into the future, which I know we're also going to get on about, the power of event driven applications. But the power of Lambda has always been its simplicity, and removing that operational burden, and that heavy lifting. But, sometimes that line is a bit of a gray area and there're people who can be purists about serverless and can be purists about FaaS and say, "Everything needs to be ephemeral. Lambda functions can't extend to anything else. There shouldn't be any state, shouldn't be any storage, shouldn't be any ..." All this kind of thing.And I think both of us can agree, but I don't want to speak for you, but I think both of us would agree that in some sense, yeah, that's fine. But we live in the real world and there's other stuff that needs to connect to and we're not here about building purist kind of stuff. So Lambda Extensions is a new way basically to integrate Lambda with your favorite tools. And that's the sort of headline thing we like to talk about. And the big idea is to open up Lambda to more effectively work mainly with partners, but also your own tools if you want to write them. And to sort of have deeper hooks into the Lambda lifecycle.And other partners are awesome and they do a whole bunch of stuff for serverless, plus customers also have connections to on-prem staff, or EC2 staff, or containers, or all kind of things. How can we make the tools more seamless in a way? How can we have a common set of tools maybe that you even use on-prem or in the cloud or containers or whatever? Why does Lambda have to be unique or different or that kind of thing? And Extensions is sort of one of the starts of that, is to be able to use these kind of tools and get more out of Lambda. So I mean, just the kind of tools that we've already got on board, there's things like Splunk and AppDynamics. And Lumigo, Epsagon, HashiCorp, Honeycomb, CoreLogic, Dynatrace, I can't think. Thundra and Sumo Logic, Check Point. Yeah, I'm sorry. Sorry for any partners who I've forgotten a few.Jeremy: No, right, no. That's very good. Shout them out, shout them out. No, I mean just, and not to interrupt you here, but ...Julian: No, please.Jeremy: ... I think that's great. I mean, I think that's one of the things that I like about the way that AWS deals with partners, is that ... I mean, I think AWS knows they can't solve all these problems on their own. I mean, maybe they could, right? But they would be their own way of solving the problems and there's other people who are solving these problems differently and giving you the ability to extend your Lambda functions into those partners is, there's a huge win for not only the partners because it creates that ecosystem for them, but also for AWS because it makes the product itself more valuable.Julian: Well, never mind the big win for customers because ultimately they're the one who then gets a common deployment tool, or a common observability tool, or a HashiCorp Vault that you can manage secrets and a Lambda function from HashiCorp Vault. I mean, that's super cool. I mean, also AWS services are picking this up because that's easy for them to do stuff. So if anybody's used Lambda Insights or even seen Lambda Insights in the console, it's somewhere in the monitoring thing, and you just click something over and you get this tool which can pull stuff that you can't normally get from a Lambda function. So things like CPU time and network throughput, which you couldn't normally get. But actually, under the hoods, Lambda Insights is using Lambda extensions. And you can see that if you look. It automatically adds the Lambda layer and job done.So anyway, this is how a lot of the tools work, that a layer is just added to a Lambda function and off you go, the tool can do its work. So also there's a very much a simplicity angle on this, that in a lot of cases you don't have to do anything. You configure some of the extensions via environment variables, if that's cooled you may just have an API key or a log retention value or something like that, I don't know, any kind of example of that. But you just configure that as a normal Lambda environment variable at this partner extension, which is just a Lambda layer, and off you go. Super simple.Jeremy: Right. So explain Extensions exactly, because I think that's one of those things because now we have Lambda layers and we have Lambda Extensions. And there's also like the runtime API and then something else. I mean, even I'm not 100% sure what all of the naming conventions. I'm pretty sure I know what they do ...Julian: Yeah, fair enough.Jeremy: ... but maybe we could say the names and say exactly what they do as well.Julian: Yeah, cool. You get an API, I get an API, everybody gets an API. So Lambda layers, let's just start, because that's, although it's not related to Extensions, it's how Extensions are delivered to the power core functions. And Lambda layers is just another way to add code to a Lambda function or not even code, it can be a dependency. It's just a way that you could, and it's cool because they are shareable. So you have some dependencies, or you have a library, or an SDK, or some training data for something, a Lambda layer just allows you to add some bits and bobs to your Lambda function. That's a horrible explanation. There's another word I was thinking of, because I don't want to use the word code, because it's not necessarily code, but it's dependency, whatever. It's just another way of adding something. I'll wake up in a cold sweat tonight thinking of the word I was thinking of, but anyway.But Lambda Extensions introduces a whole new companion API. So the runtime API is the little bit of code that allows your function to talk to the Lambda service. So when an event comes in, this is from the outside. This could be via API gateway or via the Lambda API, or where else, EventBridge or Step Functions or wherever. When you then transports that data rise in the Lambda services and HTTP call, and Lambda transposes that into an event and sends that onto the Lambda function. And it's that API that manages that. And just as a sidebar, what I find it cool on a sort of geeky, technical thing is, that actually API sits within the execution environment. People are like, "Oh, that's weird. Why would your Lambda API sit within the execution environment basically within the bubble that contains your function rather than it on the Lambda service?"And the cool answer for that is it's actually for a security mechanism. Like your function can then only ever talk to the Lambda runtime API, which is in that secure execution environment. And so our security can be a lot stronger because we know that no function code can ever talk directly out of your function into the Lambda service, it's all got to talk locally. And then the Lambda service gets that response from the runtime API and sends it back to the caller or whatever. Anyway, sidebar, thought that was nerdy and interesting. So what we've now done is we've released a new Extensions API. So the Extensions API is another API that an extension can use to get information from Lambda. And they're two different types of extensions, just briefly, internal and external extensions.Now, internal extensions run within the runtime process so that it's just basically another thread. So you can use this for Python or Java or something and say, when the Python runtime starts, let's start it with another parameter and also run this Java file that may do some observability, or logging, or tracing, or finding out how long the modules take to launch, for example. I know there's an example for Python. So that's one way of doing extensions. So it's internal extensions, they're two different flavors, but I'll send you a link. I'll provide a link to the blog posts before we go too far down the rabbit hole on that.And then the other part of extensions are external extensions. And this is a cool part because they actually run as completely separate processes, but still within that secure bubble, that secure execution environment that Lambda runs it. And this gives you some superpowers if you want. Because first of all, an extension can run in any language because it's a separate process. So if you've got a Node function, you could run an extension in other kind of languages. Now, what do we do recommend is you do run your extension in a compiled binary, just because you've got to provide the runtime that the extensions got to run in any way, so as a compiled binary, it's super easy and super useful. So is something like Go, a lot of people are doing because you write a single extension and Go, and then you can use it on your Node functions, your Java functions, your PowerShell functions, whatever. So that's a really good, simple way that you can have the portability.But now, what can these extensions do? Well, the extensions basically register with extensions API, and then they say to Lambda, "Lambda, I want to know about what happens when my functions invoke?" So the extension can start up, maybe it's got some initialization code, maybe it needs to connect to a database, or log into an observability platform, or pull down a secret order. That it can do, it's got its own init that can happen. And then it's basically ready to go before the function invokes. And then when the extension then registers and says, "I want to know when the function invokes and when it shuts down. Cool." And that's just something that registers with the API. Then what happens is, when a functioning invoke comes in, it tells the runtime API, "Hello, you now have an event," sends it off to the Lambda function, which the runtime manages, but also extension or extensions, multiple ones, hears information about that event. And so it can tell you the time it's going to run and has some metadata about that event. So it doesn't have the actual event data itself, but it's like the sort of Lambda context, a version of that that it's going to send to the extension.So the extension can use that to do various things. It can start collecting telemetry data. It can alter instrument some of your code. It could be managing a secret as a separate process that it is going to cache in the background. For example, we've got one with AppConfig, which is really cool. AppConfig is a service where you manage parameters external to your Lambda function. Well, each time your Lambda function warm invokes if you've got to do an external API call to retrieve that, well, it's going to be a little bit efficient. First of all, you're going to pay for it and it's going to take some time.So how about when the Lambda function runs and the extension could run before the Lambda function, why don't we just cache that locally? And then when your Lambda function runs, it just makes a local HTTP call to the extension to retrieve that value, which is going to be super quick. And some extensions are super clever because they're their own process. They will go, "Well, my value is for 30 minutes and every 30 minutes if I haven't been run, I will then update the value from that." So that's useful. Extensions can then also, when the runtime ... Sorry, let me back up.When the runtime is finished, it sends its response back to the runtime API, and extensions when they're done doing, so the runtime can send it back and the extension can carry on processing saying, "Oh, I've got the information about this. I know that this Lambda function has done X, Y, Z, so let me do, do some telemetry. Let me maybe, if I'm writing logs, I could write a log to S3 or to Kinesis or whatever. Do some kind of thing after the actual function invocation has happened." And then when it says it's ready, it says, "Hello, extensions API, I'm telling you I'm done." And then it's gone. And then Lambda freezes the execution environment, including the runtime and the extensions until another invocation happens. And the cycle then will happen.And then the last little bit that happens is, instead of an invoke coming in, we've extended the Lambda life cycles, so when the environment is going to be shut down, the extension can receive the shutdown and actually do some stuff and say, "Okay, well, I was connected to my observer HTTP platform, so let me close that connection. I've got some extra logs to flush out. I've got whatever else I need to do," and just be able to cleanly shut down that extra process that is running in parallel to the Lambda function.Jeremy: All right.Julian: So that was a lot of words.Jeremy: That was a lot and I bet you that would be great conversation for a dinner party. Really kicks things up. Now, the good news is that, first of all, thank you for that though. I mean, that's super technical and super in-depth. And for anyone listening who ...Julian: You did ask, I did warn you.Jeremy ... kind of lost their way ... Yes, but something that is really important to remember is that you likely don't have to write these yourself, right? There is all those companies you mentioned earlier, all those partners, they've already done this work. They've already figured this out and they're providing you access to their tools via this, that allows you to build things.Julian: Exactly.Jeremy: So if you want to build an extension and you want to integrate your product with Lambda or so forth, then maybe go back and listen to this at half speed. But for those of you who just want to take advantage of it because of the great functionality, a lot of these companies have already done that for you.Julian: Correct. And that's the sort of easiness thing, of just adding the Lambda layer or including in a container image. And yeah, you don't have to worry any about that, but behind the scenes, there's some really cool functionality that we're literally opening up our Lambda operates and allowing you to impact when a function responds.Jeremy: All right. All right. So let me ask another, maybe an overly technical question. I have heard, and I haven't experienced this, but that when it runs the life cycle that ends the Lambda function, I've heard something like it doesn't send the information right away, right? You have to wait for that Lambda to expire or something like that?Julian: Well, yes, for now, about to change. So currently Extensions is actually in preview. And that's not because it's in Beta or anything like that, but it's because we spoke to the partners and we didn't want to dump Extensions on the world. And all the partners had to come out with their extensions on day one and then try and figure out how customers are going to use them and everything. So what we really did, which I think in this case works out really well, is we worked with the partners and said, "Well, let's release this in preview mode and then give everybody a whole bunch of months to work out what's the best use cases, how can we best use this?" And some partners have said, "Oh, amazing. We're ready to go." And some partners have said, "Ah, it wasn't quite what we thought. Maybe we're going to wait a bit, or we're going to do something differently, or we've got some cool ideas, just give us time." And so that's what this time has been.The one other thing that has happened is we've actually added some performance enhancements during it. So yes, currently during the preview, the runtime and all extensions need to finish before we give you your response back to your Lambda function. So if you're in an asynchronous mode, you don't really care, but obviously if you're in a synchronous mode behind an API, yeah, you don't really want that. But when Extensions goes GA, which isn't going to be long, then that is no longer the case. So basically what'll happen is the runtime will respond and the result goes directly back to whoever's calling that, maybe API gateway, and the extensions can carry on, partly asynchronously in the background.Jeremy: Yep. Awesome. All right. And I know that the plan is to go GA soon. I'm not sure when around when this episode comes out, that that will be, but soon, so that's good to know that that is ...Julian: And in fact, when we go GA that performance enhancement is part of the GA. So when it goes GA, then you know, it's not something else you need to wait for.Jeremy: Perfect. Okay. All right. So let's move on to another bit of, I don't know if this is extensibility of the actual product itself or more so I think extensibility of maybe the workflow that you use to deploy to Lambda and deploy your serverless applications, and that's container image support. I mean, we've discussed it a lot. I think people kind of have an idea, but just give me your quick overview of what that is to set some context here.Julian: Yeah, sure. Well, container image support in a simple sort of headline thing is to be able to build and package your functions as a container image. So you basically build a function using a Docker file. So before if you use a zip function, but a lot of people use Serverless Framework or SAM, or whatever, that's all abstracted away from you, but it's actually creating a zip file and uploading it to Lambda or S3. So with container image support, you use a Docker file to build your Lambda function. That's the headline of what's happening.Jeremy: Right. And so the idea of creating, and this is also, and again, you mentioned packaging, right? I mean, that is the big thing here. This is a packaging format. You're not actually running the container in a Lambda function.Julian: Correct. Yeah, let's maybe think, because I mean, "containers," in inverted commas again for people who are on the audio, is ...Jeremy: What does it even mean?Julian: Yeah, exactly. And can be quite an overload of terms and definitely causes some confusion. And I sort of think maybe there's sort of four things that are in the container world. One, containers is an isolation mechanism. So on Linux, this is UNC Group, seccomp, other bits and pieces that can be used to isolate processes or maybe groups of processes. And then a second one, containers as the packaging mechanism. This is what Docker really popularized and this is about taking some code and the dependencies needed to run the code, and then packaging them all out together, maybe with some metadata to describe it.And then, three is containers as also a design philosophy. This is the idea, if we can package and isolate software, it's easier to run. Maybe smaller pieces of software is easy to reason about and manage independently. So I don't want to necessarily use microservices, but there's some component of that with it. And the emphasis here is on software rather than services, and standardized tooling to simplify your ops. And then the fourth thing is containers as an ecosystem. This is where all the products, tools, know how, all the actual things to how to do containers. And I mean, these are certain useful, but I wouldn't say there're anything about the other kind of things.What is cool and worth appreciating is how maybe independent these things are. So when I spoke about containers as isolation, well, we could actually replace containers as isolation with micro VMs such as we do with Firecracker, and there's no real change in the operational properties. So one, if we think, what are we doing with containers and why? One of those is in a way ticked off with Lambda. Lambda does have secure isolation. And containers as a packaging format. I mean, you could replace it with static linking, then maybe won't really be a change, but there's less convenience. And the design philosophy, that could really be applicable if we're talking microservices, you can have instances and certainly functions, but containers are all the same kind of thing.So if we talk about the packaging of Lambda functions, it's really for people who are more familiar with containers, why does Lambda have to be different? You've got, why does Lambda to have to be a snowflake in a way that you have to manage differently? And if you are packaging dependencies, and you're doing npm or pip install, and you're used to building Docker files, well, why can't we just do that for Lambda at the same things? And we've got some other things that come with that, larger function sizes, up to 10 gig, which is enabled with some of this technology. So it's a packaging format, but on the backend, there's a whole bunch of different stuff, which has to be done to to allow this. Benefits are, use your tooling. You've got your CI/CD pipelines already for containers, well, you can use that.Jeremy: Yeah, yeah. And I actually like that idea too. And when I first heard of it, I was like, I have nothing against containers, the containers are great. But when I was thinking about it, I'm like, "Wait container? No, what's happening here? We're losing something." But I will say, like when Lambda layers came out, which was I think maybe 2019 or something like that, maybe 2018, the idea of it made a lot of sense, being able to kind of supplement, add additional dependencies or code or whatever. But it always just seemed awkward. And some of the publishing for it was a little bit awkward. The versioning used like a numbered versioning instead of like semantic versioning and things like that. And then you had to share it to multiple places and if you published it as a SAR app, then you got global distri ... Anyways, it was a little bit hard to use.And so when you're trying to package large dependencies and put those in a layer and then combine them with a Lambda function, the other problem you had was you still had a maximum size that you could use for those, when those were combined. So I like this idea of saying like, "Look, I'd like to just kind of create this little isolate," like you said, "put my dependencies in there." Whether that's PyCharm or some other thing that is a big dependency that maybe I don't want to install, directly in a Lambda layer, or I don't want to do directly in my Lambda function. But you do that together and then that whole process just is a lot easier. And then you can actually run those containers, you could run those locally and test those if you wanted to.Julian: Correct. So that's also one of the sort of superpowers of this. And that's when I was talking about, just being able to package them up. Well, that now enables a whole bunch of extra kind of stuff. So yes, first of all is you can then use those container images that you've created as your local testing. And I know, it's silly for anyone to poo poo local testing. And we do like to say, "Well, bring your testing to the cloud rather than bringing the cloud to your testing." But testing locally for unit tests is super great. It's going to be super fast. You can iterate, have your Lambda functions, but we don't want to be mocking all of DynamoDB, all of building harebrained S3 options locally.But the cool thing is you've got the same Docker file that you're going to run in Lambda can be the same Docker file to build your function that you run locally. And it is literally exactly the same Lambda function that's going to run. And yes, that may be locally, but, with a bit of a stretch of kind of stuff, you could also run those Lambda functions elsewhere. So even if you need to run it on EC2 instances or ECS or Fargate or some kind of thing, this gives you a lot more opportunities to be able to use the same Lambda function, maybe in different way, shapes or forms, even if is on-prem. Now, obviously you can't recreate all of Lambda because that's connected to IM and it's got huge availability, and scalability, and latency and all that kind of things, but you can actually run a Lambda function in a lot more places.Jeremy: Yeah. Which is interesting. And then the other thing I had mentioned earlier was the size. So now the size of these container or these packages can be much, much bigger.Julian: Yeah, up to 10 gig. So the serverless purists in the back are shouting, "What about cold starts? What about cold starts?"Jeremy: That was my next question, yes.Julian: Yeah. I mean, back on zip functional archives are also all available, nothing changes with that Lambda layers, many people use and love, that's all available. This isn't a replacement it's just a new way of doing it. So now we've got Lambda functions that can be up to 10 gig in size and surely, surely that's got to be insane for cold starts. But actually, part of what I was talking about earlier of some of the work we've done on the backend to support this is to be able to support these super large package sizes. And the high level thing is that we actually cache those things really close to where the Lambda layer is going to be run.Now, if you run the Docker ecosystem, you build your Docker files based on base images, and so this needs to be Linux. One of the super things with the container image support is you don't have to use Amazon Linux or Amazon Linux 2 for Lambda functions, you can actually now build your Lambda functions also on Ubuntu, DBN or Alpine or whatever else. And so that also gives you a lot more functionality and flexibility. You can use the same Linux distribution, maybe across your entire suite, be it on-prem or anywhere else.Jeremy: Right. Right.Julian: And the two little components, there's an interface client, what you install, it's just another Docker layer. And that's that runtime API shim that talks to the runtime API. And then there's a runtime interface emulator and that's the thing that pretends to be Lambda, so you can shunt those events between HTTP and JSON. And that's the thing you would use to run locally. So runtime interface client means you can use any Linux distribution at the runtime interface client and you're compatible with Lambda, and then the interface emulators, what you would use for local testing, or if you want to spread your wings and run your Lambda functions elsewhere.Jeremy: Right. Awesome. Okay. So the other thing I think that container support does, I think it opens up a broader set of, or I guess a larger audience of people who are familiar with containerization and how that works, bringing those two Lambda functions. And one of the things that you really don't get when you run a container, I guess, on EC2, or, not EC2, I'm sorry, ECS, or Fargate or something like that, without kind of adding another layer on top of it, is the eventing aspect of it. I mean, Lambda just is naturally an event driven, a compute layer, right? And so, eventing and this idea of event driven applications and so forth has just become much more popular and I think much more mainstream. So what are your thoughts? What are you seeing in terms of, especially working with so many customers and businesses that are using this now, how are you seeing this sort of evolution or adoption of event driven applications?Julian: Yeah. I mean, it's quite funny to think that actually the event of an application was the genesis of Lambda rather than it being Serverless. I mentioned earlier about starting with S3. Yeah, the whole crux of Lambda has been, I respond to an event of an API gateway, or something on SQS, or via the API or anything. And so the whole point in a way of Lambda has been this event driven computing, which I think people are starting to sort of understand in a bigger thing than, "Oh, this is just the way you have to do Lambda." Because, I do think that serverless has a unique challenge where there is a new conceptual learning maybe that you have to go through. And one other thing that holds back service development is, people are used to a client's server and maybe ports and sockets. And even if you're doing containers or on-prem, or EC2, you're talking IP addresses and load balances, and sockets and firewalls, and all this kind of thing.But ultimately, when we're building these applications that are going to be composed of multiple services talking together through using APIs and events, the events is actually going to be a super part of it. And I know he is, not for so much longer, but my ultimate boss, but I can blame Jeff Bezos just a little bit, because he did say that, "If you want to talk via anything, talk via an API." And he was 100% right and that was great. But now we're sort of evolving that it doesn't just have to be an API and it doesn't have to be something behind API gateway or some API that you can run. And you can use the sort of power of events, particularly in an asynchronous model to not just be "forced" again in inverted commas to use APIs, but have far more flexibility of how data and information is going to flow through, maybe not just your application, but your suite of applications, or to and from your partners, or where that is.And ultimately authentications are going to be distributed, and maybe that is connecting to partners, that could be SaaS partners, or it's going to be an on-prem component, or maybe things in other kind of places. And those things need to communicate. And so the way of thinking about events is a super powerful way of thinking about that.Jeremy: Right. And it's not necessarily new. I mean, we've been doing web hooks for quite some time. And that idea of, something is going to happen somewhere and I want to be notified of it, is again, not a new concept. But I think certainly the way that it's evolved with Lambda and the way that other FaaS products had done eventing and things like that, is just those tight integrations and just all of the, I guess, the connective tissue that runs between those things to make sure that the events get delivered, and that you can DLQ them, and you can do all these other things with retries and stuff like that, is pretty powerful.I know you have, I actually just mentioned this on the last episode, about one of my favorite books, I think that changed my thinking and really got me thinking about how microservices communicate with one another. And that was Building Microservices by Sam Newman, which I actually said was sort of like my Bible for a couple of years, yes, I use that. So what are some of the other, like I know you have a favorite book on this.Julian: Well, that Building Microservices, Sam Newman, and I think there's a part two. I think it's part two, or there's another one ...Jeremy: Hopefully.Julian: ... in the works. I think even on O'Riley's website, you can go and see some preview copies of it. I actually haven't seen that. But yeah, I mean that is a great kind of Bible talking. And sometimes we do conflate this microservices things with a whole bunch of stuff, but if you are talking events, you're talking about separating things. But yeah, the book recommendation I have is one called Flow Architectures by James Urquhart. And James Urquhart actually works with VMware, but he's written this book which is looking sort of at the current state and also looking into the future about how does information flow through our applications and between companies and all this kind of thing.And he goes into some of the technology. When we talk about flow, we are talking about streams and we're talking about events. So streams would be, let's maybe put some AWS words around it, so streams would be something like Kinesis and events would be something like EventBridge, and topics would be SNS, and SQS would be queues. And I know we've got all these things and I wish some clever person would create the one flow service to rule them all, but we're not there. And they've got also different properties, which are helpful for different things and I know confusingly some of them merge. But James' sort of big idea is, in the future we are going to be able to moving data around between businesses, between applications. So how can we think of that as a flow? And what does that mean for designing applications and how we handle that?And Lambda is part of it, but even more nicely, I think is even some of the native integrations where you don't have to have a Lambda function. So if you've got API gateway talking to Step Functions directly, for example, well, that's even better. I mean, you don't have any code to manage and if it's certainly any code that I've written, you probably don't want to manage it. So yeah. I mean this idea of flow, Lambda's great for doing some of this moving around. But we are even evolving to be able to flow data around our applications without having to do anything and just wire up some things in a console or in a terminal.Jeremy: Right. Well, so you mentioned, someone could build the ultimate sort of flow control system or whatever. I mean, I honestly think EventBridge is very close to that. And I actually had Mike Deck on the show. I think it was like episode five. So two years ago, whenever it was when the show came out. I mean, when EventBridge came out. And we were talking and I sort of made the joke, I'm like, so this is like serverless web hooks, essentially being able, because there was the partner integrations where partners could push events onto an event bus, which they still can do. But this has evolved, right? Because the issue was always sort of like, I would have to subscribe to web books, I'd have to build a web hook to get events from a particular company. Which was great, always worked fine, but you're still maintaining that infrastructure.So EventBridge comes along, it creates these partner integrations and now you can just push an event on that now your applications, whether it's a Lambda function or other services, you can push them to an SQS queue, you can push them into a Kinesis stream, all these different destinations. You can go ahead and pull that data in and that's just there. So you don't have to worry about maintaining that infrastructure. And then, the EventBridge team went ahead and released the destination API, I think it's called.Julian: Yeah, API destinations.Jeremy: Event API destinations, right, where now you can set up these integrations with other companies, so you don't even have to make the API call yourself anymore, but instead you get all of the retries, you get the throttling, you get all that stuff kind of built in. So I mean, it's just really, really interesting where this is going. And actually, I mean, if you want to take a second to tell people about EventBridge API destinations, what that can do, because I think that now sort of creates both sides of that equation for you.Julian: It does. And I was just thinking over there, you've done a 10 times better job at explaining API destinations than I have, so you've nailed it on the head. And packet is that kind of simple. And it is just, events land up in your EventBridge and you can just pump events to any arbitrary endpoint. So it doesn't have to be in AWS, it can be on-prem. It can be to your Raspberry PI, it can literally be anywhere. But it's not just about pumping the events over there because, okay, how do we handle failover? And how do we handle over throttling? And so this is part of the extra cool goodies that came with API destinations, is that you can, for instance, if you are sending events to some external API and you only licensed for 1,000 invocations, not invocations, that could be too Lambda-ish, but 1,000 hits on the API every minute.Jeremy: Quotas. I think we call them quotas.Julian: Quotas, something like that. That's a much better term. Thank you, Jeremy. And some sort of quota, well, you can just apply that in API destinations and it'll basically store the data in the meantime in EventBridge and fire that off to the API destination. If the API destination is in that sort of throttle and if the API destination is down, well, it's going to be able to do some exponential back-off or calm down a little bit, don't over-flood this external API. And then eventually when the API does come back, it will be able to send those events. So that does just really give you excellent power rather than maintaining all these individual API endpoints yourself, and you're not handling the availability of the endpoint API, but of whatever your code is that needs to talk to that destination.Jeremy: Right. And I don't want to oversell this to anybody, but that also ...Julian: No, keep going. Keep going.Jeremy: ... adds the capability of enhanced security, because you're not exposing those API keys to your developers or anybody else, they're all baked in and stored within, the API destinations or within an EventBridge. You have the ability, you mentioned this idea of not needing Lambda to maybe talk directly, API gateway to DynamoDB or to step function or something like that. I mean, the cool thing about this is you do have translation capabilities, or transformation capabilities in EventBridge where you can transform the event. I haven't tried this, but I'm assuming it's possible to say, get an event from Salesforce and then pipe it into Stripe or some other API that you might want to pipe it into.So I mean, just that idea of having that centralized bus that can communicate with all these different things. I mean, we're talking about distributed systems here, right? So why is it different sending an event from my microservice A to my microservice B? Why can't I send it from my microservice A to company-wise, microservice B or whatever? And being able to do that in a secure, reliable, just with all of that stuff kind of built in for you, I think it's amazing. So I love EventBridge. To me EventBridge is one of those services that rivals Lambda. It's as, I guess as important as Lambda is, in this whole serverless equation.Julian: Absolutely, Jeremy. I mean, I'm just sitting here. I don't actually have to say anything. This is a brilliant interview and Jeremy, you're the expert. And you're just like laying down all of the excellent use cases. And exactly it. I mean, I like to think we've got sort of three interlinked services which do three different things, but are awesome. Lambda, we love if you need to do some processing or you need to do something that's literally your business logic. You've got EventBridge that can route data from in and out of SaaS partners to any other kind of API. And then you've got Step Functions that can do some coordination. And they all work together, but you've got three different things that really have sort of superpowers in terms of the amount of stuff you can do with it. And yes, start with them. If you land up bumping up against any kind of things that it doesn't work, well, first of all, get in touch with me, I'll work on that.But then you can maybe start thinking about, is it containers or EC2, or that kind of thing? But using literally just Lambda, Step Functions and EventBridge, okay. Yes, maybe you're going to need some queues, topics and APIs, and that kind of thing. But ...Jeremy: I was just going to say, add DynamoDB in there for some permanent state or for some data persistence. Right? Yeah. But other than that, no, I think you nailed it. Honestly, sometimes you're starting to build applications and yeah, you're right. You maybe need a queue here and there and things like that. But for the most part, no, I mean, you could build a lot with those three or four services.Julian: Yeah. Well, I mean, even think of it what you used to do before with API destinations. Maybe you drop something on a queue, you'd have Lambda pull that from a queue. You have Lambda concurrency, which would be set to five per second to then send that to an external API. If it failed going to that API, well, you've got to then dump it to Lambda destinations or to another SQS queue. You then got something ... You know, I'm going down the rabbit hole, or just put it on EventBridge ...Jeremy: You just have it magically happen.Julian: ... or we talk about removing serverless infrastructure, not normal infrastructure, and just removing even the serverless bits, which is great.Jeremy: Yeah, no. I think that's amazing. So we talked about a couple of these different services, and we talked about packaging formats and we talked about event driven applications, and all these other things. And a lot of this stuff, even though some of it may be familiar and you could probably equate it or relate it to things that developers might already know, there is still a lot of new stuff here. And I think, my biggest complaint about serverless was not about the capabilities of it, it was basically the education and the ability to get people to adopt it and understand the power behind it. So let's talk about that a little bit because ... What's that?Julian: It sounds like my job description, perfectly.Jeremy: Right. So there we go. Right, that's what you're supposed to be doing, Julian. Why aren't you doing it? No, but you are doing it. You are doing it. No, and that's why I want to talk to you about it. So you have that series on the Well-Architected Framework and we can talk about that. There's a whole bunch of really good resources on this. Obviously, you're doing videos and conferences, well, you used to be doing conferences. I think you probably still do some of those virtual ones, right? Which are not the same thing.Julian: Not quite, no.Jeremy: I mean, it was fun seeing you in Cardiff and where else were you?Julian: Yeah, Belfast.Jeremy: Cardiff and Northern Ireland.Julian: Yeah, exactly.Jeremy: Yeah, we were all over the place together.Julian: With the Guinness and all of us. It was brilliant.Jeremy: Right. So tell me a little bit about, sort of, the education process that you're trying to do. Or maybe even where you sort of see the state of Serverless education now, and just sort of where it's evolved, where we're getting best practices from, what's out there for people. And that's a really long question, but I don't know, maybe you can distill that down to something usable.Julian: No, that's quite right. I'm thinking back to my extensions explanation, which is a really long answer. So we're doing really long stuff, but that's fine. But I like to also bring this back to also thinking about the people aspect of IT. And we talk a lot about the technology and Lambda is amazing and S3 is amazing and all those kinds of things. But ultimately it is still sort of people lashing together these services and building the serverless applications, and deciding what you even need to do. And so the education is very much tied with, of course, having the products and features that do lots of kinds of things. And Serverless, there's always this lever, I suppose, between simplicity and functionality. And we are adding lots of knobs and levers and everything to Lambda to make it more feature-rich, but we've got to try and keep it simple at the same time.So there is sort of that trade-off, and of course with that, that obviously means not just the education side, but education about Lambda and serverless, but generally, how do I build applications? What do I do? And so you did mention the Well-Architected Framework. And so for people who don't know, this came out in 2015, and in 2017, there was a Serverless Lens which was added to it; what is basically serverless specific information for Well-Architected. And Well-Architected means bringing best practices to serverless applications. If you're building prod applications in the cloud, you're normally looking to build and operate them following best practices. And this is useful stuff throughout the software life cycle, it's not just at the end to tick a few boxes and go, "Yes, we've done that." So start early with the well-architected journey, it'll help you.And just sort of answer the question, am I well architected? And I mean, that is a bit of a fuzzy, what is that question? But the idea is to give you more confidence in the architecture and operations of your workloads, and that's not a goal it's in, but it's to reduce and minimize the impact of any issues that can happen. So what we do is we try and distill some of our questions and thoughts on how you could do things, and we built that into the Well-Architected Framework. And so the ServiceLens has a few questions on its operational excellence, security, reliability, performance, efficiency, and cost optimization. Excellent. I knew I was going to forget one of them and I didn't. So yeah, these are things like, how do you control access to an API? How do you do lifecycle management? How do you build resiliency into your application? All these kinds of things.And so the Well-Architected Framework with Serverless Lens there's a whole bunch of guidance to help you do that. And I have been slowly writing a blog series to literally cover all of the questions, they're nine questions in the Well-Architected Serverless Lens. And I'm about halfway through, and I had to pause because we have this little conference called re:Invent, which requires one or two slides to be created. But yeah, I'm desperately keen to pick that up again. And yeah, that's just providing some really and sort of more opinionated stuff, because the documentation is awesome and it's very in-depth and it's great when you need all that kind of stuff. But sometimes you want to know, well, okay, just tell me what to do or what do you think is best rather than these are the seven different options.Jeremy: Just tell me what to do.Julian: Yeah.Jeremy: I think that's a common question.Julian: Exactly. And I'll launch off from that to mention my colleague, James Beswick, he writes one or two things on serverless ...Jeremy: Yeah, I mean, every once in a while you see something from it. Yeah.Julian: ... every day. The Besbot machine of serverless. He's amazing. James, he's so knowledgeable and writes like a machine. He's brilliant. Yeah, I'm lucky to be on his team. So when you talk about education, I learn from him. But anyway, in a roundabout way, he's created this blog series and other series called the Lambda Operations Guide. And this is literally a whole in-depth study on how to operate Lambda. And it goes into a whole bunch of things, it's sort of linked to the Serverless Lens because there are a lot of common kind of stuff, but it's also a great read if you are more nerdily interested in Lambda than just firing off a function, just to read through it. It's written in an accessible way. And it has got a whole bunch of information on how to operate Lambda and some of the stuff under the scenes, how to work, just so you can understand it better.Jeremy: Right. Right. Yeah. And I think you mentioned this idea of confidence too. And I can tell you right now I've been writing serverless applications, well, let's see, what year is it? 2021. So I started in 2015, writing or building applications with Lambda. So I've been doing this for a while and I still get to a point every once in a while, where I'm trying to put something in cloud formation or I'm using the Serverless Framework or whatever, and you're trying to configure something and you think about, well, wait, how do I want to do this? Or is this the right way to do it? And you just have that moment where you're like, well, let me just search and see what other people are doing. And there are a lot of myths about serverless.There's as much good information is out there, there's a lot of bad information out there too. And that's something that is kind of hard to combat, but I think that maybe we could end it there. What are some of the things, the questions people are having, maybe some of the myths, maybe some of the concerns, what are those top ones that you think you could sort of ...Julian: Dispel.Jeremy: ... to tell people, dispel, yeah. That you could say, "Look, these are these aren't things to worry about. And again, go and read your blog post series, go and read James' blog post series, and you're going to get the right answers to these things."Julian: Yeah. I mean, there are misconceptions and some of them are just historical where people think the Lambda functions can only run for five minutes, they can run for 15 minutes. Lambda functions can also now run up to 10 gig of RAM. At re:Invent it was only 3 gig of RAM. That's a three times increase in Lambda functions within a three times proportional increase in CPU. So I like to say, if you had a CPU-intensive job that took 40 minutes and you couldn't run it on Lambda, you've now got three times the CPU. Maybe you can run it on Lambda and now because that would work. So yeah, some of those historical things that have just changed. We've got EFS for Lambda, that's some kind of thing you can't do state with Lambda. EFS and NFS isn't everybody's cup of tea, but that's certainly going to help some people out.And then the other big one is also cold starts. And this is an interesting one because, obviously we've sort of solved the cold start issue with connecting Lambda functions to VPC, so that's no longer an issue. And that's been a barrier for lots of people, for good reason, and that's now no longer the case. But the other thing for cold starts is interesting because, people do still get caught up at cold starts, but particularly for development because they create a Lambda function, they run it, that's a cold start and then update it and they run it and then go, oh, that's a cold start. And they don't sort of grok that the more you run your Lambda function the less cold starts you have, just because they're warm starts. And it's literally the number of Lambda functions that are running at exactly the same time will have a cold start, but then every subsequent Lambda function invocation for quite a while will be using a warm function.And so as it ramps up, we see, in the small percentages of cold starts that are actually going to happen. And when we're talking again about the container image support, that's got a whole bunch of complexity, which people are trying to understand. Hopefully, people are learning from this podcast about that as well. But also with the cold starts with that, those are huge and they're particular ways that you can construct your Lambda functions to really reduce those cold starts, and it's best practices anyway. But yeah, cold starts is also definitely one of those myths. And the other one ...Jeremy: Well, one note on cold starts too, just as something that I find to be interesting. I know that we, I even had to spend time battling with that earlier on, especially with VPC cold starts, that's all sort of gone away now, so much more efficient. The other thing is like provision concurrency. If you're using provision concurrency to get your cold starts down, I'm not even sure that's the right use for provision concurrency. I think provision concurrency is more just to make sure you have enough capacity because of the ramp-up time for Lambda. You certainly can use it for cold starts, but I don't think you need to, that's just my two cents on that.Julian: Yeah. No, that is true. And they're two different use cases for the same kind of thing. Yeah. As you say, Lambda is pretty scalable, but there is a bit of a ramp-up to get up to many, many, many, many thousands or tens of thousands of concurrent executions. And so yeah, using provision currency, you can get that up in advance. And yeah, some people do also use it for provision concurrency for getting those cold starts done. And yet that is another very valid use case, but it's only an issue for synchronous workloads as well. Anything that is synchronous you really shouldn't be carrying too much. Other than for cost perspective because it's going to take longer to run.Jeremy: Sure. Sure. I have a feeling that the last one you were going to mention, because this one bugs me quite a bit, is this idea of no ops or some people call it ops-less, which I think is kind of funny. But that's one of those things where, oh, it drives me nuts when I hear this.Julian: Yeah, exactly. And it's a frustrating thing. And I think often, sometimes when people are talking about no ops, they either have something to sell you. And sometimes what they're selling you is getting rid of something, which never is the case. It's not as though we develop serverless applications and we can then get rid of half of our development team, it just doesn't work like that. And it's crazy, in fact. And when I was talking about the people aspect of IT, this is a super important thing. And me coming from an infrastructure background, everybody is dying in their jobs to do more meaningful work and to do more interesting things and have the agility to try those experiments or try something else. Or do something that's better or even improve the way your build or improve the way your CI/CD pipeline runs or anything, rather than just having to do a lot of work in the lower levels.And this is what serverless really helps you do, is to be able to, we'll take over a whole lot of the ops for you, but it's not all of the ops, because in a way there's never an end to ops. Because you can always do stuff better. And it's not just the operations of deploying Lambda functions and limits and all that kind of thing. But I mean, think of observability and not knowing just about your application, but knowing about your business. Think of if you had the time that you weren't just monitoring function invocations and monitoring how long things were happening, but imagine if you were able to pull together dashboards of exactly what each transaction costs as it flows through your whole entire application. Think of the benefit of that to your business, or think of the benefit that in real-time, even if it's on Lambda function usage or something, you can say, "Well, oh, there's an immediate drop-off or pick-up in one region in the world or one particular application." You can spot that immediately. That kind of stuff, you just haven't had time to play with to actually build.But if we can take over some of the operational stuff with you and run one or two or trillions of Lambda functions in the background, just to keep this all ticking along nicely, you're always going to have an opportunity to do more ops. But I think the exciting bit is that ops is not just IT infrastructure, plumbing ops, but you can start even doing even better business ops where you can have more business visibility and more cool stuff for your business because we're not writing apps just for funsies.Jeremy: Right. Right. And I think that's probably maybe a good way to describe serverless, is it allows you to focus on more meaningful work and more meaningful tasks maybe. Or maybe not more meaningful, but more impactful on the business. Anyways, Julian, listen, this was a great conversation. I appreciate it. I appreciate the work that you're doing over at AWS ...Julian: Thank you.Jeremy: ... and the stuff that you're doing. And I hope that there will be a conference soon that we will be able to attend together ...Julian: I hope so too.Jeremy: ... maybe grab a drink. So if people want to get a hold of you or find out more about serverless and what AWS is doing with that, how do they do that?Julian: Yeah, absolutely. Well, please get hold of me anytime on Twitter, is the easiest way probably, julian_wood. Happy to answer your question about anything Serverless or Lambda. And if I don't know the answer, I'll always ask Jeremy, so you're covered twice over there. And then, three different things. James is, if you're talking specifically Lambda, James Beswick's operations guide, have a look at that. Just so much nuggets of super information. We've got another thing we did just sort of jump around, you were talking about cloud formation and the spark was going off in my head. We have something which we're calling the Serverless Patterns Collection, and this is really super cool. We didn't quite get to talk about it, but if you're building applications using SAM or serverless application model, or using the CDK, so either way, we've got a whole bunch of patterns which you can grab.So if you're pulling something from S3 to Lambda, or from Lambda to EventBridge, or SNS to SQS with a filter, all these kind of things, they're literally copy and paste patterns that you can put immediately into your cloud formation or your CDK templates. So when you are down the rabbit hole of Hacker News or Reddit or Stack Overflow, this is another resource that you can use to copy and paste. So go for that. And that's all hosted on our cool site called serverlessland.com. So that's serverlessland.com and that's an aggregation site that we run because we've got video talks, and we've got blog posts, and we've got learning path series, and we've got a whole bunch of stuff. Personally, I've got a learning path series coming out shortly on Lambda extensions and also one on Lambda observability. There's one coming out shortly on container image supports. And our team is talking all over as many things as we can virtually. I'm actually speaking about container images of DockerCon, which is coming up, which is exciting.And yeah, so serverlessland.com, that's got a whole bunch of information. That's just an easy one-stop-shop where you can get as much information about AWS services as you can. And if not yet, get in touch, I'm happy to help. I'm happy to also carry your feedback. And yeah, at the moment, just inside, we're sort of doing our planning for the next cycle of what Lambda and what all the service stuff we're going to do. So if you've got an awesome idea, please send it on. And I'm sure you'll be super excited when something pops out in the near issue, maybe just in future for a cool new functionality you could have been involved in.Jeremy: Well, I know that serverlessland.com is an excellent resource, and it's not that the AWS Compute blog is hard to parse through or anything, but serverlessland.com is certainly a much easier resource to get there. S

About Rebecca MarshburnRebecca's interested in the things that interest people—What's important to them? Why? And when did they first discover it to be so? She's also interested in sharing stories, elevating others' experiences, exploring the intersection of physical environments and human behavior, and crafting the perfect pun for every situation. Today, Rebecca is the Head of Content & Community at Common Room. Prior to Common Room, she led the AWS Serverless Heroes program, where she met the singular Jeremy Daly, and guided content and product experiences for fashion magazines, online blogs, AR/VR companies, education companies, and a little travel outfit called Airbnb.Twitter: @beccaodelayLinkedIn: Rebecca MarshburnCompany: www.commonroom.ioPersonal work (all proceeds go to the charity of the buyer's choice): www.letterstomyexlovers.comWatch this episode on YouTube: https://youtu.be/VVEtxgh6GKI This episode sponsored by CBT Nuggets and Lumigo.Transcript:Rebecca: What a day today is! It's not every day you turn 100 times old, and on this day we celebrate Serverless Chats 100th episode with the most special of guests. The gentleman whose voice you usually hear on this end of the microphone, doing the asking, but today he's going to be doing the telling, the one and only, Jeremy Daly, and me. I'm Rebecca Marshburn, and your guest host for Serverless Chats 100th episode, because it's quite difficult to interview yourself. Hey Jeremy!Jeremy: Hey Rebecca, thank you very much for doing this.Rebecca: Oh my gosh. I am super excited to be here, couldn't be more honored. I'll give your listeners, our listeners, today, the special day, a little bit of background about us. Jeremy and I met through the AWS Serverless Heroes program, where I used to be a coordinator for quite some time. We support each other in content, conferences, product requests, road mapping, community-building, and most importantly, I think we've supported each other in spirit, and now I'm the head of content and community at Common Room, and Jeremy's leading Serverless Cloud at Serverless, Inc., so it's even sweeter that we're back together to celebrate this Serverless Chats milestone with you all, the most important, important, important, important part of the podcast equation, the serverless community. So without further ado, let's begin.Jeremy: All right, hit me up with whatever questions you have. I'm here to answer anything.Rebecca: Jeremy, I'm going to ask you a few heavy hitters, so I hope you're ready.Jeremy: I'm ready to go.Rebecca: And the first one's going to ask you to step way, way, way, way, way back into your time machine, so if you've got the proper attire on, let's do it. If we're going to step into that time machine, let's peel the layers, before serverless, before containers, before cloud even, what is the origin story of Jeremy Daly, the man who usually asks the questions.Jeremy: That's tough. I don't think time machines go back that far, but it's funny, when I was in high school, I was involved with music, and plays, and all kinds of things like that. I was a very creative person. I loved creating things, that was one of the biggest sort of things, and whether it was music or whatever and I did a lot of work with video actually, back in the day. I was always volunteering at the local public access station. And when I graduated from high school, I had no idea what I wanted to do. I had used computers at the computer lab at the high school. I mean, this is going back a ways, so it wasn't everyone had their own computer in their house, but I went to college and then, my first, my freshman year in college, I ended up, there's a suite-mate that I had who showed me a website that he built on the university servers.And I saw that and I was immediately like, "Whoa, how do you do that"? Right, just this idea of creating something new and being able to build that out was super exciting to me, so I spent the next couple of weeks figuring out how to do HTML, and this was before, this was like when JavaScript was super, super early and we're talking like 1997, and everything was super early. I was using this, I eventually moved away from using FrontPage and started using this thing called HotDog. It was a software for HTML coding, but I started doing that, and I started building websites, and then after a while, I started figuring out what things like CGI-bins were, and how you could write Perl scripts, and how you could make interactions happen, and how you could capture FormData and serve up different things, and it was a lot of copying and pasting.My major at the time, I think was psychology, because it was like a default thing that I could do. But then I moved into computer science. I did computer science for about a year, and I felt that that was a little bit too narrow for what I was hoping to sort of do. I was starting to become more entrepreneurial. I had started selling websites to people. I had gone to a couple of local businesses and started building websites, so I actually expanded that and ended up doing sort of a major that straddled computer science and management, like business administration. So I ended up graduating with a degree in e-commerce and internet marketing, which is sort of very early, like before any of this stuff seemed to even exist. And then from there, I started a web development company, worked on that for 12 years, and then I ended up selling that off. Did a startup, failed the startup. Then from that startup, went to another startup, worked there for a couple of years, went to another startup, did a lot of consulting in between there, somewhere along the way I found serverless and AWS Cloud, and then now it's sort of led me to advocacy for building things with serverless and now I'm building sort of the, I think what I've been dreaming about building for the last several years in what I'm doing now at Serverless, Inc.Rebecca: Wow. All right. So this love story started in the 90s.Jeremy: The 90s, right.Rebecca: That's an incredible, era and welcome to 2021.Jeremy: Right. It's been a journey.Rebecca: Yeah, truly, that's literally a new millennium. So in a broad way of saying it, you've seen it all. You've started from the very HotDog of the world, to today, which is an incredible name, I'm going to have to look them up later. So then you said serverless came along somewhere in there, but let's go to the middle of your story here, so before Serverless Chats, before its predecessor, which is your weekly Off-by-none newsletter, and before, this is my favorite one, debates around, what the suffix "less" means when appended to server. When did you first hear about Serverless in that moment, or perhaps you don't remember the exact minute, but I do really want to know what struck you about it? What stood out about serverless rather than any of the other types of technologies that you could have been struck by and been having a podcast around?Jeremy: Right. And I think I gave you maybe too much of a surface level of what I've seen, because I talked mostly about software, but if we go back, I mean, hardware was one of those things where hardware, and installing software, and running servers, and doing networking, and all those sort of things, those were part of my early career as well. When I was running my web development company, we started by hosting on some hosting service somewhere, and then we ended up getting a dedicated server, and then we outgrew that, and then we ended up saying, "Well maybe we'll bring stuff in-house". So we did on-prem for quite some time, where we had our own servers in the T1 line, and then we moved to another building that had a T3 line, and if anybody doesn't know what that is, you probably don't need to anymore.But those are the things that we were doing, and then eventually we moved into a co-location facility where we rented space, and we rented electricity, and we rented all the utilities, the bandwidth, and so forth, but we had Blade servers and I was running VMware, and we were doing all this kind of stuff to manage the infrastructure, and then writing software on top of that, so it was a lot of work. I know I posted something on Twitter a few weeks ago, about how, when I was, when we were young, we used to have to carry a server on our back, uphill, both ways, to the data center, in the snow, with no shoes, and that's kind of how it felt, that you were doing a lot of these things.And then 2008, 2009, as I was kind of wrapping up my web development company, we were just in the process of actually saying it's too expensive at the colo. I think we were paying probably between like $5,000 and $7,000 a month between the ... we had leases on some of the servers, you're paying for electricity, you're paying for all these other things, and we were running a fair amount of services in there, so it seemed justifiable. We were making money on it, that wasn't the problem, but it just was a very expensive fixed cost for us, and when the cloud started coming along and I started actually building out the startup that I was working on, we were building all of that in the cloud, and as I was learning more about the cloud and how that works, I'm like, I should just move all this stuff that's in the co-location facility, move that over to the cloud and see what happens.And it took a couple of weeks to get that set up, and now, again, this is early, this is before ELB, this is before RDS, this is before, I mean, this was very, very early cloud. I mean, I think there was S3 and EC2. I think those were the two services that were available, with a few other things. I don't even think there were VPCs yet. But anyways, I moved everything over, took a couple of weeks to get that over, and essentially our bill to host all of our clients' sites and projects went from $5,000 to $7,000 a month, to $750 a month or something like that, and it's funny because had I done that earlier, I may not have sold off my web development company because it could have been much more profitable, so it was just an interesting move there.So we got into the cloud fairly early and started sort of leveraging that, and it was great to see all these things get added and all these specialty services, like RDS, and just taking the responsibility because I literally was installing Microsoft SQL server on an EC2 instance, which is not something that you want to do, you want to use RDS. It's just a much better way to do it, but anyways, so I was working for another startup, this was like startup number 17 or whatever it was I was working for, and we had this incident where we were using ... we had a pretty good setup. I mean, everything was on EC2 instances, but we were using DynamoDB to do some caching layers for certain things. We were using a sharded database, MySQL database, for product information, and so forth.So the system was pretty resilient, it was pretty, it handled all of the load testing we did and things like that, but then we actually got featured on Good Morning America, and they mentioned our app, it was the Power to Mobile app, and so we get mentioned on Good Morning America. I think it was Good Morning America. The Today Show? Good Morning America, I think it was. One of those morning shows, anyways, we got about 10,000 sign-ups in less than a minute, which was amazing, or it was just this huge spike in traffic, which was great. The problem was, is we had this really weak point in our system where we had to basically get a lock on the database in order to get an incremental-ID, and so essentially what happened is the database choked, and then as soon as the database choked, just to create user accounts, other users couldn't sign in and there was all kinds of problems, so we basically lost out on all of this capability.So I spent some time doing a lot of research and trying to figure out how do you scale that? How do you scale something that fast? How do you have that resilience in there? And there's all kinds of ways that we could have done it with traditional hardware, it's not like it wasn't possible to do with a slightly better strategy, but as I was digging around in AWS, I'm looking around at some different things, and we were, I was always in the console cause we were using Dynamo and some of those things, and I came across this thing that said "Lambda," with a little new thing next to it. I'm like, what the heck is this?So I click on that and I start reading about it, and I'm like, this is amazing. We don't have to spin up a server, we don't have to use Chef, or Puppet, or anything like that to spin up these machines. We can basically just say, when X happens, do Y, and it enlightened me, and this was early 2015, so this would have been right after Lambda went GA. Had never heard of Lambda as part of the preview, I mean, I wasn't sort of in that the re:Invent, I don't know, what would you call that? Vortex, maybe, is a good way to describe the event.Rebecca: Vortex sounds about right. That's about how it feels by the end.Jeremy: Right, exactly. So I wasn't really in that, I wasn't in that group yet, I wasn't part of that community, so I hadn't heard about it, and so as I started playing around with it, I immediately saw the value there, because, for me, as someone who again had managed servers, and it had built out really complex networking too. I think some of the things you don't think about when you move to an on-prem where you're managing your stuff, even what the cloud manages for you. I mean, we had firewalls, and we had to do all the firewall rules ourselves, right. I mean, I know you still have to do security groups and things like that in AWS, but just the level of complexity is a lot lower when you're in the cloud, and of course there's so many great services and systems that help you do that now.But just the idea of saying, "wait a minute, so if I have something happen, like a user signup, for example, and I don't have to worry about provisioning all the servers that I need in order to handle that," and again, it wasn't so much the server aspect of it as it was the database aspect of it, but one of the things that was sort of interesting about the idea of Serverless 2 was this asynchronous nature of it, this idea of being more event-driven, and that things don't have to happen immediately necessarily. So that just struck me as something where it seemed like it would reduce a lot, and again, this term has been overused, but the undifferentiated heavy-lifting, we use that term over and over again, but there is not a better term for that, right?Because there were just so many things that you have to do as a developer, as an ops person, somebody who is trying to straddle teams, or just a PM, or whatever you are, so many things that you have to do in order to get an application running, first of all, and then even more you have to do in order to keep it up and running, and then even more, if you start thinking about distributing it, or scaling it, or getting any of those things, disaster recovery. I mean, there's a million things you have to think about, and I saw serverless immediately as this opportunity to say, "Wait a minute, this could reduce a lot of that complexity and manage all of that for you," and then again, literally let you focus on the things that actually matter for your business.Rebecca: Okay. As someone who worked, how should I say this, in metatech, or the technology of technology in the serverless space, when you say that you were starting to build that without ELB even, or RDS, my level of anxiety is like, I really feel like I'm watching a slow horror film. I'm like, "No, no, no, no, no, you didn't, you didn't, you didn't have to do that, did you"?Jeremy: We did.Rebecca: So I applaud you for making it to the end of the film and still being with us.Jeremy: Well, the other thing ...Rebecca: Only one protagonist does that.Jeremy: Well, the other thing that's interesting too, about Serverless, and where it was in 2015, Lambda goes GA, this will give you some anxiety, there was no API gateway. So there was no way to actually trigger a Lambda function from a web request, right. There was no VPC access in Lambda functions, which meant you couldn't connect to a database. The only thing you do is connect via HDP, so you could connect to DynamoDB or things like that, but you could not connect directly to RDS, for example. So if you go back and you look at the timeline of when these things were released, I mean, if just from 2015, I mean, you literally feel like a caveman thinking about what you could do back then again, it's banging two sticks together versus where we are now, and the capabilities that are available to us.Rebecca: Yeah, you're sort of in Plato's cave, right, and you're looking up and you're like, "It's quite dark in here," and Lambda's up there, outside, sowing seeds, being like, "Come on out, it's dark in there". All right, so I imagine you discovering Lambda through the console is not a sentence you hear every day or general console discovery of a new product that will then sort of change the way that you build, and so I'm guessing maybe one of the reasons why you started your Off-by-none newsletter or Serverless Chats, right, is to be like, "How do I help tell others about this without them needing to discover it through the console"? But I'm curious what your why is. Why first the Off-by-none newsletter, which is one of my favorite things to receive every week, thank you for continuing to write such great content, and then why Serverless Chats? Why are we here today? Why are we at number 100? Which I'm so excited about every time I say it.Jeremy: And it's kind of crazy to think about all the people I've gotten a chance to talk to, but so, I think if you go back, I started writing blog posts maybe in 2015, so I haven't been doing it that long, and I certainly wasn't prolific. I wasn't consistent writing a blog post every week or every, two a week, like some people do now, which is kind of crazy. I don't know how that, I mean, it's hard enough writing the newsletter every week, never mind writing original content, but I started writing about Serverless. I think it wasn't until the beginning of 2018, maybe the end of 2017, and there was already a lot of great content out there. I mean, Ben Kehoe was very early into this and a lot of his stuff I read very early.I mean, there's just so many people that were very early in the space, I mean, Paul Johnson, I mean, just so many people, right, and I started reading what they were writing and I was like, "Oh, I've got some ideas too, I've been experimenting with some things, I feel like I've gotten to a point where what I could share could be potentially useful". So I started writing blog posts, and I think one of the earlier blog posts I wrote was, I want to say 2017, maybe it was 2018, early 2018, but was a post about serverless security, and what was great about that post was that actually got me connected with Ory Segal, who had started PureSec, and he and I became friends and that was the other great thing too, is just becoming part of this community was amazing.So many awesome people that I've met, but so I saw all this stuff people were writing and these things people were doing, and I got to maybe August of 2018, and I said to myself, I'm like, "Okay, I don't know if people are interested in what I'm writing". I wasn't writing a lot, but I was writing a little bit, but I wasn't sure people were overly interested in what I was writing, and again, that idea of the imposter syndrome, certainly everything was very early, so I felt a little bit more comfortable. I always felt like, well, maybe nobody knows what they're talking about here, so if I throw something into the fold it won't be too, too bad, but certainly, I was reading other things by other people that I was interested in, and I thought to myself, I'm like, "Okay, if I'm interested in this stuff, other people have to be interested in this stuff," but it wasn't easy to find, right.I mean, there was sort of a serverless Twitter, if you want to use that terminology, where a lot of people tweet about it and so forth, obviously it's gotten very noisy now because of people slapped that term on way too many things, but I don't want to have that discussion, but so I'm reading all this great stuff and I'm like, "I really want to share it," and I'm like, "Well, I guess the best way to do that would just be a newsletter."I had an email list for my own personal site that I had had a couple of hundred people on, and I'm like, "Well, let me just turn it into this thing, and I'll share these stories, and maybe people will find them interesting," and I know this is going to sound a little bit corny, but I have two teenage daughters, so I'm allowed to be sort of this dad-jokey type. I remember when I started writing the first version of this newsletter and I said to myself, I'm like, "I don't want this to be a newsletter." I was toying around with this idea of calling it an un-newsletter. I didn't want it to just be another list of links that you click on, and I know that's interesting to some people, but I felt like there was an opportunity to opine on it, to look at the individual links, and maybe even tell a story as part of all of the links that were shared that week, and I thought that that would be more interesting than just getting a list of links.And I'm sure you've seen over the last 140 issues, or however many we're at now, that there's been changes in the way that we formatted it, and we've tried new things, and things like that, but ultimately, and this goes back to the corny thing, I mean, one of the first things that I wanted to do was, I wanted to basically thank people for writing this stuff. I wanted to basically say, "Look, this is not just about you writing some content". This is big, this is important, and I appreciate it. I appreciate you for writing that content, and I wanted to make it more of a celebration really of the community and the people that were early contributors to that space, and that's one of the reasons why I did the Serverless Star thing.I thought, if somebody writes a really good article some week, and it's just, it really hits me, or somebody else says, "Hey, this person wrote a great article," or whatever. I wanted to sort of celebrate that person and call them out because that's one of the things too is writing blog posts or posting things on social media without a good following, or without the dopamine hit of people liking it, or re-tweeting it, and things like that, it can be a pretty lonely place. I mean, I know I feel that way sometimes when you put something out there, and you think it's important, or you think people might want to see it, and just not enough people see it.It's even worse, I mean, 240 characters, or whatever it is to write a tweet is one thing, or 280 characters, but if you're spending time putting together a tutorial or you put together a really good thought piece, or story, or use case, or something where you feel like this is worth sharing, because it could inspire somebody else, or it could help somebody else, could get them past a bump, it could make them think about something a different way, or get them over a hump, or whatever. I mean, that's just the kind of thing where I think people need that encouragement, and I think people deserve that encouragement for the work that they're doing, and that's what I wanted to do with Off-by-none, is make sure that I got that out there, and to just try to amplify those voices the best that I could. The other thing where it's sort of progressed, and I guess maybe I'm getting ahead of myself, but the other place where it's progressed and I thought was really interesting, was, finding people ...There's the heavy hitters in the serverless space, right? The ones we all know, and you can name them all, and they are great, and they produce amazing content, and they do amazing things, but they have pretty good engines to get their content out, right? I mean, some people who write for the AWS blog, they're on the AWS blog, right, so they're doing pretty well in terms of getting their things out there, right, and they've got pretty good engines.There's some good dev advocates too, that just have good Twitter followings and things like that. Then there's that guy who writes the story. I don't know, he's in India or he's in Poland or something like that. He writes this really good tutorial on how to do this odd edge-case for serverless. And you go and you look at their Medium and they've got two followers on Medium, five followers on Twitter or something like that. And that to me, just seems unfair, right? I mean, they've written a really good piece and it's worth sharing right? And it needs to get out there. I don't have a huge audience. I know that. I mean I've got a good following on Twitter. I feel like a lot of my Twitter followers, we can have good conversations, which is what you want on Twitter.The newsletter has continued to grow. We've got a good listener base for this show here. So, I don't have a huge audience, but if I can share that audience with other people and get other people to the forefront, then that's important to me. And I love finding those people and those ideas that other people might not see because they're not looking for them. So, if I can be part of that and help share that, that to me, it's not only a responsibility, it's just it's incredibly rewarding. So ...Rebecca: Yeah, I have to ... I mean, it is your 100th episode, so hopefully I can give you some kudos, but if celebrating others' work is one of your main tenets, you nail it every time. So ...Jeremy: I appreciate that.Rebecca: Just wanted you to know that. So, that's sort of the Genesis of course, of both of these, right?Jeremy: Right.Rebecca: That underpins the foundational how to share both works or how to share others' work through different channels. I'm wondering how it transformed, there's this newsletter and then of course it also has this other component, which is Serverless Chats. And that moment when you were like, "All right, this newsletter, this narrative that I'm telling behind serverless, highlighting all of these different authors from all these different global spaces, I'm going to start ... You know what else I want to do? I don't have enough to do, I'm going to start a podcast." How did we get here?Jeremy: Well, so the funny thing is now that I think about it, I think it just goes back to this tenet of fairness, this idea where I was fortunate, and I was able to go down to New York City and go to Serverless Days New York in late 2018. I was able to ... Tom McLaughlin actually got me connected with a bunch of great people in Boston. I live just outside of Boston. We got connected with a bunch of great people. And we started the Serverless Days Boston for 2019. And we were on that committee. I started traveling and I was going to conferences and I was meeting people. I went to re:Invent in 2018, which I know a lot of people just don't have the opportunity to do. And the interesting thing was, is that I was pulling aside brilliant people either in the hallway at a conference or more likely for a very long, deep discussion that we would have about something at a pub in Northern Ireland or something like that, right?I mean, these were opportunities that I was getting that I was privileged enough to get. And I'm like, these are amazing conversations. Just things that, for me, I know changed the way I think. And one of the biggest things that I try to do is evolve my thinking. What I thought a year ago is probably not what I think now. Maybe call it flip-flopping, whatever you want to call it. But I think that evolving your thinking is the most progressive thing that you can do and starting to understand as you gain new perspectives. And I was talking to people that I never would have talked to if I was just sitting here in my home office or at the time, I mean, I was at another office, but still, I wasn't getting that context. I wasn't getting that experience. And I wasn't getting those stories that literally changed my mind and made me think about things differently.And so, here I was in this privileged position, being able to talk to these amazing people and in some cases funny, because they're celebrities in their own right, right? I mean, these are the people where other people think of them and it's almost like they're a celebrity. And these people, I think they deserve fame. Don't get me wrong. But like as someone who has been on that side of it as well, it's ... I don't know, it's weird. It's weird to have fans in a sense. I love, again, you can be my friend, you don't have to be my fan. But that's how I felt about ...Rebecca: I'm a fan of my friends.Jeremy: So, a fan and my friend. So, having talked to these other people and having these really deep conversations on serverless and go beyond serverless to me. Actually I had quite a few conversations with some people that have nothing to do with serverless. Actually, Peter Sbarski and I, every time we get together, we only talk about the value of going to college for some reason. I don't know why. It has usually nothing to do with serverless. So, I'm having these great conversations with these people and I'm like, "Wow, I wish I could share these. I wish other people could have this experience," because I can tell you right now, there's people who can't travel, especially a lot of people outside of the United States. They ... it's hard to travel to the United States sometimes.So, these conversations are going on and I thought to myself, I'm like, "Wouldn't it be great if we could just have these conversations and let other people hear them, hopefully without bar glasses clinking in the background. And so I said, "You know what? Let's just try it. Let's see what happens. I'll do a couple of episodes. If it works, it works. If it doesn't, it doesn't. If people are interested, they're interested." But that was the genesis of that, I mean, it just goes back to this idea where I felt a little selfish having conversations and not being able to share them with other people.Rebecca: It's the very Jeremy Daly tenet slogan, right? You got to share it. You got to share it ...Jeremy: Got to share it, right?Rebecca: The more he shares it, it celebrates it. I love that. I think you do ... Yeah, you do a great job giving a megaphone so that more people can hear. So, in case you need a reminder, actually, I'll ask you, I know what the answer is to this, but do you know the answer? What was your very first episode of Serverless Chats? What was the name, and how long did it last?Jeremy: What was the name?Rebecca: Oh yeah. Oh yeah.Jeremy: Oh, well I know ... Oh, I remember now. Well, I know it was Alex DeBrie. I absolutely know that it was Alex DeBrie because ...Rebecca: Correct on that.Jeremy: If nobody, if you do not know Alex DeBrie, not only is he an AWS data hero, as well as the author of The DynamoDB Book, but he's also like the most likable person on the planet too. It is really hard if you've ever met Alex, that you wouldn't remember him. Alex and I started communicating, again, we met through the serverless space. I think actually he was working at Serverless Inc. at the time when we first met. And I think I met him in person, finally met him in person at re:Invent 2018. But he and I have collaborated on a number of things and so forth. So, let me think what the name of it was. "Serverless Purity Versus Practicality" or something like that. Is that close?Rebecca: That's exactly what it was.Jeremy: Oh, all right. I nailed it. Nailed it. Yes!Rebecca: Wow. Well, it's a great title. And I think ...Jeremy: Don't ask me what episode number 27 was though, because no way I could tell you that.Rebecca: And just for fun, it was 34 minutes long and you released it on June 17th, 2019. So, you've come a long way in a year and a half. That's some kind of wildness. So it makes sense, like, "THE," capital, all caps, bold, italic, author for databases, Alex DeBrie. Makes sense why you selected him as your guest. I'm wondering if you remember any of the ... What do you remember most about that episode? What was it like planning it? What was the reception of it? Anything funny happened recording it or releasing it?Jeremy: Yeah, well, I mean, so the funny thing is that I was incredibly nervous. I still am, actually a lot of guests that I have, I'm still incredibly nervous when I'm about to do the actual interview. And I think it's partially because I want to do justice to the content that they're presenting and to their expertise. And I feel like there's a responsibility to them, but I also feel like the guests that I've had on, some of them are just so smart, and the things they say, just I'm in awe of some of the things that come out of these people's mouths. And I'm like, "This is amazing and people need to hear this." And so, I feel like we've had really good episodes and we've had some okay episodes, but I feel like I want to try to keep that level up so that they owe that to my listener to make sure that there is high quality episode that, high quality information that they're going to get out of that.But going back to the planning of the initial episodes, so I actually had six episodes recorded before I even released the first one. And the reason why I did that was because I said, "All right, there's no way that I can record an episode and then wait a week and then record another episode and wait a week." And I thought batching them would be a good idea. And so, very early on, I had Alex and I had Nitzan Shapira and I had Ran Ribenzaft and I had Marcia Villalba and I had Erik Peterson from Cloud Zero. And so, I had a whole bunch of these episodes and I reached out to I think, eight or nine people. And I said, "I'm doing this thing, would you be interested in it?" Whatever, and we did planning sessions, still a thing that I do today, it's still part of the process.So, whenever I have a guest on, if you are listening to an episode and you're like, "Wow, how did they just like keep the thing going ..." It's not scripted. I don't want people to think it's scripted, but it is, we do review the outline and we go through some talking points to make sure that again, the high-quality episode and that the guest says all the things that the guest wants to say. A lot of it is spontaneous, right? I mean, the language is spontaneous, but we do, we do try to plan these episodes ahead of time so that we make sure that again, we get the content out and we talk about all the things we want to talk about. But with Alex, it was funny.He was actually the first of the six episodes that I recorded, though. And I wasn't sure who I was going to do first, but I hadn't quite picked it yet, but I recorded with Alex first. And it was an easy, easy conversation. And the reason why it was an easy conversation was because we had talked a number of times, right? It was that in a pub, talking or whatever, and having that friendly chat. So, that was a pretty easy conversation. And I remember the first several conversations I had, I knew Nitzan very well. I knew Ran very well. I knew Erik very well. Erik helped plan Serverless Days Boston with me. And I had known Marcia very well. Marcia actually had interviewed me when we were in Vegas for re:Invent 2018.So, those were very comfortable conversations. And so, it actually was a lot easier to do, which probably gave me a false sense of security. I was like, "Wow, this was ... These came out pretty well." The conversations worked pretty well. And also it was super easy because I was just doing audio. And once you add the video component into it, it gets a little bit more complex. But yeah, I mean, I don't know if there's anything funny that happened during it, other than the fact that I mean, I was incredibly nervous when we recorded those, because I just didn't know what to expect. If anybody wants to know, "Hey, how do you just jump right into podcasting?" I didn't. I actually was planning on how can I record my voice? How can I get comfortable behind a microphone? And so, one of the things that I did was I started creating audio versions of my blog posts and posting them on SoundCloud.So, I did that for a couple of ... I'm sorry, a couple of blog posts that I did. And that just helped make me feel a bit more comfortable about being able to record and getting a little bit more comfortable, even though I still can't stand the sound of my own voice, but hopefully that doesn't bother other people.Rebecca: That is an amazing ... I think we so often talk about ideas around you know where you want to go and you have this vision and that's your goal. And it's a constant reminder to be like, "How do I make incremental steps to actually get to that goal?" And I love that as a life hack, like, "Hey, start with something you already know that you wrote and feel comfortable in and say it out loud and say it out loud again and say it out loud again." And you may never love your voice, but you will at least feel comfortable saying things out loud on a podcast.Jeremy: Right, right, right. I'm still working on the, "Ums" and, "Ahs." I still do that. And I don't edit those out. That's another thing too, actually, that one of the things I do want people to know about this podcast is these are authentic conversations, right? I am probably like ... I feel like I'm, I mean, the most authentic person that I know. I just want authenticity. I want that out of the guests. The idea of putting together an outline is just so that we can put together a high quality episode, but everything is authentic. And that's what I want out of people. I just want that authenticity, and one of the things that I felt kept that, was leaving in, "Ums" and, "Ahs," you know what I mean? It's just, it's one of those things where I know a lot of podcasts will edit those out and it sounds really polished and finished.Again, I mean, I figured if we can get the clinking glasses out from the background of a bar and just at least have the conversation that that's what I'm trying to achieve. And we do very little editing. We do cut things out here and there, especially if somebody makes a mistake or they want to start something over again, we will cut that out because we want, again, high quality episodes. But yeah, but authenticity is deeply important to me.Rebecca: Yeah, I think it probably certainly helps that neither of us are robots because robots wouldn't say, "Um" so many times. As I say, "Uh." So, let's talk about, Alex DeBrie was your first guest, but there's been a hundred episodes, right? So, from, I might say the best guest, as a hundredth episode guests, which is our very own Jeremy Daly, but let's go back to ...Jeremy: I appreciate that.Rebecca: Your guests, one to 99. And I mean, you've chatted with some of the most thoughtful, talented, Serverless builders and architects in the industry, and across coincident spaces like ML and Voice Technology, Chaos Engineering, databases. So, you started with Alex DeBrie and databases, and then I'm going to list off some names here, but there's so many more, right? But there's the Gunnar Grosches, and the Alexandria Abbasses, and Ajay Nair, and Angela Timofte, James Beswick, Chris Munns, Forrest Brazeal, Aleksandar Simovic, and Slobodan Stojanovic. Like there are just so many more. And I'm wondering if across those hundred conversations, or 99 plus your own today, if you had to distill those into two or three lessons, what have you learned that sticks with you? If there are emerging patterns or themes across these very divergent and convergent thinkers in the serverless space?Jeremy: Oh, that's a tough question.Rebecca: You're welcome.Jeremy: So, yeah, put me on the spot here. So, yeah, I mean, I think one of the things that I've, I've seen, no matter what it's been, whether it's ML or it's Chaos Engineering, or it's any of those other observability and things like that. I think the common thing that threads all of it is trying to solve problems and make people's lives easier. That every one of those solutions is like, and we always talk about abstractions and, and higher-level abstractions, and we no longer have to write ones and zeros on punch cards or whatever. We can write languages that either compile or interpret it or whatever. And then the cloud comes along and there's things we don't have to do anymore, that just get taken care of for us.And you keep building these higher level of abstractions. And I think that's a lot of what ... You've got this underlying concept of letting somebody else handle things for you. And then you've got this whole group of people that are coming at it from a number of different angles and saying, "Well, how will that apply to my use case?" And I think a lot of those, a lot of those things are very, very specific. I think things like the voice technology where it's like the fact that serverless powers voice technology is only interesting in the fact as to say that, the voice technology is probably the more interesting part, the fact that serverless powers it is just the fact that it's a really simple vehicle to do that. And basically removes this whole idea of saying I'm building voice technology, or I'm building a voice app, why do I need to worry about setting up servers and all this kind of stuff?It just takes that away. It takes that out of the equation. And I think that's the perfect idea of saying, "How can you take your use case, fit serverless in there and apply it in a way that gets rid of all that extra overhead that you shouldn't have to worry about." And the same thing is true of machine learning. And I mean, and SageMaker, and things like that. Yeah, you're still running instances of it, or you still have to do some of these things, but now there's like SageMaker endpoints and some other things that are happening. So, it's moving in that direction as well. But then you have those really high level services like NLU API from IBM, which is the Watson Natural Language Processing.You've got AP recognition, you've got the vision API, you've got sentiment analysis through all these different things. So, you've got a lot of different services that are very specific to machine learning and solving a discrete problem there. But then basically relying on serverless or at least presenting it in a way that's serverless, where you don't have to worry about it, right? You don't have to run all of these Jupiter notebooks and things like that, to do machine learning for a lot of cases. This is one of the things I talk about with Alexandra Abbas, was that these higher level APIs are just taking a lot of that responsibility or a lot of that heavy lifting off of your plate and allowing you to really come down and focus on the things that you're doing.So, going back to that, I do think that serverless, that the common theme that I see is that this idea of worrying about servers and worrying about patching things and worrying about networking, all that stuff. For so many people now, that's just not even a concern. They didn't even think about it. And that's amazing to think of, compute ... Or data, or networking as a utility that is now just available to us, right? And I mean, again, going back to my roots, taking it for granted is something that I think a lot of people do, but I think that's also maybe a good thing, right? Just don't think about it. I mean, there are people who, they're still going to be engineers and people who are sitting in the data center somewhere and racking servers and doing it, that's going to be forever, right?But for the things that you're trying to build, that's unimportant to you. That is the furthest from your concern. You want to focus on the problem that you're trying to solve. And so I think that, that's a lot of what I've seen from talking to people is that they are literally trying to figure out, "Okay, how do I take what I'm doing, my use case, my problem, how do I take that to the next level, by being able to spend my cycles thinking about that as opposed to how I'm going to serve it up to people?"Rebecca: Yeah, I think it's the mantra, right, of simplify, simplify, simplify, or maybe even to credit Bruce Lee, be like water. You're like, "How do I be like water in this instance?" Well, it's not to be setting up servers, it's to be doing what I like to be doing. So, you've interviewed these incredible folks. Is there anyone left on your list? I'm sure there ... I mean, I know that you have a large list. Is there a few key folks where you're like, "If this is the moment I'm going to ask them, I'm going to say on the hundredth episode, 'Dear so-and-so, I would love to interview you for Serverless Chats.'" Who are you asking?Jeremy: So, this is something that, again, we have a stretch list of guests that we attempt to reach out to every once in a while just to say, "Hey, if we get them, we get them." But so, I have a long list of people that I would absolutely love to talk to. I think number one on my list is certainly Werner Vogels. I mean, I would love to talk to Dr. Vogels about a number of things, and maybe even beyond serverless, I'm just really interested. More so from a curiosity standpoint of like, "Just how do you keep that in your head?" That vision of where it's going. And I'd love to drill down more into the vision because I do feel like there's a marketing aspect of it, that's pushing on him of like, "Here's what we have to focus on because of market adoption and so forth. And even though the technology, you want to move into a certain way," I'd be really interesting to talk to him about that.And I'd love to talk to him more too about developer experience and so forth, because one of the things that I love about AWS is that it gives you so many primitives, but at the same time, the thing I hate about AWS is it gives you so many primitives. So, you have to think about 800 services, I know it's not that many, but like, what is it? 200 services, something like that, that all need to kind of connect together. And I love that there's that diversity in those capabilities, it's just from a developer standpoint, it's really hard to choose which ones you're supposed to use, especially when several services overlap. So, I'm just curious. I mean, I'd love to talk to him about that and see what the vision is in terms of, is that the idea, just to be a salad bar, to be the Golden Corral of cloud services, I guess, right?Where you can choose whatever you want and probably take too much and then not use a lot of it. But I don't know if that's part of the strategy, but I think there's some interesting questions, could dig in there. Another person from AWS that I actually want to talk to, and I haven't reached out to her yet just because, I don't know, I just haven't reached out to her yet, but is Brigid Johnson. She is like an IAM expert. And I saw her speak at re:Inforce 2019, it must have been 2019 in Boston. And it was like she was speaking a different language, but she knew IAM so well, and I am not a fan of IAM. I mean, I'm a fan of it in the sense that it's necessary and it's great, but I can't wrap my head around so many different things about it. It's such a ...It's an ongoing learning process and when it comes to things like being able to use tags to elevate permissions. Just crazy things like that. Anyways, I would love to have a conversation with her because I'd really like to dig down into sort of, what is the essence of IAM? What are the things that you really have to think about with least permission? Especially applying it to serverless services and so forth. And maybe have her help me figure out how to do some of the cross role IAM things that I'm trying to do. Certainly would love to speak to Jeff Barr. I did meet Jeff briefly. We talked for a minute, but I would love to chat with him.I think he sets a shining example of what a developer advocate is. Just the way that ... First of all, he's probably the only person alive who knows every service at AWS and has actually tried it because he writes all those blog posts about it. So that would just be great to pick his brain on that stuff. Also, Adrian Cockcroft would be another great person to talk to. Just this idea of what he's done with microservices and thinking about the role, his role with Netflix and some of those other things and how all that kind of came together, I think would be a really interesting conversation. I know I've seen this in so many of his presentations where he's talked about the objections, what were the objections of Lambda and how have you solved those objections? And here's the things that we've done.And again, the methodology of that would be really interesting to know. There's a couple of other people too. Oh, Sam Newman who wrote Building Microservices, that was my Bible for quite some time. I had it on my iPad and had a whole bunch of bookmarks and things like that. And if anybody wants to know, one of my most popular posts that I've ever written was the ... I think it was ... What is it? 16, 17 architectural patterns for serverless or serverless microservice patterns on AWS. Can't even remember the name of my own posts. But that post was very, very popular. And that even was ... I know Matt Coulter who did the CDK. He's done the whole CDK ... What the heck was that? The CDKpatterns.com. That was one of the things where he said that that was instrumental for him in seeing those patterns and being able to use those patterns and so forth.If anybody wants to know, a lot of those patterns and those ideas and those ... The sort of the confidence that I had with presenting those patterns, a lot of that came from Sam Newman's work in his Building Microservices book. So again, credit where credit is due. And I think that that would be a really fascinating conversation. And then Simon Wardley, I would love to talk to. I'd actually love to ... I actually talked to ... I met Lin Clark in Vegas as well. She was instrumental with the WebAssembly stuff, and I'd love to talk to her. Merritt Baer. There's just so many people. I'm probably just naming too many people now. But there are a lot of people that I would love to have a chat with and just pick their brain.And also, one of the things that I've been thinking about a lot on the show as well, is the term "serverless." Good or bad for some people. Some of the conversations we have go outside of serverless a little bit, right? There's sort of peripheral to it. I think that a lot of things are peripheral to serverless now. And there are a lot of conversations to be had. People who were building with serverless. Actually real-world examples.One of the things I love hearing was Yan Cui's "Real World Serverless" podcast where he actually talks to people who are building serverless things and building them in their organizations. That is super interesting to me. And I would actually love to have some of those conversations here as well. So if anyone's listening and you have a really interesting story to tell about serverless or something peripheral to serverless please reach out and send me a message and I'd be happy to talk to you.Rebecca: Well, good news is, it sounds like A, we have at least ... You've got at least another a hundred episodes planned out already.Jeremy: Most likely. Yeah.Rebecca: And B, what a testament to Sam Newman. That's pretty great when your work is referred to as the Bible by someone. As far as in terms of a tome, a treasure trove of perhaps learnings or parables or teachings. I ... And wow, what a list of other folks, especially AWS power ... Actually, not AWS powerhouses. Powerhouses who happened to work at AWS. And I think have paved the way for a ton of ways of thinking and even communicating. Right? So I think Jeff Barr, as far as setting the bar, raising the bar if you will. For how to teach others and not be so high-level, or high-level enough where you can follow along with him, right? Not so high-level where it feels like you can't achieve what he's showing other people how to do.Jeremy: Right. And I just want to comment on the Jeff Barr thing. Yeah.Rebecca: Of course.Jeremy: Because again, I actually ... That's my point. That's one of the reasons why I love what he does and he's so perfect for that position because he's relatable and he presents things in a way that isn't like, "Oh, well, yeah, of course, this is how you do this." I mean, it's not that way. It's always presented in a way to make it accessible. And even for services that I'm not interested in, that I know that I probably will never use, I generally will read Jeff's post because I feel it gives me a good overview, right?Rebecca: Right.Jeremy: It just gives me a good overview to understand whether or not that service is even worth looking at. And that's certainly something I don't get from reading the documentation.Rebecca: Right. He's inviting you to come with him and understanding this, which is so neat. So I think ... I bet we should ... I know that we can find all these twitter handles for these folks and put them in the show notes. And I'm especially ... I'm just going to say here that Werner Vogels's twitter handle is @Werner. So maybe for your hundredth, all the listeners, everyone listening to this, we can say, "Hey, @Werner, I heard that you're the number one guest that Jeremy Daly would like to interview." And I think if we get enough folks saying that to @Werner ... Did I say that @Werner, just @Werner?Jeremy: I think you did.Rebecca: Anyone if you can hear it.Jeremy: Now listen, he did retweet my serverless musical that I did. So ...Rebecca: That's right.Jeremy: I'm sort of on his radar maybe.Rebecca: Yeah. And honestly, he loves serverless, especially with the number of customers and the types of customers and ... that are doing incredible things with it. So I think we've got a chance, Jeremy. I really do. That's what I'm trying to say.Jeremy: That's good to know. You're welcome anytime. He's welcome anytime.Rebecca: Do we say that @Werner, you are welcome anytime. Right. So let's go back to the genesis, not necessarily the genesis of the concept, right? But the genesis of the technology that spurred all of these other technologies, which is AWS Lambda. And so what ... I don't think we'd be having these conversations, right, if AWS Lambda was not released in late 2014, and then when GA I believe in 2015.Jeremy: Right.Rebecca: And so subsequently the serverless paradigm was thrust into the spotlight. And that seems like eons ago, but also three minutes ago.Jeremy: Right.Rebecca: And so I'm wondering ... Let's talk about its evolution a bit and a bit of how if you've been following it for this long and building it for this long, you've covered topics from serverless CI/CD pipelines, observability. We already talked about how it's impacted voice technologies or how it's made it easy. You can build voice technology without having to care about what that technology is running on.Jeremy: Right.Rebecca: You've even talked about things like the future and climate change and how it relates to serverless. So some of those sort of related conversations that you were just talking about wanting to have or having had with previous guests. So as a host who thinks about these topics every day, I'm wondering if there's a topic that serverless hasn't touched yet or one that you hope it will soon. Those types of themes, those threads that you want to pull in the next 100 episodes.Jeremy: That's another tough question. Wow. You got good questions.Rebecca: That's what I said. Heavy hitters. I told you I'd be bringing it.Jeremy: All right. Well, I appreciate that. So that's actually a really good question. I think the evolution of serverless has seen its ups and downs. I think one of the nice things is you look at something like serverless that was so constrained when it first started. And it still has constraints, which are good. But it ... Those constraints get lifted. We just talked about Adrian's talks about how it's like, "Well, I can't do this, or I can't do that." And then like, "Okay, we'll add some feature that you can do that and you can do that." And I think that for the most part, and I won't call it anything specific, but I think for the most part that the evolution of serverless and the evolution of Lambda and what it can do has been thoughtful. And by that I mean that it was sort of like, how do we evolve this into a way that doesn't create too much complexity and still sort of holds true to the serverless ethos of sort of being fairly easy or just writing code.And then, but still evolve it to open up these other use cases and edge cases. And I think that for the most part, that it has held true to that, that it has been mostly, I guess, a smooth ride. There are several examples though, where it didn't. And I said I wasn't going to call anything out, but I'm going to call this out. I think RDS proxy wasn't great. I think it works really well, but I don't think that's the solution to the problem. And it's a band-aid. And it works really well, and congrats to the engineers who did it. I think there's a story about how two different teams were trying to build it at the same time actually. But either way, I look at that and I say, "That's a good solution to the problem, but it's not the solution to the problem."And so I think serverless has stumbled in a number of ways to do that. I also feel EFS integration is super helpful, but I'm not sure that's the ultimate goal to share ... The best way to share state. But regardless, there are a whole bunch of things that we still need to do with serverless. And a whole bunch of things that we still need to add and we need to build, and we need to figure out better ways to do maybe. But I think in terms of something that doesn't get talked about a lot, is the developer experience of serverless. And that is, again I'm not trying to pitch anything here. But that's literally what I'm trying to work on right now in my current role, is just that that developer experience of serverless, even though there was this thoughtful approach to adding things, to try to check those things off the list, to say that it can't do this, so we're going to make it be able to do that by adding X, Y, and Z.As amazing as that has been, that has added layers and layers of complexity. And I'll go back way, way back to 1997 in my dorm room. CGI-bins, if people are not familiar with those, essentially just running on a Linux server, it was a way that it would essentially run a Perl script or other types of scripts. And it was essentially like you're running PHP or you're running Node, or you're running Ruby or whatever it was. So it would run a programming language for you, run a script and then serve that information back. And of course, you had to actually know ins and outs, inputs and outputs. It was more complex than it is now.But anyways, the point is that back then though, once you had the script written. All you had to do is ... There's a thing called FTP, which I'm sure some people don't even know what that is anymore. File transfer protocol, where you would basically say, take this file from my local machine and put it on this server, which is a remote machine. And you would do that. And the second you did that, magically it was updated and you had this thing happening. And I remember there were a lot of jokes way back in the early, probably 2017, 2018, that serverless was like the new CGI-bin or something like that. But more as a criticism of it, right? Or it's just CGI-bins reborn, whatever. And I actually liked that comparison. I felt, you know what? I remember the days where I just wrote code and I just put it to some other server where somebody was dealing with it, and I didn't even have to think about that stuff.We're a long way from that now. But that's how serverless felt to me, one of the first times that I started interacting with it. And I felt there was something there, that was something special about it. And I also felt the constraints of serverless, especially the idea of not having state. People rely on things because they're there. But when you don't have something and you're forced to think differently and to make a change or find a way to work around it. Sometimes workarounds, turn into best practices. And that's one of the things that I saw with serverless. Where people were figuring out pretty quickly, how to build applications without state. And then I think the problem is that you had a lot of people who came along, who were maybe big customers of AWS. I don't know.I'm not going to say that you might be influenced by large customers. I know lots of places are. That said, "We need this." And maybe your ... The will gets bent, right. Because you just... you can only fight gravity for so long. And so those are the kinds of things where I feel some of the stuff has been patchwork and those patchwork things haven't ruined serverless. It's still amazing. It's still awesome what you can do within the course. We're still really just focusing on fast here, with everything else that's built. With all the APIs and so forth and everything else that's serverless in the full-service ecosystem. There's still a lot of amazing things there. But I do feel we've become so complex with building serverless applications, that you can't ... the Hello World is super easy, but if you're trying to build an actual application, it's a whole new mindset.You've got to learn a whole bunch of new things. And not only that, but you have to learn the cloud. You have to learn all the details of the cloud, right? You need to know all these different things. You need to know cloud formation or serverless framework or SAM or something like that, in order to get the stuff into the cloud. You need to understand the infrastructure that you're working with. You may not need to manage it, but you still have to understand it. You need to know what its limitations are. You need to know how it connects. You need to know what the failover states are like.There's so many things that you need to know. And to me, that's a burden. And that's adding new types of undifferentiated heavy-lifting that shouldn't be there. And that's the conversation that I would like to have continuing to move forward is, how do you go back to a developer experience where you're saying you're taking away all this stuff. And again, to call out Werner again, he constantly says serverless is about writing code, but ask anybody who builds serverless applications. You're doing a lot more than writing code right now. And I would love to see us bring the conversation back to how do we get back there?Rebecca: Yeah. I think it kind of goes back to ... You and I have talked about this notion of an ode to simplicity. And it's sort of what you want to write into your ode, right? If we're going to have an ode to simplicity, how do we make sure that we keep the simplicity inside of the ode?Jeremy: Right.Rebecca:So I've got ... I don't know if you've seen these.Jeremy: I don't know.Rebecca: But before I get to some wrap-up questions more from the brainwaves of Jeremy Daly, I don't want to forget to call out some long-time listener questions. And they wrote in a via Twitter and they wanted to perhaps pick your brain on a few things.Jeremy: Okay.Rebecca: So I don't know if you're ready for this.Jeremy: A-M-A. A-M-A.Rebecca: I don't know if you've seen these. Yeah, these are going to put you in the ...Jeremy: A-M-A-M. Wait, A-M-A-A? Asked me almost anything? No, go ahead. Ask me anything.Rebecca: A-M-A-A. A-M-J. No. Anyway, we got it. Ask Jeremy almost anything.Jeremy: There you go.Rebecca: So there's just three to tackle for today's episode that I'm going to lob at you. One is from Ken Collins. "What will it take to get you back to a relational database of Lambda?"Jeremy: Ooh, I'm going to tell you right now. And without a doubt, Aurora Serverless v2. I played around with that right after re:Invent 2000. What was it? 20. Yeah. Just came out, right? I'm trying to remember what year it is at this point.Rebecca: Yes. Indeed.Jeremy: When that just ... Right when that came out. And I had spent a lot of time with Aurora Serverless v1, I guess if you want to call it that. I spent a lot of time with it. I used it on a couple of different projects. I had a lot of really good success with it. I had the same pains as everybody else did when it came to scaling and just the slowness of the scaling and then ... And some of the step-downs and some of those things. There were certainly problems with it. But v2 just the early, early preview version of v2 was ... It was just a marvel of engineering. And the way that it worked was just ... It was absolutely fascinating.And I know it's getting ready or it's getting close, I think, to being GA. And when that becomes GA, I think I will have a new outlook on whether or not I can fit RDS into my applications. I will say though. Okay. I will say, I don't think that transactional applications should be using relational databases though. One of the things that was sort of a nice thing about moving to serverless, speak

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubSam Newman - Author of "Monolith to Microservices"Martin Fowler - Chief Scientist at ThoughtWorksDESCRIPTIONUpgrade your microservices knowledge by listening to a spirited conversation between two living legends: Sam Newman and Martin Fowler. The two touch upon the main reasons for using or not using microservices, and, if you decide to do use microservices, what else you should change along the way to fully benefit from the switch, plus much more.The interview is based on Sam Newman's new book "Monolith to Microservices": https://amzn.to/2Nml96ERead the full transcription of the interview here:https://gotopia.tech/bookclub/episodes/moving-to-microservices-with-sam-newman-and-martin-fowlerRECOMMENDED BOOKSam Newman • Monolith to Microservices • https://amzn.to/2Nml96Ehttps://twitter.com/GOTOconhttps://www.linkedin.com/company/goto-https://www.facebook.com/GOTOConferencesLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at https://gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.https://www.youtube.com/GotoConferences

Nicolas Rabault is the founder of Luos. Luos is building open source and real-time architecture for designing, testing, and deploying embedded applications.

Tye is a tool that makes developing, testing, and deploying microservices and distributed applications easier for developers. With very little knowledge of Docker or Kubernetes, developers can run locally orchestrated projects during development, and then publish to a hosted orchestrator of their choice.In this video, Justin and Amiee come on to talk to us about how Project Tye works. They discuss the problems it solves, show us a few demos, and even talk a little about the future of the project.[01:20] - What is Project Tye and what problems does it solve?[05:04] - How much microservice knowledge do you need to get started with Tye[06:15] - Frontend / Backend Tye Demo[11:13] - How does Tye handle project dependencies today?[12:41] - How does Tye deploy work?[14:00] - Deployment to Kubernetes Demo[18:40] - Extended Tye features[20:43] - Future of Tye Useful LinksProject Tye on GitHubTye SamplesDeveloping and Deploying Microservices with 'Tye'Introducing Project Tye

Tye is a tool that makes developing, testing, and deploying microservices and distributed applications easier for developers. With very little knowledge of Docker or Kubernetes, developers can run locally orchestrated projects during development, and then publish to a hosted orchestrator of their choice.In this video, Justin and Amiee come on to talk to us about how Project Tye works. They discuss the problems it solves, show us a few demos, and even talk a little about the future of the project.[01:20] - What is Project Tye and what problems does it solve?[05:04] - How much microservice knowledge do you need to get started with Tye[06:15] - Frontend / Backend Tye Demo[11:13] - How does Tye handle project dependencies today?[12:41] - How does Tye deploy work?[14:00] - Deployment to Kubernetes Demo[18:40] - Extended Tye features[20:43] - Future of Tye Useful LinksProject Tye on GitHubTye SamplesDeveloping and Deploying Microservices with 'Tye'Introducing Project Tye

Have you wanted to get your Python code to consume data from web-based APIs? Maybe you've dabbled with the requests package, but you don't know what steps to take next. This week on the show, David Amos is back, and he's brought another batch of PyCoder's Weekly articles and projects.

Monoliths are bad! Microservices are good! These are the "obvious" truths that many engineers hold close to heart. So, why is it that Ben Nadel ( https://www.bennadel.com ) has been slowly merging some of his Microservices back into his Monolith ( https://www.bennadel.com/blog/3944-why-ive-been-merging-microservices-back-into-the-monolith-at-invision.htm ) ? It turns out that a Monolith - like a Microservice - is a valid architectural choice that carries its own set of pros and cons. And, for him, his team, and their particular set of skills, the Monolith is proving to contain the right set of trade-offs. This week, the crew talks about Ben's journey; why InVision ( https://www.invisionapp.com/ ) started using Microservices in the first place; and, what made him realize that it was time to start pulling services back into the core Monolith. There are no hard truths here - only thoughtful, context-aware considerations. Follow the show! Our website is workingcode.dev ( https://workingcode.dev/ ) and we're *@WorkingCodePod* on Twitter ( https://twitter.com/workingcodepod ) & Instagram ( https://www.instagram.com/workingcodepod/ ). New episodes weekly on Wednesday. *Triumphs & Fails* * *Adam's Triumph* - He took the week off! He's usually not that good about taking time off; so, taking a whole week off between Christmas and New Year's was actually quite relaxing. * *Ben's Triumph* - He managed to stay production at work during the "deployment freeze" that takes place during the holidays! This meant creating lots of small, parallel git branches tied up in a bow, ready and waiting for the 2021 deployments to begin. * *Carol's Triumph* - She stayed up until 3am writing Unit Tests! She doesn't often work in an environment that does much testing; so, this was a new and thrilling experience. Who knew that one could be so happy thinking about the unhappy path ! * *Tim's Triumph* - He also took the week off (his company always takes Christmas week off)! But, he's not used to taking so much time off; and, he started to get bored by Thursday (such a classic engineer). *Notes & Links* * GitHub "Draft" pull-requests ( https://github.blog/2019-02-14-introducing-draft-pull-requests/ ) - it's just like a regular Pull Request (PR); but, it's intended to be a "work in progress" (WIP). * Silento - Watch Me (Whip/Nae Nae) ( https://www.youtube.com/watch?v=vjW8wmF5VWc ) - official music video. * Archer ( https://www.fxnetworks.com/shows/archer ) - a wonderfully raunchy animated series about spies (for adults). Sploosh! * Microservices ( https://martinfowler.com/articles/microservices.html ) - an architectural choice, write-up by Martin Fowler * Monolithic application ( https://en.wikipedia.org/wiki/Monolithic_application ) - an architectural choice. * Conway's Law ( https://en.wikipedia.org/wiki/Conway%27s_law ) - how organizational structure relates to programming structure: * Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. * Single-Tenant architecture - configuration in which one customer shares no resources with another customer. * Multi-Tenant - configuration in which many customers share the same set of resources (such as all existing in the same database). * Single Page Application (SPA) ( https://en.wikipedia.org/wiki/Single-page_application ) - a common front-end application architecture in which the front-end dynamically re-renders the UI based on data-fetches. * Distributed Monolith / Microlith - an architectural anti-pattern in which you combine the worst properties of both monoliths and microservices while reaping none / few of the rewards. * ColdFusion / Lucee CFML ( https://www.lucee.org/ ) - a modern web programming language for dynamic server-side rendering. * Mark Richards - The Rise and Fall of Microservices ( https://learning.oreilly.com/videos/oreilly-software-architecture/9781492050728/9781492050728-video328505 ) - presentation from O'Reilly Software Architecture Conference 2019. * Sam Newman - Building Microservices ( https://samnewman.io/books/building_microservices/ ) - the canonical book on Microservices. * Sam Newman - Monolith To Microservices: Evolutionary Patterns To Transform Your Monolith ( https://samnewman.io/books/monolith-to-microservices/ ) - Sam's follow-up book to Building Microservices - it should be required reading. * Simon Brown - Modular Monoliths ( http://www.codingthearchitecture.com/presentations/devnexus2016-modular-monoliths ) - presentation from DevNexus 2016 that famously had the slide: * If you can't build a well-structured monolith, what makes you think microservices is the answer? * Amazon AWS Lambda ( https://aws.amazon.com/lambda/ ) - serverless compute services. * Amazon AWS Fault-Injection Simulator ( https://aws.amazon.com/fis/ ) - aka, Chaos Monkey as a Service. * Amazon Cloudwatch ( https://docs.aws.amazon.com/cloudwatch ) - a reliable, scalable, and flexible monitoring solution. * Kevin Conway ( https://github.com/kevinconway ) - Principal engineer at InVision and a strong proponent for microservices. * Chris Richardson ( https://microservices.io/ ) - he was doing Microservices before there were Microservices. He's the maintainer of microservices.io ( https://microservices.io/ ). * Hype Cycle ( https://www.gartner.com/en/research/methodologies/gartner-hype-cycle ) - from the "Peak of Inflated Expectations" to the "Trough of Disillusionment" and every emotion in between, this is how the technology world experiences new technology. * Reactive Manifesto ( https://www.reactivemanifesto.org/ ) - an approach to building robust applications. * Lagom Reactive Microservices framework ( https://www.lagomframework.com ) - an opinionated microservices framework.

Solution Architects (SAs) play an major role in solving the most complex modern business challenges. In this episode of Cloudspotting, find out what it means to be a SA, what makes them tick and what attracts them to extremely complex business challenges. Recommended reads: * S.U.M.O. (Shut Up, Move On) by Paul McGee https://www.goodreads.com/book/show/205541.SUMOShutUpMoveOn * Thinking, Fast and Slow by Daniel Kahneman https://www.goodreads.com/book/show/11468377-thinking-fast-and-slow * Building Microservices by Sam Newman https://www.goodreads.com/book/show/22512931-building-microservices * Bad Blood: Secrets and Lies in a Silicon Valley Startup by John Carreyrou https://www.goodreads.com/book/show/37976541-bad-blood Special Guests: Markus Schmid and Simon Roberts.

Dans cet épisode, Audrey et Antonio ont invité Yannick Grenzinger et Kahled Souf pour parler micro services : pour quelle équipe, quel projet, avec quels outils … ? Nos invités vous partagent leurs retours d’expérience et leurs conseils. Enregistré le 3 juillet 2020 Téléchargement de l’épisode LesCastCodeurs-Episode–235.mp3 Interview Ta vie, ton oeuvre Yannick Grenzinger: Jardinier logiciel depuis plus de 15 ans. Actuellement coach tech et flow, je suis passionné par l’artisanat logiciel, les langages, l’architecture de systèmes complexes et la livraison de valeur métier en continue. Je suis aussi co-organisateur de la conférence FlowCon et du meetup Paris Continuous Delivery, mais c’est plus dur avec des triplés :D Khaled Souf est un Globe-trotter et développeur passionné. Il a vécu à Paris où il a travaillé pour des sociétés de conseil telles que Zenika et Arolla. il a participé à la communauté des software crafters à Paris et en Europe.Il a participe à des événements locaux, tels que les meetups Software Crafters Paris, Craft your skills, Coding Dojo. Il vit actuellement à Montréal au Canada et co-organise le Meetup Software Crafters Montréal et la conférence de SOCRATES Canada. Il aime parler de Domain Driven Design, d’architecture, d’artisanat du code, de Clean Code, des pratiques eXtreme Programming et DevOps. ksouf.com Les micro services qu’est ce que c’est ? En théorie Monolithe / Macroservices / Microservices / Fonction ? Microservices vs SOA ? Microservices, dans quel cas ? Monolithe à découper ou nouvelle app from scratch ? Patterns de migration ? Comment on découpe ses services ? Est ce qu’il y a des méthodos qui aident ? (nombre de lignes de code, nombre de pizzas par équipe, DDD) Une base de données unique pour tous les services ? Une par service ? Consistance des données ? Synchronisation des données entre bases ? Pour quelles équipes ? (DevOps, DevSecOps …) En pratique C’est quoi les reco techniques ? (frameworks Java ou autres, plateformes de déploiement, etc… ) Et dans le monde Java ? Qu’en est-il de la suite Netflix OSS (Eureka, Hystrix, Zuul, Ribbon) ? Comment on déploie / scale / fait communiquer entre eux (bloquant, non bloquant, HTTP, broker, message) ? On-premise, Cloud privée/public/hybride ? Si tu fais pas du k8s tu as loupé ta vie ? Et si tu fais pas du Kafka tu as aussi loupé ta vie ? Comment monitorer ? Et côté front ? Micro frontend : comment et pourquoi ? Le mot de la fin Phénomène de mode ou les MS sont-ils là pour rester ? Quelles sont les évolution possibles des archi MS (vers les fonctions) ? Les resources utiles Les livres de Sam Newman, surtout Building Microservices et ses talks Le livre Microservices Patterns de Chris Richardson Pour mieux appréhender la complexité de l’aventure et ses prérequis: La rubrique microservices du site de Martin Fowler 11 raisons pour lesquelles vous allez échouer avec les microservices https://www.martinfowler.com/bliki/MicroservicePrerequisites.html Recommandations sur les microservices Pourquoi les micro services devraient vous faire plus peur Vous devez être aussi grand que ça pour passer d’un monolithe à un micro services et la conf associée Pour les meilleures pratiques : Le site de Chris Richardson Le site de Microsoft Le site d’IBM DDD et microservices: DDD and Microservices: At Last, Some Boundaries! (vidéo) Strategic Microservice Patterns - Nick Tune (vidéo) Astuces pour faciliter le design de micro services avec l’event storming Orchestration, chorégraphie et saga : Orchestration vs chorégraphie Le pattern Saga pour implémenter les transactions business en microservices Using sagas to maintain data consistency in a microservice architecture - Chris Richardson(vidéo) Tests : 12 techniques pour tester les micro services Microfrontend : L’article de Martin Fowler 6 patterns pour les micro frontend Monitoring : Le pourquoi et le comment monitorer des micro services Les challenges du monitoring de microservices dans les applications cloud native Les outils : Spring qui réutilise les outils de Netflix puis Netflix qui utilise Spring Circuit breaker : Resilience4j remplace Hystrix (abandonné) Tracing : Open Tracing Zipkin et Sleuth Spring Cloud Nous contacter Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/ Flattr-ez nous (dons) sur https://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Dans cet épisode, Audrey et Antonio ont invité Yannick Grenzinger et Kahled Souf pour parler micro services : pour quelle équipe, quel projet, avec quels outils ... ? Nos invités vous partagent leurs retours d'expérience et leurs conseils. Enregistré le 3 juillet 2020 Téléchargement de l'épisode [LesCastCodeurs-Episode-235.mp3](http://traffic.libsyn.com/lescastcodeurs/LesCastCodeurs-Episode-235.mp3) ## Interview ### Ta vie, ton oeuvre [Yannick Grenzinger](https://twitter.com/ygrenzinger): Jardinier logiciel depuis plus de 15 ans. Actuellement coach tech et flow, je suis passionné par l'artisanat logiciel, les langages, l'architecture de systèmes complexes et la livraison de valeur métier en continue. Je suis aussi co-organisateur de la conférence FlowCon et du meetup Paris Continuous Delivery, mais c'est plus dur avec des triplés :D [Khaled Souf](https://twitter.com/khaledsouf) est un Globe-trotter et développeur passionné. Il a vécu à Paris où il a travaillé pour des sociétés de conseil telles que Zenika et Arolla. il a participé à la communauté des software crafters à Paris et en Europe.Il a participe à des événements locaux, tels que les meetups Software Crafters Paris, Craft your skills, Coding Dojo. Il vit actuellement à Montréal au Canada et co-organise le Meetup Software Crafters Montréal et la conférence de SOCRATES Canada. Il aime parler de Domain Driven Design, d’architecture, d’artisanat du code, de Clean Code, des pratiques eXtreme Programming et DevOps. [ksouf.com](https://ksouf.com) ### Les micro services qu’est ce que c’est ? #### En théorie Monolithe / Macroservices / Microservices / Fonction ? Microservices vs SOA ? Microservices, dans quel cas ? Monolithe à découper ou nouvelle app from scratch ? Patterns de migration ? Comment on découpe ses services ? Est ce qu’il y a des méthodos qui aident ? (nombre de lignes de code, nombre de pizzas par équipe, DDD) Une base de données unique pour tous les services ? Une par service ? Consistance des données ? Synchronisation des données entre bases ? Pour quelles équipes ? (DevOps, DevSecOps ...) #### En pratique C’est quoi les reco techniques ? (frameworks Java ou autres, plateformes de déploiement, etc... ) Et dans le monde Java ? Qu’en est-il de la suite Netflix OSS (Eureka, Hystrix, Zuul, Ribbon) ? Comment on déploie / scale / fait communiquer entre eux (bloquant, non bloquant, HTTP, broker, message) ? On-premise, Cloud privée/public/hybride ? Si tu fais pas du k8s tu as loupé ta vie ? Et si tu fais pas du Kafka tu as aussi loupé ta vie ? Comment monitorer ? #### Et côté front ? Micro frontend : comment et pourquoi ? #### Le mot de la fin Phénomène de mode ou les MS sont-ils là pour rester ? Quelles sont les évolution possibles des archi MS (vers les fonctions) ? #### Les resources utiles [Les livres de Sam Newman, surtout Building Microservices et ses talks](https://samnewman.io/talks/) [Le livre Microservices Patterns de Chris Richardson](https://www.manning.com/books/microservices-patterns) Pour mieux appréhender la complexité de l’aventure et ses prérequis: * [La rubrique microservices du site de Martin Fowler](https://www.martinfowler.com/microservices/) * [11 raisons pour lesquelles vous allez échouer avec les microservices](https://medium.com/xebia-engineering/11-reasons-why-you-are-going-to-fail-with-microservices-29b93876268b) https://www.martinfowler.com/bliki/MicroservicePrerequisites.html * [Recommandations sur les microservices](https://www.infoq.com/news/2019/03/microservices-recommendations/) * [Pourquoi les micro services devraient vous faire plus peur](https://medium.com/@bghuston/why-microservices-should-scare-you-more-556ab8f3fdb2) * [Vous devez être aussi grand que ça pour passer d'un monolithe à un micro services](https://medium.com/@ygrenzinger/you-need-to-be-this-tall-to-go-from-monolith-to-microservices-part-1-be0835ff380b) et [la conf associée](https://www.youtube.com/watch?v=dr757aMEBko) Pour les meilleures pratiques : * [Le site de Chris Richardson](https://microservices.io/index.html) * [Le site de Microsoft](https://docs.microsoft.com/en-us/azure/architecture/patterns/) * [Le site d’IBM](https://www.ibm.com/cloud/learn/microservices) DDD et microservices: * [DDD and Microservices: At Last, Some Boundaries! (vidéo)](https://www.youtube.com/watch?v=sFCgXH7DwxM) * [Strategic Microservice Patterns - Nick Tune (vidéo)](https://www.youtube.com/watch?v=ZZXMMnV3EoU) * [Astuces pour faciliter le design de micro services avec l'event storming](https://medium.com/nick-tune-tech-strategy-blog/eventstorming-modelling-tips-to-facilitate-microservice-design-1b1b0b838efc) Orchestration, chorégraphie et saga : * [Orchestration vs chorégraphie](https://stackoverflow.com/questions/4127241/orchestration-vs-choreography) * [Le pattern Saga pour implémenter les transactions business en microservices](https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/) * [Using sagas to maintain data consistency in a microservice architecture - Chris Richardson(vidéo)](https://www.youtube.com/watch?v=YPbGW3Fnmbc) Tests : [12 techniques pour tester les micro services](https://www.infoq.com/articles/twelve-testing-techniques-microservices-intro/) Microfrontend : [L'article de Martin Fowler](https://martinfowler.com/articles/micro-frontends.html) [6 patterns pour les micro frontend](https://blog.bitsrc.io/6-patterns-for-microfrontends-347ae0017ec0) Monitoring : * [Le pourquoi et le comment monitorer des micro services](https://thenewstack.io/the-hows-whys-and-whats-of-monitoring-microservices/) * [Les challenges du monitoring de microservices dans les applications cloud native](https://medium.com/@YuriShkuro/observability-challenges-in-microservices-and-cloud-native-applications-72857f9d03af) Les outils : * [Spring qui réutilise les outils de Netflix puis Netflix qui utilise Spring](https://netflixtechblog.com/netflix-oss-and-spring-boot-coming-full-circle-4855947713a0) * Circuit breaker : [Resilience4j remplace Hystrix (abandonné)](https://resilience4j.readme.io/docs) * Tracing : * [Open Tracing](https://opentracing.io/docs/overview/what-is-tracing/) * [Zipkin](https://zipkin.io/) et [Sleuth](https://spring.io/projects/spring-cloud-sleuth) * [Spring Cloud](https://spring.io/projects/spring-cloud) ## Nous contacter [Faire un crowdcast ou une crowdquestion](https://lescastcodeurs.com/crowdcasting/) Contactez-nous via twitter sur le groupe Google ou sur le site web Flattr-ez nous (dons) sur En savoir plus sur le sponsoring?

In this episode Swathi Poddar and I are talking about a thing we used to fight about: Should we or Shouldn't we allow frontend and backend specific user stories? Surely, stories should describe features, something that delivers value? But what, if there was a public API? And if it turns out that API also fed a GUI frontend? And what if your team simply demanded it as it made their lives easier? Show Notes Link to illustration which provides context for this episode: https://burnupmedia.com/2019/05/15/ep15-assigning-teams-to-features-or-services/ Sam Newman's book Building Microservices we mention (again) in this epiode: https://www.goodreads.com/book/show/22512931-building-microservices Expanded show notes and leave questions or comments for this episode at: https://burnupmedia.com/2019/05/28/ep15-should-we-allow-fe-and-be-stories/ Our guest in this episode is Swathi Poddar, Business Analyst, Product Owner and Software Consultant. She can be ‘found' and contacted here: https://www.linkedin.com/in/swathi-poddar/ – More information at https://www.theburnup.com This podcast produced by Burn Up Media Ltd under under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. Further Information at: https://creativecommons.org/licenses/by-nc-nd/4.0/

Many developers have become familiar with building microservices on traditional compute offerings such as virtual machines and containers, but what about serverless? The 'functions as a service' model behind AWS Lambda presents a number of unique differences while still providing many benefits that make it a strong fit for microservices-based architectures. In this session, we talk about mapping microservices-based architectures to Lambda's event model. You learn how to think about the bounds of functions and their alignment to the services represented. We then cover patterns that enable rapid development and easier testing. Walk away ready to build your next microservice with AWS Lambda.

Microservices are minimal function services that are deployed separately, but can interact together to function as a broader application. Microservices can be built, changed, and deployed quickly with a relatively small impact, empowering developers to speed up the rate of innovation. In this session, we show how containers help enable microservices-based application architectures, discuss best practices for building new microservices, and cover the AWS services that allow you to build performant microservices applications.

Microsoft Azure の Microservices 基盤 Service Fabric について森田が話します。

Richard Rodger is building with microservices. This episode is sponsored by Smartsheet. Show Notes: Book: The Tao of Microservices The Microservice Manifesto, also discussed in episode 77 with Chase Aucoin https://crosscuttingconcerns.com/Podcast-077-Chase-Aucoin-Microservices-Manifesto Martin Fowler on microservices microservices.io Book: Building Microservices by Sam Newman Richard Rodger is on Twitter. Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Music is by Joe Ferg, check out more music on JoeFerg.com!

Panel: Charles Max Wood Ward Bell Special Guests: Minko Gechev In this episode of Adventures in Angular, the panel talks to Minko Gechev about teaching Angular through Rhyme.com. Minko is currently working on Rhyme.com, which is a platform for hands-on demos and trainings. They touch on what Rhyme.com is, how it works, and the advantages to using it, especially in training. They also go into detail as to how an all sides workshop is set up and the versatility of using Rhyme with many different frameworks. In particular, we dive pretty deep on: Minko intro What are you most famous for in the Angular community? Angular.js style guide What is Rhyme? How does Rhyme work? All sides workshop advantages CodeSandbox.io Plunker Full on BM with virtual access Run things in your bowser eventually Working in the cloud Linux and Windows How workshops work Providing video recordings You can teach anything through Rhyme Have you used this in a coding environment? Angular CLI How are you using Angular to build this system? How much of the work is Angular pulling for you? TypeScript Architecture of Rhyme What is WebRTC? And much, much more! Links:  Rhyme.com Angular.js style guide CodeSandbox.io Plunker Linux Windows Angular CLI TypeScript WebRTC Minko’s GitHub @MGechev Minko’s Blog Picks: Charles 12 Rules for Life by Jordan B. Peterson DevChat.tv YouTube Ward Building Microservices by Sam Newman Hit Refresh by Satya Nadella Minko ngConf

Panel: Charles Max Wood Ward Bell Special Guests: Minko Gechev In this episode of Adventures in Angular, the panel talks to Minko Gechev about teaching Angular through Rhyme.com. Minko is currently working on Rhyme.com, which is a platform for hands-on demos and trainings. They touch on what Rhyme.com is, how it works, and the advantages to using it, especially in training. They also go into detail as to how an all sides workshop is set up and the versatility of using Rhyme with many different frameworks. In particular, we dive pretty deep on: Minko intro What are you most famous for in the Angular community? Angular.js style guide What is Rhyme? How does Rhyme work? All sides workshop advantages CodeSandbox.io Plunker Full on BM with virtual access Run things in your bowser eventually Working in the cloud Linux and Windows How workshops work Providing video recordings You can teach anything through Rhyme Have you used this in a coding environment? Angular CLI How are you using Angular to build this system? How much of the work is Angular pulling for you? TypeScript Architecture of Rhyme What is WebRTC? And much, much more! Links:  Rhyme.com Angular.js style guide CodeSandbox.io Plunker Linux Windows Angular CLI TypeScript WebRTC Minko’s GitHub @MGechev Minko’s Blog Picks: Charles 12 Rules for Life by Jordan B. Peterson DevChat.tv YouTube Ward Building Microservices by Sam Newman Hit Refresh by Satya Nadella Minko ngConf

Panel: Charles Max Wood Ward Bell Special Guests: Minko Gechev In this episode of Adventures in Angular, the panel talks to Minko Gechev about teaching Angular through Rhyme.com. Minko is currently working on Rhyme.com, which is a platform for hands-on demos and trainings. They touch on what Rhyme.com is, how it works, and the advantages to using it, especially in training. They also go into detail as to how an all sides workshop is set up and the versatility of using Rhyme with many different frameworks. In particular, we dive pretty deep on: Minko intro What are you most famous for in the Angular community? Angular.js style guide What is Rhyme? How does Rhyme work? All sides workshop advantages CodeSandbox.io Plunker Full on BM with virtual access Run things in your bowser eventually Working in the cloud Linux and Windows How workshops work Providing video recordings You can teach anything through Rhyme Have you used this in a coding environment? Angular CLI How are you using Angular to build this system? How much of the work is Angular pulling for you? TypeScript Architecture of Rhyme What is WebRTC? And much, much more! Links:  Rhyme.com Angular.js style guide CodeSandbox.io Plunker Linux Windows Angular CLI TypeScript WebRTC Minko’s GitHub @MGechev Minko’s Blog Picks: Charles 12 Rules for Life by Jordan B. Peterson DevChat.tv YouTube Ward Building Microservices by Sam Newman Hit Refresh by Satya Nadella Minko ngConf

Panel: Charles Max Wood Guest: Mike Gehard This week on My Ruby Story, Charles talks to Mike Gehard. Mike currently works for Pivotal working in the Platform Acceleration Lab. He first got into programming when he was 10 working with his Commodore 64, but really stepped up his interest after he graduated with his Bachelor’s in Chemical Engineering and started working at a petrochemical refining research company, where it was very computer based. They discuss how he found his way to Ruby and how easy it is to create things with it, as well as the things that he has contributed to the Ruby community that he is proud of. In particular, we dive pretty deep on: Pivotal Platform Acceleration Lab How did you first get into to programming? Commodore 64 C++ in Undergrad Bachelor’s in Chemical Engineering Master’s in Software Engineering Consulting in Chicago using C++ What is your take on the state of CS education? CS degree is not necessary, but offers many benefits It’s important to have the ability to be analytical as a programmer Scala Figure out how you learn best, and leverage that going forward Get a Coder Job Course Rails How did you get into Ruby? Rails doesn’t take a lot of “banging” to get something to fall out the other end being useful What have you contributed to the Ruby community that you’re proud of? What are you working on now? Kotlin Language IntelliJ IDEA Giving conference talks Microservices And much, much more! Links: Pivotal Platform Acceleration Lab Scala Get a Coder Job Course Rails Ruby Kotlin IntelliJ IDEA DevChat.tv YouTube @MikeGehard Picks: Charles Masterbuilt Smoker SlowCooker Elixir Mix Podcast coming soon Mike Kotlin Programming Language Building Microservices by Sam Newman

Panel: Charles Max Wood Guest: Mike Gehard This week on My Ruby Story, Charles talks to Mike Gehard. Mike currently works for Pivotal working in the Platform Acceleration Lab. He first got into programming when he was 10 working with his Commodore 64, but really stepped up his interest after he graduated with his Bachelor’s in Chemical Engineering and started working at a petrochemical refining research company, where it was very computer based. They discuss how he found his way to Ruby and how easy it is to create things with it, as well as the things that he has contributed to the Ruby community that he is proud of. In particular, we dive pretty deep on: Pivotal Platform Acceleration Lab How did you first get into to programming? Commodore 64 C++ in Undergrad Bachelor’s in Chemical Engineering Master’s in Software Engineering Consulting in Chicago using C++ What is your take on the state of CS education? CS degree is not necessary, but offers many benefits It’s important to have the ability to be analytical as a programmer Scala Figure out how you learn best, and leverage that going forward Get a Coder Job Course Rails How did you get into Ruby? Rails doesn’t take a lot of “banging” to get something to fall out the other end being useful What have you contributed to the Ruby community that you’re proud of? What are you working on now? Kotlin Language IntelliJ IDEA Giving conference talks Microservices And much, much more! Links: Pivotal Platform Acceleration Lab Scala Get a Coder Job Course Rails Ruby Kotlin IntelliJ IDEA DevChat.tv YouTube @MikeGehard Picks: Charles Masterbuilt Smoker SlowCooker Elixir Mix Podcast coming soon Mike Kotlin Programming Language Building Microservices by Sam Newman

Panel: Charles Max Wood Guest: Mike Gehard This week on My Ruby Story, Charles talks to Mike Gehard. Mike currently works for Pivotal working in the Platform Acceleration Lab. He first got into programming when he was 10 working with his Commodore 64, but really stepped up his interest after he graduated with his Bachelor’s in Chemical Engineering and started working at a petrochemical refining research company, where it was very computer based. They discuss how he found his way to Ruby and how easy it is to create things with it, as well as the things that he has contributed to the Ruby community that he is proud of. In particular, we dive pretty deep on: Pivotal Platform Acceleration Lab How did you first get into to programming? Commodore 64 C++ in Undergrad Bachelor’s in Chemical Engineering Master’s in Software Engineering Consulting in Chicago using C++ What is your take on the state of CS education? CS degree is not necessary, but offers many benefits It’s important to have the ability to be analytical as a programmer Scala Figure out how you learn best, and leverage that going forward Get a Coder Job Course Rails How did you get into Ruby? Rails doesn’t take a lot of “banging” to get something to fall out the other end being useful What have you contributed to the Ruby community that you’re proud of? What are you working on now? Kotlin Language IntelliJ IDEA Giving conference talks Microservices And much, much more! Links: Pivotal Platform Acceleration Lab Scala Get a Coder Job Course Rails Ruby Kotlin IntelliJ IDEA DevChat.tv YouTube @MikeGehard Picks: Charles Masterbuilt Smoker SlowCooker Elixir Mix Podcast coming soon Mike Kotlin Programming Language Building Microservices by Sam Newman

The O’Reilly Programming Podcast: How to effectively make the transition from monoliths to microservices.In this episode of the O’Reilly Programming Podcast, we revisit our June 2017 conversation with Sam Newman, presenter of the O’Reilly video course The Principles of Microservices and the online training course From Monolith to Microservices. He is also the author of the book Building Microservices: Designing Fine-Grained Systems.Here are some highlights from the conversation: Getting started with microservices If you’re interested in adopting a microservice architecture, start with only one or two services at the beginning. Get them deployed into production, and see if it gives you the outcome you’re looking for. How microservices allow scaling By breaking apart a monolithic system into individual services, those individual services could be scaled up as required. I could run my pricing engine on multiple separate physical machines, allowing it to handle more load. I could take another part of my system and run it on a smaller machine that doesn’t need as much load. The importance of independent deployability If you create a systems architecture where you have that characteristic of independent deployability—where you can make a change to a service and deploy that service by itself into a production environment without having to redeploy anything else—so many other benefits flow from that. Other links: Newman’s presentation Confusion in the land of the serverless at the O’Reilly 2017 Velocity Conference in London

The O’Reilly Programming Podcast: How to effectively make the transition from monoliths to microservices.In this episode of the O’Reilly Programming Podcast, we revisit our June 2017 conversation with Sam Newman, presenter of the O’Reilly video course The Principles of Microservices and the online training course From Monolith to Microservices. He is also the author of the book Building Microservices: Designing Fine-Grained Systems.Here are some highlights from the conversation: Getting started with microservices If you’re interested in adopting a microservice architecture, start with only one or two services at the beginning. Get them deployed into production, and see if it gives you the outcome you’re looking for. How microservices allow scaling By breaking apart a monolithic system into individual services, those individual services could be scaled up as required. I could run my pricing engine on multiple separate physical machines, allowing it to handle more load. I could take another part of my system and run it on a smaller machine that doesn’t need as much load. The importance of independent deployability If you create a systems architecture where you have that characteristic of independent deployability—where you can make a change to a service and deploy that service by itself into a production environment without having to redeploy anything else—so many other benefits flow from that. Other links: Newman’s presentation Confusion in the land of the serverless at the O’Reilly 2017 Velocity Conference in London

Panel: Charles Max Wood  Aimee Knight AJ O’Neal Joe Eames  Special Guests: Gareth McCumskey In this episode, JavaScript Jabber speaks with Gareth McCumskey about Serverless For JavaScript. Gareth leads the dev team at Expat Explore in Cape Town, South Africa. Gareth and this team specialize in exploring the Serverless realm in JavaScript. The JavaScript Jabbers panel and Gareth discuss the many different types of serverless systems, and when to implement them, how serverless system work, and when to go in the direction of using Serverless.  In particular, we dive pretty deep on: What does it mean to be Serverless?  Since platform as a service. Microservice on Docker  Firebase “no backend”  Backend systems  Cloud functions and failure in systems  How do you start to think about a serverless system?  How do decide what to do? AWS Lambda  Working in a different vendor Node 4  Programming JS to deploy  Using libraries for NPM How is works with AWS Lambda Where is the database? More point of failure?  Calls to Slack? Authentication Micro Services Elastic Bean Stalk Static Assets, S3, Managing Testing the services  Integration testing And much more!  Links: @garethmcc @expatexplore gareth.mccumskey.com https://github.com/garethmcc serverless.com Picks: Aimee Serverless Architectures  NG-BE Conference  AJ Documentary on Enron Hard Thing about Hard Things  Charles Serverless Framework The Storm Light Achieves  Avengers: Infinity War Gareth Building MicroServices  Skeptics Guide To The Universe Podcast Expate Explore  Joe  Wonder -  Movie Gloom In Space - Board Game   

Panel: Charles Max Wood  Aimee Knight AJ O’Neal Joe Eames  Special Guests: Gareth McCumskey In this episode, JavaScript Jabber speaks with Gareth McCumskey about Serverless For JavaScript. Gareth leads the dev team at Expat Explore in Cape Town, South Africa. Gareth and this team specialize in exploring the Serverless realm in JavaScript. The JavaScript Jabbers panel and Gareth discuss the many different types of serverless systems, and when to implement them, how serverless system work, and when to go in the direction of using Serverless.  In particular, we dive pretty deep on: What does it mean to be Serverless?  Since platform as a service. Microservice on Docker  Firebase “no backend”  Backend systems  Cloud functions and failure in systems  How do you start to think about a serverless system?  How do decide what to do? AWS Lambda  Working in a different vendor Node 4  Programming JS to deploy  Using libraries for NPM How is works with AWS Lambda Where is the database? More point of failure?  Calls to Slack? Authentication Micro Services Elastic Bean Stalk Static Assets, S3, Managing Testing the services  Integration testing And much more!  Links: @garethmcc @expatexplore gareth.mccumskey.com https://github.com/garethmcc serverless.com Picks: Aimee Serverless Architectures  NG-BE Conference  AJ Documentary on Enron Hard Thing about Hard Things  Charles Serverless Framework The Storm Light Achieves  Avengers: Infinity War Gareth Building MicroServices  Skeptics Guide To The Universe Podcast Expate Explore  Joe  Wonder -  Movie Gloom In Space - Board Game   

Panel: Charles Max Wood  Aimee Knight AJ O’Neal Joe Eames  Special Guests: Gareth McCumskey In this episode, JavaScript Jabber speaks with Gareth McCumskey about Serverless For JavaScript. Gareth leads the dev team at Expat Explore in Cape Town, South Africa. Gareth and this team specialize in exploring the Serverless realm in JavaScript. The JavaScript Jabbers panel and Gareth discuss the many different types of serverless systems, and when to implement them, how serverless system work, and when to go in the direction of using Serverless.  In particular, we dive pretty deep on: What does it mean to be Serverless?  Since platform as a service. Microservice on Docker  Firebase “no backend”  Backend systems  Cloud functions and failure in systems  How do you start to think about a serverless system?  How do decide what to do? AWS Lambda  Working in a different vendor Node 4  Programming JS to deploy  Using libraries for NPM How is works with AWS Lambda Where is the database? More point of failure?  Calls to Slack? Authentication Micro Services Elastic Bean Stalk Static Assets, S3, Managing Testing the services  Integration testing And much more!  Links: @garethmcc @expatexplore gareth.mccumskey.com https://github.com/garethmcc serverless.com Picks: Aimee Serverless Architectures  NG-BE Conference  AJ Documentary on Enron Hard Thing about Hard Things  Charles Serverless Framework The Storm Light Achieves  Avengers: Infinity War Gareth Building MicroServices  Skeptics Guide To The Universe Podcast Expate Explore  Joe  Wonder -  Movie Gloom In Space - Board Game   

Increasingly, organizations are turning to microservices to help them empower autonomous teams, letting them innovate and ship software faster than ever before. But implementing a microservices architecture comes with a number of new challenges that need to be dealt with. Chief among these finding an appropriate platform to help manage a growing number of independently deployable services.  In this session, Sam Newman, author of Building Microservices and a renowned expert in microservices strategy, will discuss strategies for building scalable and robust microservices architectures, how to choose the right platform for building microservices, and common challenges and mistakes organizations make when they move to microservices architectures.

The O’Reilly Programming Podcast: The next technological evolution of cloud systems.In this episode of the O’Reilly Programming Podcast, I talk serverless architecture with Mike Roberts, engineering leader and co-founder of Symphonia, a serverless and cloud architecture consultancy. Roberts will give two presentations—Serverless Architectures: What, Why, Why Not, and Where Next? and Designing Serverless AWS Applications—at the O’Reilly Software Architecture Conference, October 16-19, 2017, in London.Discussion points: Why Roberts calls serverless “the next evolution of cloud systems,” as individual process deployment and the resource allocation of servers are increasingly outsourced to vendors How serverless architectures use backend-as-a-service (BaaS) products and functions-as-a-service (FaaS) platforms The similarities and differences between a serverless architecture and microservices, and how microservices ideas can be applied to serverless Roberts explains that serverless is “not an all-or-nothing approach,” and that often “the best architecture for a company is going to be a hybrid architecture between serverless and non-serverless technologies.” Recent advances in serverless tooling, including progress in distributed system monitoring tools, such as Amazon’s X-Ray We also get a preview of JupyterCon, August 22-25, 2017, in New York, from conference co-chair Fernando Perez. Our discussion highlights the sessions on JupyterLab, and the UC Berkeley Data Science program, an introductory-level course in which the students use Jupyter Notebooks. Other links: Video of Roberts’ presentation An Introduction to Serverless at the April 2017 Software Architecture in New York The free eBook What Is Serverless?, by Mike Roberts and John Chapin The video AWS Lambda, presented by Mike Roberts and John Chapin Video of Roberts and Chapin’s OSCON 2017 presentation Building, Displaying and Running a Scalable and Extensible Serverless Application Using AWS Sam Newman’s book Building Microservices

The O’Reilly Programming Podcast: The next technological evolution of cloud systems.In this episode of the O’Reilly Programming Podcast, I talk serverless architecture with Mike Roberts, engineering leader and co-founder of Symphonia, a serverless and cloud architecture consultancy. Roberts will give two presentations—Serverless Architectures: What, Why, Why Not, and Where Next? and Designing Serverless AWS Applications—at the O’Reilly Software Architecture Conference, October 16-19, 2017, in London.Discussion points: Why Roberts calls serverless “the next evolution of cloud systems,” as individual process deployment and the resource allocation of servers are increasingly outsourced to vendors How serverless architectures use backend-as-a-service (BaaS) products and functions-as-a-service (FaaS) platforms The similarities and differences between a serverless architecture and microservices, and how microservices ideas can be applied to serverless Roberts explains that serverless is “not an all-or-nothing approach,” and that often “the best architecture for a company is going to be a hybrid architecture between serverless and non-serverless technologies.” Recent advances in serverless tooling, including progress in distributed system monitoring tools, such as Amazon’s X-Ray We also get a preview of JupyterCon, August 22-25, 2017, in New York, from conference co-chair Fernando Perez. Our discussion highlights the sessions on JupyterLab, and the UC Berkeley Data Science program, an introductory-level course in which the students use Jupyter Notebooks. Other links: Video of Roberts’ presentation An Introduction to Serverless at the April 2017 Software Architecture in New York The free eBook What Is Serverless?, by Mike Roberts and John Chapin The video AWS Lambda, presented by Mike Roberts and John Chapin Video of Roberts and Chapin’s OSCON 2017 presentation Building, Displaying and Running a Scalable and Extensible Serverless Application Using AWS Sam Newman’s book Building Microservices

This week brings us back to an interview that we did while at Cloud Next last week. Mark and Francesc talk to William Bonnell, Senior Director of SRE at The Home Depot all about SRE culture, and the CRE team as well. About William Bonnell William Bonnell is Senior Director of Site Reliability Engineering at The Home Depot - managing the e-commerce and order management systems, support millions of customers per day! Cool things of the week 100 announcements (!) from Google Cloud Next ‘17 blog Identity-Aware Proxy (IAP) for Google Cloud Platform (Beta) site Cloud.google.com/community site Cloud SQL for Postgre SQL (Beta) site 64 Core machines + more memory blog A new issue tracker for Google Cloud Platform blog Happy Pi Day! site Interviews 24⁄7 resiliency (Google Cloud Next ‘17) youtube Smart, Secure, and Modern app delivery for enterprises and cloud-natives (Google Cloud Next ‘17) youtube Building Microservices book Production-Ready Microservices book Site Reliability Engineering book Introducing Google Customer Reliability Engineering blog Managed Instance Groups docs Question of the week Why should I be using Cloud Spanner, rather than Cloud SQL? (Thanks AJ!) What's the difference between Google Cloud Spanner and Cloud SQL? quora Cloud Spanner docs Cloud Spanner Pricing docs Where can you find us next? Mark will be heading to Polyglot Vancouver Meetup in April, and then on to East Coast Games Conference and Vector Francesc will be presenting at Gophercon China in April.

Software Methodologies, process, patterns, platform, and devices are constantly evolving. Fast, agile, inexpensive, and massively scalable infrastructure, is improving operational efficiency and enabling faster-time-to-value across industries. However, many companies are finding that making their applications highly available, scalable and agile is still challenging.Join Lex Thomas and Razi Rais as they cover the Microservices landscape - from what it is to how your organization and customers can benefit from it. They’ll discuss how Azure Container Service and Azure Service Fabric are two major services that provide easy options to deploy large scale microservices on Azure as well as show us how to build a simple fully functional microservice in a cross-platform manner. [0:40] What is a Microservice and how can organizations benefit from them?[5:58] What are the basic principles of Microservices?[10:15] How are these principles implemented?[11:28] What hosting options are available in Azure for Microservices?[17:17] Let's chat about the Azure Service Fabric and Azure Container Service --- how does this fit into microservices?[27:45] DEMO: How to get started on Microservices on AzureWant to learn more about Microservices on Azure? Click here Join our workshop today! If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:Websites & Blogs:Microsoft Services Premier Support__________________________Send your comments or questions to the "Taste of Premier" Podcast show!Follow the conversation @TasteofPremierBecome a Fan @ Facebook.com/PremierSupportSubscribe to our podcast via iTunes, Windows Phone Podcast Marketplace or RSS

Software Methodologies, process, patterns, platform, and devices are constantly evolving. Fast, agile, inexpensive, and massively scalable infrastructure, is improving operational efficiency and enabling faster-time-to-value across industries. However, many companies are finding that making their applications highly available, scalable and agile is still challenging.Join Lex Thomas and Razi Rais as they cover the Microservices landscape - from what it is to how your organization and customers can benefit from it. They’ll discuss how Azure Container Service and Azure Service Fabric are two major services that provide easy options to deploy large scale microservices on Azure as well as show us how to build a simple fully functional microservice in a cross-platform manner. [0:40] What is a Microservice and how can organizations benefit from them?[5:58] What are the basic principles of Microservices?[10:15] How are these principles implemented?[11:28] What hosting options are available in Azure for Microservices?[17:17] Let's chat about the Azure Service Fabric and Azure Container Service --- how does this fit into microservices?[27:45] DEMO: How to get started on Microservices on AzureWant to learn more about Microservices on Azure? Click here Join our workshop today! If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:Websites & Blogs:Microsoft Services Premier Support__________________________Send your comments or questions to the "Taste of Premier" Podcast show!Follow the conversation @TasteofPremierBecome a Fan @ Facebook.com/PremierSupportSubscribe to our podcast via iTunes, Windows Phone Podcast Marketplace or RSS

Software Methodologies, process, patterns, platform, and devices are constantly evolving. Fast, agile, inexpensive, and massively scalable infrastructure, is improving operational efficiency and enabling faster-time-to-value across industries. However, many companies are finding that making their applications highly available, scalable and agile is still challenging.Join Lex Thomas and Razi Rais as they cover the Microservices landscape - from what it is to how your organization and customers can benefit from it. They’ll discuss how Azure Container Service and Azure Service Fabric are two major services that provide easy options to deploy large scale microservices on Azure as well as show us how to build a simple fully functional microservice in a cross-platform manner. [0:40] What is a Microservice and how can organizations benefit from them?[5:58] What are the basic principles of Microservices?[10:15] How are these principles implemented?[11:28] What hosting options are available in Azure for Microservices?[17:17] Let's chat about the Azure Service Fabric and Azure Container Service --- how does this fit into microservices?[27:45] DEMO: How to get started on Microservices on AzureWant to learn more about Microservices on Azure? Click here Join our workshop today! If you're interested in learning more about the products or solutions discussed in this episode, click on any of the below links for free, in-depth information:Websites & Blogs:Microsoft Services Premier Support__________________________Send your comments or questions to the "Taste of Premier" Podcast show!Follow the conversation @TasteofPremierBecome a Fan @ Facebook.com/PremierSupportSubscribe to our podcast via iTunes, Windows Phone Podcast Marketplace or RSS

A deep dive into goa, a design-based microservice framework with a DSL that generates idiomatic Go code for your APIs, swagger documentation, and tests helpers.

A deep dive into goa, a design-based microservice framework with a DSL that generates idiomatic Go code for your APIs, swagger documentation, and tests helpers.

A deep dive into goa, a design-based microservice framework with a DSL that generates idiomatic Go code for your APIs, swagger documentation, and tests helpers.

Microservices and Azure together! While at the Stockholm stop of the Azure Tour, Carl and Richard chatted with Corey Sanders in front of a live audience about the announcement at the Microsoft Connect event about Azure Service Fabric's direct support for microservices. Corey digs into the core concepts of microservices, focusing on single domain APIs that use HTTPS and REST to connect and communicate. The challenge of microservices is proliferation - between redundancy and scalability, a large application can have hundreds, even thousands of instances. Azure Service Fabric provides tooling and resources to manage the complexity of microservices while keeping the flexibility and power. Check it out!Support this podcast at — https://redcircle.com/net-rocks/donations

Microservices and Azure together! While at the Stockholm stop of the Azure Tour, Carl and Richard chatted with Corey Sanders in front of a live audience about the announcement at the Microsoft Connect event about Azure Service Fabric's direct support for microservices. Corey digs into the core concepts of microservices, focusing on single domain APIs that use HTTPS and REST to connect and communicate. The challenge of microservices is proliferation - between redundancy and scalability, a large application can have hundreds, even thousands of instances. Azure Service Fabric provides tooling and resources to manage the complexity of microservices while keeping the flexibility and power. Check it out!Support this podcast at — https://redcircle.com/net-rocks/donations

02:41 - Sam Aaron Introduction and Background Twitter GitHub Blog 10:53 - Sonic Pi Defined Affordable Creative Coding with Music 13:10 - Live Performance Aspect 23:58 - The Learning Curve 28:06 - Teaching Kids to Program Through Music Joseph Wilk: Programming as Performance @ Ruby Conf Australia 2015 34:07 - Sonic Pi in the Classroom 36:22 - Threading Cue and Sync 41:18 - Choosing Ruby Over Clojure for Sonic Pi 44:13 - Sonic Pi Roadmap: What’s Next? 49:22 - Contribute to the sonic-pi Repo! Sonic Pi on Facebook Phase Abstractions: Live Coded with Sonic Pi at NODE15, Frankfurt 50:43 - Heritage? archaeopteryx midiator 53:53 - Experimenting with Music, The Evolution of Dance Music 56:19 - Types of Sounds Synths Pre-recorded Sounds freesound.org Effects Picks Cate Huston: 5 Strategies For Making Progress on Side Projects (Coraline) TIS-100 (Coraline) Building Microservices by Sam Newman (David) Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (David) [YouTube] Ben Eggett: Writing Music with Ruby: A Subtle Introduction to Music Theory @ MountainWest RubyConf 2015 (Chuck) Elixir (Chuck) Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas (Chuck) Wabi-Sabi for Artists, Designers, Poets & Philosophers by Leonard Koren (Sam) The Joy of Clojure by Michael Fogus (Sam) Raspberry Pi (Sam)

02:41 - Sam Aaron Introduction and Background Twitter GitHub Blog 10:53 - Sonic Pi Defined Affordable Creative Coding with Music 13:10 - Live Performance Aspect 23:58 - The Learning Curve 28:06 - Teaching Kids to Program Through Music Joseph Wilk: Programming as Performance @ Ruby Conf Australia 2015 34:07 - Sonic Pi in the Classroom 36:22 - Threading Cue and Sync 41:18 - Choosing Ruby Over Clojure for Sonic Pi 44:13 - Sonic Pi Roadmap: What’s Next? 49:22 - Contribute to the sonic-pi Repo! Sonic Pi on Facebook Phase Abstractions: Live Coded with Sonic Pi at NODE15, Frankfurt 50:43 - Heritage? archaeopteryx midiator 53:53 - Experimenting with Music, The Evolution of Dance Music 56:19 - Types of Sounds Synths Pre-recorded Sounds freesound.org Effects Picks Cate Huston: 5 Strategies For Making Progress on Side Projects (Coraline) TIS-100 (Coraline) Building Microservices by Sam Newman (David) Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (David) [YouTube] Ben Eggett: Writing Music with Ruby: A Subtle Introduction to Music Theory @ MountainWest RubyConf 2015 (Chuck) Elixir (Chuck) Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas (Chuck) Wabi-Sabi for Artists, Designers, Poets & Philosophers by Leonard Koren (Sam) The Joy of Clojure by Michael Fogus (Sam) Raspberry Pi (Sam)

02:41 - Sam Aaron Introduction and Background Twitter GitHub Blog 10:53 - Sonic Pi Defined Affordable Creative Coding with Music 13:10 - Live Performance Aspect 23:58 - The Learning Curve 28:06 - Teaching Kids to Program Through Music Joseph Wilk: Programming as Performance @ Ruby Conf Australia 2015 34:07 - Sonic Pi in the Classroom 36:22 - Threading Cue and Sync 41:18 - Choosing Ruby Over Clojure for Sonic Pi 44:13 - Sonic Pi Roadmap: What’s Next? 49:22 - Contribute to the sonic-pi Repo! Sonic Pi on Facebook Phase Abstractions: Live Coded with Sonic Pi at NODE15, Frankfurt 50:43 - Heritage? archaeopteryx midiator 53:53 - Experimenting with Music, The Evolution of Dance Music 56:19 - Types of Sounds Synths Pre-recorded Sounds freesound.org Effects Picks Cate Huston: 5 Strategies For Making Progress on Side Projects (Coraline) TIS-100 (Coraline) Building Microservices by Sam Newman (David) Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (David) [YouTube] Ben Eggett: Writing Music with Ruby: A Subtle Introduction to Music Theory @ MountainWest RubyConf 2015 (Chuck) Elixir (Chuck) Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas (Chuck) Wabi-Sabi for Artists, Designers, Poets & Philosophers by Leonard Koren (Sam) The Joy of Clojure by Michael Fogus (Sam) Raspberry Pi (Sam)

Microservices? Carl and Richard talk to Howard Dierking about his work building microservices starting with the name - Howard hates the term microservices. He prefers to call them focused services, which only makes sense. The goal is to write as little code as possible while delivering the capabilities needed, not all that different from most modern development approaches. The conversation turns to how we've twisted service design because deployment and versioning were so difficult. Today its better and we can take advantage of granularity to keep our services small, independently updated and flexible!Support this podcast at — https://redcircle.com/net-rocks/donations

Microservices? Carl and Richard talk to Howard Dierking about his work building microservices starting with the name - Howard hates the term microservices. He prefers to call them focused services, which only makes sense. The goal is to write as little code as possible while delivering the capabilities needed, not all that different from most modern development approaches. The conversation turns to how we've twisted service design because deployment and versioning were so difficult. Today its better and we can take advantage of granularity to keep our services small, independently updated and flexible!Support this podcast at — https://redcircle.com/net-rocks/donations