Podcast appearances and mentions of James Urquhart

Big changes are happening in Meta's ad platform, and in this episode, Nick Boddington is joined by James Urquhart and Michael to break them down for you. From the removal of audience exclusions to the shifting nature of Meta's database, they explore what these updates mean for advertisers and how to adjust your strategy. Plus, the episode kicks off a new segment, What's Better on Meta?, covering the latest platform updates. Tune in to stay ahead of the game and keep your Facebook ad campaigns optimised for success! BUT THERE'S MORE...If you need help with your Facebook ads, then join The Ads Clinic Free Skool. Click here: https://www.skool.com/theadsclinic Follow me on Instagram to keep up to date with all the latest hacks: @nickboddington You can now watch the episode on Youtube!

In this very special episode 100 of the podcast, Nick is joined by special guest James Urquhart to look back on the last 100 episodes of the Let's Run Facebook Ads Podcast.In this episode, Nick and James discuss how advertising products has changed since the podcast started, memorable moments from the last 100 episodes as well as standout individuals they have met. Finally, they also speculate on the future of Facebook advertising and how the landscape may change in the years to come.Thanks for listening! To join our Lets Run Facebook Ads Facebook group click here: https://www.facebook.com/groups/letsrunsocialads Follow me on Instagram to keep up to date with all the latest hacks: @nickboddington You can now watch the episode on Youtube!

Reframe the Behaviour: Evaluation of a training intervention to increase capacity in managing detained youth with fetal alcohol spectrum disorder and neurodevelopmental impairmentsHayley M Passmore, Raewyn C Mutch, Rochelle Watkins, Sharyn Burns, Guy Hall, James Urquhart, Jonathan Carapetis, Carol Bower Affiliations expandPMID: 35530127PMCID: PMC9067986DOI: 10.1080/13218719.2020.1780643Free PMC articleAbstractThe first study to investigate the prevalence of fetal alcohol spectrum disorder (FASD) within an Australian juvenile detention centre has identified the highest known prevalence of FASD among a justice-involved population worldwide. However, there has been limited investigation into the capacity of the custodial workforce to identify and manage young people in Australian detention centres with FASD or other neurodevelopmental impairment (NDI), and no published interventions aiming to develop environments appropriate for those with FASD in justice settings. Using the Template for Intervention Description and Replication checklist, this study describes the conception, implementation and evaluation of a training intervention aiming to upskill the custodial workforce in the management of youth with FASD and NDI; 117 staff participated in the intervention, and 109 completed pre- and post-intervention surveys. Improvements were seen across almost all knowledge and attitude items, and the intervention was considered highly necessary, appropriate and valuable by the workforce.

A Goldilocks' balance challenges us to trade off prescriptive and flexible platforms. James Urquhart shares his experiences with Cloud Foundry, VMware, and Amazon about trying to find the right balance between building it yourself versus a prescriptive service approach. We've decided that there needs to be a middle zone with enough opportunity for customization, as well as enough pre-set, prescriptive methods to create sustainability. In this episode, we talk about that balance and how different processes have done it in industry. Transcript: https://otter.ai/u/OQBfCHldtYjUpqjKdkN3KjzLiR0 Image: https://www.pexels.com/photo/brown-teddy-bear-on-brown-wooden-bench-outside-207891/

Flow Architectures with James Urquhart Follow James here: https://twitter.com/jamesurquhart

This week we discuss 1Password moving to Electron, Knative and Infrastructure as Code best practices. Plus, what to do with extra lumber… Rundown Users lobby 1Password to abandon new Electron version (https://appleinsider.com/articles/21/08/16/users-lobby-1password-to-abandon-new-electron-version) Cisco beefing up app monitoring portfolio with acquisition of Epsagon for $500M (https://techcrunch.com/2021/08/16/cisco-beefing-up-app-monitoring-portfolio-with-acquisition-of-epsagon-for-500m/) Cloud startup Epsagon to be acquired by Cisco for $500 million (https://www.calcalistech.com/ctech/articles/0,7340,L-3915010,00.html) Relevant to your interests Clearlake Capital completes strategic equity investment in RSA (https://clearlake.com/clearlake-capital-completes-strategic-equity-investment-in-rsa/) Apple SVP Craig Federighi responds to confusion over iOS 15 iCloud child safety policies in new interview (https://9to5mac.com/2021/08/13/apple-svp-craig-federighi-responds-to-confusion-over-ios-15-icloud-child-safety-policies-in-new-interview/) Poly Network offers $500,000 reward to crypto hacker who returned stolen assets. (https://www.engadget.com/poly-network-rewards-crypto-hacker-121507483.html) PolyNetwork's Hacker Returns All Funds on Ethereum and Refuses a $500K Bug Bounty (https://cryptopotato.com/polynetworks-hacker-returns-all-funds-on-ethereum-and-refuses-a-500k-bug-bounty/) Disney Beats Q3 Estimates As Streaming Flagship Hits 116M Subscribers (https://deadline.com/2021/08/disney-q3-beats-estimates-streaming-116-million-subscribers-1234813827/) (https://www.engadget.com/poly-network-rewards-crypto-hacker-121507483.html) Translates GitHub Actions into Tekton and Knative Objects (https://github.com/triggermesh/aktion) Music Distributor DistroKid Raises Money at $1.3 Billion Valuation from the creator of F'dcompany.com (https://www.bloomberg.com/news/articles/2021-08-16/music-distributor-distrokid-raises-money-at-1-3-billion-valuation?srnd=markets-vp) HashiCorp State of Cloud Strategy Survey (https://www.hashicorp.com/state-of-the-cloud) T-Mobile Investigating Claims of Massive Data Breach (https://krebsonsecurity.com/2021/08/t-mobile-investigating-claims-of-massive-data-breach/) Funding, Buyback, and Hiring (https://ma.tt/2021/08/funding-buyback-hiring/) Palantir bought $50 million in gold bars in August as cash pile grows (https://www.cnbc.com/2021/08/17/palantir-bought-50-million-in-gold-bars-in-august-as-cash-accumulates.html) In No Code you delete code as you write it. (https://twitter.com/kelseyhightower/status/1427707854090215429?s=20) Roblox bookings grow 35% to $665.5M for Q2 2021 (https://venturebeat.com/2021/08/16/roblox-bookings-grow-35-to-665-5m-for-q2-2021/) WhatsApp Can't Ban the Taliban Because It Can't Read Their Texts (https://www.vice.com/en/article/93yvy5/whatsapp-says-its-not-banning-the-taliban-because-it-cant-read-their-texts) OK, so you stole $600m-plus from us, how about you be our Chief Security Advisor, Poly Network asks thief (https://www.theregister.com/2021/08/18/poly_network_job/) Postman's Series D Funding and the API-First World (https://blog.postman.com/postman-announces-series-d/) Would the math work if Databricks were valued at $38B? (https://techcrunch.com/2021/08/18/would-the-math-work-if-databricks-were-valued-at-38b/) Debian 11 formally debuts and hits the Bullseye (https://www.theregister.com/2021/08/16/debian_11_bullseye_released/) This is why Valve is switching from Debian to Arch for Steam Deck's Linux OS (https://www.pcgamer.com/this-is-why-valve-is-switching-from-debian-to-arch-for-steam-decks-linux-os/) Nonsense The Most Dangerous Writing App (https://www.squibler.io/dangerous-writing-prompt-app) Suicide Linux (https://qntm.org/suicide) Austin expected to become least-affordable metro for homebuyers outside of California (https://www.kvue.com/article/money/economy/boomtown-2040/austin-expected-to-become-least-affordable-metro-for-homebuyers-outside-of-california/269-6bbed38e-ce06-453e-a659-aece44c6c111) These People Who Work From Home Have a Secret: They Have Two Jobs (https://www.wsj.com/articles/these-people-who-work-from-home-have-a-secret-they-have-two-jobs-11628866529) How QR codes are made (https://twitter.com/Nick_Craver/status/1425606620265000965) Atlas | Leaps, Bounds, and Backflips (https://blog.bostondynamics.com/atlas-leaps-bounds-and-backflips) Every hotdog eaten shortens life by 36 minutes (https://news.yahoo.com/every-hot-dog-eaten-shortens-142355450.html) Progress Report: August 2021 (https://asahilinux.org/2021/08/progress-report-august-2021/) PINE64 presents PineNote, its new tablet in ebook format with electronic ink (https://linuxstoney.com/pine64-presents-pinenote/) EC2 offers 400 Instance Types (https://twitter.com/furrier/status/1426323051168165891?s=20) Amazon EC2 M6i Instances Powered by the Latest-Generation Intel Xeon Scalable Processors (https://aws.amazon.com/blogs/aws/new-amazon-ec2-m6i-instances-powered-by-the-latest-generation-intel-xeon-scalable-processors/) Sponsors strongDM — Manage and audit remote access to infrastructure. Start your free 14-day trial today at strongdm.com/SDT (http://strongdm.com/SDT) CBT Nuggets — Training available for IT Pros anytime, anywhere. Start your 7-day Free Trial today at cbtnuggets.com/sdt (https://cbtnuggets.com/sdt) Clubhouse.io — is project management built specifically for software teams. Sign up to day at www.clubhouse.io/sdt (https://clubhouse.io/sdt) Conferences SpringOne (https://springone.io), Sep 1-2 DevOps World by CloudBees September 28-30 (https://www.devopsworld.com) DevOps Loop | October 4, 2021 (https://devopsloop.io/?utm_campaign=Global_P6_TS_Q322_Event_DevOpsLoop_at_VMworld&utm_source=twitter&utm_medium=social) - see Coté's promo video (https://twitter.com/cote/status/1425460843014131716). THAT Conference comes to Texas January 17-20, 2022 (https://that.us/activities/call-for-counselors/tx/2022) SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Brandon built the Quick Concall iPhone App (https://itunes.apple.com/us/app/quick-concall/id1399948033?mt=8) and he wants you to buy it for $0.99. Use the code SDT to get $20 off Coté's book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: The White Lotus (https://www.hbo.com/the-white-lotus?camp=GOOGLE%7CHTS_SEM%7CPID_p64640553468&keyword=whats+the+white+lotus+about&utm_id=sa%7C71700000085024446%7C58700007207672331%7Cp64640553468&utm_content=tun&gclid=CjwKCAjwmeiIBhA6EiwA-uaeFZn4B3y39e_zSPMRqpQRLRlpbZcqjCPZ2XXT4RyS11xRWmAFvRv86BoCrUEQAvD_BwE&gclsrc=aw.ds) on HBO (https://www.hbo.com/the-white-lotus?camp=GOOGLE%7CHTS_SEM%7CPID_p64640553468&keyword=whats+the+white+lotus+about&utm_id=sa%7C71700000085024446%7C58700007207672331%7Cp64640553468&utm_content=tun&gclid=CjwKCAjwmeiIBhA6EiwA-uaeFZn4B3y39e_zSPMRqpQRLRlpbZcqjCPZ2XXT4RyS11xRWmAFvRv86BoCrUEQAvD_BwE&gclsrc=aw.ds) Matt: Cloud Native AF #2: James Urquhart (https://www.cloudnativeaf.com/2) Mitani Chicken Salt (https://www.mitani.com.au/) Coté: Sharp R20DS microwave (https://www.coolblue.nl/en/product/746608/sharp-r20ds.html). Also, see product descriptions about defrosting stew and other “small meals” for rival microwaves (https://twitter.com/cote/status/1423964819787485184). Photo Credit (https://unsplash.com/photos/vKyp17kj31w) Photo Credit (https://unsplash.com/photos/exf4mcFw4zg)

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

James Urquhart joins the DevOps lunch for an impromptu discussion about the importance of Flow Architecture. You will learn a lot about how flow architecture work and why they are important to infrastructure and application design. This is a great follow-up to our 1x1 interview with him on an earlier episode.

In this episode, we host James Urquhart. James is challenged with the heuristic “Use of standard interfaces and protocols for event-driven integration”, based on his recent work. We discuss the changes in the behaviour of teams creating software when they embrace an event-driven integration, together with leveraging engineering practices like continuous delivery. James also shares his experiences with value streams and the impacts on software architecture. By using event-driven integration and flow architectures to unlock the value within organisations and also between organisations. He predicts that the next decade will be very dynamic in this space, and technology and cost of ownership can be potential roadblocks. James recommends: Scale: The Universal Laws of Life, Growth, and Death in Organisms, Cities, and  Companies from Geoffrey West Open resources as Kafka, Apache Flink and Swin.AI Flow Architectures from James Urquhart Wardley Maps Promise Theory James Urquhart is a Strategic Executive Advisor for VMware Tanzu customers. James brings almost 30 years of experience in distributed applications development, deployment, and operations, focusing on software as a complex adaptive system, cloud-native applications and platforms, and automation. Prior to joining VMware, via Pivotal, James ran product and engineering teams for AWS, SOASTA, and Dell (via Enstratius). James has also written and spoken extensively about software agility and the business opportunities it affords. James was named one of the ten most influential people in cloud computing by both the MIT Technology Review and the Huffington Post and is a former contributing author to GigaOm and CNET. He recently completed a book on event-driven integration for O'Reilly Publishing titled "Flow Architectures: The Future of Event-Driven Integration". James graduated from Macalester College with a Bachelor of Arts in Mathematics and Physics.

This week Nick is joined by James Urquhart where they discuss an upcoming pitch to a big client, diving into the strategy, sharing what they will do on their side to improve their clients performance and results.

James Urquhart is the global field CTO at VMware. He brings more than 25 years of tech experience to this position, having worked as the global field CTO at Pivotal Software, the general manager of learning services at AWS, SVP of performance analytics at SOASTA, and director of product, cloud management at Dell, among other positions. Join Corey and James as they talk about Tanzu and how it is not a vertically integrated T-shirt brand; what James predicts the world will look like in five or 10 years; James’ new book, Flow Architectures: The Future of Streaming and Event-Driven Integration, and the role streaming data will play in the future; how data runs through our economy like water runs downhill through a sand dune; the important role one’s attention span plays in writing a book; what it was like for James to write the book and why he did it; how nobody really predicted how hard it would be for Google and Microsoft to catch up to AWS in the cloud space; and more.

This week we are joined by James Urquhart, co-founder and Managing Director of Lets Run Social, who shares his thoughts on utilising click to call ads for local businesses.

Author of "Flow Architectures: The Future of Streaming and Event-Driven Integration" joins us for a round on Cocktails and gives his thoughts on the future of enterprise integration with Flow and discusses the concepts and technologies behind it.

In this episode of DevOps Radio, VMware's James Urquhart joins host Brian Dawson to discuss his new book on event-driven integration.

James Urquhart (@jamesurquhart, Global Field CTO @VMware, O’Reilly Author) talks about event-driven application architectures, how it's changing real-time business models, and technology stack driven the evolution. SHOW: 483SHOW SPONSOR LINKS:BMC Wants to Know if your business is on its A-GameBMC Autonomous Digital EnterpriseDatadog Security Monitoring Homepage - Modern Monitoring and AnalyticsTry Datadog yourself by starting a free, 14-day trial today. Listeners of this podcast will also receive a free Datadog T-shirt.Okta - You should not be building your own AuthLearn how Okta helped Cengage improve student success rates during COVID.CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW NOTES:Flow Architectures - The Future of Event Streaming & Event-Driven IntegrationThe Cloudcast Eps.43 - James UrquhartThe Cloudcast Eps.344 - Bringing AI to the Edge (Swim.ai)The Cloudcast Eps.334 - The Future of Edge Computing (Derek Collison, Synadia)Topic 1 - Welcome back to the show. We’ve known you for quite a while, going back to working together on very early Cloud stuff. You’ve always enjoyed being focused on complex, distributed systems. Tell us what you’re focused on these days. Topic 2 - Let’s talk about this concept of “event-driven” and flow. Where did it come from, what does it do, why is it valuable to application designers? Topic 2a - What is a “flow” and how is it related to event-driven?Topic 3 - Events are data. We’ve had relational databases for data, and then we had NoSQL or eventually-consistent databases for data. Are events a new type of data, or a new way to deal with data in a different context? (channels, replays, etc.)Topic 4 - Can we talk through an example of an event-driven application, or an event-driven integration between multiple organizations? How is it new/different? What unique capabilities does it bring now? (Kafka, IoT, API Gateways, etc.)Topic 5 - Cloud made IT self-service. Serverless made Ops become on-demand. If I’m a business leader, what does event-driven give us? Topic 6 - Where are we in the maturity of event-driven architectures? What might be some of the next stages coming in 2021 or 2022? FEEDBACK?Email: show at thecloudcast dot netTwitter: @thecloudcastnet

This week we have a special episode for you guys. We speak in depth with James Urquhart (digital director and co-founder) about setting up Lets Run Social and starting a Facebook and Instagram Marketing Ads agency from scratch. Essentially we use data and conversions and reverse engineer what a clients goal is to get the best out of their marketing. Listen in each week for tips, techniques and tricks to help your marketing.

In the final Authors’ Matters episode of 2020, Paul Farrelly, Advocacy consultant at ALCS, talks to James Urquhart, Senior Manager for Libraries and Literature at the Arts Council England (ACE). They discuss the ways in which ACE has supported writers across the UK during the pandemic, as well as details of how to apply for the current programmes they have available for creators.We take a trip down memory lane with Tony Bradman, ALCS Chair, as he looks back at his current tenure, including ALCS milestones and how the organisation has reacted to the pandemic.Plus, Alice Donovan, Communications Executive at ALCS, gives members a heads up on upcoming deadlines and an exciting announcement about the Annual ALCS Awards.

In today's Modern Digital Enterprise, the digital transformation podcast from Anexinet, Steve and Glenn discuss how the concepts of "flow" and "path to production" represent the future of event-driven systems with VMware CTO, James Urquhart. This episode also answers the following questions: How do backyard chickens represent an event-driven system? Why is the evolution from request-response interfaces to event-driven interfaces so valuable? What does James mean by “path to production”? How does path to production minimize friction for developers and create a better environment for building and improving code? What's the best way to secure buy-in for the cultural change required to adopt this approach? Beyond CI/CD, what other activities impact the developer path to production? What is the role of containers in improving path to production? What is the role of serverless in improving path to production? How should leaders organize IT for modern software development and efficient path to production? What is “flow” (a.k.a., the "world wide flow") and how will it change the way we use software? What would incentivize an organization to use stream processing? What are the infrastructural hurdles to adopting this approach? What architectural decisions should you be making to prepare for flow technologies? What are the most powerful uses of streams? How do streams increase organizational efficiencies and improve your customer experience? How can organizations benefit from sharing flow streams? What are the ways event-based integration might scale over time?

There is a need to educate technology leaders across the Department of Defense and national security community with the frameworks and strategies to run digital transformation efforts. This episode explores Wardley mapping: empowering leaders to understand the structure and ecosystem around a technology or service by mapping its components on dimensions like technology maturity and user value. In a defense and national security context, this allows leaders to better align their solution development trajectory and strategy with emerging market trends and user needs to optimize product-mission fit. The insights from this event are designed to help defense leaders to deconstruct their technology and innovation development efforts like business cases, ensuring our energy and talent gets invested on the right problems. James Urquhart is a proven technology executive, and a key influencer in the use of distributed systems technologies in the enterprise setting. Focusing on distributed systems development and operations, James has a background that includes both field and product leadership, with both start-ups and large corporations. James is perhaps best known for his influence on the emerging cloud computing market over the last decade. Named one of the ten most influential people in cloud computing by the MIT Technology Review, The Next Web and the Huffington Post, and a former contributing author to GigaOm and CNET, James frequent writes and speaks to these disruptive technologies and the business opportunities they afford. James played a key role in building the product, online service and related messaging for Enstratius, a start-up focused on multi-cloud management for the enterprise. Purchased by Dell in 2013 at a significant multiple, Enstratius was considered one of two leading first-generation multi-cloud VM management tools. James's latest role as SVP of Product Management at leading Digital Performance Management platform vendor, SOASTA, immersed him in the world of data science, which has led to one of his current interests, distributed real-time data analytics and anomaly detection. James has even started a Medium publication to explore this subject at https://medium.com/digital-anatomy. James has also played key strategic roles at Cisco and Dell, advising senior management on everything from product strategy to messaging.

Is Edge a natural progression of compute? How do bottlenecks play into Edge? Why is a tree like a traffic system is like our circulatory system? L8ist Sh9ny podcast episode: https://soundcloud.com/user-410091210/james-urquhart-on-edge-computing-and-flow-evolution James Urquhart blog post: https://www.infoq.com/articles/edge-flow-evolution/ Geoffrey West's book: https://www.amazon.com/Scale-Universal-Innovation-Sustainability-Organisms/dp/1594205582

Joining us this week is James Urquhart, Executive Technical Advisor, VMware James offers additional thoughts to his recent post "Edge Computing and Flow Evolution" on InfoQ. (https://www.infoq.com/articles/edge-flow-evolution/) James book can be pre-ordered at https://www.amazon.com/Flow-Architectures-Streaming-Event-Driven-Integration/dp/1492075892

Learn more:VMware TanzuAn introduction to event-driven architecture and Apache KafkaLearn the 'whats' and 'whys' of Apache Kafka in 15 minutesThe Main Event: How Event-Driven Architecture Helps Discover Move Faster and Win More Card CustomersScale and velocity are driving the next generation of DevOps'Objection inversion': Why platform ops can create new champions in ITFollow everyone on Twitter:IntersectJames UrquhartDerrick HarrisVMware Tanzu

Learn more:VMware TanzuAn introduction to event-driven architecture and Apache KafkaLearn the 'whats' and 'whys' of Apache Kafka in 15 minutesThe Main Event: How Event-Driven Architecture Helps Discover Move Faster and Win More Card CustomersScale and velocity are driving the next generation of DevOps'Objection inversion': Why platform ops can create new champions in ITFollow everyone on Twitter:IntersectJames UrquhartDerrick HarrisVMware Tanzu

Learn more:VMware TanzuAn introduction to event-driven architecture and Apache KafkaLearn the 'whats' and 'whys' of Apache Kafka in 15 minutesThe Main Event: How Event-Driven Architecture Helps Discover Move Faster and Win More Card CustomersScale and velocity are driving the next generation of DevOps'Objection inversion': Why platform ops can create new champions in ITFollow everyone on Twitter:IntersectJames UrquhartDerrick HarrisVMware Tanzu

Applications, development, deployment, and theory are all key pieces behind customer experience, event streaming, and improving systems and integration. James Urquhart (Global Field CTO, VMware) is writing a book combining Wardley Mapping and Promise Theory to evaluate the future of event streaming and how it will become a more economic choice for users. James argues that reducing the cost of integration does not deter people from buying but instead encourages creativity to find more uses for integration. He stresses the importance of user experience and how knowing what users are going through helps mend products and workflows, which improves systems that bring economic value. The two then go into explanations around the Promise Theory, Jevons Paradox, and Geoffrey Moore's Core vs. Context Theory. EPISODE LINKSPromise Theory: Principles and ApplicationsJoin the Confluent Community SlackLearn about Apache Kafka® at Confluent Developer

In this episode, we talk with James Urquhart on the operational complexity associated with distributed systems with Edge Computing and IoT, the changing app development paradigm and flow architectures, developer trends in real-time streaming applications and more. We end the podcast with James talking about his upcoming book. Don't miss this episode.

Sound Wave Podcast 12 December 2019 hosted by Leonardo La Mark ••• Tracklist: 01. Babert - Time After Time [Soulfuric Deep] 02. DISCO TOWN, Angelo Ferreri, Moon Rocket, LauMii - Running Out (Live Mix) [Moon Rocket] 03. JedX - When You Want Me [Star Funk] 04. James Urquhart, Samo - Wherever You Are (Samo Remix) [Power & Purpose] 05. Husky - Promise Me [Monoside] 06. Piem - Little Boy Blue (Husky's BHM Mix) [Motive] 07. Kings Of Tomorrow feat. April Morgan - It's Only You (Sandy Rivera Remix) [Deepvisionz] 08. Babert - I Can't Be You [Mood Funk] 09. Sammy Deuce - Funk Me Sideways [Good For You] 10. Soul Shadow - Times Have Changed (Risk Asessment Remix) [No Fuss] 11. Jarred Gallo - Do The Dance [Cruise Music] 12. Hiva - In Your Mind [84Bit Music] 13. Squirt D - And I Like It [Mood Funk] 14. Music P, Marque Aurel - F.E.E.L. (Angelo Ferreri Remix) [Monoside] ••• Sound Wave instagram.com/soundwave_48 facebook.com/soundwavepodcast #soundwave48 #soundwavepodcast

Sound Wave Podcast 12 December 2019 hosted by Leonardo La Mark ••• Tracklist: 01. Babert - Time After Time [Soulfuric Deep] 02. DISCO TOWN, Angelo Ferreri, Moon Rocket, LauMii - Running Out (Live Mix) [Moon Rocket] 03. JedX - When You Want Me [Star Funk] 04. James Urquhart, Samo - Wherever You Are (Samo Remix) [Power & Purpose] 05. Husky - Promise Me [Monoside] 06. Piem - Little Boy Blue (Husky's BHM Mix) [Motive] 07. Kings Of Tomorrow feat. April Morgan - It's Only You (Sandy Rivera Remix) [Deepvisionz] 08. Babert - I Can't Be You [Mood Funk] 09. Sammy Deuce - Funk Me Sideways [Good For You] 10. Soul Shadow - Times Have Changed (Risk Asessment Remix) [No Fuss] 11. Jarred Gallo - Do The Dance [Cruise Music] 12. Hiva - In Your Mind [84Bit Music] 13. Squirt D - And I Like It [Mood Funk] 14. Music P, Marque Aurel - F.E.E.L. (Angelo Ferreri Remix) [Monoside] ••• Sound Wave instagram.com/soundwave_48 facebook.com/soundwavepodcast #soundwave48 #soundwavepodcast

Sound Wave Podcast 12 December 2019 hosted by Leonardo La Mark ••• Tracklist: 01. Babert - Time After Time [Soulfuric Deep] 02. DISCO TOWN, Angelo Ferreri, Moon Rocket, LauMii - Running Out (Live Mix) [Moon Rocket] 03. JedX - When You Want Me [Star Funk] 04. James Urquhart, Samo - Wherever You Are (Samo Remix) [Power & Purpose] 05. Husky - Promise Me [Monoside] 06. Piem - Little Boy Blue (Husky's BHM Mix) [Motive] 07. Kings Of Tomorrow feat. April Morgan - It's Only You (Sandy Rivera Remix) [Deepvisionz] 08. Babert - I Can't Be You [Mood Funk] 09. Sammy Deuce - Funk Me Sideways [Good For You] 10. Soul Shadow - Times Have Changed (Risk Asessment Remix) [No Fuss] 11. Jarred Gallo - Do The Dance [Cruise Music] 12. Hiva - In Your Mind [84Bit Music] 13. Squirt D - And I Like It [Mood Funk] 14. Music P, Marque Aurel - F.E.E.L. (Angelo Ferreri Remix) [Monoside] ••• Sound Wave instagram.com/soundwave_48 facebook.com/soundwavepodcast #soundwave48 #soundwavepodcast

We've touched on the mindset shift of treating your internal application platform as a product (or offering) for your developers. In this episode, Dormain talks to James Urquhart about defining the go-to-market strategy of that offering. Have you built the right service? What does my MVP look like? How do we educate, broadcast, and onboard developers? This conversation builds upon previous episodes on the topic of "platform as product." We refer to the episode with Paula Kennedy, as well as Dormain's post on "How to Get Developers to Start Using Your Application Platform." https://content.pivotal.io/podcasts/for-platform-teams-the-developers-are-the-customer-with-pivotals-paula-kennedy https://content.pivotal.io/blog/how-to-get-developers-to-start-using-your-application-platform

We've touched on the mindset shift of treating your internal application platform as a product (or offering) for your developers. In this episode, Dormain talks to James Urquhart about defining the go-to-market strategy of that offering. Have you built the right service? What does my MVP look like? How do we educate, broadcast, and onboard developers? This conversation builds upon previous episodes on the topic of "platform as product." We refer to the episode with Paula Kennedy, as well as Dormain's post on "How to Get Developers to Start Using Your Application Platform." https://content.pivotal.io/podcasts/for-platform-teams-the-developers-are-the-customer-with-pivotals-paula-kennedy https://content.pivotal.io/blog/how-to-get-developers-to-start-using-your-application-platform

We've touched on the mindset shift of treating your internal application platform as a product (or offering) for your developers. In this episode, Dormain talks to James Urquhart about defining the go-to-market strategy of that offering. Have you built the right service? What does my MVP look like? How do we educate, broadcast, and onboard developers? This conversation builds upon previous episodes on the topic of "platform as product." We refer to the episode with Paula Kennedy, as well as Dormain's post on "How to Get Developers to Start Using Your Application Platform." https://content.pivotal.io/podcasts/for-platform-teams-the-developers-are-the-customer-with-pivotals-paula-kennedy https://content.pivotal.io/blog/how-to-get-developers-to-start-using-your-application-platform

We've touched on the mindset shift of treating your internal application platform as a product (or offering) for your developers. In this episode, Dormain talks to James Urquhart about defining the go-to-market strategy of that offering. Have you built the right service? What does my MVP look like? How do we educate, broadcast, and onboard developers? This conversation builds upon previous episodes on the topic of "platform as product." We refer to the episode with Paula Kennedy, as well as Dormain's post on "How to Get Developers to Start Using Your Application Platform." https://content.pivotal.io/podcasts/for-platform-teams-the-developers-are-the-customer-with-pivotals-paula-kennedy https://content.pivotal.io/blog/how-to-get-developers-to-start-using-your-application-platform

We've touched on the mindset shift of treating your internal application platform as a product (or offering) for your developers. In this episode, Dormain talks to James Urquhart about defining the go-to-market strategy of that offering. Have you built the right service? What does my MVP look like? How do we educate, broadcast, and onboard developers? This conversation builds upon previous episodes on the topic of "platform as product." We refer to the episode with Paula Kennedy, as well as Dormain's post on "How to Get Developers to Start Using Your Application Platform." https://content.pivotal.io/podcasts/for-platform-teams-the-developers-are-the-customer-with-pivotals-paula-kennedy https://content.pivotal.io/blog/how-to-get-developers-to-start-using-your-application-platform

This week, we talk with James Urquhart who joined Pivotal recently in the CTO group. We talk about some architectural ideas for converting the enterprise over to an event-driven flow, discuss the reasons for doing multi-cloud, and also what kinds of conversations "executives" find helpful. Coté does a great job mangling Pivotal product names. Also, hot takes on "on-premises" vs. "on-premise."

This week, we talk with James Urquhart who joined Pivotal recently in the CTO group. We talk about some architectural ideas for converting the enterprise over to an event-driven flow, discuss the reasons for doing multi-cloud, and also what kinds of conversations "executives" find helpful. Coté does a great job mangling Pivotal product names. Also, hot takes on "on-premises" vs. "on-premise."

This week, we talk with James Urquhart who joined Pivotal recently in the CTO group. We talk about some architectural ideas for converting the enterprise over to an event-driven flow, discuss the reasons for doing multi-cloud, and also what kinds of conversations "executives" find helpful. Coté does a great job mangling Pivotal product names. Also, hot takes on "on-premises" vs. "on-premise."

This week, we talk with James Urquhart who joined Pivotal recently in the CTO group. We talk about some architectural ideas for converting the enterprise over to an event-driven flow, discuss the reasons for doing multi-cloud, and also what kinds of conversations "executives" find helpful. Coté does a great job mangling Pivotal product names. Also, hot takes on "on-premises" vs. "on-premise."

This week, we talk with James Urquhart who joined Pivotal recently in the CTO group. We talk about some architectural ideas for converting the enterprise over to an event-driven flow, discuss the reasons for doing multi-cloud, and also what kinds of conversations "executives" find helpful. Coté does a great job mangling Pivotal product names. Also, hot takes on "on-premises" vs. "on-premise."

'Let There Be House' is the bi weekly radio show presented by Glen Horsborough. Glen regularly plays around the Uk, Europe & Worldwide.Each week he delves and digs out the latest upfront tracks that are doing the business on dancefloors globally!Tracklist 1. Solution - Feels So Right (Victor Simonelli Remix)2. Dirty Secretz & Glen Horsborough feat Tess Leah - Scream & Shout (Fix's Disco Divide Remix)3 . Funkatomic - You'd Better Believe4. Jay Vegas - I Need U (Re-Tide Dub)5. Street Players - Make It Through6. Sebb Junior - The Reason (Club Mix)7. Mark Funk & Danny Cruz - Superlovin (Original Mix)8. Angelo Ferreri, Moon Rocket, Bel-Ami - From Disco To Disco9. Groove Committee, K69, Dancing Divaz - Dirty Games10. SolarTrak & DJ Mikey feat Laura Louise - Right Now (Original Mix)11. Alexis Raphael - You Know That I Love You12. James Urquhart feat Everett - This Is My House (Stephen Nicholls Ibiza Garden Remix)13. David Penn - Losing You14. Andy Lakey - Shake It DownFollow on Twitterwww.twitter.com/LTBH_www.twitter.com/GlenHorsboroughLike on Facebookwww.facebook.com/LTBHMusic www.facebook.com/GlenHorsboroughwww.ltbh.co.uk See acast.com/privacy for privacy and opt-out information.

'Let There Be House' is the bi weekly radio show presented by Glen Horsborough. Glen regularly plays around the Uk, Europe & Worldwide.Each week he delves and digs out the latest upfront tracks that are doing the business on dancefloors globally!Tracklist 1. DJ Rae - Crazy Trippin (Part II) (Sandy Rivera & DJ Rae Club Mix)2. Dvit Bousa - TeKey (Blaise Remix)3 . Husky Feat Letta - Want U Back (Scott Diaz Grand Plans Dub)4. PEZNT - Toxic Love (Extended Mix)5. James Urquhart feat Everett - This Is My House (Stephen Nicholls Ibiza Garden Remix)6. Funky Truckerz - Good Things (Vanilla Ace Remix)7. Purple Disco Machine - Dished Male Stripper (Extended Mix)8. Weiss - Feel My Needs (Original Mix)9. Gary Tuohy - Guys From The Block (SAMO Remix)10. Jacques Chirac - Gotta Love 11. Dirty Secretz & Glen Horsborough feat Tess Leah - Scream & Shout (Original Mix)12. Dennis Quin, Shermanology - Move out of My Way (Original Mix) Follow on Twitterwww.twitter.com/LTBH_www.twitter.com/GlenHorsboroughLike on Facebookwww.facebook.com/LTBHMusic www.facebook.com/GlenHorsboroughwww.ltbh.co.uk See acast.com/privacy for privacy and opt-out information.

'Let There Be House' is the weekly radio show presented by Glen Horsborough. Glen regularly plays around the Uk, Europe & Worldwide.Each week he delves and digs out the latest upfront tracks that are doing the business on dancefloors globally!Tracklist 1. Shakedown - At Night (Purple Disco Machine Extended Remix)2. Throttle - All In (VIP Mix)3 . CID x Anabel Englund - Use Me Up (Extended Mix)4. Rogero Lunez & AM2PM - Give It All (Original Mix)5. Todd Terry ft. Ami Carmine - Love Is Gone (InHouse Mix)6. James Urquhart feat Everett - This Is My House (Original Mix)7. Mike Mago - Wasted So Much Of My Life (Extended Mix)8. Spendogg - Feel The Rush9. Harmo & Vibes - Be Free (Extended Mix)10. Inner City feat Steffanie Christian - Heavy (C2Back2ThaBasicsEDIT)11. Felon, Hayley May - Till The Morning (Extended Club Mix)12. Dvit Bousa - TeKey (Original Mix)13. Soulsearcher - Can't Get Enough! (Angelo Ferreri Extended Vocal Remix)14. Element 125 - The Deep (Club Mix) Follow on Twitterwww.twitter.com/LTBH_www.twitter.com/GlenHorsboroughLike on Facebookwww.facebook.com/LTBHMusic www.facebook.com/GlenHorsboroughwww.ltbh.co.uk See acast.com/privacy for privacy and opt-out information.

In this episode, we talk to James Urquhart, Dell Technologies (at the time of recording and currently at AWS) on his idea of Services as a platform. James has been talking about this idea for quite some time and this discussion will help enterprise decision makers understand the world of cloud services --- Support this podcast: https://anchor.fm/modernenterprise/support

:):)Thank you for supporting the art and artist that support this project (:(: 01.Eventual Groove & Papa Tony- I Will Shine Above (Original Mix) King Street 02.David Federmann ft Maeva- Cherry Tree (Original Mix) Foliage 03.DJ Leandro ft Natalie Poulli- Wicked Game (Original Mix) Nite Grooves 04.James Urquhart ft Amy Pearson- Touch (orig) Deeptown Music 05.The Layabouts & Imaani- Stay (The Layabouts Vocal Mix) Foliage 06.Luca Lala ft Angel-A- Changed (Original Vocal Mix) 2Elle Records 07.Chanelle- Separate Lives (Original Mix) Phunky Rabbit Records 08.The Lounge Lizards ft Jill Rock Jones- Rah Rah (Main Mix) Makin' Moves 09.Klevakeys feat Liz Jai- Lifetime (Original Mix) House Keys Records 10.DJ Ceez ft Niki Gee & Mara Marie- Be Her (Original Vocal) New Generation Records 11.Sir Mos, Maronza ft Lady Knight- Where Do I Stand (De Mogul SA Remix) Deep Fusion Records 12.Vangela Crowe ft Reggie Steele- Where is the Love (Corey Holmes Vocal Mix) New Generation Records 13.Christian B & Lavvy Levan- Mystery (Reason 4) (Five Resaons EP) Friday Fox Recordings 14.Lavvy Levan interview 15.Christian B & Lavvy Levan- Your Light (Reason 2) (Five Resaons EP) Friday Fox Recordings 16.Rampus ft JM Browne- Losing Time (Original Mix) Phunky Rabbit Records 17.Federico d'Alessio & Giulio Bonaccio ft Aaron K Gray- Reason (Federico d'alessio Vocal Mix) King Street

Brian talks with James Urquhart (@jamesurquhart, Senior Vice President of Performance Analytics @SOASTA) about the evolution of the digital economy, performance testing applications, understanding business impact of performance, and how companies are evolving in this new economy. Show Notes: Krispy Kreme Challenge Donations - https://www.crowdrise.com/thecloudcastkrispykr/fundraiser/briangracely
 SOASTA Homepage - http://www.soasta.com/ Topic 1 - Welcome back to the show, it’s been a little while. Tell us what you’re doing these days. Topic 2 - We now live in a (mostly) digital world, where applications are the face or experience of many businesses. Where does SOASTA fit into this new world? Topic 3 - Last summer, I was at VelocityConf and saw this massive display (for SOASTA) and it looked like the control center in movies for a Space Shuttle launch. Turns out it was the launch of the mPulse platform. It was very business centric, which was unique and unusual for a highly technical conference. Topic 4 - Lots of talk about microservices and distributed applications. Also, lots of talk about how this becomes orders of magnitude more complex. How are application teams explaining this to their businesses, and how does SOASTA help them manage this? Topic 5 - Mobile devices are everything these days, and they have very different usage/access patterns. From a Performance/Analysis perspective, what are some of the most important things companies need to think about? Topic 6 - We’re starting to see more and more traditionally “non-technical” companies that will have massive application challenges in the future (e.g. connected vehicles). What’s your advice to them beyond just “be sure you’re testing early and often”?

Manageability has been called the toughest problem to solve in the data center. What happens when you have to extend that to also managing your cloud? James Urquhart, VP of Product Strategy at enStratus, stops by to discuss the problem of managing a massively interconnected system when different agents have their own rules for interacting with a system and apps can have effects on other apps multiple steps down the chain. For more information, James blogs at: http://gigaom.com/author/jurquhart/.

Brian talks with James Urquhart (VP Product Strategy, enStratus) about interconnected systems (Clouds, APIs), complex systems, and how transparency and governance are critical to be able to design, build and operate today’s Cloud Computing environments.

Brian talks with Rick Clark and James Urquhart of Cisco about the evolution of networking in OpenStack and the multiple ways Cisco is involved in the project.