Podcasts about twelve factor app

Микросервисы, контейнеры, SAAS-ы.... вот деды кидали exe файлик по FTP и норм все было... ведь было же?Спасибо всем, кто нас слушает. Ждем Ваши комментарии.Бесплатный открытый курс "Rust для DotNet разработчиков": https://www.youtube.com/playlist?list=PLbxr_aGL4q3S2iE00WFPNTzKAARURZW1ZShownotes: 00:00:00 Вступление00:06:00 Зачем оно надо?00:07:30 CV driven development00:10:00 Преждевременная оптимизация00:15:40 А как же IIS?00:18:00 Что делать если урвал сервак?00:22:00 Кубер это дорого?00:27:00 Надо ли "как у больших"?00:34:00 А как же Serverless?00:38:50 Сколько стоит "сразу нормально"?00:49:00 Что кубер дает и не дает?00:57:00 А что для программиста?Ссылки:- https://github.com/dotnet/eShop : Референсный проект интернет магазина от майков- https://12factor.net/ : The Twelve-Factor AppВидео: https://youtube.com/live/t2UMkLSBOUQ Слушайте все выпуски: https://dotnetmore.mave.digitalYouTube: https://www.youtube.com/playlist?list=PLbxr_aGL4q3R6kfpa7Q8biS11T56cNMf5Twitch: https://www.twitch.tv/dotnetmoreОбсуждайте:- Telegram: https://t.me/dotnetmore_chatСледите за новостями:– Twitter: https://twitter.com/dotnetmore– Telegram channel: https://t.me/dotnetmoreCopyright: https://creativecommons.org/licenses/by-sa/4.0/

Heroku is a cloud platform-as-a-service that enables developers to build, deploy, and manage applications. It was founded in 2007 and was acquired by Salesforce in 2010. The platform supports multiple programming languages, including Ruby, Python, Node.js, and Java, and has features such as automated scaling, database monitoring tools, and a streamlined deployment workflow. Vish Abrams The post Heroku and the Twelve-Factor App with Vish Abrams appeared first on Software Engineering Daily.

Heroku is a cloud platform-as-a-service that enables developers to build, deploy, and manage applications. It was founded in 2007 and was acquired by Salesforce in 2010. The platform supports multiple programming languages, including Ruby, Python, Node.js, and Java, and has features such as automated scaling, database monitoring tools, and a streamlined deployment workflow. Vish Abrams The post Heroku and the Twelve-Factor App with Vish Abrams appeared first on Software Engineering Daily.

Heroku has open-sourced its Twelve-Factor App methodology, initially created in 2011 to help developers build portable, resilient cloud applications. Heroku CTO Gail Frederick announced this shift at KubeCon + CloudNativeCon North America, explaining the move aims to involve the community in modernizing the framework. While the methodology inspired a generation of cloud developers, certain factors are now outdated, such as the focus on logs as event streams. Frederick highlighted the need for updates to address current practices like telemetry and metrics visualization, reflecting the rise of OpenTelemetry.The updated Twelve-Factor methodology will expand to accommodate modern cloud-native realities, such as deploying interconnected systems of apps with diverse backing services. Planned enhancements include supporting documents, reference architectures, and code examples illustrating the principles in action. Success will be measured by its applicability to use cases involving edge computing, IoT, serverless, and distributed systems. Heroku views this open-source effort as an opportunity to redefine best practices for the next era of cloud development.Learn more from The New Stack about Heroku: How Heroku Is Positioned To Help Ops Engineers in the GenAI EraThe Data Stack Journey: Lessons from Architecting Stacks at Heroku and MattermostJoin our community of newsletter subscribers to stay on top of the news and at the top of your game. 

In this episode of Book Overflow, Carter and Nathan discuss The Twelve-Factor App, a free-to-read manifesto on the fundamentals of building a modern web application. Join them as they discuss scalability, statelessness, and the proper way to handle logs! -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- The Twelve-Factor App https://12factor.net/ Web Scalability for Startup Engineers by Artur Ejsmont https://amzn.to/3AWkfKp (paid link) ---------------- Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5L Apple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325 X: https://x.com/bookoverflowpod Carter on X: https://x.com/cartermorgan Nathan's Functionally Imperative: www.functionallyimperative.com ---------------- Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week! The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

This is a recap of the top 10 posts on Hacker News on October 12th, 2023.This podcast was generated by wondercraft.ai(00:32): Introduction to Modern StatisticsOriginal post: https://news.ycombinator.com/item?id=37854846&utm_source=wondercraft_ai(02:28): First word discovered in unopened Herculaneum scroll by CS studentOriginal post: https://news.ycombinator.com/item?id=37857417&utm_source=wondercraft_ai(04:13): The midwit homeOriginal post: https://news.ycombinator.com/item?id=37859437&utm_source=wondercraft_ai(05:56): Desmos 3D graphing calculatorOriginal post: https://news.ycombinator.com/item?id=37859085&utm_source=wondercraft_ai(07:51): The Twelve-Factor App (2011)Original post: https://news.ycombinator.com/item?id=37857544&utm_source=wondercraft_ai(09:44): Scrollbars are becoming a problemOriginal post: https://news.ycombinator.com/item?id=37864867&utm_source=wondercraft_ai(11:43): Can't be fucked: Underrated cause of tech debtOriginal post: https://news.ycombinator.com/item?id=37859311&utm_source=wondercraft_ai(13:39): Automakers invented the crime of jaywalking (2015)Original post: https://news.ycombinator.com/item?id=37859905&utm_source=wondercraft_ai(15:11): OpenAI is too cheap to beatOriginal post: https://news.ycombinator.com/item?id=37860819&utm_source=wondercraft_ai(17:04): Email and Git =

Grace Jansen joins us to chat about how bees and biology can help us better understand software development tools & paradigms like Reactive, Kubernetes, and maybe parts of the 15 Factor App methodology (a modernized version of the Twelve-Factor App methodology). Discuss this episode: https://discord.gg/nPa76qF

In part 2 of the Twelve-Factor App, we'll explore the second half of the principles. Be sure to listen to the previous episode as well. We still have only four minutes, so let's go! Read more: https://nurkiewicz.com/76 Get the new episode straight to your mailbox: https://nurkiewicz.com/newsletter

Twelve-Factor App is a set of design guidelines defined by Heroku. These guidelines are best suited for cloud-native, portable and resilient services. In this episode, I'll explain the first seven principles. I have four minutes left, so let's go! Read more: https://nurkiewicz.com/75 Get the new episode straight to your mailbox: https://nurkiewicz.com/newsletter

About PeterPeter's spent more than a decade building scalable and robust systems at startups across adtech and edtech. At Remind, where he's VP of Technology, Peter pushes for building a sustainable tech company with mature software engineering. He lives in Southern California and enjoys spending time at the beach with his family.Links: Redis: https://redis.com/ Remind: https://www.remind.com/ Remind Engineering Blog: https://engineering.remind.com LinkedIn: https://www.linkedin.com/in/hamiltop Email: peterh@remind101.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats V-U-L-T-R.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn and this is a fun episode. It is a promoted episode, which means that our friends at Redis have gone ahead and sponsored this entire episode. I asked them, “Great, who are you going to send me from, generally, your executive suite?” And they said, “Nah. You already know what we're going to say. We want you to talk to one of our customers.” And so here we are. My guest today is Peter Hamilton, VP of Technology at Remind. Peter, thank you for joining me.Peter: Thanks, Corey. Excited to be here.Corey: It's always interesting when I get to talk to people on promoted guest episodes when they're a customer of the sponsor because to be clear, you do not work for Redis. This is one of those stories you enjoy telling, but you don't personally have a stake in whether people love Redis, hate Redis, adopt that or not, which is exactly what I try and do on these shows. There's an authenticity to people who have in-the-trenches experience who aren't themselves trying to sell the thing because that is their entire job in this world.Peter: Yeah. You just presented three or four different opinions and I guarantee we felt all at the different times.Corey: [laugh]. So, let's start at the very beginning. What does Remind do?Peter: So, Remind is a messaging tool for education, largely K through 12. We support about 30 million active users across the country, over 2 million teachers, making sure that every student has, you know, equal opportunities to succeed and that we can facilitate as much learning as possible.Corey: When you say messaging that could mean a bunch of different things to a bunch of different people. Once on a lark, I wound up sitting down—this was years ago, so I'm sure the number is a woeful underestimate now—of how many AWS services I could use to send a message from me to you. And this is without going into the lunacy territory of, “Well, I can tag a thing and then mail it to you like a Snowball Edge or something.” No, this is using them as intended, I think I got 15 or 16 of them. When you say messaging, what does that mean to you?Peter: So, for us, it's about communication to the end-user. We will do everything we can to deliver whatever message a teacher or district administrator has to the user. We go through SMS, text messaging, we go through Apple and Google's push services, we go through email, we go through voice call, really pulling out all the stops we can to make sure that these important messages get out.Corey: And I can only imagine some of the regulatory pressure you almost certainly experience. It feels like it's not quite to HIPAA levels, where ohh, there's a private cause of action if any of this stuff gets out, but people are inherently sensitive about communications involving their children. I always sort of knew this in a general sense, and then I had kids myself, and oh, yeah, suddenly I really care about those sorts of things.Peter: Yeah. One of the big challenges, you can build great systems that do the correct thing, but at the end of the day, we're relying on a teacher choosing the right recipient when they send a message. And so we've had to build a lot of processes and controls in place, so that we can, kind of, satisfy two conflicting needs: One is to provide a clear audit log because that's an important thing for districts to know if something does happen, that we have clear communication; and the other is to also be able to jump in and intervene when something inappropriate or mistaken is sent out to the wrong people.Corey: Remind has always been one of those companies that has a somewhat exalted reputation in the AWS space. You folks have been early adopters of a bunch of different services—which let's be clear, in the responsible way, not the, “Well, they said it on stage; time to go ahead and put everything they just listed into production because we for some Godforsaken reason, view it as a todo list.”—but you've been thoughtful about how you approach things, and you have been around as a company for a while. But you've also been making a significant push toward being cloud-native by certain definitions of that term. So, I know this sounds like a college entrance essay, but what does cloud-native mean to you?Peter: So, one of the big gaps—if you take an application that was written to be deployed in a traditional data center environment and just drop it in the cloud, what you're going to get is a flaky data center.Corey: Well, that's unfair. It's also going to be extremely expensive.Peter: [laugh]. Sorry, an expensive, flaky data set.Corey: There we go. There we go.Peter: What we've really looked at–and a lot of this goes back to our history in the earlier days; we ran a top of Heroku and it was kind of the early days what they call the Twelve-Factor Application—but making aggressive decisions about how you structure your architecture and application so that you fit in with some of the cloud tools that are available and that you fit in, you know, with the operating models that are out there.Corey: When you say an aggressive decision, what sort of thing are you talking about? Because when I think of being aggressive with an approach to things like AWS, it usually involves Twitter, and I'm guessing that is not the direction you intend that to go.Peter: No, I think if you look at Twitter or Netflix or some of these players that, quite frankly, have defined what AWS is to us today through their usage patterns, not quite that.Corey: Oh, I mean using Twitter to yell at them explicitly about things—Peter: Oh.Corey: —because I don't do passive-aggressive; I just do aggressive.Peter: Got it. No, I think in our case, it's been plotting a very narrow path that allows us to avoid some of the bigger pitfalls. We have our sponsor here, Redis. Talk a little bit about our usage of Redis and how that's helped us in some of these cases. One of the pitfalls you'll find with pulling a non-cloud-native application and put it in the cloud is state is hard to manage.If you put state on all your machines and machines go down, networks fail, all those things, you now no longer have access to that state and we start to see a lot of problems. One of the decisions we've made is try to put as much data as we can into data stores like Redis or Postgres or something, in order to decouple our hardware from the state we're trying to manage and provide for users so that we're more resilient to those sorts of failures.Corey: I get the sense from the way that we're having this conversation, when you talk about Redis, you mean actual Redis itself, not ElastiCache for Redis, or as to I'm tending to increasingly think about AWS's services, Amazon Basics for Redis.Peter: Yeah. I mean, Amazon has launched a number of products. They have their ElastiCache, they have their new MemoryDB, there's a lot different ways to use this. We've relied pretty heavily on Redis, previously known as Redis Labs, and their enterprise product in their cloud, in order to take care of our most important data—which we just don't want to manage ourselves—trying to manage that on our own using something like ElastiCache, there's so many pitfalls, so many ways that we can lose that data. This data is important to us. By having it in a trusted place and managed by a great ops team, like they have at Redis, we're able to then lean in on the other aspects of cloud data to really get as much value as we can out of AWS.Corey: I am curious. As I said you've had a reputation as a company for a while in the AWS space of doing an awful lot of really interesting things. I mean, you have a robust GitHub presence, you have a whole bunch of tools that have come out Remind that are great, I've linked to a number of them over the years in the newsletter. You are clearly not afraid, culturally, to get your hands dirty and build things yourself, but you are using Redis Enterprise as opposed to open-source Redis. What drove that decision? I have to assume it's not, “Wait. You mean, I can get it for free as an open-source project? Why didn't someone tell me?” What brought you to that decision?Peter: Yeah, a big part of this is what we could call operating leverage. Building a great set of tools that allow you to get more value out of AWS is a little different story than babysitting servers all day and making sure they stay up. So, if you look through, most of our contributions in open-source space have really been around here's how to expand upon these foundational pieces from AWS; here's how to more efficiently launch a suite of servers into an auto-scaling group; here's, you know, our troposphere and other pieces there. This was all before Amazon CDK product, but really, it was, here's how we can more effectively use CloudFormation to capture our Infrastructure as Code. And so we are not afraid in any way to invest in our tooling and invest in some of those things, but when we look at the trade-off of directly managing stateful services and dealing with all the uncertainty that comes, we feel our time is better spent working on our product and delivering value to our users and relying on partners like Redis in order to provide that stability we need.Corey: You raise a good point. An awful lot of the tools that you've put out there are the best, from my perspective, approach to working with AWS services. And that is a relatively thin layer built on top of them with an eye toward making the user experience more polished, but not being so heavily opinionated that as soon as the service goes in a different direction, the tool becomes completely useless. You just decide to make it a bit easier to wind up working with specific environment variables or profiles, rather than what appears to be the AWS UX approach of, “Oh, now type in your access key, your secret key and your session token, and we've disabled copy and paste. Go, have fun.” You've really done a lot of quality of life improvements, more so than you have this is the entire system of how we do deploys, start to finish. It's opinionated and sort of a, like, a take on what Netflix, did once upon a time, with Asgard. It really feels like it's just the right level of abstraction.Peter: We did a pretty good job. I will say, you know, years later, we felt that we got it wrong a couple times. It's been really interesting to see that, that there are times when we say, “Oh, we could take these three or four services and wrap it up into this new concept of an application.” And over time, we just have to start poking holes in that new layer and we start to see we would have been better served by sticking with as thin a layer as possible that enables us, rather than trying to get these higher-level pieces.Corey: It's remarkably refreshing to hear you say that just because so many people love to tell the story on podcasts, or on conference stages, or whatever format they have of, “This is what we built.” And it is an aspirationally superficial story about this. They don't talk about that, “Well, firstly, without these three wrong paths first.” It's always a, “Oh, yes, obviously, we are smart people and we only make the correct decision.”And I remember in the before times sitting in conference talks, watching people talk about great things they'd done, and I'll turn next to the person next to me and say, “Wow, I wish I could be involved in a project like that.” And they'll say, “Yeah, so do I.” And it turns out they work at the company the speaker is from. Because all of these things tend to be the most positive story. Do you have an example of something that you have done in your production environment that going back, “Yeah, in hindsight, I would have done that completely differently.”Peter: Yeah. So, coming from Heroku moving into AWS, we had a great open-source project called Empire, which kind of bridge that gap between them, but used Amazon's ECS in order to launch applications. It was actually command-line compatible with the Heroku command when it first launched. So, a very big commitment there. And at the time—I mean, this comes back to the point I think you and I were talking about earlier, where architecture, costs, infrastructure, they're all interlinked.And I'm a big fan of Conway's Law, which says that an organization's structure needs to match its architecture. And so six, seven years ago, we're heavy growth-based company and we are interns running around, doing all the things, and we wanted to have really strict guardrails and a narrow set of things that our development team could do. And so we built a pretty constrained: You will launch, you will have one Docker image per ECS service, it can only do these specific things. And this allowed our development team to focus on pretty buttons on the screen and user engagement and experiments and whatnot, but as we've evolved as a company, as we built out a more robust business, we've started to track revenue and costs of goods sold more aggressively, we've seen, there's a lot of inefficient things that come out of it.One particular example was we used PgBouncer for our connection pooling to our Postgres application. In the traditional model, we had an auto-scaling group for a PgBouncer, and then our auto-scaling groups for the other applications would connect to it. And we saw additional latency, we saw additional cost, and we eventually kind of twirl that down and packaged that PgBouncer alongside the applications that needed it. And this was a configuration that wasn't available on our first pass; it was something we intentionally did not provide to our development team, and we had to unwind that. And when we did, we saw better performance, we saw better cost efficiency, all sorts of benefits that we care a lot about now that we didn't care about as much, many years ago.Corey: It sounds like you're describing some semblance of an internal platform, where instead of letting all your engineers effectively, “Well, here's the console. Ideally, you use some form of Infrastructure as Code. Good luck. Have fun.” You effectively gate access to that. Is that something that you're still doing or have you taken a different approach?Peter: So, our primary gate is our Infrastructure as Code repository. If you want to make a meaningful change, you open up a PR, got to go through code review, you need people to sign off on it. Anything that's not there may not exist tomorrow. There's no guarantees. And we've gone around, occasionally just shut random servers down that people spun up in our account.And sometimes people will be grumpy about it, but you really need to enforce that culture that we have to go through the correct channels and we have to have this cohesive platform, as you said, to support our development efforts.Corey: So, you're a messaging service in education. So, whenever I do a little bit of digging into backstories of companies and what has made, I guess, an impression, you look for certain things and explicit dates are one of them, where on March 13th of 2020, your business changed just a smidgen. What happened other than the obvious, we never went outside for two years?Peter: [laugh]. So, if we roll back a week—you know, that's March 13th, so if we roll back a week, we're looking at March 6th. On that day, we sent out about 60 million messages over all of our different mediums: Text, email, push notifications. On March 13th that was 100 million, and then, a few weeks later on March 30th, that was 177 million. And so our traffic effectively tripled over the course of those three weeks. And yeah, that's quite a ride, let me tell you.Corey: The opinion that a lot of folks have who have not gotten to play in sophisticated distributed systems is, “Well, what's the hard part there you have an auto-scaling group. Just spin up three times the number of servers in that fleet and problem solved. What's challenging?” A lot, but what did you find that the pressure points were?Peter: So, I love that example, that your auto-scaling group will just work. By default, Amazon's auto-scaling groups only support 1000 backends. So, when your auto-scaling group goes from 400 backends to 1200, things break, [laugh] and not in ways that you would have expected. You start to learn things about how database systems provided by Amazon have limits other than CPU and memory. And they're clearly laid out that there's network bandwidth limits and things you have to worry about.We had a pretty small team at that time and we'd gotten this cadence where every Monday morning, we would wake up at 4 a.m. Pacific because as part of the pandemic, our traffic shifted, so our East Coast users would be most active in the morning rather than the afternoon. And so at about 7 a.m. on the east coast is when everyone came online. And we had our Monday morning crew there and just looking to see where the next pain point was going to be.And we'd have Monday, walk through it all, Monday afternoon, we'd meet together, we come up with our three or four hypotheses on what will break, if our traffic doubles again, and we'd spend the rest of that next week addressing those the best we could and repeat for the next Monday. And we did this for three, four or five weeks in a row, and finally, it stabilized. But yeah, it's all the small little things, the things you don't know about, the limits in places you don't recognize that just catch up to you. And you need to have a team that can move fast and adapt quickly.Corey: You've been using Redis for six, seven years, something along those lines, as an enterprise offering. You've been working with the same vendor who provides this managed service for a while now. What are the fruits of that relationship? What is the value that you see by continuing to have a long-term relationship with vendors? Because let's be serious, most of us don't stay in jobs that long, let alone work with the same vendor.Peter: Yeah. So, coming back to the March 2020 story, many of our vendors started to see some issues here that various services weren't scaled properly. We made a lot of phone calls to a lot of vendors in working with them, and I… very impressed with how Redis Labs at the time was able to respond. We hopped on a call, they said, “Here's what we think we need to do, we'll go ahead and do this. We'll sort this out in a few weeks and figure out what this means for your contract. We're here to help and support in this pandemic because we recognize how this is affecting everyone around the world.”And so I think when you get in those deeper relationships, those long-term relationships, it is so helpful to have that trust, to have a little bit of that give when you need it in times of crisis, and that they're there and willing to jump in right away.Corey: There's a lot to be said for having those working relationships before you need them. So often, I think that a lot of engineering teams just don't talk to their vendors to a point where they may as well be strangers. But you'll see this most notably because—at least I feel it most acutely—with AWS service teams. They'll do a whole kickoff when the enterprise support deal is signed, three years go passed, and both the AWS team and the customer's team have completely rotated since then, and they may as well be strangers. Being able to have that relationship to fall back on in those really weird really, honestly, high-stress moments has been one of those things where I didn't see the value myself until the first time I went through a hairy situation where I found that that was useful.And now it's oh, I—I now bias instead for, “Oh, I can fit to the free tier of this service. No, no, I'm going to pay and become a paying customer.” I'd rather be a customer that can have that relationship and pick up the phone than someone whining at people in a forum somewhere of, “Hey, I'm a free user, and I'm having some problems with production.” Just never felt right to me.Peter: Yeah, there's nothing worse than calling your account rep and being told, “Oh, I'm not your account rep anymore.” Somehow you missed the email, you missed who it was. Prior to Covid, you know—and we saw this many, many years ago—one of the things about Remind is every back-to-school season, our traffic 10Xes in about three weeks. And so we're used to emergencies happening and unforeseen things happening. And we plan through our year and try to do capacity planning and everything, but we been around the block a couple of times.And so we have a pretty strong culture now leaning in hard with our support reps. We have them in our Slack channels. Our AWS team, we meet with often. Redis Labs, we have them on Slack as well. We're constantly talking about databases that may or may not be performing as we expect them, too. They're an extension of our team, we have an incident; we get paged. If it's related to one of the services, we hit them in Slack immediately and have them start checking on the back end while we're checking on our side. So.Corey: One of the biggest takeaways I wish more companies would have is that when you are dependent upon another company to effectively run your production infrastructure, they are no longer your vendor, they're your partner, whether you want them to be or not. And approaching it with that perspective really pays dividends down the road.Peter: Yeah. One of the cases you get when you've been at a company for a long time and been in relationship for a long time is growing together is always an interesting approach. And seeing, sometimes there's some painful points; sometimes you're on an old legacy version of their product that you were literally the last customer on, and you got to work with them to move off of. But you were there six years ago when they're just starting out, and they've seen how you grow, and you've seen how they've grown, and you've kind of been able to marry that experience together in a meaningful way.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of “Hello, World” demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free? This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: Redis is, these days, of data platform back once upon a time, I viewed it as more of a caching layer. And I admit that the capabilities of the platform has significantly advanced since those days when I viewed it purely through lens of cache. But one of the interesting parts is that neither one of those use cases, in my mind, blends particularly well with heavy use of Spot Fleets, but you're doing exactly that. What are your folks doing over there?Peter: [laugh]. Yeah, so as I mentioned earlier, coming back to some of the Twelve-Factor App design, we heavily rely on Redis as sort of a distributed heap. One of our challenges of delivering all these messages is every single message has its in-flight state: Here's the content, here's who we sent it to, we wait for them to respond. On a traditional application, you might have one big server that stores it all in-memory, and you get the incoming requests, and you match things up. By moving all that state to Redis, all of our workers, all of our application servers, we know they can disappear at any point in time.We use Amazon's Spot Instances and their Spot Fleet for all of our production traffic. Every single web service, every single worker that we have runs on this infrastructure, and we would not be able to do that if we didn't have a reliable and robust place to store this data that is in-flight and currently being accessed. So, we'll have a couple hundred gigs of data at any point in time in a Redis Database, just representing in-flight work that's happening on various machines.Corey: It's really neat seeing Spot Fleets being used as something more than a theoretical possibility. It's something I've always been very interested in, obviously, given the potential cost savings; they approach cheap is free in some cases. But it turns out—we talked earlier about the idea of being cloud-native versus the rickety, expensive data center in the cloud, and an awful lot of applications are simply not built in a way that yeah, we're just going to randomly turn off a subset of your systems, ideally, with two minutes of notice, but all right, have fun with that. And a lot of times, it just becomes a complete non-starter, even for stateless workloads, just based upon how all of these things are configured. It is really interesting to watch a company that has an awful lot of responsibility that you've been entrusted with who embraces that mindset. It's a lot more rare than you'd think.Peter: Yeah. And again, you know, sometimes, we overbuild things, and sometimes we go down paths that may have been a little excessive, but it really comes down to your architecture. You know, it's not just having everything running on Spot. It's making effective use of SQS and other queueing products at Amazon to provide checkpointing abilities, and so you know that should you lose an instance, you're only going to lose a few seconds of productive work on that particular workload and be able to kick off where you left off.It's properly using auto-scaling groups. From the financial side, there's all sorts of weird quirks you'll see. You know, the Spot market has a wonderful set of dynamics where the big instances are much, much cheaper per CPU than the small ones are on the Spot market. And so structuring things in a way that you can colocate different workloads onto the same hosts and hedge against the host going down by spreading across multiple availability zones. I think there's definitely a point where having enough workload, having enough scale allows you to take advantage of these things, but it all comes down to the architecture and design that really enables it.Corey: So, you've been using Redis for longer than I think many of our listeners have been in tech.Peter: [laugh].Corey: And the key distinguishing points for me between someone who is an advocate for a technology and someone who's a zealot—or a pure critic—is they can identify use cases for which is great and use cases for which it is not likely to be a great experience. In your time with Redis, what have you found that it's been great at and what are some areas that you would encourage people to consider more carefully before diving into it?Peter: So, we like to joke that five, six years ago, most of our development process was, “I've hit a problem. Can I use Redis to solve that problem?” And so we've tried every solution possible with Redis. We've done all the things. We have number of very complicated Lua scripts that are managing different keys in an atomic way.Some of these have been more successful than others, for sure. Right now, our biggest philosophy is, if it is data we need quickly, and it is data that is important to us, we put it in Enterprise Redis, the cloud product from Redis. Other use cases, there's a dozen things that you can use for a cache, Redis is great for cache, memcache does a decent job as well; you're not going to see a meaningful difference between those sorts of products. Where we've struggled a little bit has been when we have essentially relational data that we need fast access to. And we're still trying to find a clear path forward here because you can do it and you can have atomic updates and you can kind of simulate some of the ACID characteristics you would have in a relational database, but it adds a lot of complexity.And that's a lot of overhead to our team as we're continuing to develop these products, to extend them, to fix any bugs you might have in there. And so we're kind of recalibrating a bit, and some of those workloads are moving to other data stores where they're more appropriate. But at the end of the day, it's data that we need fast, and it's data that's important, we're sticking with what we got here because it's been working pretty well.Corey: It sounds almost like you started off with the mindset of one database for a bunch of different use cases and you're starting to differentiate into purpose-built databases for certain things. Or is that not entirely accurate?Peter: There's a little bit of that. And I think coming back to some of our tooling, as we kind of jumped on a bit of the microservice bandwagon, we would see, here's a small service that only has a small amount of data that needs to be stored. It wouldn't make sense to bring up a RDS instance, or an Aurora instance, for that, you know, in Postgres. Let's just store it in an easystore like Redis. And some of those cases have been great, some of them have been a little problematic.And so as we've invested in our tooling to make all our databases accessible and make it less of a weird trade-off between what the product needs, what we can do right now, and what we want to do long-term, and reduce that friction, we've been able to be much more deliberate about the data source that we choose in each case.Corey: It's very clear that you're speaking with a voice of experience on this where this is not something that you just woke up and figured out. One last area I want to go into with you is when I asked you what is you care about primarily as an engineering leader and as you look at serving your customers well, you effectively had a dual answer, almost off the cuff, of stability and security. I find the two of those things are deeply intertwined in most of the conversations I have, but they're rarely called out explicitly in quite the way that you do. Talk to me about that.Peter: Yeah, so in our wild journey, stability has always been a challenge. And we've alway—you know, been an early startup mode, where you're constantly pushing what can we ship? How quickly can we ship it? And in our particular space, we feel that this communication that we foster between teachers and students and their parents is incredibly important, and is a thing that we take very, very seriously. And so, a couple years ago, we were trying to create this balance and create not just a language that we could talk about on a podcasts like this, but really recognizing that framing these concepts to our company internally: To our engineers to help them to think as they're building a feature, what are the things they should think about, what are the concerns beyond the product spec; to work with our marketing and sales team to help them to understand why we're making these investments that may not get particular feature out by X date but it's still a worthwhile investment.So, from the security side, we've really focused on building out robust practices and robust controls that don't necessarily lock us into a particular standard, like PCI compliance or things like that, but really focusing on the maturity of our company and, you know, our culture as we go forward. And so we're in a place now we are ISO 27001; we're heading into our third year. We leaned in hard our disaster recovery processes, we've leaned in hard on our bug bounties, pen tests, kind of, found this incremental approach that, you know, day one, I remember we turned on our bug bounty and it was a scary day as the reports kept coming in. But we take on one thing at a time and continue to build on it and make it an essential part of how we build systems.Corey: It really has to be built in. It feels like security is not something could be slapped on as an afterthought, however much companies try to do that. Especially, again, as we started this episode with, you're dealing with communication with people's kids. That is something that people have remarkably little sense of humor around. And rightfully so.Seeing that there is as much if not more care taken around security than there is stability is generally the sign of a well-run organization. If there's a security lapse, I expect certain vendors to rip the power out of their data centers rather than run in an insecure fashion. And your job done correctly—which clearly you have gotten to—means that you never have to make that decision because you've approached this the right way from the beginning. Nothing's perfect, but there's always the idea of actually caring about it being the first step.Peter: Yeah. And the other side of that was talking about stability, and again, it's avoiding the either/or situation. We can work in as well along those two—stability and security—we work in our cost of goods sold and our operating leverage in other aspects of our business. And every single one of them, it's our co-number one priorities are stability and security. And if it costs us a bit more money, if it takes our dev team a little longer, there's not a choice at that point. We're doing the correct thing.Corey: Saving money is almost never the primary objective of any company that you really want to be dealing with unless something bizarre is going on.Peter: Yeah. Our philosophy on, you know, any cost reduction has been this should have zero negative impact on our stability. If we do not feel we can safely do this, we won't. And coming back to the Spot Instance piece, that was a journey for us. And you know, we tested the waters a bit and we got to a point, we worked very closely with Amazon's team, and we came to that conclusion that we can safely do this. And we've been doing it for over a year and seen no adverse effects.Corey: Yeah. And a lot of shops I've talked to folks about well, when we go and do a consulting project, it's, “Okay. There's a lot of things that could have been done before we got here. Why hasn't any of that been addressed?” And the answer is, “Well. We tried to save money once and it caused an outage and then we weren't allowed to save money anymore. And here we are.” And I absolutely get that perspective. It's a hard balance to strike. It always is.Peter: Yeah. The other aspect where stability and security kind of intertwine is you can think about security as InfoSec in our systems and locking things down, but at the end of the day, why are we doing all that? It's for the benefit of our users. And Remind, as a communication platform, and safety and security of our users is as dependent on us being up and available so that teachers can reach out to parents with important communication. And things like attendance, things like natural disasters, or lockdowns, or any of the number of difficult situations schools find themselves in. This is part of why we take that stewardship that we have so seriously is that being up and protecting a user's data just has such a huge impact on education in this country.Corey: It's always interesting to talk to folks who insists they're making the world a better place. And it's, “What do you do?” “We're improving ad relevance.” I mean, “Okay, great, good for you.” You're serving a need that I would I would not shy away from classifying what you do, fundamentally, as critical infrastructure, and that is always a good conversation to have. It's nice being able to talk to folks who are doing things that you can unequivocally look at and say, “This is a good thing.”Peter: Yeah. And around 80% of public schools in the US are using Remind in some capacity. And so we're not a product that's used in a few civic regions. All across the board. One of my favorite things about working in Remind is meeting people and telling them where I work, and they recognize it.They say, “Oh, I have that app, I use that app. I love it.” And I spent years and ads before this, and you know, I've been there and no one ever told me they were glad to see an ad. That's never the case. And it's been quite a rewarding experience coming in every day, and as you said, being part of this critical infrastructure. That's a special thing.Corey: I look forward to installing the app myself as my eldest prepares to enter public school in the fall. So, now at least I'll have a hotline of exactly where to complain when I didn't get the attendance message because, you know, there's no customer quite like a whiny customer.Peter: They're still customers. [laugh]. Happy to have them.Corey: True. We tend to be. I want to thank you for taking so much time out of your day to speak with me. If people want to learn more about what you're up to, where's the best place to find you?Peter: So, from an engineering perspective at Remind, we have our blog, engineering.remind.com. If you want to reach out to me directly. I'm on LinkedIn; good place to find me or you can just reach out over email directly, peterh@remind101.com.Corey: And we will put all of that into the show notes. Thank you so much for your time. I appreciate it.Peter: Thanks, Corey.Corey: Peter Hamilton, VP of Technology at Remind. This has been a promoted episode brought to us by our friends at Redis, and I'm Cloud Economist Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry and insulting comment that you will then hope that Remind sends out to 20 million students all at once.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

What's the distinction between the Spring Framework and Spring Boot? If you are building a car, the Spring Framework is the engine while Spring Boot gives you the vehicle that you ride in. With experience teaching and answering questions on how to use Spring and Apache Kafka® together, Viktor Gamov (Principal Developer Advocate, Kong) designed a free course on Confluent Developer and previews it in this episode. Not only this, but he also explains why the opinionated Spring Framework would be a good hero in Marvel. Spring is an ever-evolving framework that embraces modern, cloud-native technologies with cross-language options, such as Kotlin integration. Unlike its predecessors, the Spring Framework supports a modern version of Java and the requirements of the Twelve-Factor App manifesto for you to move an application between environments without changing the code. With that engine in place, Spring Boot introduces a microservices architecture. Spring Boot contains databases and messaging systems integrations, reducing development time and increasing overall productivity. Spring for Apache Kafka applies best practices of the Spring community to the Kafka ecosystem, including features that abstract away infrastructure code for you to focus on programming logic that is important for your application. Spring for Apache Kafka provides a wrapper around the producer and consumer to ease Kafka configuration with APIs, including KafkaTemplate, MessageListenerContainer, @KafkaListener, and TopicBuilder.The Spring Framework and Apache Kafka course will equip you with the knowledge you need in order to build event-driven microservices using Spring and Kafka on Confluent Cloud. Tim and Viktor also discuss Spring Cloud Stream as well as Spring Boot integration with Kafka Streams and more. EPISODE LINKSSpring Framework and Apache Kafka courseSpring for Apache Kafka 101Bootiful Stream Processing with Spring and KafkaLiveStreams with Viktor GamovUse kafkaa35 to get 30% off "Kafka in Action"Watch the video version of this podcastJoin the Confluent CommunityLearn more with Kafka tutorials, resources, and guides at Confluent DeveloperLive demo: Intro to Event-Driven Microservices with ConfluentUse PODCAST100 to get an additional $100 of free Confluent Cloud usage (details)

The JavaScript Jabber panel teams up to discuss their favorite moments and episodes over the last nearly 10 years of the show. They discuss where things are at and where they're going next. Panel Aimee Knight AJ O'Neal Charles Max Wood Dan Shappir Steve Edwards Sponsors JavaScript Error and Performance Monitoring | Sentry Level Up | Devchat.tv PodcastBootcamp.io Links JSJ 478: Browser Standards Rampage: Can We Have Nice Things? Live Pull Request Review, Review: Pushback (kindly) when appropriate. Don't let pride ruin you. Pt.6 Picks Aimee- GitHub | syncfast/clockwise Aimee- Inner Engineering AJ- Laws of UX AJ- The Better Parts. Douglas Crockford. JS Fest 2018 AJ- GitHub | ewjoachim/zen-of-python AJ- GitHub | BeyondCodeBootcamp/go-proverbs AJ- Manifesto for Agile Software Development AJ- The Twelve-Factor App AJ- AHA Programming AJ- Our Software Dependency Problem AJ- THE FALLACY OF PREMATURE OPTIMIZATION AJ- Crockford on JavaScript Charles- Jungle Cruise Charles- Podcast Playbook Dan- Pick-A-Flick Steve- Stay alert Steve- Jungle cruise puns Contact Aimee: Aimee Knight – Software Architect, and International Keynote Speaker GitHub: Aimee Knight ( AimeeKnight ) Twitter: Aimee Knight ( @Aimee_Knight ) LinkedIn: Aimee K. aimeemarieknight | Instagram Aimee Knight | Facebook Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir ) LinkedIn: Dan Shappir Twitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

The JavaScript Jabber panel teams up to discuss their favorite moments and episodes over the last nearly 10 years of the show. They discuss where things are at and where they're going next. Panel Aimee KnightAJ O'NealCharles Max WoodDan ShappirSteve Edwards Sponsors JavaScript Error and Performance Monitoring | SentryLevel Up | Devchat.tvPodcastBootcamp.io Links JSJ 478: Browser Standards Rampage: Can We Have Nice Things?Live Pull Request Review, Review: Pushback (kindly) when appropriate. Don't let pride ruin you. Pt.6 Picks Aimee- GitHub | syncfast/clockwiseAimee- Inner EngineeringAJ- Laws of UXAJ- The Better Parts. Douglas Crockford. JS Fest 2018AJ- GitHub | ewjoachim/zen-of-pythonAJ- GitHub | BeyondCodeBootcamp/go-proverbsAJ- Manifesto for Agile Software DevelopmentAJ- The Twelve-Factor AppAJ- AHA ProgrammingAJ- Our Software Dependency ProblemAJ- THE FALLACY OF PREMATURE OPTIMIZATIONAJ- Crockford on JavaScriptCharles- Jungle CruiseCharles- Podcast PlaybookDan- Pick-A-FlickSteve- Stay alertSteve- Jungle cruise puns Contact Aimee: Aimee Knight – Software Architect, and International Keynote SpeakerGitHub: Aimee Knight ( AimeeKnight )Twitter: Aimee Knight ( @Aimee_Knight )LinkedIn: Aimee K.aimeemarieknight | InstagramAimee Knight | Facebook Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards

The JavaScript Jabber panel teams up to discuss their favorite moments and episodes over the last nearly 10 years of the show. They discuss where things are at and where they're going next. Panel Aimee KnightAJ O'NealCharles Max WoodDan ShappirSteve Edwards Sponsors JavaScript Error and Performance Monitoring | SentryLevel Up | Devchat.tvPodcastBootcamp.io Links JSJ 478: Browser Standards Rampage: Can We Have Nice Things?Live Pull Request Review, Review: Pushback (kindly) when appropriate. Don't let pride ruin you. Pt.6 Picks Aimee- GitHub | syncfast/clockwiseAimee- Inner EngineeringAJ- Laws of UXAJ- The Better Parts. Douglas Crockford. JS Fest 2018AJ- GitHub | ewjoachim/zen-of-pythonAJ- GitHub | BeyondCodeBootcamp/go-proverbsAJ- Manifesto for Agile Software DevelopmentAJ- The Twelve-Factor AppAJ- AHA ProgrammingAJ- Our Software Dependency ProblemAJ- THE FALLACY OF PREMATURE OPTIMIZATIONAJ- Crockford on JavaScriptCharles- Jungle CruiseCharles- Podcast PlaybookDan- Pick-A-FlickSteve- Stay alertSteve- Jungle cruise puns Contact Aimee: Aimee Knight – Software Architect, and International Keynote SpeakerGitHub: Aimee Knight ( AimeeKnight )Twitter: Aimee Knight ( @Aimee_Knight )LinkedIn: Aimee K.aimeemarieknight | InstagramAimee Knight | Facebook Contact AJ: AJ ONealCoolAJ86 on GITBeyond Code BootcampBeyond Code Bootcamp | GitHubFollow Beyond Code Bootcamp | FacebookTwitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir )LinkedIn: Dan ShappirTwitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 )GitHub: Steve Edwards ( wonder95 )LinkedIn: Steve Edwards

The JavaScript Jabber panel teams up to discuss their favorite moments and episodes over the last nearly 10 years of the show. They discuss where things are at and where they're going next. Panel Aimee Knight AJ O'Neal Charles Max Wood Dan Shappir Steve Edwards Sponsors JavaScript Error and Performance Monitoring | Sentry Level Up | Devchat.tv PodcastBootcamp.io Links JSJ 478: Browser Standards Rampage: Can We Have Nice Things? Live Pull Request Review, Review: Pushback (kindly) when appropriate. Don't let pride ruin you. Pt.6 Picks Aimee- GitHub | syncfast/clockwise Aimee- Inner Engineering AJ- Laws of UX AJ- The Better Parts. Douglas Crockford. JS Fest 2018 AJ- GitHub | ewjoachim/zen-of-python AJ- GitHub | BeyondCodeBootcamp/go-proverbs AJ- Manifesto for Agile Software Development AJ- The Twelve-Factor App AJ- AHA Programming AJ- Our Software Dependency Problem AJ- THE FALLACY OF PREMATURE OPTIMIZATION AJ- Crockford on JavaScript Charles- Jungle Cruise Charles- Podcast Playbook Dan- Pick-A-Flick Steve- Stay alert Steve- Jungle cruise puns Contact Aimee: Aimee Knight – Software Architect, and International Keynote Speaker GitHub: Aimee Knight ( AimeeKnight ) Twitter: Aimee Knight ( @Aimee_Knight ) LinkedIn: Aimee K. aimeemarieknight | Instagram Aimee Knight | Facebook Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir ) LinkedIn: Dan Shappir Twitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

The JavaScript Jabber panel teams up to discuss their favorite moments and episodes over the last nearly 10 years of the show. They discuss where things are at and where they're going next. Panel Aimee Knight AJ O'Neal Charles Max Wood Dan Shappir Steve Edwards Sponsors JavaScript Error and Performance Monitoring | Sentry Level Up | Devchat.tv PodcastBootcamp.io Links JSJ 478: Browser Standards Rampage: Can We Have Nice Things? Live Pull Request Review, Review: Pushback (kindly) when appropriate. Don't let pride ruin you. Pt.6 Picks Aimee- GitHub | syncfast/clockwise Aimee- Inner Engineering AJ- Laws of UX AJ- The Better Parts. Douglas Crockford. JS Fest 2018 AJ- GitHub | ewjoachim/zen-of-python AJ- GitHub | BeyondCodeBootcamp/go-proverbs AJ- Manifesto for Agile Software Development AJ- The Twelve-Factor App AJ- AHA Programming AJ- Our Software Dependency Problem AJ- THE FALLACY OF PREMATURE OPTIMIZATION AJ- Crockford on JavaScript Charles- Jungle Cruise Charles- Podcast Playbook Dan- Pick-A-Flick Steve- Stay alert Steve- Jungle cruise puns Contact Aimee: Aimee Knight – Software Architect, and International Keynote Speaker GitHub: Aimee Knight ( AimeeKnight ) Twitter: Aimee Knight ( @Aimee_Knight ) LinkedIn: Aimee K. aimeemarieknight | Instagram Aimee Knight | Facebook Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Charles: Devchat.tv DevChat.tv | Facebook Twitter: DevChat.tv ( @devchattv ) Contact Dan: GitHub: Dan Shappir ( DanShappir ) LinkedIn: Dan Shappir Twitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Jimmy Bogard takes us through the interesting possibilties of logging with OpenTelemetry. Then we discuss refactoring strategies friendly for Domain Driven Design. Panel Shawn ClaboughWai Liu Guest Jimmy Bogard Sponsors Dev Influencers AcceleratorRaygun | Click here to get started on your free 14-day trial Links .NET 057: Open source, MediatR and Automapper with Jimmy Bogard | Devchat.tvThe Twelve-Factor Appmartinfowler.comTwitter: Jimmy Bogard ( @jbogard ) Picks Jimmy- Power AppsShawn- Fiber internetWai- Developer Program Contact Wai: Linkedin: Wai LiuFacebook: Wai Liu Contact Shawn Twitter: Shawn Clabough (DotNetSuperhero) Special Guest: Jimmy Bogard.

Jimmy Bogard takes us through the interesting possibilties of logging with OpenTelemetry. Then we discuss refactoring strategies friendly for Domain Driven Design. Panel Shawn Clabough Wai Liu Guest Jimmy Bogard Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial Links .NET 057: Open source, MediatR and Automapper with Jimmy Bogard | Devchat.tv The Twelve-Factor App martinfowler.com Twitter: Jimmy Bogard ( @jbogard ) Picks Jimmy- Power Apps Shawn- Fiber internet Wai- Developer Program Contact Wai: Linkedin: Wai Liu Facebook: Wai Liu Contact Shawn Twitter: Shawn Clabough (DotNetSuperhero)

Rick Viscomi joins us from Google to talk to us about the Chrome User Experience Report (CrUX) and the HTTP Archive. He explains what it tells us about how the web is built, how it performs, and what we know about the web today. Panel Aimee Knight AJ O'Neal Dan Shappir Steve Edwards Guest Rick Viscomi Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial  Links JSJ 334: “Web Performance API” with Dan Shappir | Devchat.tv JSJ 428: The Alphabet Soup of Performance Measurements | Devchat.tv Is my host fast yet? Twitter: Rick Viscomi ( @rick_viscomi ) Picks Aimee- SparkPost Aimee- BigQuery: Qwik Start - Console AJ- SendGrid AJ- Tuscan Dairy Whole Vitamin D Milk AJ- The Twelve-Factor App AJ- webinstall.dev/fzf Dan- Great TV Dan- Keep daylight savings time all year round Rick- Vsauce - YouTube Rick- Uranium Ore Steve- The State of CSS Survey Steve- GitHub | State of JS 2020 Questions Contact Aimee: Aimee Knight – Software Architect, and International Keynote Speaker GitHub: Aimee Knight ( AimeeKnight ) Twitter: Aimee Knight ( @Aimee_Knight ) LinkedIn: Aimee K. aimeemarieknight | Instagram Aimee Knight | Facebook Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Dan: GitHub: Dan Shappir ( DanShappir ) LinkedIn: Dan Shappir Twitter: Dan Shappir ( @DanShappir ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Rick Viscomi joins us from Google to talk to us about the Chrome User Experience Report (CrUX) and the HTTP Archive. He explains what it tells us about how the web is built, how it performs, and what we know about the web today. Panel Aimee Knight AJ O'Neal Dan Shappir Steve Edwards Guest Rick Viscomi Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial  Links JSJ 334: “Web Performance API” with Dan Shappir | Devchat.tv JSJ 428: The Alphabet Soup of Performance Measurements | Devchat.tv Is my host fast yet? Twitter: Rick Viscomi ( @rick_viscomi ) Picks Aimee- SparkPost Aimee- BigQuery: Qwik Start - Console AJ- SendGrid AJ- Tuscan Dairy Whole Vitamin D Milk AJ- The Twelve-Factor App AJ- webinstall.dev/fzf Dan- Great TV Dan- Keep daylight savings time all year round Rick- Vsauce - YouTube Rick- Uranium Ore Steve- The State of CSS Survey Steve- GitHub | State of JS 2020 Questions Contact Aimee: Aimee Knight – Software Architect, and International Keynote Speaker GitHub: Aimee Knight ( AimeeKnight ) Twitter: Aimee Knight ( @Aimee_Knight ) LinkedIn: Aimee K. aimeemarieknight | Instagram Aimee Knight | Facebook Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Rick Viscomi joins us from Google to talk to us about the Chrome User Experience Report (CrUX) and the HTTP Archive. He explains what it tells us about how the web is built, how it performs, and what we know about the web today. Panel Aimee Knight AJ O'Neal Dan Shappir Steve Edwards Guest Rick Viscomi Sponsors Dev Influencers Accelerator Raygun | Click here to get started on your free 14-day trial  Links JSJ 334: “Web Performance API” with Dan Shappir | Devchat.tv JSJ 428: The Alphabet Soup of Performance Measurements | Devchat.tv Is my host fast yet? Twitter: Rick Viscomi ( @rick_viscomi ) Picks Aimee- SparkPost Aimee- BigQuery: Qwik Start - Console AJ- SendGrid AJ- Tuscan Dairy Whole Vitamin D Milk AJ- The Twelve-Factor App AJ- webinstall.dev/fzf Dan- Great TV Dan- Keep daylight savings time all year round Rick- Vsauce - YouTube Rick- Uranium Ore Steve- The State of CSS Survey Steve- GitHub | State of JS 2020 Questions Contact Aimee: Aimee Knight – Software Architect, and International Keynote Speaker GitHub: Aimee Knight ( AimeeKnight ) Twitter: Aimee Knight ( @Aimee_Knight ) LinkedIn: Aimee K. aimeemarieknight | Instagram Aimee Knight | Facebook Contact AJ: AJ ONeal CoolAJ86 on GIT Beyond Code Bootcamp Beyond Code Bootcamp | GitHub Follow Beyond Code Bootcamp | Facebook Twitter: Beyond Code Bootcamp ( @_beyondcode ) Contact Steve: Twitter: Steve Edwards ( @wonder95 ) GitHub: Steve Edwards ( wonder95 ) LinkedIn: Steve Edwards

Więcej Niż Konteneryzacja to podcast dla osób zainteresowanych tematyką konteneryzacji oraz najpopularniejszymi narzędziami takimi jak: Docker, Kubernetes. Druga strona podcastu to tematy związane z automatyzacją, infrastrukturą jako kod (IaC) oraz szeroko pojętym światem DevOps. Z piątego odcinka podcastu "Więcej Niż Konteneryzacja" dowiesz się: Czym właściwie jest Cloud Native? Jakie są fundamenty Cloud Native? Co to jest CNFC? Kto należy do CNFC? Kubernetes a CNFC Proces inkubacji projektów w CNFC Linki: Zrozumieć aplikacje Cloud Native https://www.redhat.com/en/topics/cloud-native-apps Twelve Factor App https://12factor.net/pl/ Początki CNFC: https://www.cncf.io/news/2015/07/21/techcrunch-as-kubernetes-hits-1-0-google-donates-technology-to-newly-formed-cloud-native-computing-foundation/ https://www.cncf.io/announcements/2015/06/21/new-cloud-native-computing-foundation-to-drive-alignment-among-container-technologies/ Kto należy do CNFC: https://www.cncf.io/about/members/ Projekty w ramach CNFC: https://www.cncf.io/projects/ Zapraszam! Prowadzi: Damian Naprawa Po więcej treści zajrzyj na blog SzkolaDockera.pl

Benedikt Koller is a self-professed "Ops guy", having spent over 12 years working in roles such as DevOps engineer, platform engineer, and infrastructure tech lead at companies like Stylight and Talentry in addition to his own consultancy KEMB. He's recently dove head first into the world of ML, where he hopes to bring his extensive ops knowledge into the field as the co-founder of Maiot, the company behind ZenML, an open source MLOps framework. Learn more: https://zenml.io/ (https://zenml.io/) https://maiot.io/ (https://maiot.io/) Every Thursday I send out the most useful things I've learned, curated specifically for the busy machine learning engineer. Sign up here: https://www.cyou.ai/newsletter (https://www.cyou.ai/newsletter) Follow Charlie on Twitter: https://twitter.com/CharlieYouAI (https://twitter.com/CharlieYouAI) Subscribe to ML Engineered: https://mlengineered.com/listen (https://mlengineered.com/listen) Comments? Questions? Submit them here: http://bit.ly/mle-survey (http://bit.ly/mle-survey) Take the Giving What We Can Pledge: https://www.givingwhatwecan.org/ (https://www.givingwhatwecan.org/) Timestamps: 02:15 Introducing Benedikt Koller 05:30 What the "DevOps revolution" was 10:10 Bringing good Ops practices into ML projects 30:50 Pivoting from vehicle predictive analytics to open source ML tooling 34:35 Design decisions made in ZenML 39:20 Most common problems faced by applied ML teams 49:00 The importance of separating configurations from code 55:25 Resources Ben recommends for learning Ops 57:30 What to monitor in an ML pipelines 01:00:45 Why you should run experiments in automated pipelines 01:08:20 The essential components of an MLOps stack 01:10:25 Building an open source business and what's next for ZenML 01:20:20 Rapid fire questions Links: https://github.com/maiot-io/zenml (ZenML's GitHub) https://blog.maiot.io/ (Maiot Blog) https://12factor.net/ (The Twelve Factor App) https://blog.maiot.io/12-factors-of-ml-in-production/ (12 Factors of reproducible Machine Learning in production) https://www.seldon.io/ (Seldon) https://www.pachyderm.com/ (Pachyderm) https://www.kubeflow.org/ (KubeFlow) https://www.penguinrandomhouse.com/books/566988/something-deeply-hidden-by-sean-carroll/ (Something Deeply Hidden) https://www.goodreads.com/series/56399-the-expanse (The Expanse Series) https://us.macmillan.com/books/9780765382030 (The Three Body Problem) https://echelonfront.com/extreme-ownership/ (Extreme Ownership)

The conversation covers:  Why Kevin helped launch Single Music, where he currently provides SRE and architect duties. Single Music's technical evolution from Docker Swarm to Kubernetes, and the key reasons that drove Kevin and his team to make the leap. What's changed at Single Music since migrating to Kubernetes, and how Kubernetes is opening new doors for the company — increasing stability, and making life easier for developers. How Kubernetes allows Single Music to grow and pivot when needed, and introduce new features and products without spending a large amount of time on backend configurations.  How the COVID-19 pandemic has impacted music sales. Single Music's new plugin system, which empowers their users to create their own middleware. Kevin's current project, which is a series of how-to manuals and guides for users of Kubernetes. Some common misconceptions about Kubernetes. Links Single Music Traefik Labs Twitter: https://twitter.com/notsureifkevin?lang=en Connect with Kevin on LinkedIn: https://www.linkedin.com/in/notsureifkevin Emily: Hi everyone. I'm Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product's value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn't talk about them. Instead, we talk a lot about technical reasons. I'm hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you'll join me.Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I am chatting with Kevin Crawley. And Kevin actually has two jobs that we're going to talk about. Kevin, can you sort of introduce yourself and what your two roles are?Kevin: First, thank you for inviting me on to the show Emily. I appreciate the opportunity to talk a little bit about both my roles because I certainly enjoy doing both jobs. I don't necessarily enjoy the amount of work it gives me, but it also allows me to explore the technical aspects of cloud-native, as well as the business and marketing aspects of it. So, as you mentioned, my name is Kevin Crawley. I work at a company called Containous. They are the company who created Traefik, the cloud-native load balancer. We've also created a couple other projects, and I'll talk a little bit about those later. For Containous, I'm a developer advocate. I work both with the marketing team and the engineering team. But also I moonlight as a co-founder and a co-owner of Single Music. And there, I fulfill mostly SRE type duties and also architect duties where a lot of times people will ask me feedback, and I'll happily share my opinion. And Single Music is actually based out of Nashville, Tennessee, where I live, and I started that with a couple friends here.Emily: Tell me actually a little bit more about why you started Single Music. And what do you do exactly?Kevin: Yeah, absolutely. So, the company started out of really an idea that labels and artists—and these are musicians if you didn't pick up on the name Single Music—we saw an opportunity for those labels and artists to sell their merchandise through a platform called Shopify to have advanced tools around selling music alongside that merchandise. And at the time, which was in 2016, there weren't any tools really to allow independent artists and smaller labels to upload their music to the web and sell it in a way in which could be reported to the Billboard charts, as well as for them to keep their profits. At the time, there was really only Apple Music, or iTunes. And iTunes keeps a significant portion of an artist's revenue, as well as they don't release those funds right away; it takes months for artists to get that money. And we saw an opportunity to make that turnaround time immediate so that the artists would get that revenue almost instantaneously. And also we saw an opportunity to be more affordable as well. So, initially, we offered that Shopify integration—and they call those applications—and that would allow those store owners to distribute that music digitally and have those sales reported in Nielsen SoundScan, and that drives the Billboard Top 100. Now since then, we've expanded quite considerably since the launch. We now report on sales for physical merchandise as well. Things like cassette tapes, and vinyl, so records. And you'd be surprised at how many people actually still buy cassette tapes. I don't know what they're doing with them, but they still do. And we're also moving into the live streaming business now, with all the COVID stuff going on, and there's been some pretty cool events that we've been a part of since we started doing that, and bands have gotten really elaborate with their live production setups and live streaming. To answer the second part of your question, what I do for them, as I mentioned, I mostly serve as an advisor, which is pretty cool because the CTO and the developers on staff, I think there's four or five developers now working on the team, they manage most of the day-to-day operations of the platform, and we have, like, over 150 Kubernetes pods running on an EKS cluster that has roughly, I'd say, 80 cores and 76 gigabytes of RAM. That is around, I'd say about 90 or 100 different services that are running at any given time, and that's across two or three environments, just depending on what we're doing at the time.Emily: Can you tell me a little bit about the sort of technical evolution at Single? Did you start in 2016 on Kubernetes? That's, I suppose, not impossible.Kevin: It's not impossible, and it's something we had considered at the time. But really, in 2016, Kubernetes, I don't even think there wasn't even a managed offering of Kubernetes outside of Google at that time, I believe, and it was still pretty early on in development. If you wanted to run Kubernetes, you were probably going to operate it on-premise, and that just seemed like way too high of a technical burden. At the time, it was just myself and the CTO, the lead developer on the project, and also the marketing or business person who was also part of the company. And at that time, it was just deemed—it was definitely going to solve the problems that we were anticipating having, which was scaling and building that microservice application environment, but at the time, it was impractical for myself to manage Kubernetes on top of managing all the stuff that Taylor, the CTO, had to build to actually make this product a reality. So, initially, we launched on Docker Swarm in my garage, on a Dell R815, which was like a, I think was 64 cores and 256 gigs of RAM, which was, like, overkill, but it was also, I think it cost me, like, $600. I bought it off of Craigslist from somebody here in the area. But it served really well as a server for us to grow into, and it was, for the most part, other than electricity and the internet connection into my house, it was free. And that was really appealing to us because we really didn't have any money. This was truly a grassroots effort that we were just—we believed in the business and we thought we could quickly ramp up to move into the Cloud. So, that's exactly what happened though. Like, we started making money—also, this was never my full-time job. I started traveling a lot for my other developer relations role. I worked at Instana before Containous. Eventually, the whole GarageOps thing just wasn't stable for the business anymore. I remember one time, I think I was in Scotland or somewhere, and it was, like, two o'clock in the morning at home here in Nashville, and the power went out. And I have a battery backup, but the power went out long enough to where the server shut down, and then it wouldn't start back up. And I literally had to call my wife at two o'clock in the morning and walk her through getting that server back up and running. And at that point in time, we had revenue, we had money coming in and I told Taylor and Tommy that, “Hey, we're moving this to AWS when I get back.” So, at that point, we moved into AWS. We just kind of transplanted the virtual machines that were running Docker Swarm into AWS. And that worked for a while, but up until earlier this year, it became really apparent that we needed to switch the platform to something that was going to serve us over the next five years.Emily: First of all, is ‘GarageOps' a technical term?Kevin: I mean, I just made it up.Emily: I love it.Kevin: I mean, it was just one of those things where we thought it was a really good idea at the time, and it worked pretty well because, in reality, everything that we did, up into that point was all webhook-based, it was really technically simple. But anything that required a lot of bandwidth like the music itself, it went directly into AWS into their S3 buckets, and it was served from there as well. So, there wasn't really any of this huge bandwidth constraint that we had to think about, that ran in our application itself. It was just a matter of really lightweight JSON REST API calls that you could serve from a residential internet connection if you understand how to set all that stuff up. And at the time, I mean, we were using Traefik, which version 1.0 at the time, and it worked really well for getting all this set up and getting it all working, and we leveraged that heavily. And at that time in 2016, there wasn't any competitor to Traefik. You would use HAProxy or you use NGINX, and both of those required a lot of hand-holding, and a lot of configuration, and it was all manual, and it was a nightmare. And one of the cool things about Docker Swarm and Traefik is that once I had all the tooling set up, it all sort of just ran itself. And the developers, I don't know around 2017 or '18, we had hired another developer on the staff. And realistically, if they wanted to define a new service, they didn't have to talk to me at all. All they did was create a new repo in GitHub, change some configuration files in the tooling we had built—or that I had built—and then they would push their code to GitLab, and all the automation would just take over and deploy their new service, and it would become exposed on the internet, if it was that type of a service, it was an API. And it would all get routed automatically. And it was really, really nice for me because I really was just there in case of the power went out in my garage, essentially.Emily: You said that up until earlier this year, this was more or less working, and then earlier this year, you really decided it wasn't working anymore. What exactly wasn't working?Kevin: There were a few different things that led us to switching, and the main one was it seemed like that every six to twelve months, the database backend on the Swarm cluster would fall over. For whatever reason, it would just—services would stop deploying, the whole cluster would seemingly lock up. It would still work, but you just couldn't deploy or change anything, and there was really no way to fix it because of how complicated and how I want to say how complex the actual databases and the data that's been stored in it because it's mostly just stateful records of all the changes that you've made to the cluster up until that point. And there was no real easy way to fix that other than just completely tearing everything down and building it up from scratch. And with all the security certificates, and the configuration that was required for that to work, it would literally take me anywhere between five to ten hours to tear everything apart, tear everything down, set up the worker nodes again, and get everything reestablished so that we could deploy services again, and the system was accepting webhooks from Shopify, and that was just way too long. Earlier this year, actually we crossed into, I want to say in January, we had over 1400 merchants in Shopify sending us thousands of orders every day, and it just wasn't acceptable for us to have that length of downtime 15, 20, 35 minutes, that's fine but several hours just wasn't going to work.Our reputation up until that point had been fairly solid. That issue or incident hadn't happened in the past eight months, but we were noticing some performance issues in the cluster, and in some cases where we were having to redeploy services two, three times for those services to apply, and that was sort of like a leading indicator that something was going to go wrong pretty soon. And it was just a situation where it was like, “Well, if we're going to have to go offline anyways, let's just do the migration.” And it just so happened that in April, I was laid off from my job at Instana and I was fortunate enough to be able to find a new job in, like, a week, but I knew that I wanted to complete this migration, so I went ahead and decided to put off starting the new job for a month. And that gave me the means, and the opportunity and the motive to actually complete this migration. There were some other factors that played into this as well, and that included the fact that in order to get Swarm stood up in 2016, I had to build a lot of bespoke tooling for the developers and for our CI/CD system to manage these services in the staging and production environment, handling things like promotion and also handling things like understanding what versions of the services are running in the cluster at any given time, and these are all tools that are widely available today in Kubernetes. Things like K9s, or Lens, or Helm, Kustomize, Skaffold, these are all tools that I essentially had to build myself in 2016 just to support a microservice environment, and it didn't make sense for us to continue maintaining that tooling and having to deal with some of their limitations because I didn't have time to keep that tooling fresh and keep it up-to-date and competitive with what's in the landscape today, which are the tools that I just described. So, it just made so much sense to get rid of all that stuff and replace it with the tools that are available today by the community and has infinitely more resources poured into them than I was ever able to provide, or I will ever be able to provide even as a single person working on a project. The one that was sort of lingering in the background was the fact that we have here recently started doing album releases, and artists are coming to us where they will sell hundreds of thousands of albums within a very short period of time, within several hours, and we were reaching the constraints of some of our database and our backend systems to where we needed to scale those horizontally. We had, kind of, reached the vertical limits of some of them, and we knew that Kubernetes was going to give us these capabilities through the modern operator pattern, and through just the stateful tooling that has matured in Kubernetes that wasn't even there in 2016, and wasn't something that we could consider, but we can now because the ecosystem has matured so much.Emily: So, yeah, it sounds like basically you were running up against some technical problems that were on the verge of becoming major business problems: the risk of downtime, and the performance issues, and then it also sounds like some of the technical architecture was limiting the types of products, the types of services that you could have. Does that sound about right?Kevin: Yeah, that's a pretty good summary of it. I think that one of the other things that we had to consider too was that the Single ecosystem, like the Single Music line of products has become so wide and so vast—I think we're coming up on five or six different product lines now—and developers need an 8 core laptop with 32 gigs of RAM just to stand up our stack because we're starting to use things like Kafka and Postgres to do analytics on all this stuff, and we're probably going to get to the point within the next 18 months to where we can't even stand up the full Single Music stack on a local machine. We're going to have to leverage Kubernetes in the Cloud for developers to even build additional products into the platform. And that's just not possible with Swarm, but it is with Kubernetes.Emily: Tell me a little bit about what has changed since making the migration to Kubernetes. And I'm actually also curious, the timeframe when this happened is really interesting, and you talked a little bit about offering these streaming services for musicians. I mean, it's an interesting time to be in the music industry. Interesting, probably in both the exciting sense and also negative sense. But how have things changed? And how has Kubernetes made things possible that maybe wouldn't have been possible otherwise?Kevin: I think right now, we're still on the precipice, or on the leading edge of really realizing the capabilities that Kubernetes has unlocked for the business. I think right now, I mean, the main benefit of it has been just a overwhelming sense of comfort and ease that has been instilled into our business side of the company, our executive side, if you will. The marketing and—of course, the sales and marketing people don't really know that much about the technical challenges that the engineering side has, and what kind of risk we were at when we were using Swarm at the time, but the owner did. There's three co-owners of the company, it's myself, Taylor, and Tommy. And Taylor, of course, is the CTO, and he is very well have the risk because he is deeply invested in the platform and understands how everything works. Now, Tommy, on the other hand, he just cares, “Is it up?” Are customers getting what their orders—are they getting their music delivered? And so, right now it's just there's a lot more confidence in the platform behaving and operating like it should. And that's a big relief for the engineers working on the project because they don't have to worry about whether or not the latest version of their service that they deployed has actually been deployed; or if the next time they deploy, are they going to bring down the entire infrastructure because the Swarm database corrupts, or because the Swarm network doesn't communicate correctly like it missed routes. We had issues where staging versions of our application would answer East-West traffic—like East-West request traffic that is supposed to go in between the services that are running in the cluster—like staging instances would answer requests that were coming from production instances when they weren't supposed to. And it's really hard to troubleshoot those problems, and it's really hard to resolve those. And so right now it's just a matter of stability. The other thing that is enabling us to do is handle the often difficult task of managing database migrations, as well as topic migrations, and, really, one-off type jobs that would happen every once in a while just depending on new products being introduced or new functionality to existing products being introduced. And these would require things like migrations in the data schema. And this used to have to be baked into the application itself, and this was really sometimes kind of tricky to manage when you start talking about applications that have multiple replicas, but with Kubernetes, you can do things like tasks, and jobs, and things that are more suited towards these one-off type activities that you don't have to worry about a bunch of services running into each other and stepping on each other's feet anymore. So, this, again, just gives a lot of comfort and peace of mind to developers who have to work on this stuff. And it also gives me peace of mind because I know ultimately, that this stuff is just going to work as long as they follow the best practices of deploying a Kubernetes manifest and Kubernetes objects, and so I don't have to worry about them breaking things per se, in a way in which they aren't able to troubleshoot, diagnose, and ultimately fix themselves. So, it just creates less maintenance overhead for me because as I mentioned at the beginning of the call, I don't get paid by Single Music, unless of course, they go public or they sell. But I'm not actually a full-time employee. I'm paid by Containous, that's my full-time job, so anything that allows me to have that security and have less maintenance work on my weekends is hugely beneficial to my well being and my peace of mind, as well. Now, the other part of the question you had, as well, is in terms of how are we transitioning, and how are we handling the ever-changing landscape of the business? I think one of the things that Kubernetes lets us do really well is pivot and introduce these new ideas and these new concepts, and these new services to the world. We get to release new features and products all the time because we're not spending a ton of time having to figure out, “Well, how do I spin up a new VM, and how do I configure the load balancer to work, and how do I configure a new schema in the database?” The stuff, it's all there for us already to use, and that's the beauty of the whole cloud-native ecosystem is that all these problems have been solved and packaged in a nice little bundle for us to just scoop up, and that enables our business to innovate and move fast. I mean, we try not to break things, but we do. But for the most part, we are just empowered to deliver value to our customers. And for instance the whole live-streaming thing, we launched that over the course of, maybe, a week. It took us a week to build that product and build that capability, and of course, we've had to invest more time into it as time has gone on because not only do our customers see value in it, we see value in it, and we see value in investing additional engineering and business marketing hours into selling that product. And so again, it's just a matter of what Kubernetes, and the cloud-native ecosystem in general—and this includes Swarm to some extent because we could not have gotten to where we did without Swarm in the beginning, and I want to give it its proper dues because, for the most part, it worked really well, and it served our needs, but it got to the point where we kind of outgrew it, and we wanted to offload the managing of our orchestrator to somebody else. We didn't want to have to manage it anymore. And Kubernetes gave us that.Emily: It sounds like, particularly when we're talking about the live streaming product, that you were able to build something really quickly that not only helped Single's business but then obviously also helped a lot of musicians, I'm assuming at least. So, this was a way to not just help your own business, but also help your customers successfully pivot in a time of fairly large upheaval for their industry.Kevin: Right. And I think one of the cool things that we experienced through the pandemic is that we saw a fairly sharp rise in sales in general in music, and I think it kind of speaks to the human nature. And what I mean by that, is that music is something that comforts people and gives people hope, and also it's an outlet. It's a way for people to, I don't want to say, disconnect because that's not really what I mean, but it gives them a means to experience something outside of themselves. And so it wasn't really that big of a surprise for us to see our numbers increase. And, I mean, the only thing that kind of did surprise—I mean, it's not a surprise now in retrospect, but one of the things that we observed as well, as soon as all the George Floyd protests started happening across the United States, the numbers conversely dropped, and at that point, we realized that there was something more important going on in the world. And we expected that and we were… it was just an interesting observation for us. And right now, I mean, we're still seeing growth, we're still seeing more artists and more bands coming online, trying to find new ways to innovate and to try to sell their music and their artwork, and we love being a part of that, so we're super stoked about it.Emily: That actually might be a good spot for us to wrap up, but I always like to give guests the opportunity to just say anything that they feel like has gone unsaid.Kevin: Well, I mean, one of the things I do want to talk about a little bit is some of the stuff that we're doing at Containous as well. As a developer advocate, I think one of the things that I really enjoy in that aspect is that this gives me an opportunity to work closely with engineers in a way in which—a lot of times, they don't have an opportunity to experience the marketing and the business side of the product, and the fact that I can interact with my community and I can work with our open-source contributors and help the engineers realize the value of that is incredible. A few things that I've done at Containous since I've joined is we are working really hard at improving our documentation and improving the way in which developers and engineers consume the Traefik product. We also are working on a service mesh, which is a really cool way for services to talk to each other. But one of the things that we've recently launched two that I want to touch on is our plugin system, which is a fairly highly requested feature in Traefik. And we launched it with Pilot, which is a new product that allows the users of Traefik to install these plugins that manipulate the request before it gets sent to the service. And that means our end-users are now empowered to create their own middleware, in essence. They're able to create their own plugins. And this allows them really unlimited flexibility in how they use the Traefik load balancer and proxy. The other thing that we're working on, too, is improving support for Kubernetes. One of the surprises that I had when migrating from Traefik version 1 to Traefik 2, when we did the Single migration to Kubernetes, was once I figured out the version two configuration, it was really easy to make that migration, but it was difficult at first to make the translation between the version 1 schema of the configuration into the version 2. So, what we're working on and what I'm working on right now with our technical writer, is a series of how-tos and guides for users of Kubernetes to be empowered in the same way that we are at Single Music to quickly and easily manage and deploy their microservices across their cluster. With that, though, I mean, I do want to talk one more thing, on maybe some misconceptions about cloud-native and Kubernetes.Emily: Oh, yes, go ahead.Kevin: Yeah, I mean, I think one of the things that I hear a lot of is that Kubernetes is really hard; it's complex. And at first, it can seem that way; I don't want to dispute that, and I don't want to dismiss or minify people's experience. But once those basic concepts are out of the way, I think Kubernetes is probably one of the easiest platforms I've ever used in terms of managing the deployment and the lifecycle of applications and web services. And I think probably the biggest challenge is for organizations and for engineers who are trying to adopt Kubernetes is that in some ways, perhaps they're trying to make Kubernetes work for applications and services that weren't designed from the ground up to work in a cloud-native ecosystem. And that was one of the things that we had the advantage of in 2016 was even though we were using Docker Swarm, we still followed something which was called the ‘Twelve-Factor App' principle. And those principles really just laid us out for a course of smooth uninterrupted, turbulence-free flying. And it's been really an amazing journey because of how simple and easy that transition from Docker Swarm into Kubernetes was, but if we had built things the old way, using maybe Packer and AMIs and not really following the microservice route, and hard coding a bunch of database URLs and keys and all kinds of things throughout our application, it would have been a nightmare. So, I want to say to anybody who is looking at adopting Kubernetes, and if it looks extremely daunting and technically challenging, it may be worth stepping back and looking at what you're trying to do with Kubernetes and what you're trying to put into it, and if there needs to be some reconciliation at what you're trying to do with it before you actually go forth and use something like Kubernetes, or containers, or this whole ecosystem for that matter.Emily: Let me go ahead and ask you my last question that I ask everybody which is, do you have a software engineering tool that you cannot live without, that you cannot do your job without? If so, what is it?Kevin: Yeah, I mean, Google's probably… [laughs] seriously, it's one of my most widely used tools as a developer, or as a software engineer, but in terms of, like, it really depends on the context of what I'm working in. If I'm working on Single Music, I would have to say the most widely used tool that I use for that is Datadog Because we have all of our telemetry going to there. And Datadog gives me a very fast and rapid understanding of the entire environment because we have metrics, we have traces, and we have logs all being shipped there. And that helps us really deep dive and understand when there's any type of performance regression, or incident happening in our cluster in real-time.As far as what my critical tooling at Containous is, because I work in Marketing and because I work more in an educational-type atmosphere there, one of the tools that I have started to lean on heavily is something most people probably haven't heard of, and this is for managing the open-source community. It's something called Bitergia. And it's an analytics platform, but it helps me understand the health of the open-source community, and it helps me inform the engineering team of the activity around multiple projects, and who's contributing, and how long is it taking for issues and pull requests to be closed and merged? What's our ratio of pull requests and issues being closed for certain reasons. And these are all interesting business-y analytics that is important for our entire engineering organization to understand because we are an open-source company, and we rely heavily on our community for understanding the health of our business.Emily: And speaking of, how can listeners connect with you?Kevin: There's a couple different ways. One is through just plain old email. And that is kevin.crawley@containous—that's C-O-N-T-A-I-N-O—dot U-S. And also through Twitter as well. And my handle is @notsureifkevin. It's kind of like the Futurama, “Not sure if serious.” I mean, those are the two ways.Emily: All right. Well, thank you so much. This was very, very interesting.Kevin: Well, it was my pleasure. Thank you for taking the time to chat with me, and I look forward to listening to the podcast.Emily: Thanks for listening. I hope you've learned just a little bit more about The Business of Cloud Native. If you'd like to connect with me or learn more about my positioning services, look me up on LinkedIn: I'm Emily Omier, that's O-M-I-E-R, or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

Willkommen zum Skillbyte-Podcast! Skillbyte ist ihr Partner für digitale Exzellenz. In diesem Podcast geht es um das Thema: Kubernetes: Flexibles und leistungsfähiges Rechenzentrum für Unternehmen // Inhalt // 01:07 - Kubernetes: Aus welchen Komponenten besteht es? Was leistet es? 06:24 - On-Premise und in der Cloud 07:26 - Yaml Beschreibung für Applikation Zielzustand 09:07 - Services, Secrets, Ingress, Namespaces, Loadbalancer,... Wie hängt das zusammen? 13:43 - Namespaces 15:18 - Kubernetes Softwarepakete mit HELM 18:05 - Kubernetes steigert Geschwindigkeit und verkürzt Innovationszyklen 25:32 - Security Checks automatisieren 27:24 - Monitoring durch Health Checks 28:11 - Entwickler übernehmen Verantwortung für Infrastruktur 30:09 - Cloud Native Softwareentwicklung 35:11 - Werkzeuge entwickeln sich schnell DevOps Folge: https://soundcloud.com/skillbyte/skillbyte-podcast-2-devops Was ist die Twelve-Factor App?: https://www.dev-insider.de/was-ist-die-twelve-factor-app-a-894702/ Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de Feedback und Fragen gerne an podcast@skillbyte.de

Joe Kutner, Software Architect for Heroku at Salesforce.com, spoke with host Kanchan Shringi about the 12-Factor App methodology, which aids development of modern apps that are portable, scalable, easy to test, and continuously deployable.

Joe Kutner, Software Architect for Heroku at Salesforce.com, discusses the twelve-factor app. The twelve-factor app is a methodology that aids development of modern apps that are portable, scalable, and maintainable. Host Kanchan Shringi spoke with Kutner about the origin of these principles; their continued and growing importance with advances in microservices, DevOps, and containerization; and […]

Sam and Ryan try to unpack the meaning of JAMstack. They discuss the constraints of the architecture, why it's confusing to think of it as an application stack, the implications it has for app cachability, and whether the Twelve Factor App that Heroku introduced in the Rails-dominated era of web development might be a better way to think about this new paradigm. Topics include:- 0:00 – Building Optimistic UIs- 13:45 – Immutable assets vs. mutable HTML- 36:05 – JAMstack, Twelve Factor Apps, and leveraging CDNs Links:- [Sam's Free Egghead Collection: Create an Optimistic UI in React with SWR](https://egghead.io/lessons/react-optimistically-update-swr-s-cache-with-client-side-data?pl=create-an-optimistic-ui-in-react-with-swr-1024)- [SWR on GitHub](https://github.com/zeit/swr)- [The Twelve Factor App](https://12factor.net/)

Z chmury wielu z nas programistów korzysta na co dzień. Wdrażamy swoje aplikacje w ramach mikroserwisów, w środowiska skonteneryzowanych. Jest kilka zasad, które musimy przestrzegać aby było to możliwe. Czasem podążamy za wytycznymi z dokumentacji danego rozwiązania. Natomiast istnieje metodologia tworzenia aplikacji o nazwie Twelve-Factor App, która definiuje pewne założenia dla naszej aplikacji. Dzięki temu będziemy mogli z łatwością nie tylko uruchamiać aplikacje w chmurach tj. AWS, Azure, GCP, ale także wykorzystywać możliwość skalowania.Jakie są plusy 12 Factor App?Podczas odcinka dyskutujemy o tym kiedy warto zastosować metodologię Twelve-Factor App, czego nam brakuje w definicji oraz co nie zawsze się sprawdza.Gotowy na podzielenie się swoimi spostrzeżeniami? Zatem:➡️ Czy spotkałeś się z 12 Factor App?➡️ Czy stosowałeś 12 Factor App podczas tworzenia aplikacji?➡️ Jakie widzisz problemy z stosowaniem tej metodologii?Zachęcam Cię do pozostawienia swojej odpowiedzi w komentarzu – dziękuję

This week's tools, tips, and tricks episodes talk about The Twelve Factor App. A methodology to help developers build software as a service in the cloud. The Twelve Factor App website. Download Twelve Factor ePub book. Be aware, be safe. Sign-Up For FREE security awareness training here. Become A Patron! Patreon Page *** Support the podcast with a cup of coffee *** - Ko-Fi Security In Five —————— Where you can find Security In Five —————— Security In Five Reddit Channel r/SecurityInFive Binary Blogger Website Security In Five Website Security In Five Podcast Page - Podcast RSS Twitter @securityinfive iTunes, YouTube, TuneIn, iHeartRadio,

ڭيڭس بلابلا هو برنامج شهري كايهضر على مواضع تقنية مختلفة بالدارجة المغربية، هو عبارة على نقاش من طرف خبراء مباشر على الفايسبوك كل أخر أحد فالشهر على الساعة التاسعة ليلا. ڭيڭس بلابلا من إنشاء مبرمجين متطوعين لتطوير المجتمع التقني فالمغرب وأي واحد يقدر يشارك فيه و يساعد بشي حاجا. ---------------------------------------------------------------------------------------- لمشاهدة جميع الحلقات https://geeksblabla.com/blablas لإقتراح موضوع نقدموه فإحدى الحلقات https://geeksblabla.com/suggest-new-episode للإشتراك فتطوير المشروع https://github.com/DevC-Casa/geeksblabla الموقع www.geeksblabla.com من بين الأشياء لي تقدرو تساهمو فيها هو إنشاء تلخيص للحلقة بعد المشاهدة ديالها للمزيد من المعلومات دخلو لهاد الرابط اتلقاو فيه التفاصيل https://github.com/DevC-Casa/geeksblabla

The Twelve-Factor App methodology  Drafted by developers at Heroku based upon their observations of what made good apps  First presented by Adam Wiggins circa 2011 (then published in 2012)  The Factors  1 - Codebase: one codebase tracked in revision control, many deploys  2 - Dependencies: explicitly declare and isolate dependencies  3 - Config: strict separation of config from code  4 - Backing services: foster loose coupling by treating backing services as attached resources  5 - Build, release, run: strictly separate build and run stages  6 - Processes: processes are stateless and share-nothing  7 - Port binding: export services via port binding  8 - Concurrency: scale out via the process model  9 - Disposability: processes are disposable, they can be started or stopped at a moment's notice  10 - Dev/prod parity: Keep development, staging, and production as similar as possible  11 - Logs: treat logs as event streams, don't manage log files  12 - Admin processes: admin and utility code ships with app code to avoid synchronization issues  What's Missing? 7 years since first being published, what changes should be made to make it more relevant for today?  Some have argued for adding 3 additional factors:  Telemetry  Security  "API First"-philosophy  For a full transcription of this episode, please visit the episode webpage.End song:Flowerchild (Roy England Remix) by Owen Ni - Make MistakesWe'd love to hear from you! You can reach us at: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast

In episode 77 of Mobycast, Jon and Chris walk through the Twelve-Factor App framework. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

Sponsors CacheFly Panel Nell Shamrell-Harrington Lee Whalen Scott Nixon Episode Summary Welcome to the first episode of the Adventures in DevOps podcast! The panelists Nell Shamrell-Harrington - Principal Engineer at Chef Software, Lee Whalen - Principal Engineer and President at Fuzzy Logic Tech, and Scott Nixon - Founder at Cloud Mechanics, kickstart the show by introducing themselves and their work. They begin the discussion by attempting to answer the fundamental question - What really is DevOps? They discuss at length the intersection of DevOps with cloud native computing. They talk about what it means to implement the DevOps way of working, what factors does it depend on, the importance of having a DevOps measuring index to make its deployment successful, prioritizing disaster recovery especially for startups, and the security concerns associated with DevOps deployment in general. This being the first episode, they discuss what they would each like to cover in the future episodes and come up with interesting topics. They end the episode with picks. Links Nell's Twitter, LinkedIn Lee's LinkedIn Scott's Twitter, LinkedIn The Phoenix Project DORA The Joel Test: 12 Steps to Better Code The Twelve-Factor App Kubernetes Failure Stories Picks Nell Shamrell-Harrington: Quiver Captain Marvel Scott Nixon: The Rise and Fall of the Dinosaurs AWS Simplify

Sponsors CacheFly Panel Nell Shamrell-Harrington Lee Whalen Scott Nixon Episode Summary Welcome to the first episode of the Adventures in DevOps podcast! The panelists Nell Shamrell-Harrington - Principal Engineer at Chef Software, Lee Whalen - Principal Engineer and President at Fuzzy Logic Tech, and Scott Nixon - Founder at Cloud Mechanics, kickstart the show by introducing themselves and their work. They begin the discussion by attempting to answer the fundamental question - What really is DevOps? They discuss at length the intersection of DevOps with cloud native computing. They talk about what it means to implement the DevOps way of working, what factors does it depend on, the importance of having a DevOps measuring index to make its deployment successful, prioritizing disaster recovery especially for startups, and the security concerns associated with DevOps deployment in general. This being the first episode, they discuss what they would each like to cover in the future episodes and come up with interesting topics. They end the episode with picks. Links Nell's Twitter, LinkedIn Lee's LinkedIn Scott's Twitter, LinkedIn The Phoenix Project DORA The Joel Test: 12 Steps to Better Code The Twelve-Factor App Kubernetes Failure Stories Picks Nell Shamrell-Harrington: Quiver Captain Marvel Scott Nixon: The Rise and Fall of the Dinosaurs AWS Simplify

Luke Melia, Aaron Chambers, and Mattia Gheda john Taras and Charles to discuss all things deployment! Luke Melia: Luke has been working with Ember since it was under early development as Sproutcore 2.0. Ember.js powers a SaaS company he co-founded, Yapp, and they funded their business for a couple of years doing Ember consulting under the Yapp Labs moniker. They're full-time on product now, and his engineering team at Yapp (currently 3 people) maintains around 6 Ember apps. Luke helps to maintain a bunch of popular addons, including ember-cli-deploy, ember-modal-dialog, ember-wormhole, ember-tether, and more. He started the Ember NYC meetup in 2012 and continues to co-organize it today. Aaron Chambers: Aaron Chambers: Aaron is the co-author of EmberCLI Deploy and is currently an Engineer at Phorest Salon Software, helping them move their desktop product to the web platform. He's been using Ember for 5 years and maintains a number of plugins in the EmberCLI Deploy ecosystem. Aaron loves trying to work out how we can ship JS apps faster, more reliably and with more confidence. Mattia Gheda: Mattia is a Software Engineer, Ember hacker, Ruby lover and Elixir aficionado. Currently he works as Director of Development for Precision Nutrition where Ember, Ruby and Elixir power several applications. He loves meetups, organizes Ember.js Toronto and co-organizes Elixir Toronto. Resource: Immutable Web Apps Please join us in these conversations! If you or someone you know would be a perfect guest, please get in touch with us at contact@frontside.io. Our goal is to get people thinking on the platform level which includes tooling, internalization, state management, routing, upgrade, and the data layer. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello and welcome to The Frontside Podcast, a place where we talk about user interfaces and everything that you need to know to build them right. My name is Charles Lowell, a developer here at the Frontside. With me also co-hosting today is Taras Mankovsky. Hey, Taras. TARAS: Hello, everyone. CHARLES: Today, we have three special guests that we're going to be talking to. We have Aaron Chambers, Luke Melia, and Mattia Gheda who originally met collaborating on fantastic open source library that we, at the Frontside, have used many, many times that saved us countless hours, saved our clients hundreds of thousands of dollars, if not more. ember-cli-deploy. We're gonna be talking not about that library in particular but around the operations that happen around UI. So, welcome you all. LUKE: Thanks, it's great to be here. CHARLES: Like I said, I actually am really excited to have you all on because when we talk about the platform that you develop your UI on, something that often gets short shrift in communities outside of the Ember community is how do I actually deliver that application into users' hands. Because obviously, we don't want it to be working just on our laptop. We want it to be delivered to our users and there are myriad ways that that can happen and it's only gotten more complex since the last time we talked which must have been like three or four years ago. I kind of just have to ask, I think that what you all were talking about then was cutting edge is still cutting edge now but there must have been some pretty incredible developments like in the last three or four years. What have been kind of the new insights that you all have? LUKE: I think that what we realized as we got started with ember-cli-deploy and a project kind of came together as a combination of a few different open source efforts, something that Aaron was working on, something that our collaborator Mike was working on. We decided to come together under one umbrella, joined forces. And what we realized pretty soon is that deployment needs vary a ton between companies. And so, we are coming from this background in Ember community where we had this attitude where nobody is a special snowflake. We all kind of have the same needs for 90% of what we do. And that's true. I really believe in a lot of that Ember [ethos]. But when it comes to deployment, you know what? A lot of companies are special snowflakes or it's at least is much more fragmented than kind of our needs around on the JavaScript side. And so, what we decided to do was to try to evolve ember-cli-deploy into a platform essentially, an ecosystem that could let people mix and match plug-ins to do in their organization without locking them into an opinion that might simply be a non-starter in their org. CHARLES: It's hard enough to have opinions just around the way that your JavaScript code is structured but when it comes to rolling out your app, it really does encompass the entire scope of your application. So, it has to take account of your server. It has to take account of your user base. It has to take account of all the different processes that might be running all over, distributed around the Internet. Maybe somewhere on AWS, maybe somewhere on Legacy servers but it has to consider that in its entirety. So, it's having opinions that span that scope is particularly difficult. LUKE: Yes. And so, you mentioned a bunch of technical details which are absolutely forcing factors for a lot of words in how they do their deployments but what we found in talking to people that there are also people in political aspects to deployment in many cases. Engineers kind of own the JavaScript code that's running within their app, more or less. But when it comes to pushing the app into the world and a lot of companies, that means they're interacting with sysadmins, ops folks, people who have very strong opinions about what is an allowable and supportable way to get those deployments done and to have that stuff exist in production. And so, we needed to come up with an architecture that was going to support all these kind of varied use cases. And so, we came up with this system of essentially a deployment pipeline and plugins that can work at various stages of that pipeline. And that ecosystem has now grown quite a bit. It's actually, I don't know Aaron if you and Mattia would agree but I think it's probably the best decision that we made in this project because that ecosystem has grown and evolved without us needing to do a ton of work in maintenance. And it's been really great. I think Mattia, you pulled some of the current numbers there. MATTIA: Yeah. I pulled some numbers just yesterday and we have currently 150 different plugins attached to themselves, to different parts of the pipeline. So some of them are about how to build the assets, some of them are about how to compress them, some of them are about shipping. And they allow people to ship it with different ways like we are seeing [inaudible] with just simply Amazon APIs or Azure APIs and some of them even are about just how to visualize data about your deployments or how to give feedback to the user about what was deployed and represent the information. And then this is kind of a bit more detail, probably specific to us but we also added this idea of plugin packs. So, in order to help people define their deployment story, we created this ideal of plugin packs. Plugin packs are simply group of plugins. So, plugins grouped together. As a user, if you want to implement what we call a deploy strategy, you can simply install a plugin pack and that will give you all the plugins that allow you to deploy in a specific way. And that's kind of like an optimization that we added just to make it easier for people to share deployment strategies, share ways of deploying applications. CHARLES: Right. It's almost like an application within the framework. MATTIA: Yeah, exactly. But to stay on the community side, I think that the interesting part about what Luke was saying which was a great success for us is that all we maintain as the core team for this project is the core infrastructure, so the pipeline and a thousand of plugins. Everything else is community-based. And often, even in my day-to-day work, I end up using plugins that I didn't write and that I don't even maintain. But because the underpinning of it were designed especially by Luke and I are flexible enough. It just like has been very, very stable and very, very reliable for many years. So, I will say definitely the idea of like in the spirit of what Ember is, I guess, creating a shared ecosystem where people can add what they want and extend what was provided has been the one single biggest win of this project. CHARLES: One of the things that I'm curious about is we've talked about how you're allowing for and kind of embracing the fragmentation that happens in people's kind of the topology of their infrastructure. What do you see is the common threads that really bind every single good deployment strategy together? MATTIA: My biggest thing here, and we actually have some shared notes about this, but my biggest thing about this is the idea that building and deploying an application for me is divided into three parts. There's building part where you have to decide how to compile your JavaScript application and how to produce some sort of artifact. There is the shipping part where it's about deciding where you're going to put the artifact. And then there is the serving part which is how you show it and deliver it to your users. I think that these three are the underpinnings of any deploy strategy. What we did with this project is just acknowledging that and give each one of these a place. And so, the entirety of what we do in what Luke defined as a pipeline is simply give you a way to customize how you build, customize how you ship, and then customize how you serve. So yeah, I think that that's kind of the root. And the question that everybody that wants to deploy a modern JavaScript application have to ask themselves is how do I want to build it, how do I want to ship it, and how will I serve it to my users. And these things are completely independent one from the order in the sense that you can have something build it, something ship it and something serve it, and that's what we end up doing in most of our deployments, I find. CHARLES: It's good to think about those things as soon as you possibly can and make sure that you have all three of those bases covered really before you start adding a whole ton of features. TARAS: Sprint 0, right? LUKE: In Agile, we call Sprint 0 the phase the thing you do right in the beginning. You've got a skeleton of an app and then you get the deployment infrastructure going, you have the test infrastructure going, so that there is no task within your actual feature development where you have to do those things. And I think that can be a valuable concept to embrace. I would just add to Mattia's three points that for deployments, to me, some very simple qualities of a good deployments are repeatability. You need to be able to reliably and consistently run your deployment process. Sounds simple but there's plenty of operations that have run up way too long on manual deployments. So, we don't want to see those rollback capabilities if you have a deployment that you realize was a mistake right after it gets into production. I'm sure none of us have ever experienced that. CHARLES: That never happens to me. LUKE: You want to have a method to roll that code back. That's something that can be remarkably complex to do. And so, having some guardrails and some support mechanisms to do that like ember-cli-deploy provides can be really useful. But whatever your approach is, I think that's a necessary quality. And then I think we start to step into kind of more advanced capabilities that a good deployment architecture can provide when we start to think about things like personalization, A/B testing, feature flags, these kinds of things. And that requires more sophistication, but you cannot build that on a deployment foundation that's not solid. AARON: I think for me, one of the things I've been really thinking about a lot lately, it's a bit of a mindset shift, I think, to get to where the things Mattia was talking about separating those different parts of deployment. And so, I really start to realize the traditional mindset around deployments like I build some stuff and I ship it to the server and then the users get it. But if we can actually stop and actually split our understanding of deployment into two separate phases. One is the building and the physical shipping of the files; and the other one's actually making them available to people. You open up this whole world of our features that you wouldn't normally have. So to be able to actually physically put stuff in production but not yet have it active, as in users don't see it yet but you can preview those versions in production against production databases. And then at some point after the fact, decide, "Okay, I'm now going to route all my users to this new thing," And to be able to do that really easily is massively, massively powerful. And so, to me, the thing I've been thinking about lately is it is a small mindset shift away from packaging everything up and pushing and overwriting what's currently there to being something, again like Luke said, immutable deployments where everything we build and ship sits next to all the other versions and we just decide which one we want to use to look at it any time which leads into then, I guess, A/B testing, feature flags and things. So I guess deployment really is not so much about the physical shipping, that's one part of it. To me, deployment now is shipping of stuff, as in physical deployment and then the releasing it or enabling it or activating it to users. CHARLES: Or routing it. Sounds like what you're describing is an extraordinarily lightweight process. AARON: It is, yeah. CHARLES: To actually route traffic to those files. AARON: It is. It's incredibly lightweight. That's the amazing thing about it. When you think about it, you're building a few JavaScript files and CSS files and images and putting them on a CDN, and then you just need a tiny web server that basically decides which version of the app you want to serve to people. There's not much to it at all, really. CHARLES: I mean that's absolutely fascinating, though the capability that you have when you have the ability to have these versions, the same versions or different versions of your application sitting along next to each other and being able to route traffic. But it also seems to me like it introduces a little bit of complexity around version matching because only certain versions are going to be compatible with certain versions of your API. You have different versions of your API talking to the -- so the simplicity of having kind of mutable deployments, so to speak, is that everything is in sync and you don't have to worry about those version mismatches. Is that a problem or this could just be me worrying about nothing? But that's kind of the thing that just immediately jumps out to me is like are there any strategies to manage that complexity? LUKE: To me, what you're describing, I kind of think of as a feature not a bug. And what I mean by that is that it is very simple to have a mental model of, "Oh, I have a version of my JavaScript code that works with this version of my API." And as long as I kind of deploy those changes together, I'm good to go. The reality is that that's impossible. The JavaScript apps that we write today, people are using anywhere from two seconds at a time to two days at a time. It's not uncommon these days to have some of these dashboard apps. People literally live-in for their job eight hours a day, nine hours a day, keep the browser tab open and come in the next morning and continue. And so, obviously there are some mechanisms we could use to force them to reload that kind of thing. But at some point in most apps, you're going to have a slightly older version of your JavaScript app talking to a slightly newer version of your API for either the span of a minute or perhaps longer depending on their strategies. So to me, the process of thinking about that and at least being aware of that as an engineer thinking about how your code is going to get from your laptop into the world, I think it's an important step that we not paper over that complexity and that we kind of embrace it and say, "Hey, this is part of life." And so, we need to think about just like we need to think about how your database migrations get into production. That's not something that you can paper over and just have a process that it's going to take care of for you. It requires thought. And I think that this, in the same token, how different versions of your JavaScript app are going to interact with your API requires thought. An exact parallel also had different versions of a native mobile app that go into the app store. How did those interact with different versions of your API? So, I think you're right. There's complexity there. There's ways that we can try to mitigate... CHARLES: Keep repeating ourselves if we think that that [inaudible] actually doesn't exist even in the simple case? MATTIA: Yeah. I think that that's to reiterate what Luke is saying. That's exactly the point. You can pretend it's not there but it is and you have no way to avoid it. Once you ship something to a browser, you have no control over it anymore. And so, you have to assume that somebody is going to be using it. LUKE: Aaron, I think you too, I don't know if you can share it. But you recently told us some stories about kind of what you encountered in your work about this and of how long people were using versions and stuff. AARON: Yeah. Something that we hadn't sort of put a lot of thought into. But the last place I worked at, we had quite a long lived app and we're using feature flags and we're using launch [inaudible] something and it gives you a list of flags and when they were last requested. And there were also flags that we removed from the code and it was just a matter of waiting until all the users had the most current version of the app and weren't requesting the flag anymore. But this one flag just kept getting requested for months and we just could not work out why. It really sort of opened my eyes up to this exact problem that these long lived apps set in the browser and if you have someone that just doesn't reload the browser or restart the machine or anything, your app can live a lot longer than maybe you actually realize it is. So we're shipping bug fixes, we're shipping new features, and we're all patting ourselves in the back. We fixed this bug but have we really? If your users haven't reloaded the app and gotten the latest version, then you haven't actually fixed the bug for some number of people. And it's really hard to tell them as you think about this and put things in place, really hard to tell what versions are out in the world, how many people are using this buggy version still. CHARLES: Yeah, that's an excellent point. I haven't even thought about that. I mean, what is the countermeasure? AARON: We hadn't made it until we came across [crosstalk]. CHARLES: It's nothing quite like getting smacked in the face of the problem to make you aware of it. AARON: That's right. CHARLES: So, what's the strategy to deal with that? AARON: I guess for me, my learnings from that would be from very early on thinking about how we're going to encourage people to reload, to start with, and maybe even have the ability to force a reload and what that means but then that has gotchas as well. You don't want to just reload something when a user is in the middle of writing a big essay or something like that. But definitely thinking about it from the start is one of the things you've got to think about from the start. But I guess something that I'd like to implement and I've kind of thought through but not really explored yet, but the ability to see what versions are out there in the world and there are things I've been thinking about in terms of this little server that serves different versions. Maybe we can start having that kind of tracking what versions are out there and who's using what and being able to see because it would be great to be out to see a live chart or a dashboard or something that sort of shows what versions are out there, which ones we need to be aware of that are still there and even what users are using and what versions they can maybe even move them on, if we need to. But there's definitely a bunch of things that aren't immediately obvious. And I don't know how many people actually think about this early on, but it's critical to actually think about it early on. MATTIA: Yeah. I was going to share what we do which is very similar to what Aaron said just maybe for the listeners to have some context. The first thing you can do is basically what Gmail does, which is every time a web app sends a request, an [inaudible], it will send the version of the app with the request and the backend can check. And the backend can check if you are sending a request from the same version that is the most recent deployed version. And if it's not, this sends back a header and the same way that Gmail does, it will display a pop up that is like, "Hey, we have a new version if you want reload." And on top of that [inaudible] is that we have a dead man's switch. So if we accidentally deploy a broken version, a part of this process, the frontend application tracks in the headers. And if a special header is sent, it force reloads, which is not nice for the user but it's better and sometimes is critical to do so. CHARLES: Right. I remember that was that case where Gmail released something. They were doing something with broken service workers and the app got completely and totally borked. I remember that my Twitter blew up, I don't know, about a year ago I think, and one of the problems I don't think they had was they did not have that capability. MATTIA: I mean, you learned this the hard way sadly. But I think these two things are definitely crucial. And the third one, [inaudible]. I thought, Luke, you had the ability that Aaron was talking about like tracking versions in the world. And I think that's more useful for stats so that you know how often your users update. And then you can make the design decisions based on that and based on how much you want to support in the past. LUKE: Yeah. We haven't implemented that but it reminds me whenever there's a new iOS version, we do a bunch of mobile work in the app and we're always looking at that adoption curve that's published. A few different analytic services publish it and say, "OK. How fast is iOS 12 adoption? How fast are people leaving behind the old versions?" And that helps to inform how much time you're spending doing bug fixes on old version versus just telling people, "Hey, this is fixed in the new OS. Go get it." But if you are able to see that for your own JavaScript apps, I think that would be pretty hot. CHARLES: Yeah. Crazy thought here but it almost makes me wonder if there's something to learn from the Erlang community because this is kind of a similar problem. They solved 20 years ago where you have these very, very long running processes. Some of them there's some telephone servers in Sweden. They've been running for over a decade without the process ever coming down. And yet they're even upgrading the version of Erlang that the VM is running. And they have the capability to even upgrade a function like a recursive function as it's running. And there's just a lot of -- I don't know what the specific lessons are but I wonder if that's an area for study because if there's any community that has locked in on hot upgrade, I feel like it's that one. LUKE: That's a terrific analogy. I bet we could learn a ton. Just hearing that kind of makes me think about how kind of coursed our mental model is about updates to our JavaScript apps. We talked to Aaron, we're talking about kind of this idea of a mutable apps and you have different versions side by side. But the idea of being able to kind of hot upgrade a version with running code in a browser, now that's an ambitious idea. That's something I'd say, "Wow! That kind of thing would be a game changer." CHARLES: Yeah. AARON: Makes me feel like we got a whole bunch of work to do. CHARLES: We welcome them. I'm always happy to give people plenty more work to do. No, but how they manage even being able to do migrations on the memory that's running. I don't know if it's something that's going to be achievable but it sounds kind of like that's the direction that we're heading. LUKE: It does, as these apps get more complex and they continue to live longer. The idea, the work arounds that Mattia mentioned about kind of showing a message and having a dead man's switch, these are all certainly useful. And today, I would say even like the best practice but they were not what you would want to do if you could magically design any system. If you're taking a magical approach, the app will just be upgraded seamlessly as a user was using it. And they would be none the wiser, the bugs would be fixed. End of story. There's no interruption to their workflow. At least for me personally, I don't really think about that as a possibility but I love the Erlang story and analogy and to say maybe that is a possibility, what would it take? I would obviously take a collaboration across your JavaScript framework, perhaps even JavaScript language features and browser runtime features as well as your backend and deployment mechanism. But I think it's a great avenue for some creative thinking. CHARLES: I'm curious because when we're talking about this, I'm imagining the perfect evergreen app but there's also feels like there's maybe even a tension that arises because one of the core principles of good UI is you don't yank the rug out from underneath the user. They need to, at some point and we've all been there when the application does something of its own agency, that feels bad. It feels like, "Nope, this is my workspace. I need to be in control of it." The only way that something should move from one place to the other without me being involved is if it's part of some repeatable process that I kicked off. But obviously, things like upgrading the color of a button or fixing a layout bug, those are things that I'm just going to want to have happen automatically. I'm not going to worry about it. But there is this kind of a gradation of features and at what point do you say, "You know what? Upgrading needs to be something that the user explicitly requires," versus, "This is something that we're just going to push. We're going to make that decision for them." LUKE: Yeah, it's a great question. One of the things that I'm curious what you all think is when you think about the mental model that our users have of working in a browser app, do you think that there is a mental model of, "Oh, when I refresh, I might get a new version." Do people even think about that? Or are they just like your example about a button color changing as kind of a minor thing. I don't even know if I could endure stack. We've all been I think in situations where you do a minor redesign and all of a sudden, all hell breaks loose and users are in revolt. Take the slack icon. So, I think it's a fascinating question. CHARLES: I don't know. What's the answer? Do you always ask for an upgrade just observing? I don't have any data other than observing people around me who use web applications who don't understand how they actually work under the covers. I don't think it's the expectation that this code, this application is living and changing underneath their feet. I think the general perception is that the analogy to the desktop application where you've got the bundled binary and that's the one you're running is that's the perception. AARON: I'd say the difference there is that, and with all these new ways of deploying, we're shipping small things faster in multiple, multiple times a day or even an hour. So it's not the sort of thing you really want time to use. There has been an update, need to upgrade as well. And that's the difference between the desktop mentality. And if that's the mentality they have, it sits quite a bit of a shift, I guess. MATTIA: It makes me think that one of the tools that the users -- if you take a look at the general public, there's probably one tool that everybody can relate to which is Facebook. So, I think if there is a way to say what do people generally expect. There is a business user which I think we are often most familiar with but the general public, probably what they're most familiar with is what happens in Facebook. And I don't use Facebook almost. I haven't used it for a couple of years but I wonder how much of what people experience in Facebook actually impacts the expectations around how applications should behave. LUKE: I think that's a really good question. I do think your underlying point of you have to know your own users I think is an important one also. Obviously, some folks are going to be more technical than others or some audiences will be more technical than others. But I would even question, Charles, your suggestion that people think of it kind of as like a binary that it stays the same until you refresh. I think people have an idea that web apps improve over time or sometimes they get bugs but hopefully that they improve and change over time, and that there is a tradeoff there that means sometimes there's something new to learn but at the same time, you get new features. But I don't know that people necessarily associate that with and it happens when I hit reload or it only happens when I open a new browser, like I don't know that it's that clear for people in their head. CHARLES: Right. I can see that. But the question is if the evolution is too stark, I think people tend to get annoyed. If they're in the middle of a workflow or in the middle of a use case and something changes, then it gives it a feeling of instability and non-determinism which I think can be unsettling. LUKE: Definitely. We all value, as engineers, we value getting into that flow state so much of like, "Oh man, I'm being productive. I don't have any distractions." And you kind of owe that to your users also to be able to let them get into that state with your app and not be throwing up, "Hey, there's new stuff. Reload." "I'm in the middle of something. Sorry." CHARLES: Yeah. I definitely do the same thing. Sometimes, I let iOS be bugging me to upgrade for a month until I finally start to feel guilty about security and actually do the upgrade. LUKE: Right. CHARLES: Although once they started doing it at night, it actually made it a lot better. LUKE: That's an interesting idea, too. I think there's a natural tension between the lower integration risk that we have as the engineering teams of shipping very frequently. Aaron mentioned shipping a dozen times a day. We certainly have been there and done that as well. I would say on average, we ship a few times a day. But the reason that we do that is because we know the faster we get code into production, the faster we can trust it. So it passes all your tests, it passes your [inaudible], but you don't really know if you're being honest. You don't really know until there's thousands of people using it in production. And yet, this conversation makes me think about there is a tension between how frequently you do that versus your users' kind of comfort level and expectations. CHARLES: And maybe there is a thing where you can kind of analyze on a per user basis how often they're active in the application and try to push updates on times that are customized to them. LUKE: Like when a user has been idle for 30 minutes or something like that. CHARLES: Yep. Or even like track trends over months and see when they're most likely to be idle and schedule it for them. LUKE: Good point. CHARLES: Something like that. TARAS: I have an idea. We should introduce screen savers into web apps. And so when the user stops using the app, just turn on screen saver and do the upgrade. LUKE: I can see the VC patch. It's after dark but for the web. CHARLES: Enter install flying toaster. AARON: It does that to open up the idea as well of that automated checking that things are okay well after the fact because it's all right to sit there maybe activate something and sit there even for an hour and make sure there's no bug request coming in. But if no one's actually received your app, then of course it's not going to come in. And it's very easy to kind of move onto the next thing and forget about that. I guess it's not something that I've ever put a lot of time in and I haven't worked anywhere that's had really great automated checking to see is everything still okay. And I guess it's an interesting thing to start thinking about as well an important thing. CHARLES: Like actually bundling in diagnostics in with your application to get really fine grained information about kind of status and availability inside the actual app. AARON: I'm not exactly sure, really. I guess I maybe wasn't thinking about inside the app but I don't know what it looks like exactly. But there is that element of shipping fast and getting stuff out there. But are we really making sure it all works later on when everyone's actually using it. LUKE: Yeah. This by the way, I just wanted to say when we were talking earlier what are the essential qualities around deploying an app. And this reminds me that one thing that we didn't mention but is very simple is your app should have a version. And it should be unique and traceable back to what was the GitHub, git commit that was the origin of that code. It's just a very simple idea but if you're going to be analyzing errors in production when you have multiple different versions of your JavaScript app running, you're going to need to know what version caused this error and then how do I trace it back and make sure that the code that I'm trying to debug is actually the code that was running when this error happened. CHARLES: Do you only use just [inaudible] or do you assign like a build number or using SemVer? What's a good strategy? LUKE: In our case, we use git tags. And so, our CI deployment process for our Ember apps basically looks like this is we work on a PR, we'll merge it to master. If it builds, the master gets deployed into our QA environment automatically using ember-cli-deploy from our CI server. And then once we're happy with how things are on QA, we do git tag or actually I use an ember addon called ember release that does that tagging for me and I'll tag it either in patch minor or major, roughly [inaudible] although it doesn't matter that much in the case of apps. When there is a new tag that builds green on CI, that gets deployed automatically into production by ember-cli-deploy. And so, that's kind of a basic flow. That tagging, just to be clear, the SemVer tag is just going to be number.number.number. You can get more sophisticated than that and I think both Aaron and Mattia have a system where even in the PR stage, there's automatic deployments happening. So maybe one of you want to mention that. AARON: We're slightly different. Every time we push the pull request, that gets deployed to production. We're able to preview up pull requests in production before we even merge into master which we find super useful to send out links to stakeholders and maybe people that have raised bugs just to get them to verify things are fixed. And then at the point that it's all Google merged, the pull request to master which will automatically do another deploy which is the thing we'll ultimately activate, we activate it manually after the fact. We just do a little bit of sanity checking but we could automatically activate that on merge to master as well. But yeah, the being able to preview a pull request in production is super powerful for us. CHARLES: That is definitely a nice capability. It's hard. It's one of those certain workflows or patterns or tools that you remember life before them and then after them and it's very hard to go back to life before. I would definitely say kind of the whole concept of preview applications is one of those. AARON: Absolutely. It's a daunting concept if you're not there, previewing something that's essentially a work in progress and production. And there are some things you want to be careful with, obviously. But for the most part, it's a super valuable thing. As you say, it's a world where once you're there, it's very hard to step back and not be there again. CHARLES: So I had a question about, we talked about I think it was 162 plugins around the ember-cli-deploy community. What for you all has been the most surprising and delightful plugin to arrive that you never imagined? MATTIA: That is a good one. I'm pulling up the list. What I can tell you, for me, it's not about a specific plugin. The surprising part was the sheer amount of different strategies that people use for the shipping part. At least, I found that the build part is similar for most people, like most people want to do the things that you're supposed to do. So, you want to build your application and then you want a minify it in some way. And there's a bunch of options there from gzip to more recent technologies. But the way people deliver it to servers and the difference in the solutions, that I think for me has been the biggest thing, where people that ship [inaudible] are people that ship directly to Fastly, people that use FTP files, people that use old FTP, people that use our sync, people that do it over SSH. We have people that ship stuff directly to a database because some databases actually have great support for large files. So we even use it as a storage. We have people that do it in MySequel, people that do it in [inaudible]. CHARLES: It's actually storing the build artifacts inside of a database? MATTIA: Yes, I've seen them in that. It's kind of interesting like the solutions that people ended up using. And so for me, I think that that's been the most fascinating part. Because as we were saying at the beginning, I'm just seeing now, we even have one for ZooKeeper. I don't have an idea what this does but it's probably related to some sort of registration around the seven-day index. That, to me, I think has been the biggest surprise. Everybody ends up working in a different environment. And so, that flexibility that users need has been by far the most surprising one. AARON: I think that's also been one of the challenging things, one of the enlightening things for me. I think in the Ember ecosystem, addons and even just Ember itself, it's all about convention of configuration and doing a lot of the stuff that you do for you. I think people expect them to see a lot of point to do the same thing. But the key thing here is it just really automates all the things you would do manually and you need to understand exactly what you want your deployment strategy to be before use them to see a lot of [inaudible] could do for you. You need to decide do I want to install my assets on a CDN and do I want to install my index in Redis or in console or in S3 bucket. You need to know all these things and have decided on all these things and then ember-cli-deploy will make that really easy for you. And this is one of the educational things, I think we still haven't even nailed because there are always people that want to know why this doesn't work. But deployments are complex thing and as what you were saying Mattia, there are so many different variables and variations on doing this that there's no sensible configuration ember-cli-deploy could really provide out of the box, I guess. And so, that's why we ended up with a pipeline that gives you the tools to be flexible enough to support your strategy. LUKE: I think the closest that we come to the convention is that if any app is using ember-cli-deploy, you can run ember deployment targets or ember deploy prod and ember deploy QA and you can expect that that's going to work. What you don't know is how has it happened to be configured in this project. Charles, your question about kind of the most surprising thing that's come out of the ecosystem. For me, I would say -- Mattia mentioned plugin packs earlier which are groups of plugins that kind work together well. And so, we've seen some plugin packs like you might expect, like an AWS pack for deploying to AWS. But the more interesting ones to me that we've seen a lot of, companies open source their plugin packs. So what you naturally fall into as a company that's adopting ember-cli-deploy that has multiple ember apps is that you are going to develop your own plugin pack for internal use because generally speaking, companies follow the same deployment pattern for each of their apps. There's usually not any reason to vary that. So then the new thing that happen on top of that is people said, "Why don't I make this open source so other people can kind of see how we do it?" And that's been a really delightful part of the process to kind of get a peek into how other organizations are orchestrating their deployments. And if people are curious about kind of looking at that themselves, you can go on NPM and look for keyword ember-cli-deploy-plugin-pack and pull up all of those. And you can kind of poke around and see what different companies have open source there. CHARLES: I actually love all three of those answers because it really is for me when you have a constellation of people around a particular problem, it's the surprising solutions that emerge that are some of the most exciting that would have lain hidden otherwise. It would have been kind of buried beneath the source of company A or company B or company C but actually having it all out in the open so that you can inspect it and say, "Wow, where has this solution been all my life?" Something that you have never imagined yourself. LUKE: It's so funny that you mentioned that because that actually is the origin story way back, I'm talking like 2013 probably when we were very early Ember adopters and we were trying to figure out how do we deploy this thing. We're deploying it with our Rails app, like literally deploying the Ruby code and the JavaScript code together which took forever which is a disaster. And I heard through the grapevine, just exactly what you're saying Charles, where the good ideas are kind of hidden inside of a company. I heard through the grapevine that Square had this approach that they were using where they would deploy their JavaScript assets and then deploy their index HTML file, the contents of that file, into a database, it's Redis in their case, and serve then it out of there. And it empowered all of these interesting situations of like having multiple versions, being able to preview the release, et cetera. And so we then set out to copy that idea because there was nothing open source. So we had to create it ourselves which we did in Ruby which we made it inaccessible to many JavaScript shops in the first place. Then the evolution of that kind of over time and of Mattia and Aaron and Mike and the rest of the community kind of talking together has now moved this into the open source sphere where these ideas are more accessible and we've created an ecosystem encouraging these ideas to stay out in the open. It's so true that there's just gems of ideas that have been created by really brilliant engineers inside of companies that could be benefiting so many people, they just haven't seen the light of day yet. CHARLES: Yeah, that leads me to my next question. I would say most of the ideas that we've been talking about today really, except for the build part, how Ember specific are they? Obviously, the ember-cli is a great resource and has a lot of great opinions for actually building the JavaScript assets themselves. But the second two phases of the pipeline really can vary freely, if I understand correctly. And so, have you all ever thought about trying to maybe kind of abstract these processes and these plugins so that these same ideas don't remain not just inside of a company but inside a community that spans a set of companies so that it's available for a wider audience? How integrated is it with Ember and what kind of effort would that be? LUKE: That's a great question. Aaron or Mattia, one of you guys wanna talk a little bit about the history here? MATTIA: Yeah, sure. We've been thinking about this as well. In the past, a guy on the ember-cli-deploy team, Pepin, has actually started this effort and it kind of prototyped this very idea of separating the ember-cli-deploy part from Ember CLI itself and make it a bit more generic. And he started a project called Deploy JS which I can give you a link for the show notes later. I don't think that the project is currently maintained but definitely the start of the effort is there. And the funny thing is that it was surprisingly easy. I think that we didn't get there mostly because we just all use Ember at work. As you know, open source is mostly motivated by the needs that an individual or a group of people have. But if any of the listeners were very interested in this, I think they should definitely get in touch and we will be happy to talk to them and see what can be done here. AARON: And also if you look, there's actually a plugin called ember-cli-deploy-create-react-app and there's also ember-cli-build-view. So it can and is being used to deploy non-Ember apps which I think is super interesting because the only real Ember part of it is just using the CLI to discover the addons and plugins. And from then on, it's really out of the hands of Ember. But it sort of leads into a little bit, Luke mentioned this concept of immutable web apps. And I've been thinking a lot about this lately because a deployment strategy that ember-cli-deploy use as an example a lot and it's kind of become [inaudible] ember-cli-deploy in ways, the lightning approach which is this whole idea of splitting or putting your assets in CDN and your index HTML separately maybe in Redis and serving that. I've been trying to work out how I can talk about this to the wider JavaScript community in a non-Ember way and knowing full well that the concept of lightning deployment means nothing to anyone outside of Ember. Just by chance, I was just talking to some people and this terminology of immutable deployments kind of rose. I started searching around and I come across a website called ImmutableWebApps.org which was just scarily the same as what we've been talking about for the last three or four years with ember-cli-deploy. And a way to boil down at a framework-agnostic level, what are the key points that you need to consider when building a JavaScript web app to make it immutable. And it was just really amazing seeing it. This website was put up 3 weeks before I did my Google search coincidentally. And it's basically word for word what we have been talking about the last three or four years, So, someone else in the other side of the world's been coming up with the same ideas in their company like you were talking about earlier and we've reached out to him. I guess that, to me, is sort of the way forward that I want to sort of pursue to try and get these ideas out in a framework-agnostic way to the rest of community and say, "Hey, we thought about deployment in this way. Have you thought about building your app in this way to give you these sorts of capabilities?" CHARLES: I think the wider community could definitely benefit from that because most of the blog posts and talks I've seen that concern themselves with deployment of single page applications, it's still much more of the tutorial phase. Like, "This is how I achieve getting this deployment strategy." Not, "This is how I repeatedly encode it as a program," and leverage it that way. And so, definitely getting that message out to a wider audience, I think it's a -- what's the word? It's an underserved market. LUKE: Yeah. I really like this idea also. I think about this ImmutableWebApps.org, if you look at it. It's sort of a manifesto with conceptual description of what are the qualities that your app has to have to qualify as an immutable web app which I think is kind of a funny idea but one that people can start to get their heads around and compare that description to their own apps and say how do I hit this or fall short. And it reminds me a lot of kind of the idea of Twelve-Factor App which is an idea that I think came out of Heroku originally. And it's an idea of a backend app that is portable to be able to easily move across different hosts and easily be scalable to different instances of [inaudible] if your app obeys all of these things then it's going to do well under those circumstances, that will satisfy those needs. So, I think it's a great way of thinking and probably maybe even a better entree into the conversation with the wider community than a library, this is certainly a library called ember-cli-deploy. CHARLES: This is a fantastic discussion. It's definitely reminded me of some of the best practices that I haven't thought about in a long time and definitely opened my eyes to some new ones and some new developments. So often, we can be focused on how our apps work internally, like how the JavaScript code works that we can just kind of -- what's the saying -- lose sight of the forest through the trees or I can't remember. It's like too busy looking down the end of your nose to see past your face. I've probably mangled both of those adages, but maybe 60% of two mangled adages is at least equal to one. This is something that we need to be thinking about more, that everybody needs to be thinking about more. This is actually a very exciting, very useful problem space and I'm just really grateful that you guys came on to talk to us about it. So, thank you, Mattia. Thank you, Luke. Thank you, Aaron. MATTIA: Thank you so much. It was a great time. AARON: It was a pleasure. Thanks for having us. LUKE: Thanks so much. CHARLES: Thank you for listening. If you or someone you know has something to say about building user interfaces that simply must be heard, please get in touch with us. We can be found on Twitter at @TheFrontside or over just plain old email at contact@frontside.io. Thanks and see you next time.

Sponsors Sentry use code “devchat” for 2 months free on Sentry small plan TripleByte offers a $1000 signing bonus Panel Dave Kimura Eric Berry Charles Wood Joined by special guest: Jesus Castello Episode Summary In this episode, Jesus Castello, a ruby developer who has been programming since he was 10 years old. He has been a Ruby Developer for 7 years. He teaches Ruby and has a Youtube channel and website. — discusses with the panel his post about Environmental Variables. Jesus teaches what an environmental variable is, and then together Jesus and the panel discuss the uses of environmental variables. One specific topic they go into detail on is credentials and the master key. They also ask him questions about his career teaching Ruby to those on the web. Links Ruby Guides - Jesus Castello Jesus Castello Twitter Ruby Guides Youtube - Jesus Castello The Twelve Factor App Jesus Castello Facebook Heroku AWS - Amazon nginx Apache bkeepers/dotenv - GitHub Enivronmental Variable in Ruby laserlemon/figaro GitHub Removing sensitive data from a repository - GitHub Codefund dry-configurable https://12factor.net/config yuki24/did_you_mean GitHub Picks Dave Kimura: Nobilechairs Epic Satechi Clamp Hub Andrew Mason: EugeneMayer/ docker-sync Jesus Castello: Brakeman 4.4.0 Released acts_as_list GitHub awesome-print/awesome_print GitHub Ruby Deep Dive Eric Berry: CODEFUND Jobs Charles Wood: Canon EOS M6 (Black) EF-M 15-45mm f/3.5-6.3 IS STM Lens Kit Rode VideoMic GO Lightweight On-Camera Microphone with Integrated Rycote Shockmount Skyward by Brandon Sanderson

Sponsors Sentry use code “devchat” for 2 months free on Sentry small plan TripleByte offers a $1000 signing bonus Panel Dave Kimura Eric Berry Charles Wood Joined by special guest: Jesus Castello Episode Summary In this episode, Jesus Castello, a ruby developer who has been programming since he was 10 years old. He has been a Ruby Developer for 7 years. He teaches Ruby and has a Youtube channel and website. — discusses with the panel his post about Environmental Variables. Jesus teaches what an environmental variable is, and then together Jesus and the panel discuss the uses of environmental variables. One specific topic they go into detail on is credentials and the master key. They also ask him questions about his career teaching Ruby to those on the web. Links Ruby Guides - Jesus Castello Jesus Castello Twitter Ruby Guides Youtube - Jesus Castello The Twelve Factor App Jesus Castello Facebook Heroku AWS - Amazon nginx Apache bkeepers/dotenv - GitHub Enivronmental Variable in Ruby laserlemon/figaro GitHub Removing sensitive data from a repository - GitHub Codefund dry-configurable https://12factor.net/config yuki24/did_you_mean GitHub Picks Dave Kimura: Nobilechairs Epic Satechi Clamp Hub Andrew Mason: EugeneMayer/ docker-sync Jesus Castello: Brakeman 4.4.0 Released acts_as_list GitHub awesome-print/awesome_print GitHub Ruby Deep Dive Eric Berry: CODEFUND Jobs Charles Wood: Canon EOS M6 (Black) EF-M 15-45mm f/3.5-6.3 IS STM Lens Kit Rode VideoMic GO Lightweight On-Camera Microphone with Integrated Rycote Shockmount Skyward by Brandon Sanderson

songmuさん、t_wadaさん、katzchangと監視、Observability、Envoy、Twelve-Factor App、SimpleとEasy、Readability、キーバインドなどについて話しました。 songmu on Twitter: “#ajitofm の治安が良いの許せん。 @t_wada さんとめちゃくちゃになりてぇ” O’Reilly Japan - 入門 監視 書評「入門 監視」 - アプリケーションエンジニアにこそおすすめの監視入門本 - すずけんメモ ajitofm 13: Test Driven Development songmu on Twitter: “「俺自身が @t_wada になることだ」と言う社内エントリを書いた” Mackerel Meetup #12で異常検知機能について発表しました - yasuhisa’s blog Distributed Systems Tracing with Zipkin (2012) Observability at Twitter: technical overview, part I クラウドネイティブアプリケーションの観測可能性と監視 Monitoring and Observability – Cindy Sridharan – Medium O’Reilly Japan - 進化的アーキテクチャ ajitofm 29: Chiki Chiki Monitoring Envoy Proxy - Home Service Mesh and Cookpad - クックパッド開発者ブログ The Twelve-Factor App （日本語訳） heroku/12factor The Big Kickoff | Heroku (2007) ビジネスチャットツール | Typetalk（タイプトーク） Kazuho@Cybozu Labs: 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について) (2010) Home - Test Anything Protocol Songmu/horenso: Command wrapper for reporting the result. It is useful for cron jobs. mkr wrapでcronなどのバッチジョブを監視する - Mackerel ヘルプ shell - What does “–” (double-dash) mean? (also known as “bare double dash”) - Unix & Linux Stack Exchange LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ | Nicole Forsgren Ph.D., Jez Humble, Gene Kim, 武舎広幸, 武舎るみ | 工学 | Kindleストア | Amazon The DevOps　逆転だ！究極の継続的デリバリー | ジーン キム, ケビン ベア, ジョージ スパッフォード, 長尾 高弘, 榊原 彰 | コンピュータ・IT | Kindleストア | Amazon 東京トイボックス 新装版 1 | うめ | 青年マンガ | Kindleストア | Amazon テスト駆動開発 | ＫｅｎｔＢｅｃｋ, 和田卓人 | 工学 | Kindleストア | Amazon サーバサイドからクライアントサイドのJavaScriptを呼び出す際のベストプラクティス - kazuhoのメモ置き場 SimpleとEasyは違う / Simple is not Easy - Speaker Deck Simplicity is Complicated (2015) vimが生成する元ネタ dotfiles/go.snippets at master · suzuken/dotfiles 本の虫: MITがSICPを教えなくなった理由 IdeaVim - Plugins | JetBrains PhpStorm45分集中超絶技巧 #phpconsen #phpconsen_b - Speaker Deck Upsource: Code Review, Project Analytics, and Team Collaboration by JetBrains みんなのGo言語 現場で使える実践テクニック：書籍案内｜技術評論社 Mackerel Meetup #13 Tokyo #mackerelio - connpass SeleniumConf Tokyo 2019 - SeleniumConf Tokyo 2019 DevOps Days Tokyo 2019 フィードバックもお待ちしております！ https://ajito.fm/form/ または Twitter: #ajitofm までどうぞ。

Sponsors Sentry use code “devchat” for 2 months free on Sentry small plan TripleByte offers a $1000 signing bonus Panel Dave Kimura Eric Berry Charles Wood Joined by special guest: Jesus Castello Episode Summary In this episode, Jesus Castello, a ruby developer who has been programming since he was 10 years old. He has been a Ruby Developer for 7 years. He teaches Ruby and has a Youtube channel and website. — discusses with the panel his post about Environmental Variables. Jesus teaches what an environmental variable is, and then together Jesus and the panel discuss the uses of environmental variables. One specific topic they go into detail on is credentials and the master key. They also ask him questions about his career teaching Ruby to those on the web. Links Ruby Guides - Jesus Castello Jesus Castello Twitter Ruby Guides Youtube - Jesus Castello The Twelve Factor App Jesus Castello Facebook Heroku AWS - Amazon nginx Apache bkeepers/dotenv - GitHub Enivronmental Variable in Ruby laserlemon/figaro GitHub Removing sensitive data from a repository - GitHub Codefund dry-configurable https://12factor.net/config yuki24/did_you_mean GitHub Picks Dave Kimura: Nobilechairs Epic Satechi Clamp Hub Andrew Mason: EugeneMayer/ docker-sync Jesus Castello: Brakeman 4.4.0 Released acts_as_list GitHub awesome-print/awesome_print GitHub Ruby Deep Dive Eric Berry: CODEFUND Jobs Charles Wood: Canon EOS M6 (Black) EF-M 15-45mm f/3.5-6.3 IS STM Lens Kit Rode VideoMic GO Lightweight On-Camera Microphone with Integrated Rycote Shockmount Skyward by Brandon Sanderson

stdout.fm 13번째 로그에서는 Read the Docs, Write the Docs, 도커를 사용하는 이유에 대해서 이야기를 나눴습니다. 참가자: @seapy, @raccoonyy, @nacyo_t Home | Read the Docs Read the Docs 2018 Stats — Read the Docs Blog sphinx-doc/sphinx: Main repository for the Sphinx documentation builder reStructuredText Ruby-Doc.org: Documenting the Ruby Language realpython/python-guide: Python best practices guidebook, written for humans. Getting Started with Sphinx — Read the Docs 2.7 documentation ? Welcome to phpMyAdmin’s documentation! — phpMyAdmin 5.0.0-dev documentation The Hitchhiker’s Guide to Python! — The Hitchhiker’s Guide to Python Requests: HTTP for Humans™ — Requests 2.21.0 documentation Welcome to our community! — Write the Docs Write the Docs 2018 Stats — Write the Docs 테크니컬 라이팅 컨퍼런스: Write the Docs Prague 2018 방문기 - LINE ENGINEERING I want to run a Write the Docs conference, now what? — Write the Docs 파이콘 APAC 2016 - Write the Docs Seoul Meetup #1 왜 굳이 도커(컨테이너)를 써야 하나요? - 컨테이너를 사용해야 하는 이유 | 44bits.io Docker (Compose) 활용법 - 개발 환경 구성하기 Docker 1.3: signed images, process injection, security options, Mac shared directories - Docker Blog DEVIEW 2014 - Docker로 보는 클라우드 서버 운영의 미래 DEVIEW 2013 - 이렇게 배포해야 할까? - Lightweight Linux Container Docker 를 활용하여 어플리케이션 배포하기 Production-Grade Container Orchestration - Kubernetes AWS Fargate – 서버 또는 클러스터를 관리할 필요 없이 컨테이너를 실행 Cloud Application Platform | Heroku The Twelve-Factor App Kubernetes가 가져온 분산 시스템의 위협과의 싸움(Wantedly 사례, 일본어) - Speaker Deck Netlify: All-in-one platform for automating modern web projects. vaidik/sherlock: Easy distributed locks for Python with a choice of backends. whining - Ruby evolution is taking TOO long : ruby Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」 － Publickey Feature #6284: Add composition for procs - Ruby trunk - Ruby Issue Tracking System Yukihiro Matsumoto on Twitter: “20+ years ago, …” Younggun Kim on Twitter: “이유가 무엇이든 …” Publickey on Twitter: “ありがとうございます。…” Ruby is dead | A totally legit site based on science Is Ruby Dead? Using Ruby in 2019 - Jason Charnes Heartbleed Bug Spyware Disguises as Android Applications on Google Play - TrendLabs Security Intelligence Blog

Si quieres ver el vídeo con slides: https://youtu.be/YN4imZmyRxE Twelve-Factor app es una metodología de desarrollo de aplicaciones y servicios web. Su objetivo es homogeneizar los procesos de diseño, implementación y despliegue de forma que interactúen correctamente con las nuevas soluciones disponibles basadas en contenedores y clusters autogestionados (Heroku, OpenShift…). Adicionalmente, genera una serie de beneficios inmediatos muy valiosos a nivel de DevOps. Aplicar la metodología “Twelve-Factor app” a Python es a veces es complicado y controvertido. En esta charla discutiremos los desafíos que esta forma de trabajar presenta. La PyConES es una conferencia de tres días de duración en la que se dan cita profesionales y entusiastas del lenguaje de programación Python que difunden su experiencia en varias sesiones de charlas técnicas. Por su naturaleza, la audiencia de la PyConES procede no sólo de sectores tecnológicos como desarrollo web, Business Intelligence o desarrollo de juegos sino también del mundo académico, siendo utilizado por multitud de profesores e investigadores.

Panel: Charles Max Wood Eric Berry Mark Erikson Special Guests: Julian Fahrer In this episode of Elixir Mix, the panel talks to Julian Fahrer about Docker. Docker is a container platform, which you can imagine as a set of tools, services, and practices that help you to develop, ship, and run your applications using software container technology. They talk about the applicability for developers for using Docker, the two different ways people use Docker, and how he usually uses Docker. They also touch on the main idea behind containers, the basics of Docker, and more! In particular, we dive pretty deep on: What is Docker? Containers are very lightweight Containers VS virtual machines How are people using Docker with Erlang and/or Elixir? What’s the applicability for using Docker? Ability to set up complex systems Docker works out of the box with Windows, Mac, and Linux 2 different ways people use Docker How do you usually use Docker? Working with Discourse Discourse uses Docker exclusively CodeFund Are you saying that the projects are headed more towards open source using Docker? Using Docker to have a front and backend separated experience Phoenix Main idea behind containers Running things in isolation John Papa Demonstration The value of deploying a release if you’re doing a Docker container The basics of Docker learndocker.online And much, much more! Links: Docker Erlang Elixir Discourse CodeFund Phoenix John Papa Demonstration learndocker.online Prometheus Twelve Factor App codetales.io @jufahr Julian GitHub Sponsors: Digital Ocean Picks: Charles Take time to code for fun Get away devchat.tv/elixir-docker Eric Cross Stitching Mark Dockerfile – his Gist Julian CNCF Landscape IndieHackers.com The UltraMind Solution by Mark Hyman

Panel: Charles Max Wood Eric Berry Mark Erikson Special Guests: Julian Fahrer In this episode of Elixir Mix, the panel talks to Julian Fahrer about Docker. Docker is a container platform, which you can imagine as a set of tools, services, and practices that help you to develop, ship, and run your applications using software container technology. They talk about the applicability for developers for using Docker, the two different ways people use Docker, and how he usually uses Docker. They also touch on the main idea behind containers, the basics of Docker, and more! In particular, we dive pretty deep on: What is Docker? Containers are very lightweight Containers VS virtual machines How are people using Docker with Erlang and/or Elixir? What’s the applicability for using Docker? Ability to set up complex systems Docker works out of the box with Windows, Mac, and Linux 2 different ways people use Docker How do you usually use Docker? Working with Discourse Discourse uses Docker exclusively CodeFund Are you saying that the projects are headed more towards open source using Docker? Using Docker to have a front and backend separated experience Phoenix Main idea behind containers Running things in isolation John Papa Demonstration The value of deploying a release if you’re doing a Docker container The basics of Docker learndocker.online And much, much more! Links: Docker Erlang Elixir Discourse CodeFund Phoenix John Papa Demonstration learndocker.online Prometheus Twelve Factor App codetales.io @jufahr Julian GitHub Sponsors: Digital Ocean Picks: Charles Take time to code for fun Get away devchat.tv/elixir-docker Eric Cross Stitching Mark Dockerfile – his Gist Julian CNCF Landscape IndieHackers.com The UltraMind Solution by Mark Hyman

Part of what defines an application as "cloud native" is an application and management style described by "the 12 factors." While these seem simple at first, each of them just the top of the iceberg of recommendations. Coté plumbs the depths with Nate Schutta to see what's under the waterline. They also discuss where state is in this stateless model and how it's managed. Full show notes: http://pivotal.io/podcast

Part of what defines an application as "cloud native" is an application and management style described by "the 12 factors." While these seem simple at first, each of them just the top of the iceberg of recommendations. Coté plumbs the depths with Nate Schutta to see what's under the waterline. They also discuss where state is in this stateless model and how it's managed. Full show notes: http://pivotal.io/podcast

Part of what defines an application as "cloud native" is an application and management style described by "the 12 factors." While these seem simple at first, each of them just the top of the iceberg of recommendations. Coté plumbs the depths with Nate Schutta to see what's under the waterline. They also discuss where state is in this stateless model and how it's managed. Full show notes: http://pivotal.io/podcast

Part of what defines an application as "cloud native" is an application and management style described by "the 12 factors." While these seem simple at first, each of them just the top of the iceberg of recommendations. Coté plumbs the depths with Nate Schutta to see what's under the waterline. They also discuss where state is in this stateless model and how it's managed. Full show notes: http://pivotal.io/podcast

Part of what defines an application as "cloud native" is an application and management style described by "the 12 factors." While these seem simple at first, each of them just the top of the iceberg of recommendations. Coté plumbs the depths with Nate Schutta to see what's under the waterline. They also discuss where state is in this stateless model and how it's managed. Full show notes: http://pivotal.io/podcast

Nachdem Christian mich in der letzten Folge fragte, was eigentlich Spring ist, ist es heute höchste Zeit, sich mal den Thema Spring und Spring Boot anzunähern. Der perfekte Gast hierfür ist Johannes Edmeier (twitter.com/joshiste), der schon seit einigen Jahren in der Community aktiv ist und u.a. den Spring Boot Admin betreut. Johannes erklärt mir, wie sich JavaEE und Spring voneinander abgrenzen und warum es sich lohnen kann, hier auf Spring zu setzen. Spring ist open source und erlaubt Euch aktiv an der Entwicklung teilzunehmen (github.com/spring-projects). In vielen Fällen kann es sich lohnen, hier noch etwas weiter zu gehen und Spring Boot einzusetzen. Gerade, wenn man schnell loslegen möchte und wenig Aufwand in die Konfiguration investieren möchte. Das Tolle an Spring Boot ist, dass es gerade den Einstieg enorm vereinfacht: ihr könnt unter start.spring.io Euer Projekt einfach konfigurieren und diese dann auch direkt starten. Johannes nutzt dies auch gerne mal für kleine Projekte. Richtig ins Schwärmen kommt Johannes beim Thema Dependencies: Hier kann man sich bei Spring Boot darauf verlassen, dass alles gut zusammen funktioniert. Gerade für den Einstieg natürlich ein großer Vorteil aber auch für erfahrene Spring Entwickler ein klarer Vorteil. Eine Alternative aus dem Java Ökosystem zu Spring Boot ist übrigens Dropwizard (dropwizard.io) bei dem sich das Spring Boot Team auch ein paar Dinge abgeguckt hat. Die von Johannes erwähnte URL guides.spring.io gibt es nicht, richtig ist hier spring.io/guides. Dort findet ihr dann zahlreiche Guides, die Euch den Einstieg in Spring und Spring Boot vereinfachen. Die Seite zur Twelve Factor App findet ihr unter 12factor.net. Wir sprechen noch über das Zusammenspiel mit den unterschiedlichen JVM Sprachen wie Scala, Groovy oder auch Kotlin: Hier kann man bei Spring aus dem vollen schöpfen, auch wenn es hier und da vielleicht nicht perfekt zueinander passt. Wenn ihr Groovy einsetzt, braucht es auch nicht mehr als einen Tweet für die erste Anwendung. Beim Gespräch über Microservices offenbart sich dann, dass ich wohl während des Studiums etwas zuviel World of Warcraft gespielt habe: Ich meinte natürlich Zuul von Netflix und nicht Gruul. Natürlich frage ich Johannes auch ein paar Dinge zum Spring Boot Admin (github.com/codecentric/spring-boot-admin) und erfahre auch ein paar Dinge zu dessen Geschichte. Spring Boot Admin nutzt die Actuator Endpoints von Spring Boot Anwendungen und stellt eine UI für diese bereit. So lassen sich auch mehrere Anwendungen bspw. in einem Microservice Umfeld, bequem überwachen. Zudem bietet es einige Konfigurationsmöglichkeiten. Wenn ihr Spring Boot einsetzt und ein Monitoring Tool benötigt, lohnt ein Blick auf den Spring Boot Admin. PS: Wir haben heute ein paar Störgeräuche dabei, die mit dem Mikro zusammenhängen. Das wird in den nächsten Folgen wieder besser. Wenn ihr etwas ergänzen wollt oder eine Frage habt könnt ihr dies über diesen Issue bei Github tun.

Join Jess, Todd, and Chris as they discuss "The Twelve-Factor App": a set of patterns and practices that are crucial to building modern, scalable, and "cloud-ready" applications.

Naoya Ito さんをゲストに迎えて、サーバレスアーキテクチャ、Lambda, MBaaS, LINE などについて話しました。 Show Notes ServerlessConf Tokyo Serverless Architectures Can we please rename #serverless to #faas? serverless-conf-agenda/agenda.md 紙面ビューアーを支える サーバーレスアーキテクチャ AWS Lambda - Serverless Compute The Serverless Application Framework AWS Lambda Functions in Go The Twelve-Factor App Solving anything in VCL VCLとAMP〜Frontend Meetup Tokyo Beacon termination at the edge | Fastly Introducing the Realm Mobile Platform Plagger で更新情報を LINE で受け取る plugin plagger docker 化 LINE Notify 1人CTO Night 開発組織マネジメントのコツ

We've seen a goodly spate of news in the container space recently which we cover in the episode. In the second half, we talk with Kevin Hoffman about the .NET world, Steel Toe, and his book, Beyond the Twelve-Factor App. A recent survey from the Cloud Foundry Foundation is widening the framing around container management, adding in the use of Platform-as-a-Service into the usual container orchestration mix. The survey also shows some interesting results around adoption, e.g., managing containers in production ends up being more difficult than people predict during evaluations. Also since our last episode, DockerCon brought a bevy of announcements in the container ecosystem which we cover briefly. And highly relevant to our guest, Kevin Hoffman, .NET Core 1.0 was officially released, as open source. In the second half we talk about the recent history of .NET and how it's being used to create microservices. We also talk about the three extra "factors" Kevin's book adds to the 12 factor app and typical experiences when migrating to 12 factor apps. Full show notes: http://pivotal.io/podcast Feeds, archives, etc: https://soundcloud.com/pivotalconversations

We've seen a goodly spate of news in the container space recently which we cover in the episode. In the second half, we talk with Kevin Hoffman about the .NET world, Steel Toe, and his book, Beyond the Twelve-Factor App. A recent survey from the Cloud Foundry Foundation is widening the framing around container management, adding in the use of Platform-as-a-Service into the usual container orchestration mix. The survey also shows some interesting results around adoption, e.g., managing containers in production ends up being more difficult than people predict during evaluations. Also since our last episode, DockerCon brought a bevy of announcements in the container ecosystem which we cover briefly. And highly relevant to our guest, Kevin Hoffman, .NET Core 1.0 was officially released, as open source. In the second half we talk about the recent history of .NET and how it's being used to create microservices. We also talk about the three extra "factors" Kevin's book adds to the 12 factor app and typical experiences when migrating to 12 factor apps. Full show notes: http://pivotal.io/podcast Feeds, archives, etc: https://soundcloud.com/pivotalconversations

We've seen a goodly spate of news in the container space recently which we cover in the episode. In the second half, we talk with Kevin Hoffman about the .NET world, Steel Toe, and his book, Beyond the Twelve-Factor App. A recent survey from the Cloud Foundry Foundation is widening the framing around container management, adding in the use of Platform-as-a-Service into the usual container orchestration mix. The survey also shows some interesting results around adoption, e.g., managing containers in production ends up being more difficult than people predict during evaluations. Also since our last episode, DockerCon brought a bevy of announcements in the container ecosystem which we cover briefly. And highly relevant to our guest, Kevin Hoffman, .NET Core 1.0 was officially released, as open source. In the second half we talk about the recent history of .NET and how it's being used to create microservices. We also talk about the three extra "factors" Kevin's book adds to the 12 factor app and typical experiences when migrating to 12 factor apps. Full show notes: http://pivotal.io/podcast Feeds, archives, etc: https://soundcloud.com/pivotalconversations

We've seen a goodly spate of news in the container space recently which we cover in the episode. In the second half, we talk with Kevin Hoffman about the .NET world, Steel Toe, and his book, Beyond the Twelve-Factor App. A recent survey from the Cloud Foundry Foundation is widening the framing around container management, adding in the use of Platform-as-a-Service into the usual container orchestration mix. The survey also shows some interesting results around adoption, e.g., managing containers in production ends up being more difficult than people predict during evaluations. Also since our last episode, DockerCon brought a bevy of announcements in the container ecosystem which we cover briefly. And highly relevant to our guest, Kevin Hoffman, .NET Core 1.0 was officially released, as open source. In the second half we talk about the recent history of .NET and how it's being used to create microservices. We also talk about the three extra "factors" Kevin's book adds to the 12 factor app and typical experiences when migrating to 12 factor apps. Full show notes: http://pivotal.io/podcast Feeds, archives, etc: https://soundcloud.com/pivotalconversations

We've seen a goodly spate of news in the container space recently which we cover in the episode. In the second half, we talk with Kevin Hoffman about the .NET world, Steel Toe, and his book, Beyond the Twelve-Factor App. A recent survey from the Cloud Foundry Foundation is widening the framing around container management, adding in the use of Platform-as-a-Service into the usual container orchestration mix. The survey also shows some interesting results around adoption, e.g., managing containers in production ends up being more difficult than people predict during evaluations. Also since our last episode, DockerCon brought a bevy of announcements in the container ecosystem which we cover briefly. And highly relevant to our guest, Kevin Hoffman, .NET Core 1.0 was officially released, as open source. In the second half we talk about the recent history of .NET and how it's being used to create microservices. We also talk about the three extra "factors" Kevin's book adds to the 12 factor app and typical experiences when migrating to 12 factor apps. Full show notes: http://pivotal.io/podcast Feeds, archives, etc: https://soundcloud.com/pivotalconversations

Check out Freelance Remote Conf!   02:48 - Andrew Connell Introduction Twitter GitHub Blog 03:16 - Building for an Office Platform SharePoint Office 365 Deep Dive into Office 365 Development on non-Microsoft Stack 08:12 - How do you host Angular code? 09:56 - Why Angular in this situation? Training Modules for Using Angular to Talk to Office 365 as a Standalone App, Building Office Add-ins for Outlook & Excel 14:41 - SharePoint Add-ins Getting Started Building Office Add-ins Training Modules for Doing ^ 27:32 - Adoption, Uptake 29:29 - Office UI Fabric Angular 1.x Directives for Office UI Fabric 33:03 - What’s the plan for Angular 2? The Binding Syntax Picks Shannara (John) [egghead.io] Getting Started with Redux (Lukas) View-Master Virtual Reality Starter Pack (Lukas) Dan Abramov’s work on React (Ward) JavaScript Jabber Episode 179: redux and React with Dan Abramov (Chuck) JavaScript Jabber Episode 181: The Evolution of Flux Libraries with Andrew Clark and Dan Abramov (Chuck) Star Wars (Joe) Sphero BB-8 (Joe) Build-A-Bear Chewbacca (Joe) The Star Wars: The Force Awakens Soundtrack (Joe) LambdaConf (Joe) MyFitnessPal (Chuck) Allrecipes (Chuck) A gym membership (Chuck) The Nike+ Running App (Chuck) Run 10k (Chuck) Aftershokz Blues 2 (Chuck) The Twelve Factor App (Andrew) ngOfficeUIFabric.com (Andrew) The Innovators (How a Group of Hackers Geniuses and Geeks Created the Digital Revolution) by Walter Isaacson (Andrew)  

Check out Freelance Remote Conf!   02:48 - Andrew Connell Introduction Twitter GitHub Blog 03:16 - Building for an Office Platform SharePoint Office 365 Deep Dive into Office 365 Development on non-Microsoft Stack 08:12 - How do you host Angular code? 09:56 - Why Angular in this situation? Training Modules for Using Angular to Talk to Office 365 as a Standalone App, Building Office Add-ins for Outlook & Excel 14:41 - SharePoint Add-ins Getting Started Building Office Add-ins Training Modules for Doing ^ 27:32 - Adoption, Uptake 29:29 - Office UI Fabric Angular 1.x Directives for Office UI Fabric 33:03 - What’s the plan for Angular 2? The Binding Syntax Picks Shannara (John) [egghead.io] Getting Started with Redux (Lukas) View-Master Virtual Reality Starter Pack (Lukas) Dan Abramov’s work on React (Ward) JavaScript Jabber Episode 179: redux and React with Dan Abramov (Chuck) JavaScript Jabber Episode 181: The Evolution of Flux Libraries with Andrew Clark and Dan Abramov (Chuck) Star Wars (Joe) Sphero BB-8 (Joe) Build-A-Bear Chewbacca (Joe) The Star Wars: The Force Awakens Soundtrack (Joe) LambdaConf (Joe) MyFitnessPal (Chuck) Allrecipes (Chuck) A gym membership (Chuck) The Nike+ Running App (Chuck) Run 10k (Chuck) Aftershokz Blues 2 (Chuck) The Twelve Factor App (Andrew) ngOfficeUIFabric.com (Andrew) The Innovators (How a Group of Hackers Geniuses and Geeks Created the Digital Revolution) by Walter Isaacson (Andrew)  

Check out Freelance Remote Conf!   02:48 - Andrew Connell Introduction Twitter GitHub Blog 03:16 - Building for an Office Platform SharePoint Office 365 Deep Dive into Office 365 Development on non-Microsoft Stack 08:12 - How do you host Angular code? 09:56 - Why Angular in this situation? Training Modules for Using Angular to Talk to Office 365 as a Standalone App, Building Office Add-ins for Outlook & Excel 14:41 - SharePoint Add-ins Getting Started Building Office Add-ins Training Modules for Doing ^ 27:32 - Adoption, Uptake 29:29 - Office UI Fabric Angular 1.x Directives for Office UI Fabric 33:03 - What’s the plan for Angular 2? The Binding Syntax Picks Shannara (John) [egghead.io] Getting Started with Redux (Lukas) View-Master Virtual Reality Starter Pack (Lukas) Dan Abramov’s work on React (Ward) JavaScript Jabber Episode 179: redux and React with Dan Abramov (Chuck) JavaScript Jabber Episode 181: The Evolution of Flux Libraries with Andrew Clark and Dan Abramov (Chuck) Star Wars (Joe) Sphero BB-8 (Joe) Build-A-Bear Chewbacca (Joe) The Star Wars: The Force Awakens Soundtrack (Joe) LambdaConf (Joe) MyFitnessPal (Chuck) Allrecipes (Chuck) A gym membership (Chuck) The Nike+ Running App (Chuck) Run 10k (Chuck) Aftershokz Blues 2 (Chuck) The Twelve Factor App (Andrew) ngOfficeUIFabric.com (Andrew) The Innovators (How a Group of Hackers Geniuses and Geeks Created the Digital Revolution) by Walter Isaacson (Andrew)  

Welcome back to the dramatic conclusion of our discussion on the 12 factor app. This time we're talking dev/prod parity, logs, and admin processes. Oh, and Call of Duty! News […]

Welcome back to the dramatic conclusion of our discussion on the 12 factor app. This time we’re talking dev/prod parity, logs, and admin processes. Oh, and Call of Duty! News Thanks for the reviews! arathustra, lu S, Seb (from London), S Willowood, TheDarkKnight15, FreeAppsHunter Where do transforms go? UI or Middleware? Joe had surgery! Oopsy […]

It's time for more DevOps fun as we continue learning about the Twelve-Factor app. This week we dive into the next three chapters: port binding, concurrency, and disposability.

It's time for more DevOps fun as we continue learning about the Twelve-Factor app. This week we dive into the next three chapters: port binding, concurrency, and disposability.

O Heroku foi um pioneiro em PaaS, oferece desde 2007 uma plataforma de Cloud robusta e fácil de usar. Depois de tantos anos e milhares de clientes, é óbvio que aprenderam muito sobre aplicações web. Esse aprendizado está condensado no Twelve-Factor App, um guia de recomendações/boas práticas no desenvolvimento/operação de …

We're headed back to the Twelve-Factor app territory and this time we're picking up with the next three chapters – backing services, building and releasing and processes.  Jump in to […]

We’re headed back to the Twelve-Factor app territory and this time we’re picking up with the next three chapters – backing services, building and releasing and processes.  Jump in to get the shownotes and listen to the next three pieces of building a manageable and scalable twelve-factor app. Survey News Mark Tinsley – PHP Composer […]

Dipping our toes into the DevOps waters with the Twelve-Factor App. How important is depedency management, and how fired would you be if you accidentally leaked your company's source code? […]

Dipping our toes into the DevOps waters with the Twelve-Factor App. How important is depedency management, and how fired would you be if you accidentally leaked your company’s source code? News We have a new logo! Allen was right… Soundcloud Thanks for the reviews! GunBlade77 What is the Twelve-Factor App? A methodology for writing applications […]

Today we continue our discussion on The Twelve-Factor App. In this episode, we'll be focusing on dependencies and config, offering tips along the way. Thanks to Harvest, today's sponsor. Go to getharvest.com and try out their time tracking software for 30 days. After your trial use code TEATIME to get 50% off your first month.

Today's episode will be focused around codebase also known as a repository. We'll talk about understanding codebase, implementing techniques and deploying. Special thanks to today's sponsor: Hired. Check out hired.com/developertea for free, no obligation job searching and let employers come to you. If you or someone you know is looking for a job in development or design, get on hired.com/developertea.

Michael Vitz und Stefan Tilkov sprechen in dieser Folge über die Twelve-Factor App, eine Entwicklungsmethode für skalierbare Web-Applikationen in der Cloud. Michael erklärt zunächst, welche Ziele hinter dieser Methode stehen und erläutert dann die 12 Faktoren im Detail. Außerdem diskutieren Stefan und Michael über Vor- und Nachteile der Twelve-Factor App und beleuchten Gemeinsamkeiten und Unterschiede zu Microservices.

Ryo Nakamuraさんをゲストに迎えて、JSON Schema, Rails, Postgres, RSpec, ChatOps, Markdown, 絵文字などについて話しました。 Show Notes Qiita クックパッドとマイクロサービス cookpad/garage JSON Schema and Hyper-Schema r7kamura/jdoc JSON SchemaとAPIテスト - YAPC::Asia 2014 Heroku | JSON Schema for the Heroku Platform API JSON Hyper-Schemaのようなサービスディスクリプションがうまくいかない理由 rails/jbuilder rails-api/active_model_serializers apotonick/roar Upgrading GitHub to Rails 3 with Zero Downtime Continuous Delivery at GitHub // Speaker Deck cookpad/chanko PostgreSQL: Documentation: 9.4: JSON Types miyagawa/mongery Query Documents - MongoDB Manual Query Mongo: MySQL to MongoDB Query Translator Rubyテスティングフレームワークの歴史 Transpec - The RSpec Syntax Converter Autodoc - r7km/s r7kamura/ruboty Ruby製HubotクローンのRubotyをSlackで動かす - Qiita jimmycuadra/lita The Twelve-Factor App Heroku | Introducing Heroku Button Hubot Scripting チャット経由でデプロイする - Qiita Markdownを拡張して独自記法をつくる - Qiita increments/qiita-markdown html-pipeline: Chainable Content Filters Open sourcing Twitter emoji for everyone | Twitter Blogs Six Apart絵文字 特集 : 絵文字が開いてしまった「パンドラの箱」 Unicode proposes a way to let an emoji black man and white woman hold hands Advent Calendar - Qiita