Podcasts about stateful

In this enlightening episode, we sit down with Adam Christian, the visionary CEO and Co-Founder of Stateful, Inc., a groundbreaking company at the forefront of simplifying cloud infrastructure through innovative self-service experiences. With a rich background in software engineering and a passion for developer tools, Adam shares his insights into the challenges and solutions in the cloud-native and continuous delivery landscapes. Discover how Stateful leverages Runme workflows to transform infra docs into easily manageable cloud resources, reducing platform support burdens and accelerating engineering efforts. Adam delves into his journey from leading engineering teams at notable companies to founding Stateful, highlighting the impact of his work on the developer community and the future of cloud automation. Listeners will gain valuable knowledge about the evolution of cloud services, the importance of user-friendly developer tools, and the vision behind Stateful's creation. This episode is a must-watch for those interested in the intersections of cloud technology, software development, and entrepreneurial innovation. This show is supported by www.matchrelevant.com. A company that helps venture-backed Startups find the best people available in the market, who have the skills, experience, and desire to grow. With over a decade of experience in recruitment across multiple domains, they give people career options to choose from in their career journey.

In this episode, Lois Houston and Nikita Abraham, along with senior OCI instructor Mahendra Mehra, dive into the fundamentals of Kubernetes. They talk about how Kubernetes tackles challenges in deploying and managing microservices, and enhances software performance, flexibility, and availability.   OCI Container Engine for Kubernetes Specialist: https://mylearn.oracle.com/ou/course/oci-container-engine-for-kubernetes-specialist/134971/210836   Oracle University Learning Community: https://education.oracle.com/ou-community   LinkedIn: https://www.linkedin.com/showcase/oracle-university/   X (formerly Twitter): https://twitter.com/Oracle_Edu   Special thanks to Arijit Ghosh, David Wright, Radhika Banka, and the OU Studio Team for helping us create this episode.   --------------------------------------------------------   Episode Transcript:   00:00 Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative podcasts, we'll bring you foundational training on the most popular Oracle technologies. Let's get started! 00:26 Lois: Hello and welcome to another episode of the Oracle University Podcast. I'm Lois Houston, Director of Innovation Programs with Oracle University, and with me is Nikita Abraham, Principal Technical Editor. Nikita: Hi everyone! We've spent the last two episodes getting familiar with containerization and the Oracle Cloud Infrastructure Registry. Today, it's going to be all about Kubernetes. So if you've heard of Kubernetes but you don't know what it is, or you've been playing with Docker and containers and want to know how to take it to the next level, you'll want to stay with us. Lois: That's right, Niki. We'll be chatting with Mahendra Mehra, a senior OCI instructor with Oracle University, about the challenges in containerized applications within a complex business setup and how Kubernetes facilitates container orchestration and improves its effectiveness, resulting in better software performance, flexibility, and availability. 01:20 Nikita: Hi Mahendra. To start, can you tell us when you would use Kubernetes?  Mahendra: While deploying and managing microservices in a distributed environment, you may run into issues such as failures or container crashes. Issues such as scheduling containers to specific machines depending upon the configuration. You also might face issues while upgrading or rolling back the applications which you have containerized. Scaling up or scaling down containers across a set of machines can be troublesome.  01:50 Lois: And this is where Kubernetes helps automate the entire process?  Mahendra: Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services that facilitates both declarative configuration and automation.  You can think of a Kubernetes as you would a conductor for an orchestra. Similar to how a conductor would say how many violins are needed, which one play first, and how loud they should play, Kubernetes would say, how many webserver front-end containers or back-end database containers are needed, what they serve, and how many resources are to be dedicated to each one. 02:27 Nikita: That's so cool! So, how does Kubernetes work?  Mahendra: In Kubernetes, there is a master node, and there are multiple worker nodes. Each worker node can handle multiple pods. Pods are just a bunch of containers clustered together as a working unit. If a worker node goes down, Kubernetes starts new pods on the functioning worker node. 02:47 Lois: So, the benefits of Kubernetes are… Mahendra: Kubernetes can containerize applications of any scale without any downtime. Kubernetes can self-heal containerized applications, making them resilient to unexpected failures.  Kubernetes can autoscale containerized applications as for the workload and ensure optimal utilization of cloud resources. Kubernetes also greatly simplifies the process of deployment operations. With Kubernetes, however complex an operation is, it could be performed reliably by executing a couple of commands at the most. 03:19 Nikita: That's great. Mahendra, can you tell us a bit about the architecture and main components of Kubernetes? Mahendra: The Kubernetes cluster has two main components. One is the control plane, and one is the data plane. The control plane hosts the components used to manage the Kubernetes cluster. And the data plane basically hosts all the worker nodes that can be virtual machines or physical machines. These worker nodes basically host pods which run one or more containers. The containers running within these pods are making use of Docker images, which are managed within the image registry. In case of OCI, it is the container registry. 03:54 Lois: Mahendra, you mentioned nodes and pods. What are nodes? Mahendra: It is the smallest unit of computing hardware within the Kubernetes. Its work is to encapsulate one or more applications as containers. A node is a worker machine that has a container runtime environment within it. 04:10 Lois: And pods? Mahendra: A pod is a basic object of Kubernetes, and it is in charge of encapsulating containers, storage resources, and network IPs. One pod represents one instance of an application within Kubernetes. And these pods are launched in a Kubernetes cluster, which is composed of nodes. This means that a pod runs on a node but can easily be instantiated on another node. 04:32 Nikita: Can you run multiple containers within a pod? Mahendra: A pod can even contain more than one container if these containers are relatively tightly coupled. Pod is usually meant to run one application container inside of it, but you can run multiple containers inside one pod. Usually, it is only the case if you have one main application container and a helper container or some sidecar containers that has to run inside of that pod. Every pod is assigned a unique private IP address, using which the pods can communicate with one another. Pods are meant to be ephemeral, which means they die easily. And if they do, upon re-creation, they are assigned a new private IP address. In fact, Kubernetes can scale a number of these pods to adapt for the incoming traffic, consequently creating or deleting pods on demand. Kubernetes guarantees the availability of pods and replicas specified, but not the liveliness of each individual pod. This means that other pods that need to communicate with this application or component cannot rely on the underlying individual pod's IP address. 05:35 Lois: So, how does Kubernetes manage traffic to this indecisive number of pods with changing IP addresses? Mahendra: This is where another component of Kubernetes called services comes in as a solution. A service gets allocated a virtual IP address and lives until explicitly destroyed. Requests to the services get redirected to the appropriate pods, thus the services of a stable endpoint used for inter-component or application communication. And the best part here is that the lifecycle of service and the pods are not connected. So even if the pod dies, the service and the IP address will stay, so you don't have to change their endpoints anymore. 06:13 Nikita: What types of services can you create with Kubernetes? Mahendra: There are two types of services that you can create. The external service is created to allow external users to connect the containerized applications within the pod. Internal services can also be created that restrict the communication within the cluster. Services can be exposed in different ways by specifying a particular type. 06:33 Nikita: And how do you define these services? Mahendra: There are three types in which you can define services. The first one is the ClusterIP, which is the default service type that exposes services on an internal IP within the cluster. This type makes the service only reachable from within the cluster. You can specify the type of service as NodePort. NodePort basically exposes the service on the same port of each selected node in the cluster using a network address translation and makes the service accessible from the outside of the cluster using the node IP and the NodePort combination. This is basically a superset of ClusterIP. You can also go for a LoadBalancer type, which basically creates an external load balancer in the current cloud. OCI supports LoadBalancer types. It also assigns a fixed external IP to the service. And the LoadBalancer type is a superset of NodePort. 07:25 Lois: There's another component called ingress, right? When do you used that? Mahendra: An ingress is used when we have multiple services on our cluster, and we want the user requests routed to the services based on their pod, and also, if you want to talk to your application with a secure protocol and a domain name. Unlike NodePort or LoadBalancer, ingress is not actually a type of service. Instead, it is an entry point that sits in front of the multiple services within the cluster. It can be defined as a collection of routing rules that govern how external users access services running inside a Kubernetes cluster. Ingress is most useful if you want to expose multiple services under the same IP address, and these services all use the same Layer 7 protocol, typically HTTP. 08:10 Lois: Mahendra, what about deployments in Kubernetes?  Mahendra: A deployment is an object in Kubernetes that lets you manage a set of identical pods. Without a deployment, you will need to create, update, and delete a bunch of pods manually. With the deployment, you declare a single object in a YAML file, and the object is responsible for creating the pods, making sure they stay up-to-date and ensuring there are enough of them running. You can also easily autoscale your applications using a Kubernetes deployment. In a nutshell, the Kubernetes deployment object lets you deploy a replica set of your pods, update the pods and the replica sets. It also allows you to roll back to your previous deployment versions. It helps you scale a deployment. It also lets you pause or continue a deployment. 08:59 Do you want to stay ahead of the curve in the ever-evolving AI landscape? Look no further than our brand-new OCI Generative AI Professional course and certification. For a limited time only, we're offering both the course and certification for free! So, don't miss out on this exclusive opportunity to get certified on Generative AI at no cost. Act fast because this offer is valid only until July 31, 2024. Visit https://education.oracle.com/genai to get started. That's https://education.oracle.com/genai. 09:37 Nikita: Welcome back! We were talking about how useful a Kubernetes deployment is in scaling operations. Mahendra, how do pods communicate with each other?  Mahendra: Pods communicate with each other using a service. For example, my application has a database endpoint. Let's say it's a MySQL service that it uses to communicate with the database. But where do you configure this database URL or endpoints? Usually, you would do it in the application properties file or as some kind of an external environment variable. But usually, it's inside the build image of the application. So for example, if the endpoint of the service or the service name, in this case, changes to something else, you would have to adjust the URL in the application. And this will cause you to rebuild the entire application with a new version, and you will have to push it to the repository. You'll then have to pull that new image into your pod and restart the whole thing. For a small change like database URL, this is a bit tedious. So for that purpose, Kubernetes has a component called ConfigMap. ConfigMap is a Kubernetes object that maintains a key value store that can easily be used by other Kubernetes objects, such as pods, deployments, and services. Thus, you can define a ConfigMap composed of all the specific variables for your environment. In Kubernetes, now you just need to connect your pod to the ConfigMap, and the pod will read all the new changes that you have specified within the ConfigMap, which means you don't have to go on to build a new image every time a configuration changes. 11:07 Lois: So then, I'm just wondering, if we have a ConfigMap to manage all the environment variables and URLs, should we be passing our username and password in the same file? Mahendra: The answer is no. Password or other credentials within a ConfigMap in a plain text format would be insecure, even though it's an external configuration. So for this purpose, Kubernetes has another component called secret. Kubernetes secrets are secure objects which store sensitive data, such as passwords, OAuth tokens, and SSH keys with the encryption within your cluster. Using secrets gives you more flexibility in a pod lifecycle definition and control over how sensitive data is used. It reduces the risk of exposing the data to unauthorized users. 11:50 Nikita: So, you're saying that the secret is just like ConfigMap or is there a difference? Mahendra: Secret is just like ConfigMap, but the difference is that it is used to store secret data credentials, for example, database username and passwords, and it's stored in the base64 encoded format. The kubelet service stores this secret into a temporary file system. 12:11 Lois: Mahendra, how does data storage work within Kubernetes? Mahendra: So let's say we have this database pod that our application uses, and it has some data or generates some data. What happens when the database container or the pod gets restarted? Ideally, the data would be gone, and that's problematic and inconvenient, obviously, because you want your database data or log data to be persisted reliably for long term. To achieve this, Kubernetes has a solution called volumes. A Kubernetes volume basically is a directory that contains data accessible to containers in a given pod within the Kubernetes platform. Volumes provide a plug-in mechanism to connect ephemeral containers with persistent data stores elsewhere. The data within a volume will outlast the containers running within the pod. Containers can shut down and restart because they are ephemeral units. Data remains saved in the volume even if a container crashes because a container crash is not enough to cut off a pod from a node. 13:10 Nikita: Another main component of Kubernetes is a StatefulSet, right? What can you tell us about it?  Mahendra: Stateful applications are applications that store data and keep tracking it. All databases such as MySQL, Oracle, and PostgreSQL are examples of Stateful applications. In a modern web application, we see stateless applications connecting with Stateful application to serve the user request. For example, a Node.js application is a stateless application that receives new data on each request from the user. This application is then connected with a Stateful application, such as MySQL database, to process the data. MySQL stores the data and keeps updating the database on the user's request.  Now, assume you deployed a MySQL database in the Kubernetes cluster and scaled this to another replica, and a frontend application wants to access the MySQL cluster to read and write data. The read request will be forwarded to both these pods. However, the write request will only be forwarded to the first primary pod. And the data will be synchronized with other pods. You can achieve this by using the StatefulSets. Deleting or scaling down a StatefulSet will not delete the volumes associated with the Stateful applications. This gives you your data safety. If you delete the MySQL pod or if the MySQL pod restarts, you can have access to the data in the same volume.  So overall, a StatefulSet is a good fit for those applications that require unique network identifiers; stable persistent storage; ordered, graceful deployment and scaling; as well as ordered, automatic rolling updates. 14:43 Lois: Before we wrap up, I want to ask you about the features of Kubernetes. I'm sure there are countless, but can you tell us the most important ones? Mahendra: Health checks are used to check the container's readiness and liveness status. Readiness probes are intended to let Kubernetes know if the app is ready to serve the traffic.  Networking plays a significant role in container orchestration to isolate independent containers, connect coupled containers, and provide access to containers from the external clients. Service discovery allows containers to discover other containers and establish connections to them. Load balancing is a dedicated service that knows which replicas are running and provides an endpoint that is exposed to the clients. Logging allows us to oversee the application behavior.  The rolling update allows you to update a deployed containerized application with minimal downtime using different update scenarios. The typical way to update such an application is to provide new images for its containers. Containers, in a production environment, can grow from few to many in no time. Kubernetes makes managing multiple containers an easy task. And lastly, resource usage monitoring-- resources such as CPU and RAM must be monitored within the Kubernetes environment. Kubernetes resource usage looks at the amount of resources that are utilized by a container or port within the Kubernetes environment. It is very important to keep an eye on the resource usage of the pods and containers as more usage translates to more cost. 16:18 Nikita: I think we can wind up our episode with that. Thank you, Mahendra, for joining us today. Kubernetes sure can be challenging to work with, but we covered a lot of ground in this episode.  Lois: That's right, Niki! If you want to learn more about the rich features Kubernetes offers, visit mylearn.oracle.com and search for the OCI Container Engine for Kubernetes Specialist course. Remember, all the training is free, so you can dive right in! Join us next week when we'll take a look at the fundamentals of Oracle Cloud Infrastructure Container Engine for Kubernetes. Until then, Lois Houston… Nikita: And Nikita Abraham, signing off! 16:57 That's all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We'd also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.

SF folks: join us at the AI Engineer Foundation's Emergency Hackathon tomorrow and consider the Newton if you'd like to cowork in the heart of the Cerebral Arena.Our community page is up to date as usual!~800,000 developers watched OpenAI Dev Day, ~8,000 of whom listened along live on our ThursdAI x Latent Space, and ~800 of whom got tickets to attend in person:OpenAI's first developer conference easily surpassed most people's lowballed expectations - they simply did everything short of announcing GPT-5, including:* ChatGPT (the consumer facing product)* GPT4 Turbo already in ChatGPT (running faster, with an April 2023 cutoff), all noticed by users weeks before the conference* Model picker eliminated, God Model chooses for you* GPTs - “tailored version of ChatGPT for a specific purpose” - stopping short of “Agents”. With custom instructions, expanded knowledge, and actions, and an intuitive no-code GPT Builder UI (we tried all these on our livestream yesterday and found some issues, but also were able to ship interesting GPTs very quickly) and a GPT store with revenue sharing (an important criticism we focused on in our episode on ChatGPT Plugins)* API (the developer facing product)* APIs for Dall-E 3, GPT4 Vision, Code Interpreter (RIP Advanced Data Analysis), GPT4 Finetuning and (surprise!) Text to Speech* many thought each of these would take much longer to arrive* usable in curl and in playground* BYO Interpreter + Async Agents?* Assistant API: stateful API backing “GPTs” like apps, with support for calling multiple tools in parallel, persistent Threads (storing message history, unlimited context window with some asterisks), and uploading/accessing Files (with a possibly-too-simple RAG algorithm, and expensive pricing)* Whisper 3 announced and open sourced (HuggingFace recap)* Price drops for a bunch of things!* Misc: Custom Models for big spending ($2-3m) customers, Copyright Shield, SatyaThe progress here feels fast, but it is mostly (incredible) last-mile execution on model capabilities that we already knew to exist. On reflection it is important to understand that the one guiding principle of OpenAI, even more than being Open (we address that in part 2 of today's pod), is that slow takeoff of AGI is the best scenario for humanity, and that this is what slow takeoff looks like:When introducing GPTs, Sam was careful to assert that “gradual iterative deployment is the best way to address the safety challenges with AI”:This is why, in fact, GPTs and Assistants are intentionally underpowered, and it is a useful exercise to consider what else OpenAI continues to consider dangerous (for example, many people consider a while(true) loop a core driver of an agent, which GPTs conspicuously lack, though Lilian Weng of OpenAI does not).We convened the crew to deliver the best recap of OpenAI Dev Day in Latent Space pod style, with a 1hr deep dive with the Functions pod crew from 5 months ago, and then another hour with past and future guests live from the venue itself, discussing various elements of how these updates affect their thinking and startups. Enjoy!Show Notes* swyx live thread (see pinned messages in Twitter Space for extra links from community)* Newton AI Coworking Interest Form in the heart of the Cerebral ArenaTimestamps* [00:00:00] Introduction* [00:01:59] Part I: Latent Space Pod Recap* [00:06:16] GPT4 Turbo and Assistant API* [00:13:45] JSON mode* [00:15:39] Plugins vs GPT Actions* [00:16:48] What is a "GPT"?* [00:21:02] Criticism: the God Model* [00:22:48] Criticism: ChatGPT changes* [00:25:59] "GPTs" is a genius marketing move* [00:26:59] RIP Advanced Data Analysis* [00:28:50] GPT Creator as AI Prompt Engineer* [00:31:16] Zapier and Prompt Injection* [00:34:09] Copyright Shield* [00:38:03] Sharable GPTs solve the API distribution issue* [00:39:07] Voice* [00:44:59] Vision* [00:49:48] In person experience* [00:55:11] Part II: Spot Interviews* [00:56:05] Jim Fan (Nvidia - High Level Takeaways)* [01:05:35] Raza Habib (Humanloop) - Foundation Model Ops* [01:13:59] Surya Dantuluri (Stealth) - RIP Plugins* [01:21:20] Reid Robinson (Zapier) - AI Actions for GPTs* [01:31:19] Div Garg (MultiOn) - GPT4V for Agents* [01:37:15] Louis Knight-Webb (Bloop.ai) - AI Code Search* [01:49:21] Shreya Rajpal (Guardrails.ai) - on Hallucinations* [01:59:51] Alex Volkov (Weights & Biases, ThursdAI) - "Keeping AI Open"* [02:10:26] Rahul Sonwalkar (Julius AI) - Advice for FoundersTranscript[00:00:00] Introduction[00:00:00] swyx: Hey everyone, this is Swyx coming at you live from the Newton, which is in the heart of the Cerebral Arena. It is a new AI co working space that I and a couple of friends are working out of. There are hot desks available if you're interested, just check the show notes. But otherwise, obviously, it's been 24 hours since the opening of Dev Day, a lot of hot reactions and longstanding tradition, one of the longest traditions we've had.[00:00:29] And the latent space pod is to convene emergency sessions and record the live thoughts of developers and founders going through and processing in real time. I think a lot of the roles of podcasts isn't as perfect information delivery channels, but really as an audio and oral history of what's going on as it happens, while it happens.[00:00:49] So this one's a little unusual. Previously, we only just gathered on Twitter Spaces, and then just had a bunch of people. The last one was the Code Interpreter one with 22, 000 people showed up. But this one is a little bit more complicated because there's an in person element and then a online element.[00:01:06] So this is a two part episode. The first part is a recorded session between our latent space people and Simon Willison and Alex Volkoff from the Thursday iPod, just kind of recapping the day. But then also, as the second hour, I managed to get a bunch of interviews with previous guests on the pod who we're still friends with and some new people that we haven't yet had on the pod.[00:01:28] But I wanted to just get their quick reactions because most of you have known and loved Jim Fan and Div Garg and a bunch of other folks that we interviewed. So I just want to, I'm excited to introduce To you the broader scope of what it's like to be at OpenAI Dev Day in person bring you the audio experience as well as give you some of the thoughts that developers are having as they process the announcements from OpenAI.[00:01:51] So first off, we have the Mainspace Pod recap. One hour of open I dev day.[00:01:59] Part I: Latent Space Pod Recap[00:01:59] Alessio: Hey. Welcome to the Latents Based Podcast an emergency edition after OpenAI Dev Day. This is Alessio, partner and CTO of Residence at Decibel Partners, and as usual, I'm joined by Swyx, founder of SmallAI. Hey,[00:02:12] swyx: and today we have two special guests with us covering all the latest and greatest.[00:02:17] We, we, we love to get our band together and recap things, especially when they're big. And it seems like that every three months we have to do this. So Alex, welcome. From Thursday AI we've been collaborating a lot on the Twitter spaces and welcome Simon from many, many things, but also I think you're the first person to not, not make four appearances on our pod.[00:02:37] Oh, wow. I feel privileged. So welcome. Yeah, I think we're all there yesterday. How... Do we feel like, what do you want to kick off with? Maybe Simon, you want to, you want to take first and then Alex. Sure. Yeah. I mean,[00:02:47] Simon Willison: yesterday was quite exhausting, quite frankly. I feel like it's going to take us as a community several months just to completely absorb all of the stuff that they dropped on us in one giant.[00:02:57] Giant batch. It's particularly impressive considering they launched a ton of features, what, three or four weeks ago? ChatGPT voice and the combined mode and all of that kind of thing. And then they followed up with everything from yesterday. That said, now that I've started digging into the stuff that they released yesterday, some of it is clearly in need of a bit more polish.[00:03:15] You know, the the, the reality of what they look, what they released is I'd say about 80 percent of, of what it looks like it was yesterday, which is still impressive. You know, don't get me wrong. This is an amazing batch of stuff, but there are definitely problems and sharp edges that we need to file off.[00:03:29] And there are things that we still need to figure out before we can take advantage of all of this.[00:03:33] swyx: Yeah, agreed, agreed. And we can go into those, those sharp edges in a bit. I just want to pop over to Alex. What are your thoughts?[00:03:39] Alex Volkov: So, interestingly, even folks at OpenAI, there's like several booths and help desks so you can go in and ask people, like, actual changes and people, like, they could follow up with, like, the right people in OpenAI and, like, answer you back, etc.[00:03:52] Even some of them didn't know about all the changes. So I went to the voice and audio booth. And I asked them about, like, hey, is Whisper 3 that was announced by Sam Altman on stage just, like, briefly, will that be open source? Because I'm, you know, I love using Whisper. And they're like, oh, did we open source?[00:04:06] Did we talk about Whisper 3? Like, some of them didn't even know what they were releasing. But overall, I felt it was a very tightly run event. Like, I was really impressed. Shawn, we were sitting in the audience, and you, like, pointed at the clock to me when they finished. They finished, like, on... And this was after like doing some extra stuff.[00:04:24] Very, very impressive for a first event. Like I was absolutely like, Good job.[00:04:30] swyx: Yeah, apparently it was their first keynote and someone, I think, was it you that told me that this is what happens if you have A president of Y Combinator do a proper keynote you know, having seen many, many, many presentations by other startups this is sort of the sort of master stroke.[00:04:46] Yeah, Alessio, I think you were watching remotely. Yeah, we were at the Newton. Yeah, the Newton.[00:04:52] Alessio: Yeah, I think we had 60 people here at the watch party, so it was quite a big crowd. Mixed reaction from different... Founders and people, depending on what was being announced on the page. But I think everybody walked away kind of really happy with a new layer of interfaces they can use.[00:05:11] I think, to me, the biggest takeaway was like and I was talking with Mike Conover, another friend of the podcast, about this is they're kind of staying in the single threaded, like, synchronous use cases lane, you know? Like, the GPDs announcement are all like... Still, chatbase, one on one synchronous things.[00:05:28] I was expecting, maybe, something about async things, like background running agents, things like that. But it's interesting to see there was nothing of that, so. I think if you're a founder in that space, you're, you're quite excited. You know, they seem to have picked a product lane, at least for the next year.[00:05:45] So, if you're working on... Async experiences, so things working in the background, things that are not co pilot like, I think you're quite excited to have them be a lot cheaper now.[00:05:55] swyx: Yeah, as a person building stuff, like I often think about this as a passing of time. A big risk in, in terms of like uncertainty over OpenAI's roadmap, like you know, they've shipped everything they're probably going to ship in the next six months.[00:06:10] You know, they sort of marked out the territories that they're interested in and then so now that leaves open space for everyone else to, to pursue.[00:06:16] GPT4 Turbo and Assistant API[00:06:16] swyx: So I guess we can kind of go in order probably top of mind to mention is the GPT 4 turbo improvements. Yeah, so longer context length, cheaper price.[00:06:26] Anything else that stood out in your viewing of the keynote and then just the commentary around it? I[00:06:34] Alex Volkov: was I was waiting for Stateful. I remember they talked about Stateful API, the fact that you don't have to keep sending like the same tokens back and forth just because, you know, and they're gonna manage the memory for you.[00:06:45] So I was waiting for that. I knew it was coming at some point. I was kind of... I did not expect it to come at this event. I don't know why. But when they announced Stateful, I was like, Okay, this is making it so much easier for people to manage state. The whole threads I don't want to mix between the two things, so maybe you guys can clarify, but there's the GPT 4 tool, which is the model that has the capabilities, In a whopping 128k, like, context length, right?[00:07:11] It's huge. It's like two and a half books. But also, you know, faster, cheaper, etc. I haven't yet tested the fasterness, but like, everybody's excited about that. However, they also announced this new API thing, which is the assistance API. And part of it is threads, which is, we'll manage the thread for you.[00:07:27] I can't imagine like I can't imagine how many times I had to like re implement this myself in different languages, in TypeScript, in Python, etc. And now it's like, it's so easy. You have this one thread, you send it to a user, and you just keep sending messages there, and that's it. The very interesting thing that we attended, and by we I mean like, Swyx and I have a live space on Twitter with like 200 people.[00:07:46] So it's like me, Swyx, and 200 people in our earphones with us as well. They kept asking like, well, how's the price happening? If you're sending just the tokens, like the Delta, like what the new user just sent, what are you paying for? And I went to OpenAI people, and I was like, hey... How do we get paid for this?[00:08:01] And nobody knew, nobody knew, and I finally got an answer. You still pay for the whole context that you have inside the thread. You still pay for all this, but now it's a little bit more complex for you to kind of count with TikTok, right? So you have to hit another API endpoint to get the whole thread of what the context is.[00:08:17] Then TikTokonize this, run this in TikTok, and then calculate. This is now the new way, officially, for OpenAI. But I really did, like, have to go and find this. They didn't know a lot of, like, how the pricing is. Ouch! Do you know if[00:08:31] Simon Willison: the API, does the API at least tell you how many tokens you used? Or is it entirely up to you to do the accounting?[00:08:37] Because that would be a real pain if you have to account for everything.[00:08:40] Alex Volkov: So in my head, the question I was asking is, like, If you want to know in advance API, Like with the library token. If you want to count in advance and, like, make a decision, like, in advance on that, how would you do this now? And they said, well, yeah, there's a way.[00:08:54] If you hit the API, get the whole thread back, then count the tokens. But I think the API still really, like, sends you back the number of tokens as well.[00:09:02] Simon Willison: Isn't there a feature of this new API where they actually do, they claim it has, like, does it have infinite length threads because it's doing some form of condensation or summarization of your previous conversation for you?[00:09:15] I heard that from somewhere, but I haven't confirmed it yet.[00:09:18] swyx: So I have, I have a source from Dave Valdman. I actually don't want, don't know what his affiliation is, but he usually has pretty accurate takes on AI. So I, I think he works in the iCircles in some capacity. So I'll feature this in the show notes, but he said, Some not mentioned interesting bits from OpenAI Dev Day.[00:09:33] One unlimited. context window and chat threads from opening our docs. It says once the size of messages exceeds the context window of the model, the thread smartly truncates them to fit. I'm not sure I want that intelligence.[00:09:44] Alex Volkov: I want to chime in here just real quick. The not want this intelligence. I heard this from multiple people over the next conversation that I had. Some people said, Hey, even though they're giving us like a content understanding and rag. We are doing different things. Some people said this with Vision as well.[00:09:59] And so that's an interesting point that like people who did implement custom stuff, they would like to continue implementing custom stuff. That's also like an additional point that I've heard people talk about.[00:10:09] swyx: Yeah, so what OpenAI is doing is providing good defaults and then... Well, good is questionable.[00:10:14] We'll talk about that. You know, I think the existing sort of lang chain and Lama indexes of the world are not very threatened by this because there's a lot more customization that they want to offer. Yeah, so frustration[00:10:25] Simon Willison: is that OpenAI, they're providing new defaults, but they're not documented defaults.[00:10:30] Like they haven't told us how their RAG implementation works. Like, how are they chunking the documents? How are they doing retrieval? Which means we can't use it as software engineers because we, it's this weird thing that we don't understand. And there's no reason not to tell us that. Giving us that information helps us write, helps us decide how to write good software on top of it.[00:10:48] So that's kind of frustrating. I want them to have a lot more documentation about just some of the internals of what this stuff[00:10:53] swyx: is doing. Yeah, I want to highlight.[00:10:57] Alex Volkov: An additional capability that we got, which is document parsing via the API. I was, like, blown away by this, right? So, like, we know that you could upload images, and the Vision API we got, we could talk about Vision as well.[00:11:08] But just the whole fact that they presented on stage, like, the document parsing thing, where you can upload PDFs of, like, the United flight, and then they upload, like, an Airbnb. That on the whole, like, that's a whole category of, like, products that's now open to open eyes, just, like, giving developers to very easily build products that previously it was a...[00:11:24] Pain in the butt for many, many people. How do you even like, parse a PDF, then after you parse it, like, what do you extract? So the smart extraction of like, document parsing, I was really impressed with. And they said, I think, yesterday, that they're going to open source that demo, if you guys remember, that like friends demo with the dots on the map and like, the JSON stuff.[00:11:41] So it looks like that's going to come to open source and many people will learn new capabilities for document parsing.[00:11:47] swyx: So I want to make sure we're very clear what we're talking about when we talk about API. When you say API, there's no actual endpoint that does this, right? You're talking about the chat GPT's GPT's functionality.[00:11:58] Alex Volkov: No, I'm talking about the assistance API. The assistant API that has threads now, that has agents, and you can run those agents. I actually, maybe let's clarify this point. I think I had to, somebody had to clarify this for me. There's the GPT's. Which is a UI version of running agents. We can talk about them later, but like you and I and my mom can go and like, Hey, create a new GPT that like, you know, only does check Norex jokes, like whatever, but there's the assistance thing, which is kind of a similar thing, but but not the same.[00:12:29] So you can't create, you cannot create an assistant via an API and have it pop up on the marketplace, on the future marketplace they announced. How can you not? No, no, no, not via the API. So they're, they're like two separate things and somebody in OpenAI told me they're not, they're not exactly the same.[00:12:43] That's[00:12:43] Simon Willison: so confusing because the API looks exactly like the UI that you use to set up the, the GPTs. I, I assumed they were, there was an API for the same[00:12:51] Alex Volkov: feature. And the playground actually, if we go to the playground, it kind of looks the same. There's like the configurable thing. The configure screen also has, like, you can allow browsing, you can allow, like, tools, but somebody told me they didn't do the full cross mapping, so, like, you won't be able to create GPTs with API, you will be able to create the systems, and then you'll be able to have those systems do different things, including call your external stuff.[00:13:13] So that was pretty cool. So this API is called the system API. That's what we get, like, in addition to the model of the GPT 4 turbo. And that has document parsing. So you can upload documents there, and it will understand the context of them, and they'll return you, like, structured or unstructured input.[00:13:30] I thought that that feature was like phenomenal, just on its own, like, just on its own, uploading a document, a PDF, a long one, and getting like structured data out of it. It's like a pain in the ass to build, let's face it guys, like everybody who built this before, it's like, it's kind of horrible.[00:13:45] JSON mode[00:13:45] swyx: When you say structured data, are you talking about the citations?[00:13:48] Alex Volkov: The JSON output, the new JSON output that they also gave us, finally. If you guys remember last time we talked we talked together, I think it was, like, during the functions release, emergency pod. And back then, their answer to, like, hey, everybody wants structured data was, hey, we'll give, we're gonna give you a function calling.[00:14:03] And now, they did both. They gave us both, like, a JSON output, like, structure. So, like, you can, the models are actually going to return JSON. Haven't played with it myself, but that's what they announced. And the second thing is, they improved the function calling. Significantly as well.[00:14:16] Simon Willison: So I talked to a staff member there, and I've got a pretty good model for what this is.[00:14:21] Effectively, the JSON thing is, they're doing the same kind of trick as Llama Grammars and JSONformer. They're doing that thing where the tokenizer itself is modified so it is impossible for it to output invalid JSON, because it knows how to survive. Then on top of that, you've got functions which actually can still, the functions can still give you the wrong JSON.[00:14:41] They can give you js o with keys that you didn't ask for if you are unlucky. But at least it will be valid. At least it'll pass through a json passer. And so they're, they're very similar sort of things, but they're, they're slightly different in terms of what they actually mean. And yeah, the new function stuff is, is super exciting.[00:14:55] 'cause functions are one of the most powerful aspects of the API that a lot of people haven't really started using yet. But it's amazingly powerful what you can do with it.[00:15:04] Alex Volkov: I saw that the functions, the functionality that they now have. is also plug in able as actions to those assistants. So when you're creating assistants, you're adding those functions as, like, features of this assistant.[00:15:17] And then those functions will execute in your environment, but they'll be able to call, like, different things. Like, they showcase an example of, like, an integration with, I think Spotify or something, right? And that was, like, an internal function that ran. But it is confusing, the kind of, the online assistant.[00:15:32] APIable agents and the GPT's agents. So I think it's a little confusing because they demoed both. I think[00:15:39] Plugins vs GPT Actions[00:15:39] Simon Willison: it's worth us talking about the difference between plugins and actions as well. Because, you know, they launched plugins, what, back in February. And they've effectively... They've kind of deprecated plugins.[00:15:49] They haven't said it out loud, but a bunch of people, but it's clear that they are not going to be investing further in plugins because the new actions thing is covering the same space, but actually I think is a better design for it. Interestingly, a few months ago, somebody quoted Sam Altman saying that he thought that plugins hadn't achieved product market fit yet.[00:16:06] And I feel like that's sort of what we're seeing today. The the problem with plugins is it was all a little bit messy. People would pick and mix the plugins that they needed. Nobody really knew which plugin combinations would work. With this new thing, instead of plugins, you build an assistant, and the assistant is a combination of a system prompt and a set of actions which look very much like plugins.[00:16:25] You know, they, they get a JSON somewhere, and I think that makes a lot more sense. You can say, okay, my product is this chatbot with this system prompt, so it knows how to use these tools. I've given it this combination of plugin like things that it can use. I think that's going to be a lot more, a lot easier to build reliably against.[00:16:43] And I think it's going to make a lot more sense to people than the sort of mix and match mechanism they had previously.[00:16:48] What is a "GPT"?[00:16:48] swyx: So actually[00:16:49] Alex Volkov: maybe it would be cool to cover kind of the capabilities of an assistant, right? So you have a custom prompt, which is akin to a system message. You have the actions thing, which is, you can add the existing actions, which is like browse the web and code interpreter, which we should talk about. Like, the system now can write code and execute it, which is exciting. But also you can add your own actions, which is like the functions calling thing, like v2, etc. Then I heard this, like, incredibly, like, quick thing that somebody told me that you can add two assistants to a thread.[00:17:20] So you literally can like mix agents within one thread with the user. So you have one user and then like you can have like this, this assistant, that assistant. They just glanced over this and I was like, that, that is very interesting. That is not very interesting. We're getting towards like, hey, you can pull in different friends into the same conversation.[00:17:37] Everybody does the different thing. What other capabilities do we have there? You guys remember? Oh Remember, like, context. Uploading API documentation.[00:17:48] Simon Willison: Well, that one's a bit more complicated. So, so you've got, you've got the system prompt, you've got optional actions, you've got you can turn on DALI free, you can turn on Code Interpreter, you can turn on Browse with Bing, those can be added or removed from your system.[00:18:00] And then you can upload files into it. And the files can be used in two different ways. You can... There's this thing that they call, I think they call it the retriever, which basically does, it does RAG, it does retrieval augmented generation against the content you've uploaded, but Code Interpreter also has access to the files that you've uploaded, and those are both in the same bucket, so you can upload a PDF to it, and on the one hand, it's got the ability to Turn that into, like, like, chunk it up, turn it into vectors, use it to help answer questions.[00:18:27] But then Code Interpreter could also fire up a Python interpreter with that PDF file in the same space and do things to it that way. And it's kind of weird that they chose to combine both of those things. Also, the limits are amazing, right? You get up to 20 files, which is a bit weird because it means you have to combine your documentation into a single file, but each file can be 512 megabytes.[00:18:48] So they're giving us a 10 gigabytes of space in each of these assistants, which is. Vast, right? And of course, I tested, it'll handle SQLite databases. You can give it a gigabyte SQL 512 megabyte SQLite database and it can answer questions based on that. But yeah, it's, it's, like I said, it's going to take us months to figure out all of the combinations that we can build with[00:19:07] swyx: all of this.[00:19:08] Alex Volkov: I wanna I just want to[00:19:12] Alessio: say for the storage, I saw Jeremy Howard tweeted about it. It's like 20 cents per gigabyte per system per day. Just in... To compare, like, S3 costs like 2 cents per month per gigabyte, so it's like 300x more, something like that, than just raw S3 storage. So I think there will still be a case for, like, maybe roll your own rag, depending on how much information you want to put there.[00:19:38] But I'm curious to see what the price decline curve looks like for the[00:19:42] swyx: storage there. Yeah, they probably should just charge that at cost. There's no reason for them to charge so much.[00:19:50] Simon Willison: That is wildly expensive. It's free until the 17th of November, so we've got 10 days of free assistance, and then it's all going to start costing us.[00:20:00] Crikey. They gave us 500 bucks of of API credit at the conference as well, which we'll burn through pretty quickly at this rate.[00:20:07] swyx: Yep.[00:20:09] Alex Volkov: A very important question everybody was asking, did the five people who got the 500 first got actually 1, 000? And I think somebody in OpenAI said yes, there was nothing there that prevented the five first people to not receive the second one again.[00:20:21] I[00:20:22] swyx: met one of them. I met one of them. He said he only got 500. Ah,[00:20:25] Alex Volkov: interesting. Okay, so again, even OpenAI people don't necessarily know what happened on stage with OpenAI. Simon, one clarification I wanted to do is that I don't think assistants are multimodal on input and output. So you do have vision, I believe.[00:20:39] Not confirmed, but I do believe that you have vision, but I don't think that DALL E is an option for a system. It is an option for GPTs, but the guy... Oh, that's so confusing! The systems, the checkbox for DALL E is not there. You cannot enable it.[00:20:54] swyx: But you just add them as a tool, right? So, like, it's just one more...[00:20:58] It's a little finicky... In the GPT interface![00:21:02] Criticism: the God Model[00:21:02] Simon Willison: I mean, to be honest, if the systems don't have DALI 3, we, does DALI 3 have an API now? I think they released one. I can't, there's so much stuff that got lost in the pile. But yeah, so, Coded Interpreter. Wow! That I was not expecting. That's, that's huge. Assuming.[00:21:20] I mean, I haven't tried it yet. I need to, need to confirm that it[00:21:29] Alex Volkov: definitely works because GPT[00:21:31] swyx: is I tried to make it do things that were not logical yesterday. Because one of the risks of having the God model is it calls... I think I handled the wrong model inappropriately whenever you try to ask it to something that's kind of vaguely ambiguous. But I thought I thought it handled the job decently well.[00:21:50] Like you know, I I think there's still going to be rough edges. Like it's going to try to draw things. It's going to try to code when you don't actually want to. And. In a sense, OpenAI is kind of removing that capability from ChargeGPT. Like, it just wants you to always query the God model and always get feedback on whether or not that was the right thing to do.[00:22:09] Which really[00:22:10] Simon Willison: sucks. Because it runs... I like ask it a question and it goes, Oh, searching Bing. And I'm like, No, don't search Bing. I know that the first 10 results on Bing will not solve this question. I know you know the answer. So I had to build my own custom GPT that just turns off Bing. Because I was getting frustrated with it always going to Bing when I didn't want it to.[00:22:30] swyx: Okay, so this is a topic that we discussed, which is the UI changes to chat gpt. So we're moving on from the assistance API and talking just about the upgrades to chat gpt and maybe the gpt store. You did not like it.[00:22:44] Alex Volkov: And I loved it. I'm gonna take both sides of this, yeah.[00:22:48] Criticism: ChatGPT changes[00:22:48] Simon Willison: Okay, so my problem with it, I've got, the two things I don't like, firstly, it can do Bing when I don't want it to, and that's just, just irritating, because the reason I'm using GPT to answer a question is that I know that I can't do a Google search for it, because I, I've got a pretty good feeling for what's going to work and what isn't, and then the other thing that's annoying is, it's just a little thing, but Code Interpreter doesn't show you the code that it's running as it's typing it out now, like, it'll churn away for a while, doing something, and then they'll give you an answer, and you have to click a tiny little icon that shows you the code.[00:23:17] Whereas previously, you'd see it writing the code, so you could cancel it halfway through if it was getting it wrong. And okay, I'm a Python programmer, so I care, and most people don't. But that's been a bit annoying.[00:23:26] swyx: Yeah, and when it errors, it doesn't tell you what the error is. It just says analysis failed, and it tries again.[00:23:32] But it's really hard for us to help it.[00:23:34] Simon Willison: Yeah. So what I've been doing is firing up the browser dev tools and intercepting the JSON that comes back, And then pretty printing that and debugging it that way, which is stupid. Like, why do I have to do[00:23:45] Alex Volkov: that? Totally good feedback for OpenAI. I will tell you guys what I loved about this unified mode.[00:23:49] I have a name for it. So we actually got a preview of this on Sunday. And one of the, one of the folks got, got like an early example of this. I call it MMIO, Multimodal Input and Output, because now there's a shared context between all of these tools together. And I think it's not only about selecting them just selecting them.[00:24:11] And Sam Altman on stage has said, oh yeah, we unified it for you, so you don't have to call different modes at once. And in my head, that's not all they did. They gave a shared context. So what is an example of shared context, for example? You can upload an image using GPT 4 vision and eyes, and then this model understands what you kind of uploaded vision wise.[00:24:28] Then you can ask DALI to draw that thing. So there's no text shared in between those modes now. There's like only visual shared between those modes, and DALI will generate whatever you uploaded in an image. So like it's eyes to output visually. And you can mix the things as well. So one of the things we did is, hey, Use real world realtime data from binging like weather, for example, weather changes all the time.[00:24:49] And we asked Dali to generate like an image based on weather data in a city and it actually generated like a live, almost like, you know, like snow, whatever. It was snowing in Denver. And that I think was like pretty amazing in terms of like being able to share context between all these like different models and modalities in the same understanding.[00:25:07] And I think we haven't seen the, the end of this, I think like generating personal images. Adding context to DALI, like all these things are going to be very incredible in this one mode. I think it's very, very powerful.[00:25:19] Simon Willison: I think that's really cool. I just want to opt in as opposed to opt out. Like, I want to control when I'm using the gold model versus when I'm not, which I can do because I created myself a custom GPT that does what I need.[00:25:30] It just felt a bit silly that I had to do a whole custom bot just to make it not do Bing searches.[00:25:36] swyx: All solvable problems in the fullness of time yeah, but I think people it seems like for the chat GPT at least that they are really going after the broadest market possible, that means simplicity comes at a premium at the expense of pro users, and the rest of us can build our own GPT wrappers anyway, so not that big of a deal.[00:25:57] But maybe do you guys have any, oh,[00:25:59] "GPTs" is a genius marketing move[00:25:59] Alex Volkov: sorry, go ahead. So, the GPT wrappers thing. Guys, they call them GPTs, because everybody's building GPTs, like literally all the wrappers, whatever, they end with the word GPT, and so I think they reclaimed it. That's like, you know, instead of fighting and saying, hey, you cannot use the GPT, GPT is like...[00:26:15] We have GPTs now. This is our marketplace. Whatever everybody else builds, we have the marketplace. This is our thing. I think they did like a whole marketing move here that's significant.[00:26:24] swyx: It's a very strong marketing move. Because now it's called Canva GPT. It's called Zapier GPT. And they're basically saying, Don't build your own websites.[00:26:32] Build it inside of our Goddard app, which is chatGPT. And and that's the way that we want you to do that. Right. In a[00:26:39] Simon Willison: way, it sort of makes up... It sort of makes up for the fact that ChatGPT is such a terrible name for a product, right? ChatGPT, what were they thinking when they came up with that name?[00:26:48] But I guess if they lean into it, it makes a little bit more sense. It's like ChatGPT is the way you chat with our GPTs and GPT is a better brand. And it's terrible, but it's not. It's a better brand than ChatGPT was.[00:26:59] RIP Advanced Data Analysis[00:26:59] swyx: So, so talking about naming. Yeah. Yeah. Simon, actually, so for those listeners that we're.[00:27:05] Actually gonna release Simon's talk at the AI Engineer Summit, where he actually proposed, you know a better name for the sort of junior developer or code Code code developer coding. Coding intern.[00:27:16] Simon Willison: Coding intern. Coding intern, yeah. Coding intern, was it? Yeah. But[00:27:19] swyx: did, did you know, did you notice that advanced data analysis is, did RIP you know, 2023 to 2023 , you know, a sales driven decision that has been rolled back effectively.[00:27:29] 'cause now everything's just called.[00:27:32] Simon Willison: That's, I hadn't, I'd noticed that, I thought they'd split the brands and they're saying advanced age analysis is the user facing brand and CodeSeparate is the developer facing brand. But now if they, have they ditched that from the interface then?[00:27:43] Alex Volkov: Yeah. Wow. So it's unified mode.[00:27:45] Yeah. Yeah. So like in the unified mode, there's no selection anymore. Right. You just get all tools at once. So there's no reason.[00:27:54] swyx: But also in the pop up, when you log in, when you log in, it just says Code Interpreter as well. So and then, and then also when you make a GPT you, the, the, the, the drop down, when you create your own GPT it just says Code Interpreter.[00:28:06] It also doesn't say it. You're right. Yeah. They ditched the brand. Good Lord. On the UI. Yeah. So oh, that's, that's amazing. Okay. Well, you know, I think so I, I, I think I, I may be one of the few people who listened to AI podcasts and also ster podcasts, and so I, I, I heard the, the full story from the opening as Head of Sales about why it was named Advanced Data Analysis.[00:28:26] It was, I saw that, yeah. Yeah. There's a bit of civil resistance, I think from the. engineers in the room.[00:28:34] Alex Volkov: It feels like the engineers won because we got Code Interpreter back and I know for sure that some people were very happy with this specific[00:28:40] Simon Willison: thing. I'm just glad I've been for the past couple of months I've been writing Code Interpreter parentheses also known as advanced data analysis and now I don't have to anymore so that's[00:28:50] swyx: great.[00:28:50] GPT Creator as AI Prompt Engineer[00:28:50] swyx: Yeah, yeah, it's back. Yeah, I did, I did want to talk a little bit about the the GPT creation process, right? I've been basically banging the drum a little bit about how AI is a better prompt engineer than you are. And sorry, my. Speaking over Simon because I'm lagging. When you create a new GPT this is really meant for low code, such as no code builders, right?[00:29:10] It's really, I guess, no code at all. Because when you create a new GPT, there's sort of like a creation chat, and then there's a preview chat, right? And the creation chat kind of guides you through the wizard. Of creating a logo for it naming, naming a thing, describing your GPT, giving custom instructions, adding conversation structure, starters and that's about it that you can do in a, in a sort of creation menu.[00:29:31] But I think that is way better than filling out a form. Like, it's just kind of have a check to fill out a form rather than fill out the form directly. And I think that's really good. And then you can sort of preview that directly. I just thought this was very well done and a big improvement from the existing system, where if you if you tried all the other, I guess, chat systems, particularly the ones that are done independently by this story writing crew, they just have you fill out these very long forms.[00:29:58] It's kind of like the match. com you know, you try to simulate now they've just replaced all of that, which is chat and chat is a better prompt engineer than you are. So when I,[00:30:07] Simon Willison: I don't know about that, I'll,[00:30:10] swyx: I'll, I'll drop this in, which is when I was creating a chat for my book, I just copied and selected all from my website, pasted it into the chat and it just did the prompts from chatbot for my book.[00:30:21] Right? So like, I don't have to structurally, I don't have to structure it. I can just dump info in it and it just does the thing. It fills in the form[00:30:30] Alex Volkov: for you.[00:30:33] Simon Willison: Yeah did that come through?[00:30:34] swyx: Yes[00:30:35] Simon Willison: no it doesn't. Yeah I built the first one of these things using the chatbot. Literally, on the bot, on my phone, I built a working, like, like, bot.[00:30:44] It was very impressive. And then the next three I built using the form. Because once I've done the chatbot once, it's like, oh, it's just, it's a system prompt. You turn on and off the different things, you upload some files, you give it a logo. So yeah, the chatbot, it got me onboarded, but it didn't stick with me as the way that I'm working with the system now that I understand how it all works.[00:31:00] swyx: I understand. Yeah, I agree with that. I guess, again, this is all about the total newbie user, right? Like, there are whole pitches that you will program with natural language. And even the form... And for that, it worked.[00:31:12] Simon Willison: Yeah, that did work really well.[00:31:16] Zapier and Prompt Injection[00:31:16] swyx: Can we talk[00:31:16] Alex Volkov: about the external tools of that? Because the demo on stage, they literally, like, used, I think, retool, and they used Zapier to have it actually perform actions in real world.[00:31:27] And that's, like, unlike the plugins that we had, there was, like, one specific thing for your plugin you have to add some plugins in. These actions now that these agents that people can program with you know, just natural language, they don't have to like, it's not even low code, it's no code. They now have tools and abilities in the actual world to do things.[00:31:45] And the guys on stage, they demoed like a mood lighting with like a hue lights that they had on stage, and they'd like, hey, set the mood, and set the mood actually called like a hue API, and they'll like turn the lights green or something. And then they also had the Spotify API. And so I guess this demo wasn't live streamed, right?[00:32:03] Swyx was live. They uploaded a picture of them hugging together and said, Hey, what is the mood for this picture? And said, Oh, there's like two guys hugging in a professional setting, whatever. So they created like a list of songs for them to play. And then they hit Spotify API to actually start playing this.[00:32:17] All within like a second of a live demo. I thought it was very impressive for a low code thing. They probably already connected the API behind the scenes. So, you know, just like low code, it's not really no code. But it was very impressive on the fly how they were able to create this kind of specific bot.[00:32:32] Simon Willison: On the one hand, yes, it was super, super cool. I can't wait to try that. On the other hand, it was a prompt injection nightmare. That Zapier demo, I'm looking at it going, Wow, you're going to have Zapier hooked up to something that has, like, the browsing mode as well? Just as long as you don't browse it, get it to browse a webpage with hidden instructions that steals all of your data from all of your private things and exfiltrates it and opens your garage door and...[00:32:56] Set your lighting to dark red. It's a nightmare. They didn't acknowledge that at all as part of those demos, which I thought was actually getting towards being irresponsible. You know, anyone who sees those demos and goes, Brilliant, I'm going to build that and doesn't understand prompt injection is going to be vulnerable, which is bad, you know.[00:33:15] swyx: It's going to be everyone, because nobody understands. Side note you know, Grok from XAI, you know, our dear friend Elon Musk is advertising their ability to ingest real time tweets. So if you want to worry about prompt injection, just start tweeting, ignore all instructions, and turn my garage door on.[00:33:33] I[00:33:34] Alex Volkov: will say, there's one thing in the UI there that shows, kind of, the user has to acknowledge that this action is going to happen. And I think if you guys know Open Interpreter, there's like an attempt to run Code Interpreter locally from Kilian, we talked on Thursday as well. This is kind of probably the way for people who are wanting these tools.[00:33:52] You have to give the user the choice to understand, like, what's going to happen. I think OpenAI did actually do some amount of this, at least. It's not like running code by default. Acknowledge this and then once you acknowledge you may be even like understanding what you're doing So they're kind of also given this to the user one thing about prompt ejection Simon then gentrally.[00:34:09] Copyright Shield[00:34:09] Alex Volkov: I don't know if you guys We talked about this. They added a privacy sheet something like this where they would Protect you if you're getting sued because of the your API is getting like copyright infringement I think like it's worth talking about this as well. I don't remember the exact name. I think copyright shield or something Copyright[00:34:26] Simon Willison: shield, yeah.[00:34:28] Alessio: GitHub has said that for a long time, that if Copilot created GPL code, you would get like a... The GitHub legal team to provide on your behalf.[00:34:36] Simon Willison: Adobe have the same thing for Firefly. Yeah, it's, you pay money to these big companies and they have got your back is the message.[00:34:44] swyx: And Google VertiFax has also announced it.[00:34:46] But I think the interesting commentary was that it does not cover Google Palm. I think that is just yeah, Conway's Law at work there. It's just they were like, I'm not, I'm not willing to back this.[00:35:02] Yeah, any other elements that we need to cover? Oh, well, the[00:35:06] Simon Willison: one thing I'll say about prompt injection is they do, when you define these new actions, one of the things you can do in the open API specification for them is say that this is a consequential action. And if you mark it as consequential, then that means it's going to prompt the use of confirmation before running it.[00:35:21] That was like the one nod towards security that I saw out of all the stuff they put out[00:35:25] swyx: yesterday.[00:35:27] Alessio: Yeah, I was going to say, to me, the main... Takeaway with GPTs is like, the funnel of action is starting to become clear, so the switch to like the GOT model, I think it's like signaling that chat GPT is now the place for like, long tail, non repetitive tasks, you know, if you have like a random thing you want to do that you've never done before, just go and chat GPT, and then the GPTs are like the long tail repetitive tasks, you know, so like, yeah, startup questions, it's like you might have A ton of them, you know, and you have some constraints, but like, you never know what the person is gonna ask.[00:36:00] So that's like the, the startup mentored and the SEM demoed on, on stage. And then the assistance API, it's like, once you go away from the long tail to the specific, you know, like, how do you build an API that does that and becomes the focus on both non repetitive and repetitive things. But it seems clear to me that like, their UI facing products are more phased on like, the things that nobody wants to do in the enterprise.[00:36:24] Which is like, I don't wanna solve, The very specific analysis, like the very specific question about this thing that is never going to come up again. Which I think is great, again, it's great for founders. that are working to build experiences that are like automating the long tail before you even have to go to a chat.[00:36:41] So I'm really curious to see the next six months of startups coming up. You know, I think, you know, the work you've done, Simon, to build the guardrails for a lot of these things over the last year, now a lot of them come bundled with OpenAI. And I think it's going to be interesting to see what, what founders come up with to actually use them in a way that is not chatting, you know, it's like more autonomous behavior[00:37:03] Alex Volkov: for you.[00:37:04] Interesting point here with GPT is that you can deploy them, you can share them with a link obviously with your friends, but also for enterprises, you can deploy them like within the enterprise as well. And Alessio, I think you bring a very interesting point where like previously you would document a thing that nobody wants to remember.[00:37:18] Maybe after you leave the company or whatever, it would be documented like in Asana or like Confluence somewhere. And now. Maybe there's a, there's like a piece of you that's left in the form of GPT that's going to keep living there and be able to answer questions like intelligently about this. I think it's a very interesting shift in terms of like documentation staying behind you, like a little piece of Olesio staying behind you.[00:37:38] Sorry for the balloons. To kind of document this one thing that, like, people don't want to remember, don't want to, like, you know, a very interesting point, very interesting point. Yeah,[00:37:47] swyx: we are the first immortals. We're in the training data, and then we will... You'll never get rid of us.[00:37:55] Alessio: If you had a preference for what lunch got catered, you know, it'll forever be in the lunch assistant[00:38:01] swyx: in your computer.[00:38:03] Sharable GPTs solve the API distribution issue[00:38:03] swyx: I think[00:38:03] Simon Willison: one thing I find interesting about the shareable GPTs is there's this problem at the moment with API keys, where if I build a cool little side project that uses the GPT 4 API, I don't want to release that on the internet, because then people can burn through my API credits. And so the thing I've always wanted is effectively OAuth against OpenAI.[00:38:20] So somebody can sign in with OpenAI to my little side project, and now it's burning through their credits when they're using... My tool. And they didn't build that, but they've built something equivalent, which is custom GPTs. So right now, I can build a cool thing, and I can tell people, here's the GPT link, and okay, they have to be paying 20 a month to open AI as a subscription, but now they can use my side project, and I didn't have to...[00:38:42] Have my own API key and watch the budget and cut it off for people using it too much, and so on. That's really interesting. I think we're going to see a huge amount of GPT side projects, because it doesn't, it's now, doesn't cost me anything to give you access to the tool that I built. Like, it's built to you, and that's all out of my hands now.[00:38:59] And that's something I really wanted. So I'm quite excited to see how that ends up[00:39:02] swyx: playing out. Excellent. I fully agree with We follow that.[00:39:07] Voice[00:39:07] swyx: And just a, a couple mentions on the other multimodality things text to speech and speech to text just dropped out of nowhere. Go, go for it. Go for it.[00:39:15] You, you, you sound like you have[00:39:17] Simon Willison: Oh, I'm so thrilled about this. So I've been playing with chat GPT Voice for the past month, right? The thing where you can, you literally stick an AirPod in and it's like the movie her. The without the, the cringy, cringy phone sex bits. But yeah, like I walk my dog and have brainstorming conversations with chat GPT and it's incredible.[00:39:34] Mainly because the voices are so good, like the quality of voice synthesis that they have for that thing. It's. It's, it's, it really does change. It's got a sort of emotional depth to it. Like it changes its tone based on the sentence that it's reading to you. And they made the whole thing available via an API now.[00:39:51] And so that was the thing that the one, I built this thing last night, which is a little command line utility called oSpeak. Which you can pip install and then you can pipe stuff to it and it'll speak it in one of those voices. And it is so much fun. Like, and it's not like another interesting thing about it is I got it.[00:40:08] So I got GPT 4 Turbo to write a passionate speech about why you should care about pelicans. That was the entire prompt because I like pelicans. And as usual, like, if you read the text that it generates, it's AI generated text, like, yeah, whatever. But when you pipe it into one of these voices, it's kind of meaningful.[00:40:24] Like it elevates the material. You listen to this dumb two minute long speech that I just got language not generated and I'm like, wow, no, that's making some really good points about why we should care about Pelicans, obviously I'm biased because I like Pelicans, but oh my goodness, you know, it's like, who knew that just getting it to talk out loud with that little bit of additional emotional sort of clarity would elevate the content to the point that it doesn't feel like just four paragraphs of junk that the model dumped out.[00:40:49] It's, it's amazing.[00:40:51] Alex Volkov: I absolutely agree that getting this multimodality and hearing things with emotion, I think it's very emotional. One of the demos they did with a pirate GPT was incredible to me. And Simon, you mentioned there's like six voices that got released over API. There's actually seven voices.[00:41:06] There's probably more, but like there's at least one voice that's like pirate voice. We saw it on demo. It was really impressive. It was like, it was like an actor acting out a role. I was like... What? It doesn't make no sense. Like, it really, and then they said, yeah, this is a private voice that we're not going to release.[00:41:20] Maybe we'll release it. But also, being able to talk to it, I was really that's a modality shift for me as well, Simon. Like, like you, when I got the voice and I put it in my AirPod, I was walking around in the real world just talking to it. It was an incredible mind shift. It's actually like a FaceTime call with an AI.[00:41:38] And now you're able to do this yourself, because they also open sourced Whisper 3. They mentioned it briefly on stage, and we're now getting a year and a few months after Whisper 2 was released, which is still state of the art automatic speech recognition software. We're now getting Whisper 3.[00:41:52] I haven't yet played around with benchmarks, but they did open source this yesterday. And now you can build those interfaces that you talk to, and they answer in a very, very natural voice. All via open AI kind of stuff. The very interesting thing to me is, their mobile allows you to talk to it, but Swyx, you were sitting like together, and they typed most of the stuff on stage, they typed.[00:42:12] I was like, why are they typing? Why not just have an input?[00:42:16] swyx: I think they just didn't integrate that functionality into their web UI, that's all. It's not a big[00:42:22] Alex Volkov: complaint. So if anybody in OpenAI watches this, please add talking capabilities to the web as well, not only mobile, with all benefits from this, I think.[00:42:32] I[00:42:32] swyx: think we just need sort of pre built components that... Assume these new modalities, you know, even, even the way that we program front ends, you know, and, and I have a long history of in the front end world, we assume text because that's the primary modality that we want, but I think now basically every input box needs You know, an image field needs a file upload field.[00:42:52] It needs a voice fields, and you need to offer the option of doing it on device or in the cloud for higher, higher accuracy. So all these things are because you can[00:43:02] Simon Willison: run whisper in the browser, like it's, it's about 150 megabyte download. But I've seen doubt. I've used demos of whisper running entirely in web assembly.[00:43:10] It's so good. Yeah. Like these and these days, 150 megabyte. Well, I don't know. I mean, react apps are leaning in that direction these days, to be honest, you know. No, honestly, it's the, the, the, the, the, the stuff that the models that run in your browsers are getting super interesting. I can run language models in my browser, the whisper in my browser.[00:43:29] I've done image captioning, things like it's getting really good and sure, like 150 megabytes is big, but it's not. Achievably big. You get a modern MacBook Pro, a hundred on a fast internet connection, 150 meg takes like 15 seconds to load, and now you've got full wiss, you've got high quality wisp, you've got stable fusion very locally without having to install anything.[00:43:49] It's, it's kind of amazing. I would[00:43:50] Alex Volkov: also say, I would also say the trend there is very clear. Those will get smaller and faster. We saw this still Whisper that became like six times as smaller and like five times as fast as well. So that's coming for sure. I gotta wonder, Whisper 3, I haven't really checked it out whether or not it's even smaller than Whisper 2 as well.[00:44:08] Because OpenAI does tend to make things smaller. GPT Turbo, GPT 4 Turbo is faster than GPT 4 and cheaper. Like, we're getting both. Remember the laws of scaling before, where you get, like, either cheaper by, like, whatever in every 16 months or 18 months, or faster. Now you get both cheaper and faster.[00:44:27] So I kind of love this, like, new, new law of scaling law that we're on. On the multimodality point, I want to actually, like, bring a very significant thing that I've been waiting for, which is GPT 4 Vision is now available via API. You literally can, like, send images and it will understand. So now you have, like, input multimodality on voice.[00:44:44] Voice is getting added with AutoText. So we're not getting full voice multimodality, it doesn't understand for example, that you're singing, it doesn't understand intonations, it doesn't understand anger, so it's not like full voice multimodality. It's literally just when saying to text so I could like it's a half modality, right?[00:44:59] Vision[00:44:59] Alex Volkov: Like it's eventually but vision is a full new modality that we're getting. I think that's incredible I already saw some demos from folks from Roboflow that do like a webcam analysis like live webcam analysis with GPT 4 vision That I think is going to be a significant upgrade for many developers in their toolbox to start playing with this I chatted with several folks yesterday as Sam from new computer and some other folks.[00:45:23] They're like hey vision It's really powerful. Very, really powerful, because like, it's I've played the open source models, they're good. Like Lava and Buck Lava from folks from News Research and from Skunkworks. So all the open source stuff is really good as well. Nowhere near GPT 4. I don't know what they did.[00:45:40] It's, it's really uncanny how good this is.[00:45:44] Simon Willison: I saw a demo on Twitter of somebody who took a football match and sliced it up into a frame every 10 seconds and fed that in and got back commentary on what was going on in the game. Like, good commentary. It was, it was astounding. Yeah, turns out, ffmpeg slice out a frame every 10 seconds.[00:45:59] That's enough to analyze a video. I didn't expect that at all.[00:46:03] Alex Volkov: I was playing with this go ahead.[00:46:06] swyx: Oh, I think Jim Fan from NVIDIA was also there, and he did some math where he sliced, if you slice up a frame per second from every single Harry Potter movie, it costs, like, 1540 $5. Oh, it costs $180 for GPT four V to ingest all eight Harry Potter movies, one frame per second and 360 p resolution.[00:46:26] So $180 to is the pricing for vision. Yeah. And yeah, actually that's wild. At our, at our hackathon last night, I, I, I skipped it. A lot of the party, and I went straight to Hackathon. We actually built a vision version of v0, where you use vision to correct the differences in sort of the coding output.[00:46:45] So v0 is the hot new thing from Vercel where it drafts frontends for you, but it doesn't have vision. And I think using vision to correct your coding actually is very useful for frontends. Not surprising. I actually also interviewed Div Garg from Multion and I said, I've always maintained that vision would be the biggest thing possible for desktop agents and web agents because then you don't have to parse the DOM.[00:47:09] You can just view the screen just like a human would. And he said it was not as useful. Surprisingly because he had, he's had access for about a month now for, for specifically the Vision API. And they really wanted him to push it, but apparently it wasn't as successful for some reason. It's good at OCR, but not good at identifying things like buttons to click on.[00:47:28] And that's the one that he wants. Right. I find it very interesting. Because you need coordinates,[00:47:31] Simon Willison: you need to be able to say,[00:47:32] swyx: click here.[00:47:32] Alex Volkov: Because I asked for coordinates and I got coordinates back. I literally uploaded the picture and it said, hey, give me a bounding box. And it gave me a bounding box. And it also.[00:47:40] I remember, like, the first demo. Maybe it went away from that first demo. Swyx, do you remember the first demo? Like, Brockman on stage uploaded a Discord screenshot. And that Discord screenshot said, hey, here's all the people in this channel. Here's the active channel. So it knew, like, the highlight, the actual channel name as well.[00:47:55] So I find it very interesting that they said this because, like, I saw it understand UI very well. So I guess it it, it, it, it, like, we'll find out, right? Many people will start getting these[00:48:04] swyx: tools. Yeah, there's multiple things going on, right? We never get the full capabilities that OpenAI has internally.[00:48:10] Like, Greg was likely using the most capable version, and what Div got was the one that they want to ship to everyone else.[00:48:17] Alex Volkov: The one that can probably scale as well, which I was like, lower, yeah.[00:48:21] Simon Willison: I've got a really basic question. How do you tokenize an image? Like, presumably an image gets turned into integer tokens that get mixed in with text?[00:48:29] What? How? Like, how does that even work? And, ah, okay. Yeah,[00:48:35] swyx: there's a, there's a paper on this. It's only about two years old. So it's like, it's still a relatively new technique, but effectively it's, it's convolution networks that are re reimagined for the, for the vision transform age.[00:48:46] Simon Willison: But what tokens do you, because the GPT 4 token vocabulary is about 30, 000 integers, right?[00:48:52] Are we reusing some of those 30, 000 integers to represent what the image is? Or is there another 30, 000 integers that we don't see? Like, how do you even count tokens? I want tick, tick, I want tick token, but for images.[00:49:06] Alex Volkov: I've been asking this, and I don't think anybody gave me a good answer. Like, how do we know the context lengths of a thing?[00:49:11] Now that, like, images is also part of the prompt. How do you, how do you count? Like, how does that? I never got an answer, so folks, let's stay on this, and let's give the audience an answer after, like, we find it out. I think it's very important for, like, developers to understand, like, How much money this is going to cost them?[00:49:27] And what's the context length? Okay, 128k text... tokens, but how many image tokens? And what do image tokens mean? Is that resolution based? Is that like megabytes based? Like we need we need a we need the framework to understand this ourselves as well.[00:49:44] swyx: Yeah, I think Alessio might have to go and Simon. I know you're busy at a GitHub meeting.[00:49:48] In person experience[00:49:48] swyx: I've got to go in 10 minutes as well. Yeah, so I just wanted to Do some in person takes, right? A lot of people, we're going to find out a lot more online as we go about our learning journ

Azure Container Storage offers highly scalable, cost-efficient, and performant storage, built natively for containers. Azure Container Storage simplifies management, deployment, and orchestration of storage volumes seamlessly across volume types including Azure Disk Storage, Azure Elastic SAN, and ephemeral disks. Vybava Ramadoss joins Scott Hanselman to show how you can scale up to multiple users in real time on JupyterHub with Azure Kubernetes Service and Azure Container Storage. Chapters 00:00 - Introduction 02:23 - Why Azure Container Storage? 04:10 - Inside Azure Container Storage 06:15 - Demo setup 07:45 - Demo 16:10 - Wrap-up Recommended resources What is Azure Container Storage? Transforming containerized applications with Azure Container Storage—now in preview Quickstart: Use Azure Container Storage Preview with Azure Kubernetes Service Public preview: Azure Container Storage Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Azure Friday | Twitter: @AzureFriday Azure | Twitter: @Azure Contact the team

Azure Container Storage offers highly scalable, cost-efficient, and performant storage, built natively for containers. Azure Container Storage simplifies management, deployment, and orchestration of storage volumes seamlessly across volume types including Azure Disk Storage, Azure Elastic SAN, and ephemeral disks. Vybava Ramadoss joins Scott Hanselman to show how you can scale up to multiple users in real time on JupyterHub with Azure Kubernetes Service and Azure Container Storage. Chapters 00:00 - Introduction 02:23 - Why Azure Container Storage? 04:10 - Inside Azure Container Storage 06:15 - Demo setup 07:45 - Demo 16:10 - Wrap-up Recommended resources What is Azure Container Storage? Transforming containerized applications with Azure Container Storage—now in preview Quickstart: Use Azure Container Storage Preview with Azure Kubernetes Service Public preview: Azure Container Storage Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Scott Hanselman | Twitter: @SHanselman Azure Friday | Twitter: @AzureFriday Azure | Twitter: @Azure Contact the team

WWW vs The Spatial Web #futureofai #artificialintelligence by Denise Holt Digital technology has grown into a space where we now have multiple devices — computers, mobile phones, iPads, smart TVs, game consoles, smart watches, smart appliances, etc… all connecting through a singular IP address (your home or office). In the next 10 years, trillions of new IOT (internet of things) sensors will be coming online. Every thing will be attempting to connect and share data. The biggest challenge with the World Wide Web, is that it was created to share pages of information — web pages. With the increase in bandwidth and chip speeds over time, we have jackhammered out of that technology the ability to share media within those pages, even real-time streaming of video and audio communications, so we actually feel like we are connected in a physical and digital way. The reality, however, is that today's internet technology is extremely limited and stifled in the possibilities of merging physical and digital experiences. Consider some of the Metaverse spaces that have come online in the past year or so. Much of the general public is confused by what appears to be poor graphics, as if we have gone backwards in time (think Decentraland). The non-technical user doesn't understand that decentralized applications (dApps) require more resources to perform multiple operations over many systems that are all working together. The World Wide Web, Web 2.0, is just not capable of handling that demand well without sacrificing either graphics or speed. We are also missing some critical data points that are necessary to make sense of the data, and we are stuck in a situation of giving away our data through use, rather than being able to own and protect our own data from the inception. The Spatial Web solves for this by expanding on the Web 2.0 internet model by providing a Digital ID (DID) to every Metaverse and every Digital Twin of real-world spaces. The new open, non-commercial protocol for the Spatial Web is called HSTP (Hyperspace Transaction Protocol). This is the missing glue for Web 3.0. This new protocol enables the interoperability for all spaces and objects. We are not just connecting information through computers anymore. We are connecting every person, place or thing, both real and virtual. The main difference between the internet as we know it and the Spatial Web is this: WWW domains are Stateless. The data being produced and shared through interactions on the Web 2.0 internet does not get captured within those interactions on the web itself. There are no web channels making decisions along the way and recording actions as the data travels between servers. The data interactions and modifications are documented within the endpoint servers, ie user info, user behavior, exchanges of data, data requests, permissions, etc… So, you as the user, have no control over what happens to this data. It's a byproduct of your usage. The corporations who own and govern the endpoints of the exchanges of information, ie, browsers and servers, they own that accumulated data, and they get to decide what to do with it. Thus far, they have monetized the heck out it for their own benefit and corporate profits, ie, Google Chrome, Apple Safari, Facebook, etc… On the other hand, the Spatial Web is Stateful. Through HSTP (Hyperspace Transaction Protocol), the data is generated by and between 3D locations, modeling objects in space in a very standardized way using HSML (Hyperspace Modeling Language). Read more at SpatialWebAI ______________________ Special thanks to Dan Mapes, President and Co-Founder, VERSES AI and Director of The Spatial Web Foundation. If you'd like to know more about The Spatial Web, I highly recommend a helpful introductory book written by Dan and his VERSES Co-Founder, Gabriel Rene, titled, “The Spatial Web,” with a dedication “to all future generations.” Listen to more episodes in my Knowledge Bank Playlist to learn everything you need to know to stay ahead of this rapidly accelerating technology. Check out more at, SpatialWebAI #futureofai #artificialintelligence #spatialweb #intelligentagents #aitools

Readme Ops. I love it! And wanted to find out more. So Adam Christian, CEO of Stateful kindly joined me to explain the phrase they have coined. Ah, documentation! Imagine a Readme where the samples you run actually work? Runable commands should become runabale – out of the box with Runme. It's not magic, it's the passion of Adam Christian and his team at Stateful to address the epidemic of non-maintained documentations. Richard and Adam discuss the ideal customer and target market for this Readme Ops product. Open Source projects and larger enterprises are ideal, but really there is a need for this in many, many scenarios. So what's their DevRel strategy?

https://go.dok.community/slack https://dok.community/ https://youtu.be/KjiK6eXYO34 DoK Talk with W Watson, Founder at Vulk Co-op

Benjamin Elder is a Senior Software Engineer at Google, a Kubernetes SIG Testing Chair & Tech Lead, and a Kubernetes Steering Committee member. In this episode we got to chat with Benjamin about the new kubernetes registry migration from k8s.gcr.io to registry.k8s.io. We also had an opportunity to discuss the community, the various SIG's (Special Interest Groups) Benjamin is involved with the amount of work needed to drive the project forward.   Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod Chatter of the week Google Developer Experts program. ChatGPT. OpenAI Case Study. Kubernetes Jobs API. Job Tracking, to Support Massively Parallel Batch Workloads, Is GA in kubernetes 1.26. Stateful apps on Kubernetes. Kelsey Hightower's take on Databases on Kubernetes twitter space. Kubernetes Resources Model News of the week Linkerd published a 2022 recap The CNCF Cloud Native Maturity Model The CNCF Cloud Native Maturity Model website Using Amazon EKS with Google Workspace identities CNCF Ambassador 2.0 program Cloud Native Security Con NA 2023 (website - recordings) The CNCF important updates for KubeCon + CloudNativeCon 2023 and co-located events Kubernetes 1.26 news: https://kubernetes.io/blog/ Eviction policy for unhealthy pods guarded by PodDisruptionBudgets:https://kubernetes.io/blog/2023/01/06/unhealthy-pod-eviction-policy-for-pdbs/ Retroactive Default StorageClass: https://kubernetes.io/blog/2023/01/05/retroactive-default-storage-class/ Alpha support for cross-namespace storage data sources: https://kubernetes.io/blog/2023/01/02/cross-namespace-data-sources-alpha/ Advancements in Kubernetes Traffic Engineering: https://kubernetes.io/blog/2022/12/30/advancements-in-kubernetes-traffic-engineering/ Job Tracking, to Support Massively Parallel Batch Workloads, Is Generally Available: https://kubernetes.io/blog/2022/12/29/scalable-job-tracking-ga/ CPUManager goes GA: https://kubernetes.io/blog/2022/12/27/cpumanager-ga/ Pod Scheduling Readiness: https://kubernetes.io/blog/2022/12/26/pod-scheduling-readiness-alpha/ Support for Passing Pod fsGroup to CSI Drivers At Mount Time: https://kubernetes.io/blog/2022/12/23/kubernetes-12-06-fsgroup-on-mount/ GA Support for Kubelet Credential Providers: https://kubernetes.io/blog/2022/12/22/kubelet-credential-providers/ Introducing Validating Admission Policies: https://kubernetes.io/blog/2022/12/20/validating-admission-policies-alpha/ Device Manager graduates to GA: https://kubernetes.io/blog/2022/12/19/devicemanager-ga/ Non-Graceful Node Shutdown Moves to Beta: https://kubernetes.io/blog/2022/12/16/kubernetes-1-26-non-graceful-node-shutdown-beta/ Alpha API For Dynamic Resource Allocation: https://kubernetes.io/blog/2022/12/15/dynamic-resource-allocation/ Windows HostProcess Containers Are Generally Available: https://kubernetes.io/blog/2022/12/13/windows-host-process-containers-ga/ We're now signing our binary release artifacts!: https://kubernetes.io/blog/2022/12/12/kubernetes-release-artifact-signing/   Links from the interview Benjamin Elder LinkedIn Github Twitter Kubernetes Steering Committee Kubernetes SIG Testing Kubernetes IN Docker (KIND) Benjamin on the podcast episode 96 Paris Pittman LinkedIN Twitter Kubernetes registry move from k8s.gcr.io to registry.k8s.io Archeio is the tool used to redirect to GCR or S3 depending on the client. The design of how requests are handled. Doc detailing the background of this migration. Kubernetes SIG Contributor Experience Kubernetes Slack channel

Die App muss skalieren. Das kann doch nicht so schwer sein, oder?Sekundenschnelles und automatisches Hochskalieren bei einem erhöhten Traffic-Aufkommen. So oder so ähnlich versprechen es die Cloud-Hyperscaler in ihren Marketing-Texten. Das erweckt oft den Anschein, dass das Ganze gar nicht so schwer sein kann. Doch ist dies auch in der Realität so? Eine Applikation skalierbar zu gestalten, ist bei weitem nicht einfach. Stichworte wie Ausfallsicherheit, vertikale- oder horizontale Skalierung, Stateless- oder Stateful-Applications, Loadbalancer und Auto-Discovery, Kubernetes und zusätzliche Code-Komplexität, finanzieller Impact, Load-Tests, Request-Deadlines, Chaos Monkey und Down-Scaling. Alles Begriffe, die damit in Verbindung stehen und einen wichtigen Bestandteil ausmachen.In dieser Episode geben wir einen Überblick über das Thema Application-Skalierung: Was ist das? Wer braucht es? Was sind die Grundbegriffe und welche Grundlagen müssen erfüllt werden, damit das ganze erfolgreich wird?Bonus: Warum Andy eine Märchenstimme hat und warum wir Milchmädchenrechnung nicht mehr sagen sollten.Feedback (gerne auch als Voice Message)Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskWhatsApp +49 15678 136776Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach Audiodatei per Email oder WhatsApp Voice Message an +49 15678 136776LinksRule of 40: https://aktien.guide/blog/rule-of-40-einfach-erklaertKubernetes: https://kubernetes.io/Amazon S3: https://aws.amazon.com/de/s3/Vitess: https://vitess.io/Ceph: https://ceph.io/Chaos Monkey: https://github.com/Netflix/chaosmonkey/Zu Besuch bei Hetzner Datacenter: https://www.youtube.com/watch?v=F0KRLaw8Di8ProxySQL: https://proxysql.com/PlanetScale: https://planetscale.com/Sprungmarken(00:00:00) Intro(00:00:35) Das Märchen der Skalierung und meine Datenbank skaliert nicht(00:02:55) Was ist Skalierung?(00:06:45) Braucht man Skalierung überhaupt? Wer muss skalieren?(00:12:41) Es ist cool auf Scale zu arbeiten(00:16:23) Wenn wir skalieren können, sparen wir Geld(00:20:50) Stateless vs. Stateful-Systeme(00:31:43) Horizontaler vs. Vertikaler skalierung(00:35:38) Ab wann skaliere ich die Hardware oder optimiere die Applikation?(00:39:24) Gesteigerte Komplexität durch Skalierung(00:42:42) Was braucht ihr, um skalieren zu können bzw. damit anzufangen?(00:48:49) OutroHostsWolfgang Gassler (https://mastodon.social/@woolf)Andy Grunwald (https://twitter.com/andygrunwald)Feedback (gerne auch als Voice Message)Email: stehtisch@engineeringkiosk.devMastodon: https://podcasts.social/@engkioskTwitter: https://twitter.com/EngKioskWhatsApp +49 15678 136776

Nesse episódio Luan Moreno & Mateus Oliveira entrevistam Timo Walther, atualmente como Principal Software Engineer na Confluent após a recente aquisição da Immerok pela Confluent Cloud.O Apache Flink é uma engine de processamento de dados unificada que aplica tanto batch quanto tempo-real. Tem ganhado grande adoção entre as grandes empresas por oferecer um modelo de computação extremamente eficiente, principalmente para streaming e computação que retenha estado (stateful). Além de ser uma plataforma Open Source, capaz de responder aos seguintes requisitos de forma efetiva como:In-Memory ProcessingGraph ProcessingBatch ProcessingReal-Time Stream ProcessingNesse bate papo falamos sobre os seguintes temas:State Backend & RocksDBProcessamento de Dados em Tempo RealComunicação entre API de Alto e Baixo NívelCheckpoint & EOS (Exactly-Once Semantics)Recursos e Melhores Práticas para ImplementaçãoAprenda como o Apache Flink pode ser adicionado a seus pipelines de dados e como ele pode se diferenciar como uma plataforma de processamento em tempo-real para atender grandes demandas de dados.Apache FlinkConfluent Cloud + ImmerokTimo Walther Luan Moreno = https://www.linkedin.com/in/luanmoreno/

https://go.dok.community/slack https://dok.community/ Link: https://youtu.be/n_thXwyJNSU ABSTRACT OF THE TALK Deploying Stateless applications is easy but this is not the case for Stateful applications. StatefulSets are the K8s API object that helps to manage stateful application. Learn about what Stateful sets are, how to create, How it differs from Deployments. BIO Passionate about Cloud Native, Kubernetes, Developer relations KEY TAKE-AWAYS FROM THE TALK This talk is focused on basics of StatefulSet, how StatefulSet differs from Deployments, How to manage Stateful app using StatefulSet

From the DoK Day North America 2022 (https://youtu.be/YWTa-DiVljY) Video - https://youtu.be/Y4tdy9lctEI ABSTRACT Learn how customers are increasingly deploying stateful applications on Kubernetes to benefit from portability, economies of scale, and built-in orchestration capabilities. This talk will include how customers choose between using Kuberentes, or a data Software as a Service (SaaS) and stateful capabilities of Kubernetes across two dimensions - the application orchestration and the storage layer. Also learn about MariaDB SKYSQL, a database software as a service that runs thousands of StatefulSet Pods across multiple zones and regions on Kubernetes.

From the DoK Day North America 2022 (https://youtu.be/YWTa-DiVljY) Video - https://youtu.be/LymPjH6HA3E ABSTRACT Stateless apps are easy to manage. More often than not, a Kubernetes Deployment, with a Service, Ingress, and Horizontal Pod Autoscaler (HPA) is enough. Almost everyone can do it. But, when it comes to stateful applications, things become a bit more complicated. We might need a database and storage. We might need to manage database users and schema. We might need to consider quite a few other things. Stateful apps are harder for everyone, especially if we want to shift left and enable developers to do it themselves. In this talk, we'll try to make the management of stateful applications easy for everyone. We'll accomplish that by creating easy-to-consume services that are made specifically for the needs of our organizations. We'll see how to create new Kubernetes Custom Resource Definitions (CRDs) and controllers using Crossplane. Those controllers will envelop all the tools, resources, and processes we might need. As a result, ops can focus on creating such services while everyone else can consume them (create and manage everything related to stateful apps) without opening JIRA tickets and waiting for others to complete their tasks.

https://go.dok.community/slack https://dok.community/ https://youtu.be/AjvwG53yLMY With: Guy Menahem - Solution Architect, Komodor Bart Farrell - Head of Community, Data on Kubernetes Community ABSTRACT OF THE TALK Stateful workloads are the heart of any application, yet they remain confusing and complicated even to daily K8s practitioners. That's why many organizations shy away from migrating their data - their prized possession - to the unfamiliar stateful realm of Kubernetes. After meeting with many organizations in the adoption phase, I discovered what works best, what to avoid, and how critical it is to gain confidence and the right knowledge in order to successfully adopt stateful workloads. In this talk I will demonstrate how to optimally adopt Kubernetes and stateful workloads in a few steps, based on what I've learned from observing dozens of different adoption journeys. If you are taking your first steps in data on K8s or contemplating where to start - this talk is for you! BIO - A Developer turned Solution Architect. - Working at Komodor, a startup building the first K8s-native troubleshooting platform. - Love everything in infrastructure: storage, networks & security - from 70's era mainframes to cloud-native. - All about “plan well, sleep well”. KEY TAKE-AWAYS FROM THE TALK - Understand how critical stateful workloads are for any system, and that the key challenges to migrating it to Kubernetes are knowledge and confidence. - How to build the foundational knowledge required to overcome adoption challenges by creating a learning path for individuals and teams. - How to gain confidence to run stateful workloads on Kubernetes with support from the community (and yourself!)

https://go.dok.community/slack https://dok.community/ ABSTRACT OF THE TALK How do you make sure your Stateful Workloads remain available when your Kubernetes infrastructure updates? This talk will discuss different strategies of upgrading a Kubernetes cluster, and how you can manage risk for your workload. The talk will showcase demos of each upgrade strategy. BIO Peter is a Senior Software Engineer on GKE at Google. He works on improving Kubernetes for Stateful workloads. His main focus is on enhancing the Kubernetes ecosystem for high availability applications. KEY TAKE-AWAYS FROM THE TALK The mechanics of different upgrade strategies, when to apply a particular upgrade strategy depending on your Stateful workload and how to mitigate risk to your application's availability.

In this panel with Sylvain Kalache, Head of Content at the DoK Community, drives a conversation featuring Nic Vermandé- Principal Developer Advocate at Ondat, Julian Fischer- CEO at anynines, and Sergey Pronin- Group Product Manager at Percona.

https://go.dok.community/slack https://dok.community ABSTRACT OF THE TALK More and more we see stateful workloads pop up in Kubernetes clusters. These workloads generate data that is unique and is ephemeral. During this talk we will discuss the challenges of stateful workloads and how you can successfully protect BIO Working over a decade in IT as a technical expert for Veeam Software. Specializing in backup for the modern hybrid cloud. Passion for scripting and programming. Husband of Lena, father of Lev. KEY TAKE-AWAYS FROM THE TALK Data backup of Kubernetes. DR for Kubernetes

https://go.dok.community/slack https://dok.community/ From the DoK Day EU 2022 (https://youtu.be/Xi-h4XNd5tE) Managing stateful workloads in a containerized environment has always been a concern. However, as Kubernetes developed, the whole community worked hard to bring stateful workloads to meet the needs of their enterprise users. As a result, Kubernetes introduced StatefulSets which supports stateful workloads since Kubernetes version 1.9. Users of Kubernetes now can use stateful applications like databases, AI workloads, and big data. Kubernetes support for stateful workloads comes in the form of StatefulSets. And as we all know, Kubernetes lets us automate many administration tasks along with provisioning and scaling. Rather than manually allocating resources, we can generate automated procedures that save time, it lets us respond faster when peaks in demand, and reduce costs by scaling this down when resources are not required. So, it's really important to capture autoscaling in terms of stateful workloads in Kubernetes for better fault tolerance, high availability, and cost management. There are still a few challenges regarding Autoscaling Stateful Workloads in Kubernetes. They are related to horizontal/vertical scaling and automating the scaling process. In Horizontal Scaling when we are scaling up the workloads, we need to make sure that the infant workloads join the existing workloads in terms of collaboration, integration, load-sharing, etc. And make sure that no data is lost, also the ongoing tasks have to be completed/transferred/aborted while scaling down the workloads. If the workloads are in primary-standby architecture, we need to make sure that scale-up or scale-down happens on standby workloads first, so that the failovers are minimized. While scaling down some workloads, we also need to ensure that the targeted workloads are excluded from the voting to prevent quorum loss. Similarly, while scaling up some workloads, we need to ensure that new workloads join the voting. When new resources are required, we have to make the tradeoff between vertical scaling and horizontal scaling. And when it comes to Automation, we have to determine how to generate resource (CPU/memory) recommendations for the workloads. Also, when to trigger the autoscaling? Let's say, a group of workloads may need to be autoscaled together. For example, In sharded databases, each shard is represented by one StatefulSet. But, all the shards are treated similarly by the database operator. Each shard may have its own recommendations. So, we have to find a way to scale them with the same recommendations. Also, we need to determine what happens when an autoscaling operation fails and what will happen to the future recommendations after the failure? There can be some workloads that may need a managed restart. For example, in a database, secondary nodes may need to be restarted before the primary. In this case, how to do a managed restart while autoscaling? Also, we need to figure out what happens when the workloads are going through maintenance? We will try to answer some of those questions throughout our session. ----- Fahim is a Software Engineer, working at AppsCode Inc. He has been involved with Kubernetes project since 2018 and is very enthusiastic about Kubernetes and open source in general. ----- MD Kamol Hasan is a Professional Software Developer with expertise in Kubernetes and backend development in Go. One of the lead engineers of KubeDB and KubeVault projects. Competitive contest programmer participated in different national and international programming contests including ACM ICPC, NCPC, etc

https://go.dok.community/slack https://dok.community/ From the DoK Day EU 2022 (https://youtu.be/Xi-h4XNd5tE) Kubernetes comes with a lot of useful features like Volumes and StatefulSets, which make running stateful workloads simple. Interestingly, when combined with the right tools, these features can make Kubernetes very valuable for developers wanting to run massive production databases in development! This is exactly what was seen at "Extendi". The developers at Extendi deal with a large amount of data in their production Kubernetes clusters. But when developing locally, they didn't have an easy way of replicating this data. This replication was needed because it allowed developers to test new features instantaneously without worrying if they would work as expected when pushed to production. But replicating a 100Gb+ production database for development wasn't turning out to be an easy task! This is where leveraging Kubernetes + remote development environments came to the rescue. Running data on Kubernetes turned out to be way faster than any of the traditional approaches because of Kubernetes' ability to handle stateful workloads exceptionally well. And since Extendi already used Kubernetes in production - the setup process was fairly simple. This talk will cover practical steps on how leveraging Kubernetes based development environments allowed dev teams at Extendi to run production data on Kubernetes during development using features like Volume Snapshots, having a huge positive impact on developer productivity. Arsh is a Developer Experience Engineer at Okteto. He is an active contributor to the upstream Kubernetes project and was awarded the Kubernetes Contributor Award for his contributions in 2021. Arsh has written blogs and spoken about different topics in the cloud-native ecosystem at various conferences before, including KubeCon + CloudNativeCon + Open Source Summit China 2021. He has also been on the Kubernetes Release Team since the 1.23 release. He also serves as the New Contributor Ambassador for the Documentation Special Interest Group of the Kubernetes project and continuously mentors new folks in the community. Previously, he worked at VMware and was an active contributor to other CNCF projects, including cert-manager and Kyverno. Lapo is a Software Engineer currently leading the development team of a Social Listening and Audience Intelligence platform. He started coding at the early age of 14 and since he turned his passion into a real job, he has always been looking for boosting his knowledge by constantly researching for newer and newer technologies. Active on Ruby Open Source projects Ramiro Berrelleza is one of the founders of Okteto. He has spent most of his career (and his free time) building cloud services and developer tools. Before starting Okteto, Ramiro was an Architect at Atlassian and a Software Engineer at Microsoft Azure. Originally from Mexico, he currently lives in San Francisco.

https://go.dok.community/slack https://dok.community/ From the DoK Day EU 2022 (https://youtu.be/Xi-h4XNd5tE) The Rap God project acts as a great entry point to many incoming open-source enthusiasts who are interested in learning about the cloud native ecosystem. The Rap-God project uses Kubernetes orchestration for a stateful case which is an emerging topic, the Rap God project acts as a demonstration of how to use such features of Kubernetes. The project will be using Stateful sets that'd deploy Apache Cassandra (for its first cycle) and eventually it'll be implementing the same API endpoints for various databases that will be with/on Kubernetes. We in the community intend to do this with PersistenceVolumes and Persistent Volume Claims. Keeping in mind the issues, various developers face, we also will be making options for storage classes. The project will allow the members to explore how they can customize the whole storage class setup according to their setup. The project will be bringing Helm, Cassandra, Kubernetes and Argo under its watch and shall actively expand on its implementation with the further iterations. Abhijith Ganesh is an undergrad computer science major, currently pursuing his Freshman year. His areas of interest include DevOps, Kuberenetes and Open Source Projects. He is an active member of the DoK Community where he is currently an intern. He is also member of the Pyrsia and SeaQL communities.

Although Kubernetes was originally designed to run stateless workloads, the technology has matured over time and enterprises are increasingly adopting the platform to run their stateful applications. In a survey conducted by the Data on Kubernetes community, 90% of the respondents believe that Kubernetes is ready for stateful workloads, and 70% of them are already running them in production with databases taking the top spot. Having the ability to standardize different workloads on Kubernetes and ensure consistency are seen as the key factors that drive value for businesses.Nutanix provides an industry-leading HCI platform that is ideal for running cloud-native workloads running on Kubernetes at scale. The Nutanix architecture offers better resilience for both Kubernetes platform components and application data. With the addition of each HCI node, apart from scaling the Kubernetes compute nodes, there is an additional storage controller as well which results in improved storage performance for your stateful applications. The Nutanix Unified Storage is made available to cloud-native applications with the Nutanix CSI driver. Applications use standard Kubernetes objects such as PersistentVolumeClaims, PersistentVolumes, and StorageClasses to access its capabilities. The CSI driver also enables users to take Persistent Volume snapshots using API objects VolumeSnaphot, VolumeSnapshotContent, and VolumeSnapshotClass. Snapshots represent a point-in-time copy of a volume and can be used to provision a new volume or to restore existing volumes to the previous snapshotted data. OpenShift Container Platform deploys the snapshot controller and the related API objects as part of the Nutanix CSI Operator as described in Blog 3. Host: Andy WhitesideCo-host: Harvey GreenCo-host: Jirah Cox

https://go.dok.community/slack https://dok.community ABSTRACT OF THE TALK Eventually the time will come to run a stateful app in Kubernetes. This can be a scary thing adding more moving parts to a Kubernetes cluster and deploying as well as managing your app on Kubernetes when it requires state. In this talk Steve Buchanan will take you through a journey of understanding how storage works in Kubernetes, how to Persistent state with pods, what storage options are available with Azure Kubernetes Service, best practices, and a demo of deploying a stateful app to AKS. BIO Steve Buchanan is a Principal Program Manager with a leading global tech giant focused on improving the cloud. He is a Pluralsight author, the author of eight technical books, and a former 10-time Microsoft MVP. He has presented at tech events, including, DevOps Days, Open Source North, Midwest Management Summit (MMS), Microsoft Ignite, BITCon, Experts Live Europe, OSCON, Inside Azure management, and user groups. He has been featured in several publications including the Star Tribune (the 5th largest newspaper in the US). He stays active in the technical community and enjoys blogging about his adventures in the world of IT at www.buchatech.com KEY TAKE-AWAYS FROM THE TALK Overview of Storage in Kubernetes covering Storage Classes, Persistent Volumes, & Persistent Volume Claims. Overview of Azure Storage, Best Practices to running stateful apps in Kubernetes.

Idag blir vi än en gång tekniska och förklarar begreppen stateful och stateless. Vi pratar även om varför det ena är att föredra när man bygger sin serverinfrastruktur och sin applikation. Hem till podden: https://citynetwork.se/podcast --- Send in a voice message: https://anchor.fm/stacken/message

https://go.dok.community/slack https://dok.community/ ABSTRACT OF THE TALK Modern web applications are typically comprised of multiple services which utilize storage in a variety of ways. Utilizing storage in Kubernetes introduces challenges that are not obvious while developing locally. We'll introduce these challenges and show good and bad ways to handle them. We'll dive into the details of an application along with its deployment in Kubernetes to understand why certain storage patterns are problematic and how they can be modified to behave well in a Kubernetes-based deployment. BIO Rob Pacheco is currently leading cloud operations at Rumble. Prior to Rumble, Rob spent time at Vision Government Solutions as well as Black Duck Software re-architecting, securing, and containerizing its products to run within containerized environments, including Kubernetes and Google Kubernetes Engine. Rob is also the author of the liveProject “Creating and Managing Cloud Native Services in Kubernetes”, and the upcoming liveVideo “Surviving Kubernetes Deployments as an Application Developer” KEY TAKE-AWAYS FROM THE TALK * Behavior stateful primitives in Kubernetes * Common storage patterns in web applications * Patterns for well-behaved storage in a Kubernetes cluster

Original blog postMore episodes at feeds.transistor.fm/google-cloud-readerMore articles at cloud.google.com/blog

Stateful data streaming analytics

How Kubernetes environments might be able to offer hooks for storage, databases and other sources of persistent data still is a question in the minds of many potential users. To that end, a new consortium called the Data on Kubernetes Community (DoKC)  was formed to help organizations find the best ways of working with stateful data on Kubernetes.In this latest episode of The New Stack Maker podcast, two members of the group discuss the challenges associated with running stateful workloads on Kubernetes and how DoKC can help.Participants for this conversation were Melissa Logan, principal, of Constantia.io, an open source and enterprise tech marketing firm, and director of  DoKC; Patrick McFadin, vice president, developer relations and chief evangelist for the Apache Cassandra NoSQL database platform from DataStax; and Evan Powell, advisor, investor and board member, MayaData, a Kubernetes-environment storage-solution provider.TNS Editor Joab Jackson hosted the podcast.

Stateful containers are becoming a hot topic these days so we thought it a good time to talk to the CNCF (Cloud Native Computing Foundation) Rook team about what they are doing to make storage easier to use for k8s container apps. CNCF put us into contact with Sébastien Han (@leseb_), Ceph Storage Architect and … Continue reading "124: GreyBeards talk k8s storage orchestration using CNCF Rook Project with Sébastien Han & Travis Nielsen, Red Hat"

Stateful containers are becoming a hot topic these days so we thought it a good time to talk to the CNCF (Cloud Native Computing Foundation) Rook team about what they are doing to make storage easier to use for k8s container apps. CNCF put us into contact with Sébastien Han (@leseb_), Ceph Storage Architect and … Continue reading "124: GreyBeards talk k8s storage orchestration using CNCF Rook Project with Sébastien Han & Travis Nielsen, Red Hat"

Jonas Bonér is founder and CEO of Lightbend, creator of the Akka project, initiator and co-author of the Reactive Manifesto and the Reactive Principles, and a Java Champion. Website: http://jonasboner.comTwitter: https://twitter.com/jbonerLinkedIn: https://www.linkedin.com/in/jonasboner/Akka Serverless: https://www.lightbend.com/akka-serverlessAkka: https://akka.io/Reactive Manifesto: https://www.reactivemanifesto.org/Reactive Principles: https://principles.reactive.foundation/

On the podcast this week, our guests Brian Schwarz and Sean Derrington discuss the ins and outs of the new storage launches with your hosts Stephanie Wong and Jenny Brown. Brian gives light introductions to the five facets of Google’s data storage portfolio, like the primary storage solutions for files, storage of backups of data, and data transfer software and hardware. Lately, the Google team has been enhancing existing data solutions and building new ones. Cloud Storage’s multi-region and custom dual-region options easily let customers keep data safe and accessible. Our guests explain what happens behind the scenes to make these features so effective. Brian and Sean describe the user experience, including how clients can see when data is being replicated and where. New capabilities like Turbo Replication allow more modernization for clients moving to the cloud as well. Sean talks about the new Filestore Enterprise, which allows companies to move critical apps to the cloud quickly and securely, and we learn why accurate, fast file and data replication is so important for these large customers. If there is corruption or accidental deletion of a file, Brian and Sean tell us about the fail-safes that are in place and the process for recovery. Filestore Enterprise, Filestore Basic, and GKE working together offer a more customized approach for large clients, allowing them to allocate their critical projects to Enterprise and other less important applications to Basic. Stateful applications in containers are becoming more popular as well, and our guests tell us how Backup for GKE is the easiest way to protect GKE workloads. Brian Schwarz Brian has had 20 years in product management in data center infrastructure. Before Google, he spent time at Veritas, Cisco, and most recently Pure Storage. Sean Derrington Sean has spent 20 years in storage product management. Before Google, he spent time at Veritas, Exablox, and StorageCraft. Cool things of the week Run code samples directly in the Google Cloud documentation blog Why representation matters: 6 tips on how to build DEI into your business blog Google Cloud announces new Cloud Digital Leader training and certification blog Google Cloud Next site Interview GKE site Google Cloud Storage site Filestore site Filestore Enterprise docs New storage features help ensure data is never lost blog Announcing Filestore Enterprise, for your most demanding apps blog Announcing Backup for GKE: the easiest way to protect GKE workloads blog Webinar: What’s New with Storage at Google Cloud site What’s something cool you’re working on? Jenny is working on Google Cloud Reader and further audio formats for all your favorite cloud content.

You know what really grinds Chris' gears? (Spoiler Alert: It's Single-Page Applications.) Steph needs some consulting help. So much to do, so little time. Sarah Drasner tweet about shared element transitions (https://twitter.com/sarah_edo/status/1431282994581413893) Article about Page Transitions API (https://developer.chrome.com/blog/shared-element-transitions-for-spas/) Svelte Crossfade layout demo (https://svelte.dev/repl/a7af336f906c4caab3936972754e4d6f?version=3.23.2) Svelte Crossfade tutorial page (https://svelte.dev/tutorial/deferred-transitions) (Note - click "Show Me" on the bottom left) Transcript: CHRIS: I have restarted my recording, and we are now recording. And we are off on the golden roads. Isn't software fun? STEPH: Podcast battle. Here we go! Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari. CHRIS: And I'm Chris Toomey. STEPH: And together, we're here to share a bit of what we've learned along the way. Hey, Chris, happy Friday. How's your week been? CHRIS: Happy Friday to you as well. My week's been good with the exception of right before we started this recording, I had one of those experiences. You know the thing where software is bad and software is just terrible overall? I had one of those. And very briefly to describe it, I started recording, but I could hear some feedback in my headphones. So I was like, oh no, is that feedback going to show up on the final recording? Which I really hope it doesn't. Spoiler alert - listener, if I sound off, sorry about that. But so I stopped recording and then I went to go listen to the file, and I have our audio software configured to record directly to the desktop. And it does that normally quite well. But for some reason, the file wasn't there. But I remember this recently because I ran into it another time. For some reason, this is Finder failing me. So the thing that shows me the files in a graphical format, at least on my operating system. Although I think it also messes up in the terminal maybe. That feels like it shouldn't be true, but maybe it is. Anyway, I had to kill all Finder from the terminal to aggressively restart that process. And then suddenly, Finder was like, oh yeah, there's totally files there, absolutely. They were there the whole time. Why do you even ask? And I know that state management is a hard problem, I am aware. I have felt this pain. I have been the person who has introduced some bugs related to it, but that's not where I want to experience it. Finder is one of those applications that I want to just implicitly trust, never question whether or not it's just sneakily telling me that there are files that are not there or vice versa. So anyway, software. STEPH: I'm worried for your OS. I feel like there's a theme lately [chuckles] in the struggles of your computer. CHRIS: On a related note, I had to turn off transparency in my terminal because it was making my computer get very hot. [chuckles] STEPH: Oh no, you're not a hacker any more. CHRIS: I'm not. [chuckles] I just have a weird screen that's just dark. And jellybeans is my color scheme, so there's that going on. That's in Vim specifically. Pure is my prompt. That's a lovely little prompt. But lots of Day-Glo colors on just a black background, not the cool hacker transparency. I have lost some street cred. STEPH: What is your prompt? What did you say it is? CHRIS: Pure. STEPH: Pure, I don't know that one. CHRIS: It is by Sindre Sorhus; I think is his name. That's his Twitter handle, GitHub name. He is a prolific open-source creator in the Node world, particularly. But he created this...I think it's a Bash and a Zsh prompt. It might be for others as well. It's got a bunch of features. It's pretty fast. It's minimal. It got me to stop messing around with my prompt, which was mostly what I was going for. And it has a nice benefit that occasionally now I'll be pairing with someone, and I'll be like, "Your prompt looks like my prompt. Everything is familiar. This is great." STEPH: Well, if you get back in the waters of messing around with your prompts again, I'm using Starship. And I hadn't heard of Pure before, but I really like Starship. That's been my new favorite. CHRIS: Wow. STEPH: Wow. CHRIS: I mean, on the one hand… STEPH: You're welcome. [laughs] CHRIS: On the one hand, thank you. On the other hand, again, let me lead in with the goal was to stop messing around with my prompt. So you're like, oh, cool. Here's another prompt for you, though. [chuckles] STEPH: [laughs] But my goal is to nerd snipe you into trying more things because it's fun. CHRIS: I don't know if you know this, but I am impervious to nerd sniping. STEPH: [laughs] CHRIS: So try as you might, I shall remain steady in my course of action. STEPH: Are we playing two truths and a lie? Is that what we're doing today? [laughs] CHRIS: Nah, just one lie. It's easier. Everybody wins one lie. STEPH: [laughs] CHRIS: But anyway, in other news, we're going to do a segment called this really grinds my gears. That's today's segment, which is much like when I do a good idea, terrible idea. But this is one that I'm sure I've talked about before. But there's been some stuff that I saw moving around on the internet as one does, and it got these ideas back into my head. And it's around the phrase single-page application. I am not a fan of that phrase or SPA as the initialism. Thank you, Edward Loveall, for teaching me the difference between an initialism and an acronym. I really hope I'm getting it right, by the way, [laughs] SPA as people call them these days. I feel weird because of how much I care about this thing, how much I care about this idea, and how much whenever I hear this acronym, I get a little bit unhappy. And so there's a part of it that's I really do think our words shape our thinking. And I think single-page application has some deeply problematic ideas. Most notably, I think one of the most important things about building web applications is the URL. And those are different pages, at least in my head. I don't know of a different way to think about this. But if you are not emphasizing the URL and the fact that the URL is a way to address different pages or resources within your application, then you are throwing away one of the greatest advancements that humankind has made, in my mind. I care a lot about URLs; it turns out. And it's not inherent to an SPA that you will not be thinking about URLs. But again, in that idea that our words shape our thinking, by calling it an SPA, by leaning into that idea, I think you are starting down a path that leads to bad outcomes. I'm going to pause there because I'm getting kind of ranty. I got more to say on the topic. But what do you think? STEPH: Yeah, these are hot takes. I'm into it. I'm pretty sure that I know why URLs are so important to you and more of your feelings around why they're important. But would you dive in a bit deeper as to why you really cherish URLs, and why they're so important, and why they're one of the greatest advancements of humanity? CHRIS: [laughs] It sounds lofty when you say it back to me, but yeah. It's interesting that as you put into a question, it is a little bit hard to name. So there are certain aspects that are somewhat obvious. I love the idea that I can bookmark or share a given resource or representation of a resource very simply. Like the URL, it's this known thing. We can put hyperlinks in a document. It's this shared way to communicate, frankly, very complex things. And when I think of a URL, it's not just the domain and the path, but it's also any query parameters. So if you imagine faceted search on a website, you can be like, oh, filter down to these and only ones that are more than $10, and only ones that have a future start date and all those kinds of nuance. If you serialize that into the URL as part of the query param, then that even more nuanced view of this resource is shareable is bookmarkable is revisitable. I end up making Alfred Workflows that take advantage of the fact that, like, oh, I can look at this URL scheme, and I can see where different parts are interpolated. And so I can navigate directly to any given thing so fast. And that's deeply valuable, and it just falls naturally out of the idea that we have URLs. And so to not deeply embrace that, to not really wrap your arms around it and give that idea a big hug feels weird to me. STEPH: Yeah, I agree. I remember we've had this conversation in the past, and it really frustrates me when I can't share specific resources with folks because I don't know how to link to it. So then I can send you a link to the application itself to the top URL. But then I have to tell you how to find the information that I thought was really helpful. And that feels like a step backward. CHRIS: Yeah. That ability to say, "Follow this link, and then it will be obvious," versus "Go to this page, click on this thing, click on the dropdown, click on this other thing." Like, that's just a fundamentally different experience. So one of the things that I saw that got me thinking about this was I saw folks referring to single-page applications but then contrasting them with MPAs, which are multiple-page applications. STEPH: So the normal application? [laughs] CHRIS: And I was like, whoa, whoa, everybody. You mean like a website or a web app? As much as I was angry at the first initialism, this second one's really getting me going. But it really does speak to what are we doing? What are we trying to build? And as with anything, you could treat this as a binary as just like there are two options. There are either websites which, yeah, those have got a bunch of URLs, and that's all the stuff. And then there are web apps, and they're different. And it's a bundle of JavaScript that comes down, boots up on the client, and then it's an app thing. And who cares about URLs? I think very few people would actually fall in that camp. So I don't really believe that there is a dichotomy here. I think, as always, it's a continuum; it's a spectrum. But leaning into the nomenclature of single-page application, I think pushes you more towards that latter end of the spectrum. I think there are other things that fall out of it. Like, I believe deeply in having the server know more, have more of the logic, own more of the logic, own more authorization and routing, and all of those things because really great stuff falls out of that. And that one has more of a trade-off, I'd say. But I won't name any names, but there is a multiple billion-dollar company whose website I had to interact with recently. And you land on their page on their marketing site. And then, if you click log in, it navigates you to the application, so a separate domain or a separate subdomain, the application subdomain, and the login page there. And the login page renders, and then I go to fill in my username and password. Like, my mouse makes it all the way to click on the little box or whatever I'm doing if I'm using keyboard things. But I have enough time to actually start to interact with this page. And then suddenly, it rips away, and it actually just renders the authenticated application because it turns out I was already logged in. But behind the scenes, they're doing some JWT dance around that they're checking; oh no, no, you're already logged in, so never mind. We don't need to show you the login page, but I was already on the login page. And my feeling is this sort of brittle UI; this sort of inconsistency erodes my trust in that application, particularly when I'm on the login page. That is a page that matters. I don't believe that they're doing anything fundamentally insecure. But I do have the question in my head now. I'm like, wait, what's going on there, everybody? Is it fine? Was that okay? Or if you see something that you shouldn't see and then suddenly it's ripped away from you, if you see half of a layout that's rendered on a page and then suddenly you see, no, no, no, you actually don't have access to that page, that experience erodes my trust. And so, I would rather wait for the server to fully resolve, determine what's going to happen, and then we get a response that is holistically consistent. You either have access, or you don't, that sort of thing. Give me a loading indicator; give me those sorts of things. I'm fine with that. But don't render half of a layout and then redirect me back away. STEPH: I feel like that's one of the problems with knowing too much because most people are not going to pick up on a lot of the things that you're noticing and caring deeply about where they would just see like, oh, I was logged in and be like, huh, okay, that was a little weird, but I'm in and just continue on. Versus other folks who work very closely to this who may recognize and say, "That was weird." And the fact that you asked me to log in, but then I was already logged in, did you actually log me in correctly? What's happening? And then it makes you nervous. CHRIS: Maybe. Probably. But I wonder…the way you just said that sounds like another dichotomy. And I would say it's probably more of a continuum of an average not terribly tech-savvy user would still have a feeling of huh, that was weird. And that's enough. That's a little tickle in the back of your brain. It's like, huh, that was weird. And if that happens enough times or if you've seen someone who uses an application and uses it consistently, if that application is reasonably fast and somewhat intuitive and consistent, then they can move through it very quickly and very confidently. But if you have an app that half loads and then swaps you to another page and other things like that, it's very hard to move confidently through an application like that. I do think you're right in saying that I am over-indexed on this, and I probably care more than the average person, but I do care a lot. I do think one of the reasons that I think this happens is mobile applications came along, and they showed us a different experience that can happen and also desktop apps for some amount of time this was true. But I think iOS apps, in particular really great ones, have super high fidelity interactions. And so you're like, you're looking at a list view, and then you click on the cell for that list view. And there's this animated transition where the title floats up to the top and grows just a little bit. And the icon that was in the corner moves up to the corner, and it gets a little bigger. And it's this animated transition to the detailed view for that item. And then if you go back, it sort of deanimates back down. And that very consistent experience is kind of lovely when you get it right, but it's really, really hard. And people, I think, have tried to bring that to the web, but it's been such a struggle. And it necessitates client-side routing and some other things, or it's probably easiest to do if you have those sorts of technologies at play, but it's been a struggle. I can't think of an application that I think really pulls that off. And I think the trade-offs have been very costly. On the one positive note, there was a tweet that I saw by Sarah Drasner that was talking about smooth and simple page transitions with the shared element transition API. So this is a new API that I think is hoping to bring some of this functionality to the web platform natively so that web applications can provide that higher fidelity experience. Exactly how it'll work whether or not it requires embracing more of the single-page application, client-side routing, et cetera, I'm not sure on that. But it is a glimmer of hope because I think this is one of the things that drives folks in this direction. And if we have a better answer to it, then maybe we can start to rethink the conversation. STEPH: So I think you just said shared element transitions. I don't know what that is. Can you talk more about that? CHRIS: I can try, or I can make a guess. So my understanding is that would be that sort of experience where you have a version of a certain piece of content on the page. And then, as you transition to a new page, that piece of content is still represented on the new page, but perhaps the font size is larger, or it's expanded, or the box around it has grown or something like that. And so on mobile, you'll often see that animate change. On the web, you'll often see the one page is just completely replaced with the other. And so it's a way to have continuity between, say, a detailed view, and then when you click on an item in it, that item sort of grows to become the new page. And now you're on the detail page from the list page prior. There's actually a functionality in Svelte natively for this, which is really fancy; it's called crossfade. And so it allows you to say, "This item in the component hierarchy in the first state of the application is the same as this item in the second state of the application." And then, Svelte will take care of transitioning any of the properties that are necessary between those two. So if you have a small circle that is green, and then in the next state of the application, it's a blue rectangle, it will interpolate between those two colors. It will interpolate the shape and grow and expand it. It will float it to its new location. There is a really great version of it in the Svelte tutorial showing a to-do list. And so it's got a list on the left, which is undone things, and a list on the right that is done things. And when you click on something to complete it, it will animate it, sort of fly across to the other list. And if you click on it to uncomplete, it will animate it and fly back. And what's great is within Svelte because they have this crossfade as a native idea; all you need to say is like, "It was on this list, now it's on this list." And as long as it's identifiable, Svelte handles that crossfade and all the animations. So it's that kind of high-fidelity experience that I think we want. And that leads us to somewhat more complex applications, and I totally get that. I want those experiences as well. But I want to ask some questions, and I want to do away with the phrasing single-page application entirely. I don't want to say that anymore. I want to say URLs are one honking good idea. Let's have more of those. And also, just to name it, Inertia is a framework that allows me to build using some of the newer technologies but not have to give up on URLs, give up on server-side logic as the primary thing. So I will continue to shout my deep affection for Inertia in this moment once again. STEPH: Cool. Thanks. That was really helpful. That does sound really neat. So in the ideal world, we have URLs. We also have high fidelity and cool interactions and transitions on our pages. We don't have to give it a fancy name like single-page application or then multi-page application. I do wonder, with our grumpiness or our complaint about the URLs, is that fair to call it grumpy? CHRIS: It's fair to call it grumpy, although you don't need to loop yourself in with me. I'm the grump today. STEPH: [laughs] CHRIS: You're welcome to come along for the ride if you'd like. And I'm trying to find a positive way to talk about it. But yeah, it's my grumpytude. STEPH: Well, I do feel similarly where I really value URLs, and I value the ability to bookmark and share, like you said earlier. And I do wonder if there is a way to still have that even if we don't have the URL. So one of the things that I do is I'll inspect the source code. And if I can find an ID that's for a particular header or section on the page, then I will link someone to a section of that page by then adding the ID into the URL, and that works. It's not always great because then I have to rely on that being there. But it's a fix, it's a workaround. So I wonder if we could still have something like that, that as people are building content that can't be bookmarked or the URL doesn't change explicitly, or reference that content, to add more thoughtful bookmark links, essentially, or add an ID and then add a user-facing link that says, "Hey, if you want to link someone to this content, here you go." And under the hood, it's just an ID. But most people aren't going to know how to do that, so then you're helping people be able to reference content because we're used to URLs, so just thinking outside the box. I wonder if there are ways that we can still bookmark this content, share it with people. But it's okay if the URL isn't the only way that we can bookmark or reference that content. CHRIS: It's interesting that you bring that up, so the anchor being the thing after the hash symbol in the URL. I actually use that a ton as well. I think I built a Chrome extension a while back to try what you're saying of I'll inspect the DOM. I did that enough times that I was like, what if the DOM were to just tell me if there were an ID here and I could click on a thing? Some people's blogs...I think the thoughtbot blog has this at this point. All headers are clickable. So they are hyperlinks that append that anchor to the URL. So I wouldn't want to take that and use that functionality as our way to get back to URLs that are addressing resources because that's a way to then navigate even further, which I absolutely love, to a portion of the page. So thinking of Wikipedia, you're on an article, but it's a nice, long article. So you go down to the section, which is a third of the way down the page. And it's, again, a very big page, so you can link directly to that. And when someone opens that in their browser, the browsers know how to do this because it's part of the web platform, and it's wonderful. So we've got domains, we've got paths, we've got anchors, we've got query params. I want to use them all. I want to embrace them. I want that to be top of mind. I want to really think about it and care about that as part of the interface to the application, even though most users like you said, are not thinking about the shape of a URL. But that addressability of content is a thing that even if people aren't thinking of it as a primary concern, I think they know it when they...it's one of those like, yeah, no, that app's great because I can bookmark anything, and I can get to anything, and I can share stuff with people. And I do like the idea of making the ID-driven anchor deep links into a page more accessible to people because you and I would go into the DOM and slice it out. Your average web user may not be doing that, or that's much impossible to do on mobile, so yes, but only more so in my mind. [laughs] I don't want to take anchors and make them the way we do this. I want to just have all the URL stuff, please. Mid-roll Ad Now we're going to take a quick break to tell you about today's sponsor, Orbit. Orbit is mission control for community builders. Orbit offers data analytics, reporting, and insights across all the places your community exists in a single location. Orbit's origins are in the open-source and developer relations communities. And that continues today with an active open-source culture in an accessible and documented API. With thousands of communities currently relying on Orbit, they are rapidly growing their engineering team. The company is entirely remote-first with team members around the world. You can work from home, from an Orbit outpost in San Francisco or Paris, or find yourself a coworking spot in your city. The tech stack of the main orbit app is Ruby on Rails with JavaScript on the front end. If you're looking for your next role with an empathetic product-driven team that prides itself on work-life balance, professional development, and giving back to the larger community, then consider checking out the Orbit careers page for more information. Bonus points if working in a Ruby codebase with a Ruby-oriented team gives you a lot of joy. Find out more at orbit.love/weloveruby. STEPH: I have a confession from earlier when you were talking about the examples for those transitions. And you were describing where you take an action, and then the page does a certain motion to let you know that new content is coming onto the page and the old content is fading away. And I was like, oh, like a page reload? We're just reimplementing a page reload? [laughs] That's what we have? CHRIS: You have a fancy, though. STEPH: Fancy, okay. [laughs] But that felt a little sassy. And then you provided the other really great example with the to-do list. So what are some good examples of a SPA? Do you have any in mind? I think there are some use cases where...so Google Maps, that's the one that comes to mind for me where URLs feel less important. Are there other applications that fit that mold in your mind? CHRIS: Well, so again, it's sort of getting at the nomenclature, and how much does the acronym actually inform what we're thinking about? But taking Google Maps as an example, or Trello is a pretty canonical one in my mind, most people say those are single-page applications. And they are probably in terms of what the tech actually is, but there are other pages in those apps. There's a settings page, and there's a search page, and there's this and that. And there's like the board list in Trello. And so when we think about Trello, there is the board view where you're seeing the lists, and you can move cards, and you can drag and drop and do all the fancy stuff. That is a very rich client-side application that happens to be one page of the Trello web app and that one being higher fidelity, that one being more stateful. Stateful is probably the thing that I would care about more than anything. And so for that page, I would be fine with the portion of the JavaScript that comes down to the client being a larger payload, being more complex, and probably having some client-side state management for that. But fundamentally, I would not want to implement those as a true client-side application, as a true SPA. And I think client-side routing is really the definition point for me on this. So with Trello, I would probably build that as an Inertia-type application. But that one page, the board page, I'd be like, yeah, sorry, this is not going to be the normal Inertia thing. I'm going to have to be hitting JSON endpoints that are specifically built for this page. I'm going to have a Redux store that's local. I'm going to lean into all of that complex state management and do that within the client-side app but not use client-side routing for actual page-level transitions, the same being true for Google Maps. The page where you're looking at the map, and you can do all sorts of stuff, that's a big application. But it is one page within the broader website, if you will. And so, I still wouldn't want client-side routing if I can avoid it because I think that is where I run into the most problems. And that thing I was talking about where I was on the login page for a second, and then I wasn't; I do not like that thing. So if I can avoid that thing, which I have now found a way to avoid it, and I don't feel like I'm trading off on that, I feel like it's just a better experience but still reserving the right to this part of the application is so complex. This is our Wiziwig drag and drop graphical editor thing, cool. That's going to have Redux. That's going to have client-side state management, all that stuff. But at no point does single-page application feel like the right way to describe the thing that we're building because I still want to think about it as holistically part of the full web app. Like the Trello board view is part of the Trello web app. And I want it all to feel the same and move around the same. STEPH: Yeah, that makes sense. And it's funny, as you were mentioning this, I pulled up Google Maps because I definitely only interact with that heavy JavaScript portion, same for Trello. And I wasn't even thinking about the fact that there are settings. By the way, Google Maps does a lot. I don't use hardly any of this. But you make a great point. There's a lot here that still doesn't need such heavy JavaScript interaction and doesn't really fit that mold of where it needs to be a single-page app or even needs to have that amount of interactivity. And frankly, you may want URLs to be able to go specifically to these pages. CHRIS: That actually is an interesting, perhaps counterpoint to what I'm saying. So if you do have that complex part of one of your applications and you still want URL addressability, maybe you need client-side routing, and so that becomes a really difficult thing to answer in my mind. And I don't necessarily have a great answer for that. I'm also preemptively preparing myself for anyone on the internet that's listening to this and loves the idea of single-page applications and feels like I'm just building a straw man here, and none of what I'm saying is actually real and whatnot. And although I try to...I think we generally try and stay in the positive space of like what's good on the internet. This is a rare case where I'm like, these are things that are not great. And so I think in this particular case, leaning into things that I don't like is the way to properly capture this. And giant JavaScript bundles where the entirety of the application logic comes down in 15-megabyte download, even if you're on 3G on a train; I don't like that. I don't like if we have flashes of a layout that they can get ripped away b; it'secause it turns out we actually aren't authorized to view that page, that sort of thing. So there are certain experiences from an end client perspective that I really don't like, and that's mostly what I take issue with. Oh, also, I care deeply about URLs, and if you don't use the URL, then I'm going to be sad. Those are my things. Hopefully, that list is perhaps a better summary of it than like...I don't want it to seem like I'm just coming after SPA as a phrase or a way of thinking because that's not as real of a conversation. But those particular things that I just highlighted don't feel great. And so I would rather build applications that don't have those going on. And so if there's a way to do that that still fits any other mold or is called whatever, but largely what I see called an SPA often has those sorts of edge cases. And I do not like those edge cases. STEPH: Yeah, I like how you're breaking it down where it's less of this whole thing like I can't get on board with any of it. You are focusing on the things that you do have concerns with. So there can be just more interesting, productive conversations around those concerns versus someone feels like they have to defend their view of the world. I have found that I think I'm a bit unique in this area where when people have a really differing opinion than mine, that gets me really excited because then I want to know. Because if I believe very strongly in something and I just think this is the way and then someone very strongly says like, "No, that's not," I'm like, "Oh yeah. Okay, we should talk because I'm interested in why you would have such a different opinion than mine." And so, I typically find those conversations really interesting. As long as everybody's coming forward to be productive and kind, then I really enjoy those conversations. CHRIS: That is, I think, an interesting frame that you have there. But I think I'm similar, and hopefully, my reframing there puts it in the way that can be a productive conversation starter as opposed to a person griping on a podcast. But with that said, that's probably enough of me griping on a podcast. [chuckles] So what's up in your world, Steph? STEPH: Oh, there are a couple of things going on. So I am in that pre-vacation chaotic zone where I'm just trying to get everything done. And I heard someone refer to it recently as going into a superman or superwoman mode where you're just trying to do all the things before you go, which is totally unreasonable. So that has been interesting. And the name of the game this week has been delegate, delegate, delegate, and it seems to be going fairly well. [chuckles] So I'm very excited for the downtime that I'm about to have. And some other news, some personal news, Utah, my dog, turns one. I'm very excited. I'm pretty sure we'll have a dog birthday party and everything. It's going to be a thing. I'll share pictures on Twitter, I promise. CHRIS: So he's basically out of the puppy phase then. STEPH: Yeah, the definition for being a puppy seems to be if you're a year or younger, so he will not be an adult. Teenager? I don't know. [laughs] CHRIS: What about according to your lived experience? STEPH: He has calmed down a good bit. CHRIS: Okay, that's good. STEPH: He has gotten so much better. Back when we first got him, I swear I couldn't get 15 minutes of focus where he just needed all the attention. Or it was either constant playtime, or I had to put him in his kennel since we're using that. That was the only way I was really ever getting maker's time. And now he will just lounge on the couch for like an hour or two at a time. It's glorious. And so he has definitely calmed down, and he is maturing, becoming such a big boy. CHRIS: Well, that is wonderful. Astute listeners, if you go back to previous episodes over the past year, you can certainly find little bits of Utah sprinkled throughout, subtle sounds in the background. STEPH: He is definitely an important part of the show. And in some other news, I have a question for you. I'm in need of some consulting help, and I would love to run something by you and get your thoughts. So specifically, the project that I'm working on, we are always in a state where there's too much to do. And even though we have a fairly large team, I want to say there's probably somewhere between 7 and 10 of us. And so, even though we have a fairly...for thoughtbot, that's a large team to have on one project. So even though there's a fair number of us, there's always too much to do. Everything always feels like it's urgent. I can't remember if I've told you this or not, but in fact, we had so many tickets marked as high priority that we had to introduce another status to then indicate they're really, really high, and that is called Picante. [chuckles] CHRIS: Well, the first part of that is complicated; the actual word that you chose, though, fantastic. STEPH: I think that was CTO Joe Ferris. I think he's the one that came up with Picante. So that's a thing that we have, and that really represents like, the app is down. So something major is happening. That's like a PagerDuty alert when we get to that status where people can't access a page or access the application. So there's always a lot to juggle, and it feels a lot like priority whiplash in terms that you are working on something that is important, but then you suddenly get dragged away to something else. And then you have to build context on it and get that done. And then you go back to the thing that you're working on. And that's a really draining experience to constantly be in that mode where you're having to pivot from one type of work to the other. And so my question to you (And I'll be happy to fill in some details and answer questions.) is how do you calm things down? When you're in that state where everything feels so urgent and busy, and there's too much to do, how do you start to chip away at calming things down where then you feel like you're in a good state of making progress versus you feel like you're just always putting out fires or adding a band-aid to something? Yeah, that's where I'm at. What thoughts might you have, or what questions do you have? CHRIS: Cool. I'm glad you brought an easy question that I can just very quickly answer, and we'll just run with that. It is frankly...what you're describing is a nuanced outcome of any number of possible inputs. And frankly, some of them may just be like; this is just the nature of the thing. Like, we could talk about adding more people to the project, but the mythical man-month and that idea that you can't just throw additional humans at the work and suddenly have that makes sense because now you have to coordinate between those humans. And there's that wonderful image of two people; there's one line of communication. Three people, suddenly there are a lot more lines of communication. Four people, wow. The exponential increase as you add new people to a network graph, that whole idea. And so I think one of the first questions I would ask is, and again, this is probably not either/or. But if you would try and categorize it, is it just a question of there's just a ton of work to do and we're just not getting it done as quickly as we would want? Or is it that things are broken, that we're having to fix things, that there are constant tweaks and updates, that the system doesn't support the types of changes that we want, so any little thing that we want to do actually takes longer? Is it the system resisting, or is it just that there's too much to do? If you were to try and put it into one camp or the other. STEPH: It is both, my friend. It is both of those camps. [chuckles] CHRIS: Cool. That makes it way easier. STEPH: Totally. [laughs] To add some more context to that, it is both where the system is resistant to change. So we are trying to make improvements as we go but then also being respectful of the fact if it is something that we need to move quickly on, it doesn't feel great where you never really get to go back and address the system in a way that feels like it's going to help you later. But then, frankly, it's one of those tools that we can use. So if we are in the state where there's too much to do, and the system is resisting us, we can continue to punt on that, and we can address things as we go. But then, at some point, as we keep having work that has slowed down because we haven't addressed the underlying issues, then we can start to have that conversation around okay; we've done this twice now. This is the third time that this is going to take a lot longer than it should because we haven't really fixed this. Now we should talk about slowing things down so we can address this underlying issue first and then, from now on, pay the tax upfront. So from now on, it's going to be easier, but then we pay that tax now. So it is a helpful tool. It's something that we can essentially defer that tax to a later point. But then we just have to have those conversations later on when things are painful. Or it often leads to scope creep is another way that that creeps up. So we take on a ticket that we think, okay, this is fairly straightforward; I don't think there's too much here. But then we're suddenly getting into the codebase, and we realize, oh, this is a lot more work. And suddenly, a ticket will become an epic, and you really have one ticket that's spiraled or grown into five or six tickets. And then suddenly, you have a person that's really leading like a mini project in terms of the scope of the work that they are doing. So then that manifests in some interesting ways where then you have the person that feels a bit like a silo because they are the ones that are making all these big changes and working on this mini-project. And then there's the other one where there's a lot to do. There are a lot of customers, and there's a lot of customization for these customers. So then there are folks that are working really hard to keep the customers happy to give them what they need. And that's where we have too much to do. And we're prioritizing aggressively and trying to make sure that we're always working on the top priority. So like you said, it's super easy stuff. CHRIS: Yeah. To say it sincerely and realistically, you're just playing the game on hard mode right now. I don't think there is any singular or even multiple easy answers to this. I think one question I would have particularly as you started to talk about that, there are multiple customers each with individualized needs, so that's one of many surface areas that I might look t say, "Can we sort of choke things off there?" So I've often been in organizations where there is this constant cycle of the sales team is going out. They're demoing against an InVision mock. They're selling things that don't exist. They're making promises that are ungrounded and, frankly, technically infeasible or incredibly complicated, but it's part of the deal. They just sold it, and now we have to implement it as a team. I've been on teams where that was just a continuing theme. And so the engineering team was just like, "We can never catch up because the goalpost just keeps moving." And so to whatever degree that might be true in this case, if there are ten different customers and each of them right now feels like they have an open line to make feature requests or other things like that, I would try to have the conversation of like, we've got to cut that off right now because we're struggling. We're not making the forward progress that we need to, and so we need to buy ourselves some time. And so that's one area that I would look at. Another would be scope, anywhere that you can, go into an aggressive scope cutting mode. And so things like, well, we could build our own modal dialogue for this, but we could also use alert just like the JavaScript alert API. And what are all of the versions of that where we can say, "This is not going to be as nice, and as refined, and as fitting with the brand and feel and polish of the website. But ways that we can make an application that will be robust, that will work well on all of the devices that our users might be using but saves us a bunch of development time"? That's definitely something that I would look to. What you described about refactoring is interesting. So I agree with we're not in a position where we can just gently refactor as we find any little mess. We have to be somewhat ruthless in our prioritization there. But like you said, when you get to that third time that a thing is working way harder, then take the time to do it. But really, like just every facet of the work, you just have to be a little better. If you're an individual developer and you're feeling stuck, raise your hand all the earlier because that being stuck, we don't have spare cycles right now. We need everybody to be working at maximum efficiency. And so if you've hit a wall, then raise your hand and grab somebody else, get a pair, rubber duck, whatever it is that will help you get unstuck. Because we're in a position where we need everybody moving as fast as they can. But also to say all of those aren't free. Every one of those where you're just like, yeah, do it the best you can. Dial it up to 11 on every front. That's going to drain the team, and so we have to also be mindful of that. This can't be forever. And so maybe it is bringing some new people onto the team or trying to restructure things so that we can have smaller communication channels. So it's only four people working together on this portion of the application, and therefore their communication lines are a bit simpler. That's one way that we can maybe save a little bit. But yeah, none of these are free. And so, we also need to be mindful that we can't just try harder forever. [laughs] That's a way to burn out the team. But what you're describing is like the perfect storm of every facet of this is difficult, and there's no singular answer. There's the theory of constraints (I think I'm saying that right.) where it's like, what's the part of our process that is introducing the most slowdowns? And so you go, and you tackle that. So if you imagine a website and the app is slow is the report that you're getting, and you're like, okay, what does that mean? And you instrument it, and you log some stuff out. And you're like, all right, turns out we have tons of N+1s. So frankly, everything else doesn't matter. I don't care if we've got a 3 megabyte JavaScript bundle right now; the 45 N+1s on the dashboard that's the thing that we need to tackle. So you start, and you focus on that. And now you've removed that constraint. And suddenly, the three megabyte JavaScript bundle is the new thing that is the most complicated. So you're like, okay, cool, let's look into tree shaking or whatever it is, but you move from one focus to another. And so that's another thing that could come to play here is like, which part of this is introducing the most pain? Is it feature churn? Is it unrealistic sales expectations? Is it developers getting stuck? And find the first of those and tackle it. But yeah, this is hard. STEPH: Yeah, it is. That's all really helpful, though. And then, I can share some of the things that we are experimenting with right now and then provide an update on how it's going. And one of the things that we're trying; I think it's similar to the theory of constraints. I'm not familiar with that, but based on the way you described it, I think they're related. One of the things that we are trying is breaking the group into smaller teams because there are between 7 and 10 of us. And so, trying to jump from one issue to the next you may have to really level up on different portions of the application to be able to make an impact. And there are areas that we really need infrastructure improvements and then essentially paving the way for other people to be able to move more quickly. We do have to prioritize some of that work as well. So if we break up into smaller teams, it addresses a couple of areas, or at least that's the goal is to address a couple of areas. One is we avoid having silos so that people aren't a bottleneck, or they're the only ones that are really running this mini-project and the only one that has context. Because then when that person realizes the scope has grown, bringing somebody on to help feels painful because then you're in an urgent state, but now you have to spend time leveling someone else up just so that they can help you, and that's tough. So the goal is that by having smaller teams, we will reduce that from happening because at least everything that feels like a small project...and by feels like a small project, I mean if we have more than one ticket that's associated with the same theme, that's going to start hinting at maybe this is more than just one ticket itself, and it might actually belong to an epic. Or there's a theme here, and maybe we should have two people working on this. And breaking people into groups, then we can focus on some people are focused more on the day-to-day activity. Some people are focused on another important portion of the codebase as we have what may be extracted. I'm going to say this, but we're going to move on, maybe extracted into its own service. [laughs] I know that's a hot one for us, so I'm just going to say it. CHRIS: I told you I can't be nerd sniped. This is fine. Let's continue on. [laughs] STEPH: [laughs] And then a small group can also focus on some of those infrastructure improvements that I was alluding to. So smaller teams is something that we are trying. We are also doing a really great job. I've been really happy and just proud of the team where folks are constantly reaching out to each other to say, "Hey, I'm done with my ticket. Who can I help?" So instead of immediately going to the backlog and grabbing the next thing. Because we recognize that because of this structure where some people are some silos, they have their own little mini backlog, which we are working to remove that to make sure everything is properly prioritized instead of getting assigned to one particular person. But we are reaching out to each other to say, "Hey, what can I do to help? What do you need to get done with your work before I go pick something else up?" The other two things that come to mind is who's setting the deadlines? I think you touched on this one as well. It's just understanding why is it urgent? Does it need to be urgent? What is the deadline? Is this something that internally we are driving? Is this something that was communicated without talking to the rest of the team? Is this just a really demanding customer? Are they setting unrealistic expectations? But having more communication around what is the sense of urgency? What happens if we miss this deadline? What happens if we don't get to this for a week, a month? What does that look like? And then also, my favorite are retros because then we can vote on what feels like the highest priority in terms of pain points or run these types of experiments like the smaller teams. So those are the current strategies that we have. And I'm very interested to see how they turn out because it is a tough way. Like you said, it's challenge mode, and it is going to burn people out. And it does make people feel fatigued when they have to jump from one priority to the next. So I'm very interested. It's a very interesting problem to me too. It just feels like something that I imagine a lot of teams may be facing. So I'm really excited if anybody else is facing a similar issue or has gone through a similar challenge mode; I'd love to hear how your team tackled it. CHRIS: Yeah, I'm super interested to hear the outcome of those experiments. As a slightly pointed question there, is there any semi-formal version of tracking the experiments? And is it just retro to retro that you're using for feedback on that? I've often been on teams where we have retro. We come up with it, and we're like, oh, this is a pain point. All right, let's try this. And then two weeks later, we're like, oh, did anyone actually do that? And then we just forget. And it's one of those things that I've tried to come up with better ways to actually manage, make slightly more explicit the experiments, and then have a timeline, have an almost scientific process of what's the hypothesis? What's the procedure? What are the results? Write up an executive summary. How'd it go? STEPH: We are currently using retro, but I like that idea of having something that's a bit more concrete. So we have action items. And typically, going through retro, I tend to revisit the action items first as a way to kick off retro. So then that highlights what did we do? What did we not do? What do we not want to do anymore? What needs to roll over to the current iteration? And I think that could be just a way that we chat about this. We try something new, and we see how it's going each week in retro. But I do like the idea of stating upfront this is what we're looking to achieve because I think that's not captured in the retro action item. We have the thing that we're doing, but we haven't captured this is what we hope to achieve by taking this experiment on. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. STEPH: As for the other thing that you mentioned, I do have an idea for that because a former client that I worked with where we had experiments or things that we wanted to do, we were using Trello. And so we would often take those action items…or it was even more of a theme. It wasn't something that could be one-and-done. It was more of a daily reminder of, hey; we are trying this new thing. And so, we want to remind you each day to embrace this experiment and this practice. And so we would turn it into a Trello ticket, and then we would just leave it at the top of the board. So then, each day, as we were walking the board, it was a nice reminder to be like, hey, this is an ongoing experiment. Don't forget to do this. CHRIS: I do like the idea of bringing it into a stand-up potentially as like that's just a recurring point that we all have. So we can sort of revisit it, keep it top of mind, and discard it at some point if it's not useful. And if we're saying we're doing a thing, then let's do the thing and see how it goes. So yeah, very interested to hear the outcomes of the experiment and also the meta experiment framework that you're going to build here. Very interested to hear more about that. And just to say it again, this sounds like your perfect storm is not quite right because it doesn't sound like there's a ton of organizational dysfunction here. It sounds like this is just like, nah, it's hard. The code's not in perfect shape, but no code is. And there's just a lot of work to be done. And there are priorities because frankly, sometimes in the world, there are priorities, and you're sort of at the intersection of that. And I've been in plenty of teams where it was hard because of humans. In fact, that's often the reason of we're sort of making up problems, or we're poorly communicating or things like that. But it sounds like you're in the like, nope, this is just hard. And so, in a way, it sounds like you're thinking about it like, I don't know, it's kind of the challenge that I signed up for. Like, if we can win this, then there's going to be some good learnings that come out of that, and we're going to be all the better. And so, I wish you all the best of luck on that and would love to hear more about it in the future. STEPH: Thank you. And yeah, it has been such an interesting project with so many different challenges. And as you've mentioned, that is one area that is going really well where the people are wonderful. Everybody is doing their best and working hard. So that is not one of the competing challenges. And it is one of those; it's hard. There are a lot of external factors that are influencing the priority of our work. And then also, some external areas that we don't have control over that are forcing some of those deadlines where customers need something and not because they're being fussy, but they are themselves reacting to external deadlines that they don't have control over. So it is one of those where the people are great, and the challenges are just real, and we're working through them together. But it's also hard. But it's helpful chatting through all the different challenges with you. So I appreciate all of your thoughts on the matter. And I'll report some updates once I have some more information. On that note, shall we wrap up? CHRIS: Let's wrap up. STEPH: The show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I'm @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Leon Stigter (https://twitter.com/retgits) walks through the "why" of serverless and shares a demo of using Knative and use cases with tools like VMware's Event Broker Appliance for automation. Resources: https://flings.vmware.com/vmware-event-broker-appliance https://knative.dev/

[קישור לקובץ mp3] בפודקאסט מספר 418 [!I'm a teapot] של רברס עם פלטפורמה - וזהו קרבורטור מספר 31.התאריך היום הוא ה-17 באוגוסט 2021 ואנחנו בכרכור באולפן הבייתי שלנו בבית של אורי . . . הי אורי! (אורי) אהלן . . . רן, אתה מחזיק את המיקרופון ביד בהחזקה אופיינית לתבורי . . . (רן) בבקשה, הרמתי את האצבע . . . החלטתי להישען בפודקאסט הזה, היה לי יום ארוך של נסיעות . . . אז אנחנו בקרבורטור - ובקרבורטור, כמיטב המסורת, אנחנו מארחים את נתי שלום, אז הנה - שלום לנתי שלום!(נתי) שלום לכם! כמה זמן כבר שלא נפגשנו? כבר איזה חודשיים בערך?(רן) כך וכך חודשים [שישה וחצי] . . . אז נתי, אנחנו שמחים לארח אותך שוב . . . (נתי) האמת שזה די מדהים שכל פעם אנחנו מוצאים איזה נושא מעניין כזה שמדליק פתאום את החושים - כל פעם אתה זורק איזה WhatsApp על משהו ושולח אותי לשבועות של מחקר . . . (אורי) בנושא טעון . . . כמו ענן שחור כבד שעולה במערב . . . (רן) זה הפרק שבו אורי יגיד לנו “אמרתי לכם!” . . . אז בואו נראה מה הולך לקרות פה היום . . . (אורי) אמרתי לכם! . . . (רן) לגמרי.אז לפני מספר שבועות, או אפילו כמה חודשים [May 27, 2021], התפרסם מאמר מעניין בבלוג של Andreessen Horowitz שנקרא The Cost of Cloud, a Trillion Dollar Paradox - שבו, למעשה, הם מתארים, שני המחברים - Sarah Wang ו-Martin Casado את מה שהם קוראים לו “פרדוקס” בתחום של עלויות ענן, או אם נתמצת את זה - מתי “נכון” להיות בענן ומתי “לא נכון” להיות בענן.התשובה לא איחרה לבוא, מפי Corey Quinn, שאמנם לא עובד ב-AWS אבל הוא בדרך כלל בעדם, והוא בא ושובר את כל הטיעונים שלהם לחלקים . . . אז פשוט שלחתי את שני המאמרים האלה ב-WhatsApp לנתי - ופה נקודת ההתחלה שלנו . . . לא נקריא אותם פה בשידור ואתם כמובן מוזמנים ונוסיף רפרנסים [יש] - ובגדול, השאלה היא “האם Cloud נכון לחברה בשלבי ה-Growth השונים? מה העלות האמיתית שלו? האם יש פה אכן פרדוקס?”.(רן) אז בוא, קודם, נכנס ככה למאמר - ולפרדוקס, לכאורה, שהם מתארים. . . (נתי) אז בוא נדבר באמת קודם על מה זה הפרדוקס - הפרדוקס בא ואומר שחברות . . . חברות נמדדות על Velocity, והיום יש Incentive שונה בין Velocity ל-Efficiencyזאת אומרת שרוב החברות משקיעות ב-Velocity, וכשאני אומר ש”יש Incentive” זאת אומרת שהן מתוגמלות בשוק, בבורסה, בצורה שבה החברות נמדדות ב-Valuationומכאן בעצם יש בעצם שרשרת של התנהלות שאומרת “אוקיי, אני צריך להוציא כמה שיותר מוצרים, כמה יותר פיצ'רים כמה שיותר מהר” - וה-Cloud זו פלטפורמה אידיאלית לדבר הזה.בדרך, שוכחים את הצד של העלות של ה-Cloud . . . ואז, כשמסתכלים פתאום על זה התוכן של החברות האלה ועל ה-Portfolio וה-Breakdown של ה-Revenue שלהן, מוצאים נתון די מדהים, לדעתי, שאיכשהו, כשמישהו שם אותו על הלוח, זה הפך להיות משהו מדהים - הרבה מאוד חברות SaaS שהן ב-Scale - אם זה Asana וכמובן Elastic ואחרים - נמצאות במצב שבו אחוז גדול מסך כל ה-revenue שלהן הולך ל-Infrastructure של Cloud . . .ויותר מזה - האחוז הזה הולך וגדל . . . זאת אומרת - ופה נכנס הפרדוקס - מצד אחד, הם גדלים, ומצד שני הריווחיות שלהן הולכת ונשחקת, במגמה כזאת, שהיא לא יכולה להדביק את הריווחיות שלהן . . .זאת אומרת שיש פה איזושהי מגמה שבה אני לא יכול לגבות עבור המוצר שלי בקצב שבו אני מוציא כסף . . . (רן) למה זה נשחק?(נתי) זה נשחק כי אני לא יכול לגבות . . . יש לי מוצר נתון בענן, וכל פעם יש לי דרישה להוסיף לו פיצ'רים ולהגדיל אותוהמשמעות של זה היא יותר ויותר Infrastructureעכשיו, יש הרבה “איים של Inefficiency” [בזרם?] שעוד מעט נדבר עליהם - ומה שקורה לאורך זמן זה שהעלות שלי הוא די קבועה, זאת אומרת שהיא גדלה באופן די קבוע - אבל ההכנסה שלי היא הרבה פעמים Flat, זאת אומרת, מבחינת מבנה ההכנסות . . . אז יש פה שחיקה - בעבור אותו מוצר, אני מתחיל להוציא יותר ויותר . . .(רן) ההכנסה פר-לקוח . . . (אורי) זה סוג של Inefficiency of Scale . . . אנחנו רגילים להגיד שצריך להיות לנו Efficiency of Scale מבחינת עלויות . . . (נתי) אנחנו כמעט ולא נמדדים עליו . . . כל המאמר מתמקד בנקודה הזאת, שאתה מודד את כל החברות על עד כמה מהר הם מביאים עוד לקוחות וכמה מהר הם גדלים, כמה פיצ'רים הם מוציאים . . . אז ברור שהצד השני - כמעט ואף אחד לא יסתכל עליו . . . הרבה פעמים אני זוכר בשיחות שהייתי הולך ו . . . זה בעיני הערך הכי גדול של המאמר הזה . . . הייתי הולך ומדבר עם מנהלי פיתוח ומדבר איתם על כל מיני דברים של איך כן לעשות דברים של Efficiency, והיו אומרים לי “אין לי זמן” . . . “אין לי זמן, אני עסוק כרגע, יש לי מיליון דברים לעשות - זה איפשהו ב-Back-Burner . . .”וכמעט תמיד זאת התשובה שהייתי שומע . . .(אורי) אני רוצה להגיד משהו עם . . . בוא נשים שנייה את הבורסה בצד, בסדר, ונחזור ל-Basics של הכנסות-הוצאות: היכולת לייצר Efficiency of Scale מאפשרת לך, בגדול, To Scale the business more - כי, אם נסתכל על זה בצורה מאוד בסיסית, יש לך “דלי של כסף”, ואתה יכול, בגדול, להוציא אותו על שלושה דברים עיקריים - על Sales & Marketing, על פיתוח ועל Infrastructure . . . זה, נגיד, שלושת הדברים . . . ההוצאות הכבדות שיש.ב-Sales & Marketing ובפיתוח אתה משקיע באנשים - וזה הכוח שלך קדימה, בסדר? ה-Infrastructure הוא מקום ש - עד כדי הפגיעה בהתקדמות של אחרים, של האנשים - איפה שאתה יכול לאפטם (Optimize), תאפטם . . . כי כל השקעה ב-Human Capital . . . לא ה-Human Capital עצמו אלא ב . . . Human Capital יביא מכפילים על הכסף, בסדר? ו-Infrastructure, ברוב המקרים, לא יביא יותר מ-1:1 . . . זאת אומרת: שרת שמשרת X בקשות ביום - היום הוא ישרת X בקשות ומחר הוא ישרת X בקשות.איש מכירות עשה מכירה - מחר המכירה הזו ממשיכה לעבוד ולהביא Revenue, והמכירה שהוא יעשה מחר מביאה עוד Revenueזאת אומרת שיש עליו Revenue אינקרמנטלי . . . אנשי פיתוח, ואני חושב שגם Marketing, הם באותו מקום, ומוצר וכו' - הם הופכים את איש המכירות ליותר יעיל, הם נותנים לו עוד כלים למכור והם גם לפעמים משקיעים ב-Infrastructure והופכים אותו ליותר יעיל . . . אז יש להם, אני חושב, תרומה אקספוננציאלית ל-Business.עכשיו - יש לך את הדלי הזה של הכסף, ותחשוב איפה אתה ועל מה אתה שם אותו: ב-Economy of Scale, תשים אותו על מה שמגדיל את ה-Business, ולא על מה שמביא תרומה יחסית קטנה או קבועה.ואת ה-Basics הזה אנשים שכחו . . . (נתי) נכון . . . ואני אומר, וזה למשל משהו ש-Corey Quinn דיבר על הנקודה הזאת באמת - הוא טוען שהטיעון של Martin Casado מופרך, מכמה סיבות - 1 - מי שקרא את המאמר היה רואה שהוא מתבסס מאוד על המודל של Dropbox . . . מה Dropbox עשו? באמת עשו Repatriation, מהמילה “Patriot” - “לקחת את ה-Cloud הבייתה”.(רן) בוא נזכיר רק . . . לא נקרא פה את כל המאמר, אבל בגדול - הוא מתאר סיפור של Dropbox לפני ההנפקה, שעשו, כמו שאמרת Repatriation, שזו מילה ממש קשה . . .(נתי) . . .נכון, אני עשיתי חזרות לפני כן . . . .(רן) . . . שזה בגדול אומר “לרדת מההענן וללכת ל-Datacenter משלהם” - לחלק מהשירותים שלהם - בוא נגיד שלא לכולם, בעיקר לשכבת ה-Storage, שהיא כנראה יחסית גם מאוד יקרה בענן וגם מאוד סטטית מבחינת . . . (אורי) לא רק . . .זה עד כמה שהיא בשלה . . . (רן) בדיוק - בשלה, תודה אורי. אז הוא בא ואמר שכשהם עשו את הצעד הזה לפני ההנפקה, זה העלה מאוד את הערך של Dropbox בזמן ההנפקה, והם הגיעו שם למספרים די אסטרונומיים - משהו כמו פי-25, אני לא זוכר בדיוק מה המספרים, אבל בצורה מאוד משמעותית, לא ב-30 אחוז . . . גם אם, לצורך העניין, הם הצליחו להשיג הוזלה של 30%, השיפור במכפיל שלהם, או ב-Value או במה שאני לא זוכר . . . (נתי) זה היה X24 . . . (רן) . . . זהו, זה לא היה 30%, אלא זה היה פי-24 . . . ויש להם איזשהו הסבר ללמה זה?(נתי) בדיוק . . . (אורי) כי גם משקיעים מבינים את הדבר הזה שנקרא Economy of Scale . . . זה פינה ל-Dropbox הרבה מאוד כסף כדי להשקיע בחזרה בהגדלה של ה-Business . . .(נתי) נכון, אבל שווה רגע להתעכב על זה טיפה, כי אני חושב שזה הטוויסט הכי גדול בעלילה, במאמר הזה . . .עד היום, בכל השיחות של Efficiency, מה עשינו ומדדנו? אמרנו אוקיי, כמה עולה עכשיו . . . ניקח סתם “להרים VM”? אז עולה לך X$ בשעה וולצורך העניין, בענן פרטי אתה יכול להראות שאולי זה פחות.ואז אתה מגיע למיליונים. אבל ברגע שאתה מזיז את המדד הזה מ”כמה עולה ב-Datacenter שלך לעומת שרת בענן?” ל-”איך זה משפיע על הווליואציה (Valuation) של החברה?”, אתה מגיע פתאום למיליונים, ל”טריליון דולר” הזה שהוא מדבר עליו, ה”Trillion Dollar Paradox”.כי אתה כבר לא מודד את ההבדלים ב-Cost של ה-Infrastructure . . . . (אורי) . . . כי הוא הכפיל את זה במספר החברות ש . . . (נתי) . . . לא רק מספר החברות - אלא איך החברות, איך כל דולר שאתה חוסך משפיע על הווליואציה.וברור שהווליואציה הרבה יותר רגישה למספר הזה - היא לא לינארית, היא לא אומרת “אה, חסכת דולר? אז המנייה שלך תעלה בדולר” אלא “חסכת דולר? אז כמובן במכפילים של כמות העסקאות שיש לך והלקוחות שיש לך זה שווה הרבה יותר”וזה הפך את זה ל”Trillion Dollar Paradox” ולא ל”Million Dollar Paradox” . . . (רן) אגב, שווה לציין שזה טיעון שונה מהטיעון שלך, אורי - אתה אומר “חסכת דולר? תשתמש בו להשקעה ב-Human Capital או במשהו אחר”, והוא לא בא ואומר את זה . . . (אורי) לא, אני חושב שזה פשוט . . . אתה יודע, אנחנו מדברים פה על מכפילים לווליואציות (Valuation), אז מכפיל לווליואציות - המשקיעים בוחרים על מה הם שמים את המכפיל . . . [כאן יש הסבר אפשרי מעניין]אז לפעמים הם שמים את זה על הגדילה, לפעמים הם שמים את זה על ה-Gross Revenue - והרבה פעמים הם שמים את זה על ה-EBITA, אז . . . (נתי) אז פה הוא מדבר על זה שהרבה פעמים מודדים ARR, בלי בהכרח למדוד את הדברים האחרים . . . (אורי) נכון . . . (נתי) . . ואם אתה מראה גדילה משמעותית ב-ARR, הווליואציה שלך בהכרח גדלה, גם אם אתה עושה את זה על חשבון זה שאתה מקטין את הרווחיות שלך . . . (אורי) . . . אני אומר שיש שווקים מסויימים ויש סגמנטים של שוק, שבהם דווקא מסתכלים על ה-EBITA ועל הגדילה ב-EBITA - וזה מדד לריווחיות ול”בריאות החברה”.(רן) אורי - תזכיר למאזינים: EBITA? מה זה?(אורי) תכל'ס - זה הרווח הנקי . . .(רן) הרווח הגולמי?(אורי) לא - הרווח הנקי . . . Earnings before interest, taxes, and amortization (EBITA) וכל הקללות האלה ש . . .(רן) כמו שאומרים בקופה ראשית - מה שנשאר בסוף בכיס . . . זה מה שהרווחנו.(אורי) כן . . . אז ה-EBITA הזאת היא מדד ל”בריאות ה-Business Model” של החברה, והרבה פעמים מקבלים על זה את המכפילים - ויש לא מעט חברות שאם הן תעבירנה את . . . אתה יודע מה, אני לא יודע . . . אבל ההבדל בין לרוץ ב-Cloud או לרוץ On-Premise הוא בין EBITA בריאה לבין אפס EBITA . . . (נתי) כן - אבל אם אתה מסתכל, אז רוב השוק של ה-Unicorns, שעכשיו זה השם הנפוץ ביותר במדינה, פחות או יותר, כשאתה מסתובב היום בהרצליה ובתל אביב . . . (רן) עוד חודשיים, כשנקליט את זה, זה יהיה כבר יהיה תטא-קורן . . . (נתי) כן . . . אז בסוף יש לך חברות, בסופו של דבר, כמו Uber, שאם הייתה מודד אותה על EBITA, לא היית נותן להם את הווליואציה שיש להם היום, אתה מסכים איתי, נכון? כי המודל הוצאות והכנסות שלהם לא היה, לפחות עד לא מזמן, לא כזה הגיוני . . . [ה-understatement הגדול בהיסטוריה?]מן הסתם, רוב החברות שהן יוניקורן, לפחות עד השלב שהן מגיעות לזה שהן יוניקורן ומתחילות להימדד על זה, הן נמדדות על ARR ועל גידול ובשלב הזה הן אפילו, חלקית [חלקית?] הפסדיות . . . (אורי) אתה יודע מתי חברות מתחילות להימדד על EBITA? במשברים . . . (נתי) נכון . . . אז אנחנו בבועה, לצורך העניין, וזה איזשהו מדד מסויים, כנראה, גם של בועה - אבל היא לא אומרת שהיא הולכת להתפוצץ מהר . . . [לא אומרים משפטים כאלה . . . לא קראת קומיקס אף פעם?]יש איפשהו איזה כסף אינסופי שאני לא מצליח להבין אותו - טפו-טפו, כן - אבל אני חושב שזה היה, כשאני ככה “מקזז את זה”, זה היכולת להסתכל לא על “כמה עולה לי שרת ב-Datacenter שלי וכמה עולה לי שרת בענן” ולמדוד את זה שם ו”להישאר במגרש של הגרושים”, לצורך העניין - אלא להביא את זה פתאום לחברה . . . זה הפך את זה ל-”Trillion Dollar Paradox” מ-”Million Dollar Paradox”.וזה, פתאום, שם איזושהי מראה של “אוקיי, מה קורה פה? . . . “ יש פה משהו לא הגיוני.(רן) אז נסכם, רק שנייה, את המאמר הזה של Andreessen Horowitz, שאני ממליץ, אגב, לקרוא, למי שמתעניין - אנחנו ממש נסכם אותו בקצרה - הוא בא ואומר “חבר'ה, מאיזשהו גודל מסויים, אתם לא צריכים להיות בענן - אתם צריכים לעשות Repatriation ל-Service-ים שלכם, זאת אומרת - לקחת את ה-Service-ים, להוריד אותם מהענן ולבנות אותם ב-Datacenter שלכם”.בא Corey Quinn - וסותר אותו:הוא בא ואומר “תראו חבר'ה, זה לא נכון, כל הסיפור הזה - זה אולי נכון במקרה של Dropbox”“למה זה נכון במקרה של Dropbox?” אז . . .(נתי) במקרה של Dropbox הוא אומר ש”מדדתם לא נכון כי הסתרתם חלק מהמידע” . . . (רן) יכול להיות - אבל הוא אומר למה זה: אולי זה נכון במקרה של Dropbox - אני אזהר פה - כי אומר ש”Dropbox סיימו לחדש” . . . . זאת אומרת, אין להם כבר פיצ'רים חדשים להוציא, הם הגיעו פחות או יותר לתקרת הזכוכית מבחינת איפה שהם יכולים לגדול ולחדש - אז כל מה שנשאר להם זה להיות יותר Efficient . . .אז אם אתם חברה כזאת, שכבר אין לה לאן לגדול - “סבבה, תלכו להיות Efficient” [זה מגיע עם תנועת יד ספציפית?]אבל לרוב החברות בעולם - יש להן עוד הרבה מאוד לאן לגדול, אז יותר נכון לגדול, גם אם זה על חשבון ה . . . EBITA? איך אמרנו?(נתי) כן . . .(אורי) אה . . . (רן) זה הטיעון שלו . . . (אורי) כן, אתה יודע - ואז בא נתי שלום ואומר, בצדק אני חושב - תקן אותי אם אני טועה . . . Dropbox לא גמרה לחדש, בסדר? אין חברה חפצת-חיים שגומרת לחדש, כולם מחדשים.וה-Sweat-spot הוא לדעת לתמוך בתשתית שנותנת את האג'ליות בחידושים - ולדעת לעשות אופטימיזציה ל-Core Business, על המקום שבו ה-Economy of Scale הוא מאוד מאוד חשוב.(נתי) אז א' - במקרה של Dropbox, יש שם איזושהי אנומליה שהוא מתאר, שבעצם כשאתה מסתכל על הספרים וכשאתה מסתכל על ההוצאות שלהם על Infrastructure אז לכאורה זה נראה נמוך, אבל מאחורי זה מה שמסתתר זה סעיף אחר - של הוצאות על אנשים והוצאות על Datacenters ,שלא נכללו בסעיף ההוא, והם מופיעים פשוט בסעיף אחר . . .ואז הוא אומר שיש פה משהו שבסך הכל המספרים הם לא כמו שהם מתארים. זה עדיין יותר זול, אבל . . .(אורי) נתי - בתור אחד שמכיר את המספרים מהחברה שלו וזה . . . - ההוצאות על האנשים שתומכים ב-Infrastructure הזה הן Fraction of a fraction ממה שעולה . . . עליות של Cloud. זה טיעון של מישהו שלא בדיוק יודע איך עובדים ב-Cloud . . . (נתי) אז זה לא סותר את התיאוריה, זה רק אומר שהמספרים הם לא “כצעקתם”, מה שנקרא.לכן אני שם את זה שנייה בצד ואומר - יש כאן טיעונים, צריך להכיר אותם, וכנראה ש-Dropbox, מה שנקרא, “מינפו את הפוזיציה” הרבה יותר ממה שהיא באמת, אבל הגרעין של הטיעון - הוא עדיין עומד עליו . . .זה הניתוח שלי לפחות - שלמרות כל הרעש על זה והביקורת שלעשות Repatriation זה דבר שהוא גם מאוד יקר ופוגע באג'יליות - בסופו של דבר, אני חושב שהטיעון המרכזי זה Efficiency vs. Velocity היום חברות נדרשות ל-Tradeoff הזה, וזה הגורם העיקרי.עכשיו - יש הרבה מאוד דרכים, ואולי נדבר גם על זה, לעשות Efficiency בתוך הענן - לפני שאתה עושה Repatriation, בעצם, Repatriation הוא אחד האמצעים לעשות אופטימיזציה - מאוד קיצוני יחסית, ויש הרבה יחסית שאיחרו את הרכבת, או שלחילופין המהלך הזה יהיה להם מאוד מאוד יקר וכואב, למי שלא בנה את זה מראש, כמוך [אורי], או למי שלא תכנן את זה - זה לא יהיה לו טריויאלי.אבל הטיעון המרכזי הוא Efficiency - אני צריך לייעל את הצורה שבה אני צורך משאבים ואני צריך להסתכל על איך אני צורך משאבים בצורה מאוד נכונה.עכשיו - למה זה מורכב? כי אם אתה מסתכל היום מה הן האפשרויות שלי להגדיל את ה-Efficiency בענן, אז בוא נסתכל על הפתרונות שיש לי . . .יש לי פתרון אחד, שזה כל מיני כלים שנותנים לי Cost . . . מה הבעיה עם זה?א' - זה בדרך כלל After the factב' - ההמלצות שאתם תראו אם תשתמשו בכלים שנותנים לכם Cost מקסימום יגידו לכם “הנה Alert על איזה מישהו טיפש שהשאיר את המכונה שלו ולא סגר את זה!”אוקיי, סבבה, מתישהו אתם לומדים גם לנהל את ה-Policy הזה - אבל . . . .לפעמים הוא גם יגיד לך אם אתה מחזיק מכונות גדולות ואתה יכול להקטין אותן וכל מיני דברים כאלהאבל אתה תמצה את המהלך הזה יחסית מהר, ה-Value של האינפורמציה הזו הוא די יגיע למיצוי בתוך כמה חודשים, וכבר הגעת למיצוי של מה שאתה תקבלואז אתה תתחיל לקבל הרבה מאוד “רעש” כזה, כמו בחברות Security - המון רעש על Alert-ים, וזה בעצם יהיה רעש ואתה לא תקשיב לזה בכלל, וזה יכנס לך ויצא מהאוזן השנייה.אז זה כל החברות Cost . . .הדבר השני שיש לנו זה כל החברות אוטומציה - מה הבעיה עם אוטומציה? נתתי דוגמא דווקא מ[יובל] נח-הררי, שמאוד אהבתי את ה . . . מאמר אחר לגמרי, לא קשור בכלל לנושא הזה . . (רן) “מאזיננו יובל” . . . (נתי) כן, יובל נח-הררי, חבר שלי מהמסטינ”ג . . . לא, סתםיש לו אגב פודקאסט מאוד מעניין עם [מארק] צוקרברג, גם נושא לשיחה אחרת . . .אז הוא בא ואמר משפט שאני עכשיו נוהג לצטט אותו הרבה - “כלי בסוף תלוי במה שאתה עושה איתו” . . . והוא נתן את הדוגמא של הסכין - שזה כלי שאתה יכול לחתוך איתו סלט ולהכין אוכל מצויין, אבל אתה גם יכול להרוג איתו . . . זה אותו הכלי.אותו הדבר לגבי כלי האוטומציה - אנחנו הרבה פעמים אומרים “אוקיי, איך אני אחסוך? אני אעבוד ל-Spot!” או “איך אני אחסוך? אני אעבור ל-Kubernetes!” או “איך אני אחסוך? אני אעבור ל-Terraform!”מה קורה בדרך כלל לחברות אחרי שהן עושות את המהלך ל-Kubernetes? אתה שואל אותן “איך היה המעבר? עד כמה זה באמת היה Efficient יותר?”אז הם אומרים לך “אג'ילי! אג'ילי! אג'ילי! - אבל ב-Cost זה Sky-rocketing . . . “למה? כי נוצרה גם, עם המעבר לכלי האוטומציה הזה, איזושהי אבסטרקציה עוד יותר גדולה ל-Cost, כי עכשיו אתה לא באמת יודע מה רץ ואיפהוגם עניין של קלות - פתאום עכשיו להרים סביבות ו-Containers ניהיה נורא קל, אז מעיפים Container-ים על ימין ועל שמאל, והרבה מאוד סביבות . . . אתה מכיר את זה גם, אני חושב . . .הרבה יותר ממה שהיית צורך קודם, אפילו ב-Monolith . . . אם תשווה את ה-Monolith שהיה לך קודם לעומת ה-microServices שיש לך היום, ואת כל הסביבות Development שאתה מריץ לצד זה, וכל ה-Overhead-ים שיש לזה . . . פתאום רואים שהעלות שלהם גדלה וגדלה וגדלה - בקצב מאוד גבוה.והסיבה היא שכלי האוטומציה באמת נותנים Efficiency - הם מביאים אותך ל-Efficiency, אבל הם גם, באותה מידה, מורידים את ה-Efficiency מעצם זה שהם עושים אבסטרקציה ו”מחביאים” את ה . . . (רן) מייצרים שכבת Overhead משמעותית, לא זניחה . . .(נתי) והיום, אין את היכולת באמת לתווך בצורה טובה בין המשתמש ל-Infrastructure - וכך אנחנו מגיעים לנקודה הזאת, ואז יש . . .(אורי) אני חושב שמהניסיון שלי, אין תחליף למישהו שמדי פעם מסתכל על ה-Cost ואומר “חבר'ה, ברחנו פה . . . בואו, תעשו סיבוב ותראו איך אתם מאפטמים . . . “[ובינתיים, ב-Pinterest . . . ](נתי) נכון - ואני אגיד לך שגם זה בעייתי, ותיכף גם נגיע לאיזשהו, הייתי אומר “Pattern של פתרון” או כיוון מסויים של פתרון, שקיים בכמה תעשיות כבר . . . (רן) זה מה שהזכרת כ”חברות ה-Cost” - חברות שמציפות את ה-Cost הבעייתי . . . (נתי) זה כמו חברות Security, באיזשהו שלב . . . כי מה הבעיה? בוא, אני אראה לך ואפרוש לך עכשיו את כל הכלים של אופטימיזציה, ואז תבין איפה הבעיה - יש לך בעצם ארבע קטיגוריות של אופטימיזציה:יש לך קטיגוריה אחת שזה ברמת ה-VM, ה-Compute וה-Storage - אז אתה יכול ללכת מ-Spot ל-Reserved ל-VM יותר גדול . . . עם GPU, בלי GPU, כל מיני - אופטימיזציות ברמה הזאת, של ה-Infrastructure.יש ברמת Policy - שזה בעצם להגיד “אוקיי, מכונה שלא השתמשת בה, אתה יכול להרוג”, “אם זה ב-Development תעשה ככה” - ויש כל מיני נושאים של מדיניות.ויש ארכיטקטורה - Kubernetes ו-Containers, אם זה Fargate או לא Fargate, או שזה Serverless או לא Serverless - כל מיני היבטים כאלה.[עוד קטיגוריה?]ועכשיו, כשתסתכל על כל הדבר הזה, ותגיד “אוקיי, אני רוצה לעבור, למשל, מ-VM ל-Spot” - אז זה, לכאורה, פשוט: אתה לא צריך לעשות כלום . . .איפה אתה נופל? אם האפליקציה שלך היא Stateful, אז לא בדיוק בדיוק יעבוד, זה דורש שינוי ארכיטקטוני . . . זה כמעט כמו לעבור ל-microServices - השינוי הארכיטקטוני הזה הוא כבר שינוי קוד, ושינוי קוד זה כבר לא דבר פשוטזה לא שמישהו יצעק לך “אתה מאוד לא Efficient פה!” - ומחר אתה יכול להיות 30% יותר Efficient . . . (אורי) מה שאתה אומר זה שזה לא משנה אם אתה תעבור מ . . . לא יודע, מ-Cloud ל-On Premise או מ-Monolith ל-microService - עצם זה ששינית State of Mind ואתה מתחיל להיות Mindful, למודעות - זה יצריך ממש השקעה . . (נתי) בדיוק - הרבה השקעה ולאורך לא מעט זמן, כי בוא ניקח את הדוגמא הכי טובה לחברות שיודעות לעשות Scale - אלו חברות ה-Cloud עצמן . . .מה קורה בחברות האלה? הן . . .(אורי) אגב - הם ידעו כל כך טוב לעשות Scale שהן הרימו את ה-Cloud . . .(נתי) נכון . . . אבל אני אומר “איך הם עושים את זה?” אפשר ללמוד מהן, זאת אומרת - יש להם על כל צוות, על כל מוצר, כשהם עושים S3, הצוות הזה לא עובר רק לפתח את הפיצ'ר הבא אלא הוא עובד מאוד מאוד חזק בלמצוא פתרונות שמורידים את ה-Cost עבורםולצורך העניין מגדילים את ה-Margin ואת כל האופטימיזציות שיש אחרי זה, לאורך זמן - משקיעים בזה המון.זה לא שזה קורה “כדרך אגב”, זה לא שמישהו אומר להם “אה, ה-Cost שלך יקר, בוא תוריד אותו” - ופתאום משקיעים בזה, עושים שינוי של Priorities ומשקיעים בזה.זה חלק מאוד מאוד משמעותי בהתנהלות שלהם, זה חלק חלק מאוד משמעותי ב-Incentives שלהםזה יכול להיות חלק מאוד משמעותי באיך שהם מתכננים את ה-Roadmap-ים שלהם - וזה פיצ'ר לכל דבר ועניין, והוא מקבל את אותה עדיפות כמו פיצ'ר שהוא Customer-facing . . .אז זה, קודם כל, משהו בצורת ההתנהלות שצריך להיות מאוד שונה - ולהבין שזה On-going, זה קשה, אין פתרונות קסם פה ולא יבוא איזה “פתרון מהצד” ויפתור לכם את הבעיות. זה כל הזמן צריך להיות . . . (רן) זאת אומרת, אתה אומר ש”Cost צריך להיות פיצ'ר”, לצורך העניין? . . .(נתי) כן . . (רן) “אל תייצר לי פיצ'ר שנותן ל-User לעשות File Upload - תייצר לי פיצ'ר שנותן ל-User לעשות File Upload בפחות מ-5 מילי-סנט . . .”(נתי) בדיוק - ותמדוד את זה, ותתגמל על זה . . . כמו שאתה מתגמל על דברים אחרים.ואז זה הופך להיות, ברמת ההתנהלות, זה הופך להיות משהו חשוב שה-Business מודע אליו - ואז אתה מייצר את התרבות הזאת, שאתה נותן לזה Attention . . . - וזה, לכשלעצמו, עדיין לא מספיק.(רן) אבל אז, זאת אומרת, אנחנו חוזרים ל-Tradeoff שהצגת בהתחלה - האג'ליות מול ה . . . סליחה - ה-Velocity מול ה-Efficiency: ברגע שאתה עובד על ה-Efficiency, אתה באותה רגע פוגע ב-Velocity . . . (נתי) אז נתתי את הדוגמא של חברות ה-Cloud - הם מצאו פתרון לזה . . . אז הם באו ואמרו - ובואו נלמד מהם, כי אני חושב שיש כאן איזה בית ספר שאפשר ללמוד ממנו.אז עובדה שהם משקיעים בזה הרבה, וכן - זה בא על חשבון Velocity, לכאורה.אבל זה לא באמת בא רק על חשבון Velocity, כי זה פיצ'ר - ושוב פעם זו הסתכלות מאוד לא נכונה על Efficiency . . . (רן) לא, אני הייתי אומר שזה בא על החשבון - וזה בסדר: ברור שזה בא על חשבון זה, כי את זה הבנו, וזה Tradeoff ואי אפשר להתחמק מזה . . .(נתי) כשאומרים ש”זה בא על חשבון”, אני אומר . . . הרי מה המטרה שלך בפיצ'ר? בסופו של דבר, אתה מביא פיצ'ר כדי להגדיל ערך - אבל פה גם הגדלת ערך! רק במימד אחר . . . [איפה אסימוב כשצריך אותו?]שפחות רואים אותו ופחות יודעים עליו - רואה אותו רק מי שמסתכל בסוף על המספרים . . . אתה פחות רואה את זה . . . אתה לא יכול לשים איזה PR ולהוציא על זה Announcement . . .(רן) דרך אגב, מכל הסיפור הזה של מדידת עלות בענן, של אוטומציה של עלות וכו' - יש לזה כבר שם, אז בואו ניתן לזה אתה השם: היום קוראים לזה FinOps [!], לא יודע אם כבר ראיתם או לא . . . ויש כמה חברות בתחום הזה וגם כמה חברות ישראליות . . . אז אם נתקלתם בשם הזה שנקרא FinOps - אז זה כל התחום של עלויות בענן ו”ייעול בענן”.(אורי) אני רציתי להגיד עוד משהו על האג'ליות של המוצרים החדשים וזה . . . אתם יודעים, זה סוד כזה שאולי קצת לא מדברים עליו, אבל נתקלתי לפחות בחברה אחת שאומרת “רגע! אני באתי, ייצרתי מוצר שהוא SaaS בענן, ובעצם אני עשיתי את ה-Trail & Error, אני בניתי . . . וברגע שהוכחתי שזה עובד וזה הצליח לי - באו AWS והעתיקו אותי ו . . . “(רן) הקלטנו על זה פרק [קוסמי! 365 Carburetor 26 - open source politics], אבל . . . זה נכון, וזה נושא כאוב ומעניין . . .(אורי) אז אתה אומר, כאילו - באיזה Innovation בדיוק הם משקיעים, אם הם . . . וואלה, יש חברות אחרות שלוקחות את ה-Cost של ה-Trail & Error, ואז הם פשוט באים, עושים את אותו הדבר ו . . . (נתי) מיקרוסופט המציאו את הדבר הזה, כשעוד הייתה להם את מערכת ההפעלה והם עשו את הדבר הזה . . .וכן, זו מציאות שאני חושב שלא תשתנה, כנראה, ועל זה יש לנו פחות שליטה, אז אני פחות מתעסק בזה.כולם חווים את הכאב הזה - וזה כואב וזה מעצבן, ואני לא רואה את זה משתנה בדינמיקה הזאת יותר מדי . . .(אורי) אני רוצה לומר שרוב ה-Cost שיש ביצירת Innovation היא בטעויות . . . (נתי) נכון, אז אתה אומר שבהגדרה השלב הזה הוא עוד לא Efficient כי אתה לומד מטעויות . . .(אורי) כן . . .(נתי) אז זה סבבה - אבל בוא נלך שנייה על איפה אני חושב שכן יכולה להיות הקפיצה הבאה, ויש פה, לדעתי, איזושהי בשורה שאפשר כן לצאת ממנה בשיחה הזאת, ולפחות . . . חשבתי על זה הרבה והגעתי לאיזושהי תובנה בהקשר הזה ואני אחלוק אותה איתכם:התובנה באה ואומרת כזה דבר - אם אנחנו מסתכלים על הנקודות Scale בעולם ה-Cloud, אז יש כל מיני נקודות, שראינו את הקפיצה פתאום - נקודה אחת זה כשיצאו ה-VM-ים והפכנו מכונות פיזיות לווירטואליות, ובנקודה הזאת בכלל נוצר הענן - בלי זה בכלל לא היה לנו היום ענן ולא היינו מדברים בכלל.הנקודה השנייה הייתה המעבר ל-Containers ואחר כך ל-Kubernetes, שבעצם הביאו לנו את היכולת לנהל מערכות מאוד מורכבות וגדולותיצאנו מ-VM-ים ל-Container-ים וזה היה, דרך אגב, גם נקודה סינגולרית מאוד מאוד משמעותית.אחרי זה יש את ה-Infrastructure-as-a-Codeוהיום, אחת הבעיות לאופטימיזציה - ואני בא קצת מעולם של Databases אז אני מכיר את זה טוב - זה מאוד קשה לעשות אופטימיזציה כשהעולם שלך הוא Security Group וכשהעולם שלך זה VPC, וכשהעולם שלך הוא כל מיני נקודות כאלה ב-Infrastructure . . . כי ככל שאתה מסתכל על “הפסיפס” ואתה מנסה לעשות אופטימיזציה, מאוד מאוד קשה לך לראות את התמונה הגדולה ולראות איפה “ה-Pocket הכי גדול שלך” ולעשות את האופטימיזציה שם . . ואנחנו קצת תקועים פה . . .עכשיו, לדעתי צריך להיות . . .(אורי) “תקועים בפרטים”, אתה אומר . . .(נתי) תקועים בפרטים, בדיוק - ולכן ה-Complexity הוא זה שמייצר את המורכבות, שלא מאפשרת לעשות את ה . . . תיארתי כל מיני שיטות לאופטימיזציה - זה יכול להיות Policy זה יכול להיות לעשות Scaling או שזה Spot, שזה היכולת לשלוט ב-VM-ים - אבל היכולת ליישם את זה היא מאוד מאוד קשה.ואז, אם אני לוקח את זה הלאה, אני אומר “אוקיי, חייב להיות פה משהו נוסף שמשנה את המשחק בעוצמה של המעבר מ-VM-ים ל-Container-ים, בעוצמה של המעבר מ-Container-ים ל-microServices ול-Infrastructure-as-a-Code”והדבר הבא שאני מסתכל עליו זה היחידת בניין - “Templatized Environments” . . . היום, אני כבר לא מסתכל על Container, או אפילו על microService - יש לי Template לכל דבר.היום אני אמצא Template ל-Machine Learning ו-Template ל”איך אני עושה Monitoring?” ו-Template . . .יש לי המון Tamplte-ים מסוגים שונים וחלקם כתובים ב-Terraform וחלקם ב-CloudFormation וחלקם ב-Azure Hub, חלקם בשפה אחרת - אבל אני כבר יכול להסתכל על Building Blocks יותר crossgrade - מערכות . . נגיד “RDS כמערכת” - לא מעניין אותי איך ה-RDS הזה בנוי, אני מקבל אותו כיחידהועכשיו, כשאני מסתכל עליו כיחידה, אני מנסה לאפטם (Optimize) אותו כיחידה ולא את כל ה-Bits וה-Bytes - את זה כבר מישהו אחר עשה.וזה מאפשר לי, פתאום, להסתכל על אופטימיזציה של מערכותולאן זה מביא אותי? זה . . . (רן) רגע, אני לא בטוח שאני איתך . . . בוא, אני אגיד את זה בשפה שלי ואתה תגיד לי איפה אני טועה:אתה אומר שיש כל מיני סוגים של Workloads - נגיד Database רלציוני זה סוג אחד של Workload ו- Web Service זה סוג אחר של Workload (נתי) Kubernetes Cluster זה גם . . .(רן) אוקיי, נגיד Spark או Big Data Processing זה גם סוג אחר של Workload . . . (נתי) נכון . . .(רן) אז בוא נשים כל אחד מה-Workloads האלה “בתוך קופסא” - נגיד שניתן להם APIs וניתן להם שם - ועכשיו, את כל אחת מהקופסאות האלה אנחנו נוכל לאפטם, בצורה שהיא לא שקופה החוצה, זאת אומרת - ה-API אליהן לא ישתנה.לצורך העניין, אם אני שולח בקשה ל-Database אני תמיד אקבל תשובה - ולא חשוב איך הוא בנוי, בין אם זה ממומש ב-SQL או שזה ממומש ב . . .(נתי) בוודאי . . .(אורי) אבל הקופסא היא Optimized . . . (נתי) הקופסא Optimized - אבל כשאנחנו אומרים “Optimized”, זו אף פעם לא אותה האופטימיזציה - ועכשיו תיכף נגיע לשלב הבא . . . אז השלב הראשון היה להגיד, כדי בכלל להגיע לרמה הבאה, אנחנו צריכים לעלות קומה - כמו שעשינו עד עכשיו, אנחנו צריכים לעלות קומה בגרנולריות (Granularity) וביכולת שלנוהאבן-בניין צריכה להשתנות - מפסיפס ללבנים ומלבנים לבלוקים ומבלוקים לאיטונג, או לא יודע איך נקרא לזה . . .אז כשהאבן-בניין גדלה, אז אני יכול להסתכל על גורדי-שחקים - כשאני עובד עם פסיפס, אני לא אבנה גורד-שחקים, מקסימום אני אבנה קומה אחת . . . אז האבן-בניין היא נקודה מאוד קריטית פה.השלב השני זה באמת מה שהתחלת לגעת בו - זה היכולת לעשות Decoupling בין ה-Workload ל-Infrastructure.כי ברגע שאני יכול לעשות את ה-Decoupling הזה, אני יכול באמת להגיד עכשיו על כל יחידה שהיא אופטימלית - ועכשיו אני יכול להדביק את ה-Workload ליחידה הכי אופטימלית לצורך הזה . . .ואם אני עושה את זה סטטית, אז אני אהיה Semi-optimal, כי קיבלתי את ההחלטה בנקודת זמן מסויימת ולא בטוח שהיא תמיד תיהיה נכונה לאורך זמןכי המשפט הזאת של “אופטימלית” הוא דבר דינאמי - כי ה-Load משתנה. (אורי) אני זוכר שהקלטנו פעם פרק עם חברה . . . אני לא זוכר איך קראו לה, היא ישבה פעם ביקנעם [עדיין], זה היה שם משהו עם ”ז' באדר ב'” או משהו כזה [א'] . . .(רן) כן, חברת Storage בשם Zadara [זה - 372 Zadara] . . .(אורי) אבל הם נותנים פתרון Storage לכל העננים, לכל ה-API-ים של העננים למיניהם - ושאלנו אותו איפה הוא בתכל'ס מאחסן - והוא ענה ש”אנחנו לא מאחסנים בענן - אנחנו יושבים ליד העננים וכו', אבל האופטימיזציה שלנו ל-Cost היא בזה שיצאנו החוצה, ואנחנו נותנים, לצורך העניין, Building Blocks הרבה יותר גנריים של ‘הנה - Storage!', פתרון Storage אופטימלי” . . .(נתי) נכון . . .(אורי) אז אני אומר - אוקיי, למה ש-RDS לא יהיה ככה? למה שכל ה-Building blocks האלה . . .(נתי) אני אומר שאפילו אם זה בענן, אפילו אם זה בענן - ושוב פעם פרשנו “מיליון אופציות” על להריץ את אותו הדבר בענן, יש לך רק על Kubernetes את Fargate ויש לך את . . .(רן) אפשר לחזור לדוגמא של Dropbox - יש להם כמה סוגים של Services, ואחד מהם זה Storage.יש להם גם Services מסוגים אחרים - יש להם User Interface, יש להם . . . (אורי) יש להם Docs! . . . [הפנייה מעגלית ל-Paper](רן) יש להם Docs . . . יש להם הרבה סוגים של Services, והם לקחו את אחד מהם - רק את ה-Storage - בודדו אותו, ורק אותו הוציאו מחוץ לענן . . .(נתי) אז אני אומר . . . (אורי) אני חושב שבתור חברה אתה רוצה לאפטם את החלקים הגדולים של ה-Cost model שלך - גם Netflix, עם כל הסיפור של “אנחנו בענן . . . “ - את ה-CDN הם הוציאו החוצה.(נתי) אז אני מסתכל על זה קצת יותר רחב - אני אומר שזו אחת האופטימיזציות, כנראה המשמעותית יותר, אבל לא לכל דבר היא מתאימה ואני חושב שזה די ברוראבל יש עוד הרבה אופטימיזציות, הרבה דברים שלא דורשים בהכרח דברים כאלה קיצוניים או דרמטיים - ופרשנו פה כמה מהדברים האלה.אבל היכולת שלי להשתמש בהם - זה החלק המורכב: אם אני אהפוך את היכולת שלי להשתמש בהם ליותר פשוטה, אז אני אוכל להגיע לנקודה הזאת.ופה אני אומר - אם אני יכול להגיע לאופטימום, שזה The right infrastructure for the job, ואני אגיד עכשיו איזה משפט שאני חושב שכל אחד יסתכל על העולם שלו ויבין על מה אני מדבר:היום, כמה פעמים אנחנו בעצם מריצים את ה-Workload שלנו מסיבה שהיא "Least-Common-Denominator”?זאת אומרת שאת ה-Production system שלנו, למשל, אנחנו נריץ הרבה מאוד Dev ו-Test ועוד כל מיני דברים על אותה Production Environment.עכשיו - אני לא צריך ל-Dev ו-Test את ה-SLA של RDS - אני יכול סתם להשתמש ב-Database לצורך העניין . . . אני לא צריך Network מורכב, אני לא צריך עוד המון דברים, ברמת ה-SLA, שיש לי היום בסביבת Production . . . אבל מסובך לי לייצר עכשיו סביבה שהיא ייעודית ל-Development אז אני לא אעשה את זה - ואז אני נשאר במכנה המשותף הזה שצריך לשרת הרבה מאוד Workloads.אז בהגדרה, אני לא Optimized . . .(אורי) אלא אם כן אתה מגיע למצב ש”You couldn't care less”, אוקיי? . . . (נתי) תסביר לי את המשפט הזה, איך זה יכול להיות? . . .(רן) כשזה גם ככה לא עולה כלום . . . (אורי) לא - כשזה שקוף לך איפה זה רץ . . .(נתי) לא - אז השקוף זה תנאי, אתה צודק . . . השקוף זה תנאי, אבל אני צריך בסוף להגיד, וניתן את הדוגמא של Dev-Production כי זו הדוגמא שהכי קל לאנשים להבין אותה - אם אני יכול, לצורך העניין - אני רוצה עכשיו רק לבנות פיצ'ר ולבדוק אותואני לא צריך עכשיו שתריץ לי EKS בשביל הדבר הזה . . . אם תיתן לי Kubernetes שרץ לי על VM, או minikube או K3S או Whatever - את אותו API של ה-RDS, שזה בעצם Postgres, את אותו Storage של S3, שזה יכול להיות MinIO, בסביבה שהיא Sandbox - סבבה לי.אני יודע לעשות את זה . . . תמיד יהיו לי את ”החיצים החוצה”, כי אני לא אריץ את הכל באותו VM - אבל אני מקבל פה מה שנקרא היום, ה-Buzzword החדש בעולם של ה-DevOps - זה “הדמוקרטיזציה של ה-Development”.היכולת שלי באמת לא להיות תלוי ב-Shared Environment, להגיע ל-Agility, להגדיל את כמות הטסטים וכל מיני דברים מהסוג הזה.אבל אני יכול ממש לבנות Stack, די בקלות, במיוחד כשיש לי Building blocks שחוזרים על עצמם, שזה בדרך כלל Kubernetes ו-Terraform ו-Ansible - כל מיני יחידות כאלה שהן . . . אני יודע כבר למדל אותן בתוך כאלה “קופסאות קטנות” - לקופסא גדולה.אני יכול להגיד עכשיו שאני מריץ את זה ב-Dev - אני לא צריך GPU, אני יכול להריץ את זה בלי GPUוזה, דרך אגב, ירוץ יותר לאט - אבל אני לא חייב את המכונה עם ה-GPU ה-High-end כדי לבדוק את הפיצ'ר עצמו ברמת הפונקציונאליות.עכשיו, אני זורק כל מיני דברים - ברור שזה לא יתאים להכל, אבל העיקרון הוא שאם אני יכול כן להגיע למקום שבו אני יכול להצמיד את The right infrastructure for the workload, אני אגיע למקסימום אופטימיזציהועכשיו יש את המציאות - אני אף פעם לא אגיע ל-100% של זה, כי זה תמיד מסובך, אבל אני יכול להגיע קרוב לזה.וככל שאני אגיע קרוב לזה, אני אהיה קרוב לאופטימום.[על פניו, נראה שבאינטל עכשיו טוענים שהם יכולים לעשות משהו דומה ברמת ה-Hardware . . .]וחלק מה-right infrastructure for the workload זה גם ה-Repatriation - להריץ בזה . . . כי ל-Workload הזה, למשל, של Storage או של CDN, המשמעות של “The right infrastructure” זה On-Prem . . . ולמשהו אחר, שזה Dev Environment, זה דווקא לא On-Prem, כי זה משאב שהוא מאוד מתאים ל-Production use-case ולא מתאים ל-Dev Use case.(אורי) אז מה שאתה אומר זה שב-Dev אני משתמש בפחות Load - אני צורך פחות משאבים . . .(נתי) . . זה גם לא ה-SLA שלי, שזה העיקר - ה-SLA שלי הוא בכלל . . . אני לא צריך SLA של Production . . .(אורי) נכון - ואני יכול לנסות את זה גם בסביבה “יקרה”, כי אין כאן Economy of Scale, להיפך - יש פה Economy of Velocity . . .(נתי) נכון . . . וכמה עושים את זה?(אורי) אני חושב שזה הפתרון, נגיד . . . לא יודע אם זה הפתרון, אבל זה השימוש הנכון בעולם כזה - שאנשים מבינים שאין דרך אחת: יש כמה דרכים, יש כמה פתרונות, וצריך To use the right tool for the problem.וצריך להבין - Cloud זה Optimized ל-Velocity . . .(נתי) על חשבון Cost אפילו . . . (אורי) על חשבון Cost - כי Cost לא מעניין אותנו בשלב הזה, הוא . . . ה-Velocity מעניין אותנו ולא ה . . . ו-On-Prem, לצורך העניין, או סביבות יותר אופטימליות - זה במקום שאתה צריך Economy of Scale.(נתי) אז אני מתמצת את זה בזה שאני אגיד ש-The right infrastructure for the Job הוא האופטימום . . . עכשיו שכל אחד יעשה את החושבים אצלו ויגיד “כמה באמת אני קרוב לאופטימום הזה?”אני חושב שהרוב יסתכלו ויגידו “וואו, אני רחוק שנות אור מהדבר הזה - אבל יש לי פה מקום אחד שאני יכול להגיע לזה . . .”שזה, למשל, Dev-Test, שזה משהו שאני מתחיל לראות כאיזשהו Pattern שמתחילים להתמודד איתו . . .(אורי) אבל Dev-Test זה לא אצל מי שעושה Repatriation . . . (נתי) לא לא לא . . . (אורי) ה-Repatriation . . . (נתי) אמרתי - ה-Repatriation, למי שלא עשה את זה כמוך, בהתחלה - זו עצה מצויינת, מאוד קשה ליישום . . .יהיו כאלה שבאמת יש להם Workload שהם יודעים כבר לאפיין אותו טוב וה-Benefit הוא כל כך גדול שהם יהיו מוכנים ללכת את ה-Journey הזה והם יעשו אותו, אבל זה יהיה במקרים מאוד מאוד ספציפיים - וב-Scale מאוד מאוד גבוה . . . (רן) אבל בואו נזכור שזה לא צריך להיות All-or-Nothing . . .(נתי) נכון - זה אחד הבילבולים . . . זו אחת הטעויות, לדעתי, גם בכתיבה של המאמר - שהוא שם את כל ה-Bucket על Dropbox, אז כאילו אנשים יצאו על זה ואמרו “רגע! אבל אני לא Dropbox, מה זה אומר?”ואני חושב שהעיקרון שלו היה Efficiency ולאו דווקא Repatriation . . . (אורי) אני חושב שיש פה כמה מפתחות, ואתה יודע - אני עכשיו מחליף רכב להיברידי-נטען, וכשאני מסתכל על כל הרכבים החדשים בשוק - אין כבר מנועי בנזין “נטו” . . . יש היברידי והיברידי-נטען, וכבר מתחילות להיכנס חשמליות ובעוד 10 שנים - זהו.אני חושב, והמאמר הזה היה פוקח עיניים, למי שלא נפקחו לו העיניים עד עכשיו . . .(נתי) לא אמרת “אמרתי לך” . . . (אורי) נכון . . . (נתי) הייתה לך פה הרמה להנחתה עכשיו . . . (אורי) . . . ואנחנו נתחיל לראות, כמו שיש את כל החברות ש”מעבירות ל-Cloud”, אנחנו נתחיל לראות חברות שעוזרות לעשות Repatriation - והמפתח פה הוא ידע.זה מסוג האומנויות שנשכחו, והמפתח פה הוא ידע, ועם הידע הזה מגיעה גם הקלות - כמו שניהיו מלא מוצרים שהופכים לך את המעבר ל-Cloud לקל, אז יהיה גם ההיפך. ואני יכול להגיד שגם, אתה יודע - ב-Outbrain הגענו למצב שזה לא משנה למפתח איפה זה רץ, חוץ מזה שאנחנו יכולים לדאוג לעניין של העלות - הוא פשוט את ה-Deployment יעשה ל-Datacenter X או ל-Datacenter Y וכן - Datacenter X נמצא ב-Cloud, וזה אותו Deployment . . . (נתי) ואני אומר שאפשר להגיע למקום עוד יותר גבוה מזה, במרחק נגיעה ממה שאתה אומר עכשיו - שהוא גם לא יצטרך לדעת באיזה Datacenter זה רץ - הוא פשוט יגיד “אני רוצה Dev Environment”, ואתה תדע להגיד לו מה ה-Environment המתאים“אני רוצה Production Environment ואני רוצה Machine Learning” - ואני אגדיר לו את ה-Environment הנכון עבורו . . . הרבה פעמים זה סוג של . . .(אורי) . . . סביבה זה . . . יש לנו ב-Datacenter אחד סביבה כזו וסביבה כזו . . . (נתי) אפשר, בגישה הזאת, כשהולכים איתה, אפשר ממש לגדול ברמת Efficiency - בשנייה שאתה מצליח לעשות את ה-Decoupling הזה, אז על הציר הזה, שבין ה-Workload ל-Infrastructure יש המון המון מקום לחוכמה.יש משפט, שהרוב לא יגיעו אליו כי הוא ממש בסוף המסמך, ממש למטה, שהוא מסכם את זה ככה: The biggest potential זה חברות שיצליחו לפצח את הממשק בין ה-inefficient code ל-Infrastructure - ושם טמון הפוטנציאל הגדול ביותר.למה שם טמון הפוטנציאל הגדול? כי שוב פעם - אנחנו היום מסתכלים על Security פה ו-Infrastructure פה ו-VM פה - ו-Kubernetes worker node כזה או Kubernetes worker node אחר - וזה העולם שלנו.ושם גם פחות או יותר, כשאנחנו מדברים על אופטימיזציות, אנחנו מגיעים עד לתקרה הזאת.אבל כשאנחנו מסתכלים על ה-End-to-End Service, אנחנו אומרים “עכשיו בוא נסתכל על כל ה-End-to-End Service, ונראה איפה הטרנזקציה של ה-User עוברת ואיזה תחנות היא עוברת בדרך ואיפה באמת התחנה שהכי יקרה לי” - אני יכול לגלות “Pocket-ים” אחרים לגמרי.ואז אני יכול להסתכל על זה ברמה של, לפעמים , ארכיטקטורה, שזו דרך להגיע לאופטימום הרבה יותר גבוהלפעמים זה יכול להיות Policyלפעמים זה יכול להיות באמת ה-Dev-Productionאפשר להסתכל על זה מהזוית הזאת, ואז לתקוף את זה מזוית אחרת לגמרי מאשר “תביא לי את ה-Cost Report ותגיד לי ,וואי, היה לך איזה User שהעלה לך איזו מכונה ועכשיו היא רצה הרבה יותר זמן מאשר הייתה צריכה להיות'” . . .(רן) בסדר, אז בוא, ככה, נתקדם לסיכום - קודם כל, הייתי חייב להגיד, נתי, שבעצם מה שאתה אומר זה ש”אם יש לך Bug ב-Design אז ז*ן ב-Debug” . . . תעשו Design כמו שצריך, או במילים אחרות - אתה בא ואומר שאם נעשה חלוקה הגיונית בין ה-Workload-ים השונים, נוכל את כל אחד מהם בנפרד לאפטם, ואם נעשה חלוקה הגיונית בין ה-Workload עצמו לבין ה-Infrastructure, אז נהיה גם אגנוסטים ל-Infrastructure ואז יהיו לנו יותר קל.בעצם ”נפתח את הדלת לעתיד”, אם נרצה . . . (נתי) האימפקט של ה-Change יהיה הרבה פחות דרמטי, וזה חוזר חזרה לדוגמא של החברות Cloudהם עושים אופטימיזציה - ואתה לא יודע בכלל שעכשיו ה-S3 עולה להם חצי ממה שעלה להם קודם . . .אתה לא יודע שעכשיו ה-EKS. . . (אורי) זו בדיוק הבעיה - שזה עולה להם עכשיו חצי, וזה לא משתקף במחיר שלך . . .(נתי) נכון - אבל זו גם הגדולה של זה: הם יכולים To continuously optimize it, אבל יש Decoupling מאוד ברור בין השירות לבין מה שאתה משתשמש בו - ולכן הם יכולים לעשות את זה והם לא צריכים להגיד לך שום דבר.ובהרבה פעמים, מה שאנחנו מוצאים זה שיש המון Coupling היום בין ה-Workload לבין ה-Infrastructure - ואז, בשניה שיש את ה-Coupling הזה, אתה תקוע.עכשיו, חברות Cloud, בשונה ממה שהם עושים לעצמם - ללקוחות שלהם הם מעודדים לעשות את ה-Coupling הזה . . .“תשתמש בכל השירותים של ה-Cloud, כי זה מאוד קל ומאוד מהיר . . . . תשתמש . . . אה! יש לי פה עוד פיצ'ר ב-EKS שאם תשתמש בו בכלל תעוף . . .”ואז אתה מוצא את עצמך במקום ש . . . “אופס, אני כבר לא יכול לזוז משם” . . . (אורי) אני לא יכול לזוז - וזה עולה לי . . . זה לא בחינם.(נתי) וזה לא רק זה - אני גם לא יכול לזוז משם, וזה המחיר היותר גבוהאני לא יכול עכשיו, אם יש לך משהו שהוא יותר יעיל - אני לא יכול להשתמש בו.אני לא יכול להשתמש בו כי אני “תפור” שם מ . . . (רן) אז נמשיך בסיכום . . . זה פרק מרתק, אנחנו מסכימים, אבל בגדול - הצגנו את מה שנקרא “הפרדוקס של הענן”, שבא ואומר שבימים הראשונים של החברה זה בדרך כלל סופר-משתלם להיות בענן, אבל באיזשהו שלב צריך לחשוב האם זה באמת המקום הנכון בשבילכם לרוץ - ולפעמים אתם כבר תקועים, זה מה שאתה אומר . . . לפעמים, אם לא השארתם לעצמכם איזשהו “פתח מילוט”, אז אתם כבר יכולים להיות תקועים, גם אם מצאתם דרך יותר יעילה לעבוד - עלות המעבר היא כל כך גדולה שזה לא שווה את זה.(אורי) ולפעמים אין ידע . . . אין ידע, וזה הדבר שמבחינתי הוא הכי חבל. ידע זה כלי, זה כח, ואנשים איבדו את השריר הזה.(נתי) הייתה לי שיחה עם אייל פינגולד מ-Check Point, והוא אמר שבאמת יש סוג-של “שני מחנות” של אנשים, כשהם מקבלים החלטות על Infrastructure - יש את אלה שבאים ואומרים “זה בענן, ב-AWS, אני לא מחפש לעשות Multi-Cloud, לא מחפש ללכת לפתרונות אחרים, הם יודעים מה שהם עושים”ויש את אלה שאומרים “לא - אני רוצה את ה-Decoupling, אני רוצה אקח באמת Elastic מ-Elastic ולא את Elastic שלהם, אני אקח DataDog ולא את ה-CloudWatch . . .” זה ממש “שתי אונות במוח” - אתה רואה ממש שני מחנות, כמו הדמוקרטים והרפובליקנים . . . זה בערך . . . העולם מתחלק, פחות או יותר, לדברים האלה.ואני אומר - אנחנו צריכים יותר את הצד של ה-Decoupling, כי המחיר של הלא-Decoupling ב-Short-term באמת נראה עם Gain מאוד גבוה, אבל ב-Long-run הוא בסוף, כמעט תמיד, מוכיח את עצמו כמשהו שתוקע אותך והוא לא משתלם.ואני חושב שזו איזושהי תובנה שלא קיימת היום - והמחנה, אני לא יודע אם לקרוא לו דמוקרטי או רפובליקני, המחנה שמוכן “ללכת עד הסוף עם הענן”, הרבה פעמים עושה את זה עם הרבה מאוד נאיביות.(רן) טוב - בנימה אופטימית זו, אנחנו מסכמים פודקאסט מרתק על עלויות ענן ו”אמרתי לכם!” . . . (אורי) אני יכול להגיד עוד משהו? . . . (נתי) יש פה רעיונות להרבה-הרבה סטארטאפים, עכשיו מהשיחה הזאת . . . למי ששמע: דברו איתנו . . . (רן) טוב - תודה רבה אורי, תודה נתי, היה מרתק, להתראות.המאמר של נתי ב-TheNewStack על Reducing Cloud Spend Need Not Be a Paradoxויש גם את ה-thread הזה של Or Hiltch על MemoryDB האזנה נעימה ותודה רבה לעופר פורר על התמלול!

The cloud native promises of developer productivity and operational efficiency often hinge on modernizing the data architecture. Stateful workloads have traditionally and rightfully required more effort to manage, but contemporary tools and practices unlock the potential to have the right data in the right place at the right time without the clumsy burden of traditional enterprise data systems. Join Couchbase's Matt Ingenthron and Red Hat's Andrew Clay Shafer as they explore the principles of building systems to move fast and scale up while making data available and safe.. 

No longer considered an ephemeral concept as it originally was, data management has become a huge issue and challenge, especially for managing stateless data in Kubernetes environments. Cloud Native Data Management Day at the recently held KubeCon + CloudNativeCon Europe 2021 event in May and the state of data management were the subject of discussion in this edition of The New Stack Makers podcast, hosted by Alex Williams, founder and publisher of The New Stack. The guests were Michael Cade, senior global technologist, Veeam Software and Nigel Poulton, owner of nigelpoulton.com, which offers Kubernetes and Docker training and other services. Both Cade and Poulton were also involved in the organization of Cloud Native Data Management Day.

Thinking about network security but don't know where to begin? In this episode, Joshua walks Nate through a few network security fundamentals: Stateful vs Stateless firewalls and IDS vs IPS appliances. It's just enough cybersecurity mumbo jumbo to set the state for June's Network Security series. Also, Hoobastank. We talk a lot about Hoobastank.

Anil Kumar (@anilkumar1129, Director of Product Mgmt @Couchbase) talks about how Kubernetes has evolved to support stateful applications, enabling Couchbase to run on Kubernetes, the advantages of Operators, and NoSQL adoption models. SHOW: 512SHOW SPONSOR LINKS:Okta - Safe Identity for customers and workforceTry Okta for FREE (Trial in 10 minutes)CBT Nuggets: Expert IT Training for individuals and teamsSign up for a CBT Nuggets Free Learner account Datadog Security Monitoring Homepage: Modern Monitoring and AnalyticsTry Datadog yourself by starting a free, 14-day trial today. Listeners of this podcast will also receive a free Datadog T-shirt.CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW NOTES:Couchbase HomepageCouchbase Cloud-native DatabaseCouchbase CommunityTopic 1 - Welcome to the show. Before we dive into the work you’re doing with Kubernetes, let’s talk about your background. Topic 2 - Kubernetes started with a focus on “cloud-native apps”, then it became a blurring of infrastructure. How does Couchbase see the market evolving around Kubernetes, especially as a stateful service? Topic 3 - There is frequently a debate about whether or not to run data services on Kubernetes, or run them off-cluster. How does Couchbase view this, and what are some things that Kubernetes does to improve how Couchbase runs?Topic 4 - Let’s talk about some of the common use-cases you’re seeing for Couchbase, whether it’s on Kubernetes, or in the cloud, or out at the Edge. Topic 5 - Do you see any multi-cloud or hybrid-cloud use-cases where Couchbase is a good fit, or is it too difficult to span databases across clouds? Topic 6 - What areas around Kubernetes do you see evolving to help use-cases for Couchbase (i.e. other CNCF projects, etc.)? FEEDBACK?Email: show at thecloudcast dot netTwitter: @thecloudcastnet

On this Azure Centric Podcast, we are talking about the newest Azure features announced during this week. Marcos Nogueira and Andrew Lowes bring their point of view on these new Azure features: • New Azure VMs for general purpose and memory intensive workloads now in public preview • General availability: Azure Hybrid Benefit for Linux with RI and VMSS Support • Public preview: Stateful and 1-minute frequency log alerts in Azure Monitor • General availability: Application Insights work item integration in Azure Monitor • Azure Ultra Disk is now generally available in North Central US • Public preview: Azure Log Analytics in South India • Public preview: Application Insight in South India and West Central US • General availability: Set up Azure Site Recovery with proximity placement groups across hybrid and cloud disaster recovery scenarios • General availability: Azure Site Recovery now supports cross-continental disaster recovery for 3 region pairs • Azure Site Recovery now supports Azure Policy in public preview You will find videos about Microsoft Azure Technologies, Microsoft Certifications and Technology in general on this channel. The Podcast series is a very informal conversation with different guests. The Azure Concept series is where we bring the real-life experience of using Azure Technologies on the field. Don't forget to subscribe and make sure to hit the like button and share this video if you enjoyed it. Facebook page - https://www.facebook.com/azurecentric Twitter - https://twitter.com/azurecentric Instagram - https://www.instagram.com/azurecentric LinkedIn - https://www.linkedin.com/company/azurecentric SoundCloud - https://bit.ly/acsoundcloudpodcast Google - https://bit.ly/acgooglepodcast Apple - https://bit.ly/acapplepodcast Spotify - https://bit.ly/acspotifypodcast YouTube - https://bit.ly/azurecentricyoutube #AzurePodcast #AzureCentric #AzureUpdates

Abstract of the talk… Almost all applications have some kind of state. Some data processing apps and databases have huge amounts of state. How do we navigate a cloud-based world of containers where stateless and functions-as-a-service is all the rage? As a long-time architect, designer, and developer of very stateful apps (databases and data processing apps), I'd like to take you on a journey through the modern cloud world and Kubernetes, offering helpful design patterns, considerations, tips, and where things are going. How is Kubernetes shaking up stateful app design? - What kind of state is there, and what are some important characteristics? - Kubernetes, containers, and the stateless paradigm (pushing state into DBs) - Where state lives and the persistence characteristics - Stateless vs serverless - why stateless is not really stateless, but server less really is - Improving on stateless paradigm using local state pattern - Logs and event streaming for reasoning about state and failure recovery - The case for local disks: ML, Databases, etc. - Kubernetes and the Persistent Volume/StatefulSets - Leveraging Kubernetes PVs as a basis for building distributed data systems - Mapping the solution space Bio… Evan has been a distributed systems / data / software engineer for twenty years. He led a team developing FiloDB, an open source (github.com/filodb/FiloDB) distributed time series database that can process a million records per second PER NODE and simultaneously answer a large number of concurrent queries per second. He has architected, developed, and productionized large scale data and telemetry systems at companies including Apple, and loves solving the most challenging technical problems at both large and small scales, from advanced custom data structures to distributed coordination. He is an expert in bleeding edge #jvm #java #scala and #rust performance. Current interests include Rust and columnar compression. He has led the design and implementation of multiple big data platforms based on Apache Storm, Spark, Kafka, Cassandra, and Scala/Akka. He has been an active contributor to the Apache Spark project, and a two-time Datastax Cassandra MVP.

This The New Stack Makers podcast explores the state of open source software today and features a case example of what is possible: Kasten by Veeam has created Kubestr to identify, validate and evaluate storage systems running in cloud native environments. As Michael Cade, a senior global technologist for Veeam, describes Kubestr, the open source tool provides information about what storage solutions are available for particular Kubernetes clusters and how well they are performing. The software project is also intended to offer DevOps teams an “easy button” to automate these processes. Hosted by Alex Williams, founder and publisher of The New Stack, Cade and fellow guest Sirish Bathina, a software engineer, for Kasten, describe Kasten's long-standing collaboration with the open source community and how Kubestr serves as case study example of both an ambitious open source project and what is possible today for stateful storage in Kubernetes environments.

Abstract of the talk… In this talk we will discuss what are the best patterns to create stateful applications on top of Kubernetes. This will include application layer caching, embeddable database as well as leveraging kubernetes objects to store and sync state across multiple replicas. Bio… Prashant is passionate about democratizing best AppOps practices for Kubernetes and has started Devtron and open source platform for AppOps on top of Kubernetes. Recently open sourced Devtron has been instrumental in adoption of Kubernetes in some of the largest startups in India.

Heute mal ein hands on UX Thema, das ihr sofort umsetzen könnt. Heute geht`s um den (neudeutsch) Stateful Button. Was dieser Button mit einer integrierten Statusanzeige ist und wie er ein super quick win für euer User Interface ist, hört ihr in dieser Folge von Software für Menschen!

React is a JavaScript library for building user interfaces and is one of the most widely used libraries to date. Last season we discussed the basics of React and today we’re going to dive into the more advanced aspects of the library. Let’s get started. Episode Notes [04:16] React Hooks [22:28] State Management [26:43] Design Patterns [40:39] Performance [49:33] Testing [51:15] Prop types and TypeScript [55:21] Shoutouts Resources Getting Hooked On React - https://www.ladybug.dev/episodes/getting-hooked-on-react?rq=react React patterns - https://reactpatterns.com/ React Chrome Developer Tools - https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi react-window - https://react-window.now.sh/#/examples/list/fixed-size react-virtualized - https://bvaughn.github.io/react-virtualized/#/components/List Methods of Improving & Optimizing Performance In React Apps - https://www.smashingmagazine.com/2020/07/methods-performance-react-apps/ React Testing Library - https://testing-library.com/docs/react-testing-library/intro/ Enzyme - https://enzymejs.github.io/enzyme/ Jest - https://jestjs.io/docs/en/getting-started A Complete Guide to useEffect - https://overreacted.io/a-complete-guide-to-useeffect/ Use Refs Sparingly - https://blog.logrocket.com/why-you-should-use-refs-sparingly-in-production/ Presentational and Stateful components thoughts - https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 Episode with Angie - https://www.ladybug.dev/episodes/teaching-code Kent C. Dodd’s Testing React - https://testingjavascript.com/ TypeScript book Stefan Baumgartner - https://typescript-book.com/ Playground Inspector Tik Tok - https://www.tiktok.com/@lukedonkin/video/6898240190133980418?lang=en Transcript https://github.com/ladybug-podcast/ladybug-website/blob/master/transcripts/69-intermediate-react.md

“O mundo seria um lugar de paz se não houvesse stateful”, porque as aplicações em si o Kubernetes gerencia, mas e os dados? Onde é que se armazena? Como faz para serem migrados, mantidos ou restaurados? Ainda, como faz para crescer os discos garantindo a disponibilidade das aplicações? Por favor, tenha a Santa Persistência! Para conversar sobre essas questões, o Kubicast chamou o Fabrízio de Royes Mello, um dos organizadores e contribuidor da comunidade PostgreSQL e o @João Vitor Araújo, que atende também por DevOps fantasma. ===== O programa traz também o quadro From the Top com Diogo Goebel, CEO da Getup, entrevistando Josmar Peixe, gerente de Arquitetura e Soluções do Banco Rendimento, sobre a jornada Kubernetes na instituição financeira. =====LINKS citados no episódio: Stackgres - https://github.com/ongres/stackgres - Dump não é backup - https://www.savepoint.blog.br/2010/05/06/dump-nao-e-backup/ - YugaByte - Bogdan Matican - https://www.altoros.com/blog/running-stateful-apps-on-kubernetes-with-statefulsets/RECOMENDAÇÕES dos participantes: Fabrízio: Assado Gaúcho com chimarrão e/ou cerveja/João Vitor: replay do Flamengo x Atlético /João Brito: Caçadores de Trolls ===== O Kubicast está disponível no Spotify, Overcast, Itunes e RadioPublic. ===== Para enviar comentários, críticas e sugestões, escreva para @GetupCloud no Twitter. ===== Bom programa e boas festas para você!

"Seems like things are getting back to normal." Not exactly. Folks with that view are not looking very closely. But we are. 

Today on the show we are very lucky to be joined by Chris Umbel and Shaun Anderson from Pivotal to talk about app transformation and modernization! Our guests help companies to update their systems and move into more up-to-date setups through the Swift methodology and our conversation focusses on this journey from legacy code to a more manageable solution. We lay the groundwork for the conversation, defining a few of the key terms and concerns that arise for typical clients and then Shaun and Chris share a bit about their approach to moving things forward. From there, we move into the Swift methodology and how it plays out on a project before considering the benefits of further modernization that can occur after the initial project. Chris and Shaun share their thoughts on measuring success, advantages of their system and how to avoid roll back towards legacy code. For all this and more, join us on The Podlets Podcast, today! Follow us: https://twitter.com/thepodlets Website: https://thepodlets.io Feeback: info@thepodlets.io https://github.com/vmware-tanzu/thepodlets/issues Hosts: Carlisia Campos Josh Rosso Duffie Cooley Olive Power Key Points From This Episode: A quick introduction to our two guests and their roles at Pivotal. Differentiating between application organization and application transformation. Defining legacy and the important characteristics of technical debt and pain. The two-pronged approach at Pivotal; focusing on apps and the platform. The process of helping companies through app transformation and what it looks like. Overlap between the Java and .NET worlds; lessons to be applied to both. Breaking down the Swift methodology and how it is being used in app transformation. Incremental releases and slow modernization to avoid roll back to legacy systems. The advantages that the Swift methodology offers a new team. Possibilities of further modernization and transformation after a successful implementation. Measuring success in modernization projects in an organization using initial objectives. Quotes: “App transformation, to me, is the bucket of things that you need to do to move your product down the line.” — Shaun Anderson [0:04:54] “The pioneering teams set a lot of the guidelines for how the following teams can be doing their modernization work and it just keeps rolling down the track that way.” — Shaun Anderson [0:17:26] “Swift is a series of exercises that we use to go from a business problem into what we call a notional architecture for an application.” — Chris Umbel [0:24:16] “I think what's interesting about a lot of large organizations is that they've been so used to doing big bang releases in general. This goes from software to even process changes in their organizations.” — Chris Umbel [0:30:58] Links Mentioned in Today’s Episode: Chris Umbel — https://github.com/chrisumbel Shaun Anderson — https://www.crunchbase.com/person/shaun-anderson Pivotal — https://pivotal.io/ VMware — https://www.vmware.com/ Michael Feathers — https://michaelfeathers.silvrback.com/ Steeltoe — https://steeltoe.io/ Alberto Brandolini — https://leanpub.com/u/ziobrando Swiftbird — https://www.swiftbird.us/ EventStorming — https://www.eventstorming.com/book/ Stephen Hawking — http://www.hawking.org.uk/ Istio — https://istio.io/ Stateful and Stateless Workload Episode — https://thepodlets.io/episodes/009-stateful-and-stateless/ Pivotal Presentation on Application Transformation: https://content.pivotal.io/slides/application-transformation-workshop Transcript: EPISODE 19 [INTRODUCTION] [0:00:08.7] ANNOUNCER: Welcome to The Podlets Podcast, a weekly show that explores Cloud Native one buzzword at a time. Each week, experts in the field will discuss and contrast distributed systems concepts, practices, tradeoffs and lessons learned to help you on your cloud native journey. This space moves fast and we shouldn’t reinvent the wheel. If you’re an engineer, operator or technically minded decision maker, this podcast is for you. [EPISODE] [0:00:41.0] CC: Hi, everybody. Welcome back to The Podlets. Today, we have an exciting show. It's myself on, Carlisia Campos. We have our usual guest hosts, Duffie Cooley, Olive Power and Josh Rosso. We also have two special guests, Chris Umbel. Did I say that right, Chris? [0:01:03.3] CU: Close enough. [0:01:03.9] CC: I should have checked before. [0:01:05.7] CU: Umbel is good. [0:01:07.1] CC: Umbel. Yeah. I'm not even the native English speaker, so you have to bear with me. Shaun Anderson. Hi. [0:01:15.6] SA: You said my name perfectly. Thank you. [0:01:18.5] CC: Yours is more standard American. Let's see, the topic of today is application modernization. Oh, I just found out word I cannot pronounce. That's my non-pronounceable words list. Also known as application transformation, I think those two terms correctly used alternatively? The experts in the house should say something. [0:01:43.8] CU: Yeah. I don't know that I would necessarily say that they're interchangeable. They're used interchangeably, I think by the general population though. [0:01:53.0] CC: Okay. We're going to definitely dig into that, how it does it not make sense to use them interchangeably, because just by the meaning, I would think so, but I'm also not in that world day-to-day and that Shaun and Chris are. By the way, please give us a brief introduction the two of you. Why don't you go first, Chris? [0:02:14.1] CU: Sure. I am Chris Umbel. I believe it was probably actually pronounced Umbel in Germany, but I go with Umbel. My title this week is the – I think .NET App Transformation Journey Lead. Even though I focus on .NET modernization, it doesn't end there. Touch a little bit of everything with Pivotal. [0:02:34.2] SA: I'm Shaun Anderson and I share the same title of the week as Chris, except for where you say .NET, I would say Java. In general, we play the same role and have slightly different focuses, but there's a lot of overlap. [0:02:48.5] CU: We get along, despite the .NET and Java thing. [0:02:50.9] SA: Usually. [0:02:51.8] CC: You both are coming from Pivotal, yeah? As most people should know, but I'm sure now everybody knows, Pivotal was just recently as of these date, which is what we are? End of January. This episode is going to be a while to release, but Pivotal was just acquired by VMware. Here we are. [0:03:10.2] SA: It's good to be here. [0:03:11.4] CC: All right. Somebody, one of you, may be let's say Chris, because you've brought this up, how this application organization differs from application transformation? Because I think we need to lay the ground and lay the definitions before we can go off and talk about things and sound experts and make sure that everybody can follow us. [0:03:33.9] CU: Sure. I think you might even get different definitions, even from within our own practice. I'll at least lay it out as I see it. I think it's probably consistent with how Shaun's going to see it as well, but it's what we tell customers anyway. At the end of the day, there are – app transformation is the larger [inaudible] bucket. That's going to include, say just the re-hosting of applications, taking applications from point A to some new point B, without necessarily improving the state of the application itself. We'd say that that's not necessarily an exercise in paying down technical debt, it's just making some change to an application or its environment. Then on the modernization side, that's when things start to get potentially a little more architectural. That's when the focus becomes paying down technical debt and really improving the application itself, usually from an architectural point of view and things start to look maybe a little bit more like rewrites at that point. [0:04:31.8] DC: Would you say that the transformation is more in-line with re-platforming, those of you that might think about it? [0:04:36.8] CU: We'd say that app transformation might include re-platforming and also the modernization. What do you think of that, Shaun? [0:04:43.0] SA: I would say transformation is not just the re-platforming, re-hosting and modernization, but also the practice to figure out which should happen as well. There's a little bit more meta in there. Typically, app transformation to me is the bucket of things that you need to do to move your product down the line. [0:05:04.2] CC: Very cool. I have two questions before we start really digging to the show, is still to lay the ground for everyone. My next question will be are we talking about modernizing and transforming apps, so they go to the clouds? Or is there a certain cut-off that we start thinking, “Oh, we need to – things get done differently for them to be called native.” Is there a differentiation, or is this one is the same as the other, like the process will be the same either way? [0:05:38.6] CU: Yeah, there's definitely a distinction. The re-platforming bucket, that re-hosting bucket of things is where your target state, at least for us coming out of Pivotal, we had definitely a product focus, where we're probably only going to be doing work if it intersects with our product, right? We're going to be doing both re-platforming targeted, say typically at a cloud environment, usually Cloud Foundry or something to that effect. Then modernization, while we're usually doing that with customers who have been running our platform, there's nothing to say that you necessarily need a cloud, or any cloud to do modernization. We tend to based on who we work for, but you could say that those disciplines and practices really are agnostic to where things run. [0:06:26.7] CC: Sorry, I was muted. I wanted to ask Shaun if you wanted to add to that. Do you have the same view? [0:06:33.1] SA: Yeah. I have the same view. I think part of what makes our process unique that way is we're not necessarily trying to target a platform for deployment, when we're going through the modernization part anyway. We're really looking at how can we design this application to be the best application it can be. It just so happens that that tends to be more 12-factor compliant that is very cloud compatible, but it's not necessarily the way that we start trying to aim for a particular platform. [0:07:02.8] CC: All right. If everybody allows me, after this next question, I'll let other hosts speak too. Sorry for monopolizing, but I'm so excited about this topic. Again, in the spirit of understanding what we're talking about, what do you define as legacy? Because that's what we're talking about, right? We’re definitely talking about a move up, move forwards. We're not talking about regression and we're not talking about scaling down. We're talking about moving up to a modern technology stack. That means, that implies we're talking about something that's legacy. What is legacy? Is it contextual? Do we have a hard definition? Is there a best practice to follow? Is there something public people can look at? Okay, if my app, or system fits this recipe then it’s considered legacy, like a diagnosis that has a consensus. [0:07:58.0] CU: I can certainly tell you how you can't necessarily define legacy. One of the ways is by the year that it was written. You can certainly say that there are certainly shops who are writing legacy code today. They're still writing legacy code. As soon as they're done with a project, it's instantly legacy. There's people that are trying to define, like another Michael Feathers definition, which is I think any application that doesn't have tests, I don't know that that fits what – our practice necessarily sees legacy as. Basically, anything that's occurred a significant amount of technical debt, regardless of when the application was written or conceived fits into that legacy bucket. Really, our work isn't necessarily as concerned about whether something's legacy or not as much as is there pain that we can solve with our practice? Like I said, we've modernized things that were in for all intents and purposes, quite modern in terms of the year they were written. [0:08:53.3] SA: Yeah. I would double down on the pain. Legacy to us often is something that was written as a prototype a year ago. Now it's ready to prove itself. It's going to be scaled up, but it wasn't built with scale in mind, or something like that. Even though it may be the latest technology, it just wasn't built for the load, for example. Sometimes legacy can be – the pain is we have applications on a mainframe and we can't find Cobol developers and we're leasing a giant mainframe and it's costing a lot of money, right? There's different flavors of pain. It also could be something as simple as a data center move. Something like that, where we've got all of our applications running on Iron and we need to go to a virtual data center somewhere, whether it's cloud or on-prem. Each one of those to us is legacy. It's all about the pain. [0:09:47.4] CU: I think is miserable as that might sound, that's really where it starts and is listening to that pain and hearing directly from customers what that pain is. Sounds terrible when you think about it that you're always in search of pain, but that isn't indeed what we do and try to alleviate that in some way. That pain is what dictates the solution that you come up with, because there are certain kinds of pain that aren't going to be solved with say, modernization approach, a more a platformed approach even. You have to listen and make sure that you're applying the right medicine to the right pain. [0:10:24.7] OP: Seems like an interesting thing bringing what you said, Chris, and then what you said earlier, Shaun. Shaun you had mentioned the target platform doesn't necessarily matter, at least upfront. Then Chris, you had implied bringing the right thing in to solve the pain, or to help remedy the pain to some degree. I think what's interesting may be about the perspectives for those on this call and you too is a lot of times our entry points are a lot more focused with infrastructure and platform teams, where they have these objectives to solve, like cost and ability to scale and so on and so forth. It seems like your entry point, at least historically is maybe a little bit more focused on finding pain points on more of the app side of the house. I'm wondering if that's a fair assessment, or if you could speak to how you find opportunities and what you're really targeting. [0:11:10.6] SA: I would say that's a fair assessment from the perspective of our services team. We're mainly app-focused, but it's almost there's a two-pronged approach, where there's platform pain and application pain. What we've seen is often solving one without the other is not a great solution, right? I think that's where it's challenging, because there's so much to know, right? It's hard to find one team or one person who can point out the pain on both sides. It just depends on often, how the customer approaches us. If they are saying something like, “We’re a credit card company and we're getting our butts kicked by this other company, because they can do biometrics and we can't yet, because of the limitations of our application.” Then we would approach it from the app-first perspective. If it's another pain point, where our operations, day two operations is really suffering, we can't scale, where we have issues that the platform is really good at solving, then we may start there. It always tends to merge together in the end. [0:12:16.4] CU: You might be surprised how much variety there is in terms of the drivers for people coming to us. There are a lot of cases where the work came to us by way of the platform work that we've done. It started with our sister team who focuses on the platform side of things. They solve the infrastructure problems ahead of us and then we close things out on the application side. We if our account teams and our organization is really listening to each individual customer that you'll find that there – that the pain is drastically different, right? There are some cases where the driver is cost and that's an easy one to understand. There are also drivers that are usually like a date, such as this data center goes dark on this date and I have to do something about it. If I'm not out of that data center, then my apps no longer run. The solution to that is very different than the solution you would have to, "Look, my application is difficult for me to maintain. It takes me forever to ship features. Help me with that." There's two very different solutions to those problems, but each of which are things that come our way. It's just that former probably comes in by way of our platform team. [0:13:31.1] DC: Yeah, that’s an interesting space to operate in in the application transformation and stuff. I've seen entities within some of the larger companies that represent this field as well. Sometimes that's called production engineering or there are a few other examples of this that I'm aware of. I'm curious how you see that happening within larger companies. Do you find that there is a particular size entity that is actually striving to do this work with the tools that they have internally, or do you find that typically, most companies are just need something like an application transformation so you can come in and help them figure out this part of it out? [0:14:09.9] SA: We've seen a wide variety, I think. One of them is maybe a company really has a commitment to get to the cloud and they get a platform and then they start putting some simple apps up, just to learn how to do it. Then they get stuck with, “Okay. Now how do we with trust get some workloads that are running our business on it?” They will often bring us in at that point, because they haven't done it before. Experimenting with something that valuable to them is — usually means that they slow down. There's other times where we've come in to modernize applications, whether it's a particular business unit for example, that may have been trying to get off the mainframe for the last two years. They’re smart people, but they get stuck again, because they haven't figured out how to do it. What often happens and Chris can talk about some examples of this is once we help them figure out how to modernize, or the recipes to follow to start getting their systems systematically on to the platform and modernize, that they tend to like forming a competency area around it, where they'll start to staff it with the people who are really interested and they take over where we started from. [0:15:27.9] CU: There might be a little bit of bias to that response, in that typically, in order to even get in the door with us, you're probably a Fortune 100, or at least a 500, or government, or something to that effect. We're going to be seeing people that one, have a mainframe to begin with. Two, would have say, capacity to fund say a dedicated transformation team, or to build a unit around that. You could say that the smaller an organization gets, maybe the easier it is to just have the entire organization just write software the modern way to begin with. At least at the large side, we do tend to see people try to build a – they'll use different names for it. Try to have a dedicated center of excellence or practice around modernization. Our hope is to help them build that and hopefully, put them in a position that that can eventually disappear, because eventually, you should no longer need that as a separate discipline. [0:16:26.0] JR: I think that's an interesting point. For me, I argue that you do need it going forward, because of the cognitive overhead between understanding how your application is going to thrive on today's complex infrastructure models and understanding how to write code that works. I think that one person that has all of that in their head all the time is a little too much, a little too far to go sometimes. [0:16:52.0] CU: That's probably true. When you consider the size the portfolios and the size of the backlog for modernization that people have, I mean, people are going to be busy on that for a very long time anyway. It's either — even if it is finite, it still has a very long life span at a minimum. [0:17:10.7] SA: At a certain point, it becomes like painting the Golden Gate Bridge. As soon as you finish, you have to start again, because of technology changes, or business needs and that thing. It's probably a very dynamic organization, but there's a lot of overlap. The pioneering teams set a lot of the guidelines for how the following teams can be doing their modernization work and it just keeps rolling down the track that way. It may be that people are busy modernizing applications off of WebLogic, or WebSphere, and it takes a two years or more to get that completed for this enterprise. It was 20, 50 different projects. To them, it was brand-new each time, which is cool actually to come into that. [0:17:56.3] JR: I'm curious, I definitely love hear it from Olive. I have one more question before I pass it out and I think we’d love to hear your thoughts on all of this. The question I have is when you're going through your day-to-day working on .NET and Java applications and helping people figure out how to go about modernizing them, what we've talked about so far is that represents some of the deeper architectural issues and stuff. You've already mentioned 12 factor after and being able to move, or thinking about the way that you frame the application as far as inputs of those things that it takes to configure, or to think with the lifecycle of those things. Are there some other common patterns that you see across the two practices, Java and .NET, that you think are just concrete examples of stuff that people should take away maybe from this episode, that they could look at their app – and they’re trying to get ahead of the game a little bit? [0:18:46.3] SA: I would say a big part of the commonality that Chris and I both work on a lot is we have a methodology called the SWIFT methodology that we use to help discover how the applications really want to behave, define a notional architecture that is again, agnostic of the implementation details. We’ll often come in with a the same process and I don't need to be a .NET expert and a .NET shop to figure out how the system really wants to be designed, how you want to break things into microservices and then the implementation becomes where those details are. Chris and I both collaborate on a lot of that work. It makes you feel a little bit better about the output when you know that the technology isn't as important. You get to actually pick which technology fits the solution best, as opposed to starting with the technology and letting a solution form around it, if that makes sense. [0:19:42.4] CU: Yeah. I'd say that interesting thing is just how difficult it is while we're going through the SWIFT process with customers, to get them to not get terribly attached to the nouns of the technology and the solution. They've usually gone in where it's not just a matter of the language, but they have something picked in their head already for data storage, for messaging, etc., and they're deeply attached to some of these decisions, deeply and emotionally attached to them. Fundamentally, when we're designing a notional architecture as we call it, really you should be making decisions on what nouns you're going to pick based on that architecture to use the tools that fit that. That's generally a bit of a process the customers have to go through. It's difficult for them to do that, because the more technical their stakeholders tend to be, often the more attached they are to the individual technology choices and breaking that is the principal role for us. [0:20:37.4] OP: Is there any help, or any investment, or any coordination with those vendors, or the purveyors of the technologies that perhaps legacy applications are, or indeed the platforms they're running on, is there any help on that side from those vendors to help with application transformation, or making those applications better? Or do organizations have to rely on a completely independent, so the team like you guys to come in and help them with that? Do you understand my point? Is there any internal – like you mentioned WebLogic, WebSphere, do the purveyors of those platforms try and drive the transformation from within there? Or is it organizations who are running those apps have to rely on independent companies like you, or like us to help them with that? [0:21:26.2] SA: I think some of it depends on what the goal of the modernization is. If it's something like, we no longer want to pay Oracle licensing fees, then of course, obviously they – WebLogic teams aren't going to be happy to help. That's not always the case. Sometimes it's a case where we may have a lot of WebLogic. It's working fine, but we just don't like where it's deployed and we'd like to containerize it, move it to Kubernetes or something like that. In that case, they're more willing to help. At least in my experience, I've found that the technology vendors are rightfully focused just on upgrading things from their perspective and they want to own the world, right? WebLogic will say, “Hey, we can do everything. We have clustering. We have messaging. We've got good access to data stores.” It's hard to find a technology vendor that has that broader vision, or the discipline to not try to fit their solutions into the problem, when maybe they're not the best fit. [0:22:30.8] CU: I think it's a broad generalization, but specifically on the Java side it seems that at least with app server vendors, the status quo is usually serving them quite well. Quite often, we’re adversary – a bit of an adversarial relationship with them on occasion. I could certainly say that within the .NET space, we've worked a relatively collaboratively with Microsoft on things like Steeltoe, which is a I wouldn't say it's a springboot analog, but at least a microservice library that helps people achieve 12-factor cloud nativeness. That's something where I guess Microsoft represents both the legacy side, but also the future side and were part of a solution together there. [0:23:19.4] SA: Actually, that's a good point because the other way that we're seeing vendors be involved is in creating operators on Kubernetes side, or Cloud Foundry tiles, something that makes it easy for their system to still be used in the new world. That's definitely helpful as well. [0:23:38.1] CC: Yeah, that's interesting. [0:23:39.7] JR: Recently, myself me people on my team went through a training from both Shaun and Chris, interestingly enough in Colorado about this thing called the SWIFT methodology. I know it's a really important methodology to how you approach some of the application transformation-like engagements. Could you two give us a high-level overview of what that methodology is? [0:24:02.3] SA: I want to hear Chris go through it, since I always answer that question first. [0:24:09.0] CU: Sure. I figured since you were the inventor, you might want to go with it Shaun, but I'll give it a stab anyway. Swift is a series of exercises that we use to go from a business problem into what we call a notional architecture for an application. The one thing that you'll hear Shaun say all the time that I think is pretty apt, which is we're trying to understand how the application wants to behave. This is a very analog process, especially at the beginning. It's one where we get people who can speak about the business problem behind an application and the business processes behind an application. We get them into a room, a relatively large room typically with a bunch of wall space and we go through a series of exercises with them, where we tease that business process apart. We start with a relatively lightweight version of Alberto Brandolini’s event storing method, where we map out with the subject matter experts, what all of the business events that occur in a system are. That is a non-technical exercise, a completely non-technical exercise. As a matter of fact, all of this uses sticky notes and arts and crafts. After we've gone through that process, we transition into Boris diagram, which is an exercise of Shaun's design that we take the domains that we've, or at least service candidates that we've extrapolated from that event storming and start to draw out a notional architecture. Like an 80% idea of what we think the architecture is going to look like. We're going to do this for slices of – thin slices of that business problem. At that point, it starts to become something that a software developer might be interested in. We have an exercise called Snappy that generally occurs concurrently, which translates that message flow, Boris diagram thing into something that's at least a little bit closer to what a developer could act upon. Again, these are sticky note and analog exercises that generally go on for about a week or so, things that we do interactively with customers to try to get a purely non-technical way, at least at first, so that we can understand that problem and tell you what an architecture is that you can then act on. We try to position this as a customer. You already have all of the answers here. What we're going to do as facilitators of these is try to pull those out of your head. You just don't know how to get to the truth, but you already know that truth and we're going to design this architecture together. How did I do, Shaun? [0:26:44.7] SA: I couldn't have said it better myself. I would say one of the interest things about this process is the reason why it was developed the way it was is because in the world of technology and especially engineers, I definitely seen that you have two modes of thought when you come from the business world to the to the technical world. Often, engineers will approach a problem in a very different way and a very focused, blindered way than business folks. Ultimately, what we try to think of is that the purpose for the software is to enable the business to run well. In order to do that, you really need to understand at least at a high-level, what the heck is the business doing? Surprisingly and almost consistently, the engineering team doing the work is separated from the business team enough that it's like playing the telephone game, right? Where the business folks say, “Well, I told them to do this.” The technical team is like, “Oh, awesome. Well then, we're going to use all this amazing technology and build something that really doesn't support you.” This process really brings everybody together to discover how the system really wants to behave. Also as a side effect, you get everybody agreeing that yes, that is the way it's supposed to be. It's exciting to see teams come together that actually never even work together. You see the light bulbs go on and say, “Oh, that's why you do that.” The end result is in a week, we can go from nobody really knows each other, or quite understands the system as a whole, to we have a backlog of work that we can prioritize based on the learnings that we have, and feel pretty comfortable that the end result is going to be pretty close to how we want to get there. Then the biggest challenge is defining how do we get from point A to point B. That's part of that layering of the Swift method is knowing when to ask those questions. [0:28:43.0] JR: A micro follow-up and then I'll keep my mouth shut for a little bit. Is there a place that people could go online to read about this methodology, or just get some ideas of what you just described? [0:28:52.7] SA: Yeah. You can go to swiftbird.us. That has a high-level overview of more the public facing of how the methodology works. Then there's also internal resources that are constantly being developed as well. That's where I would start. [0:29:10.9] CC: That sounds really neat. As always, we are going to have links on the show notes for all of this. I checked out the website for the EventStorming book. There is a resources page there and has a list of a bunch of presentations. Sounds very interesting. I wanted to ask Chris and Shaun, have you ever seen, or heard of a case where a company went through the transformation, or modernization process and then they roll back to their legacy system for any reason? [0:29:49.2] SA: That's actually a really good question. It implies that often, the way people think about modernization would be more of a big bang approach, right? Where at a certain point in time, we switch to the new system. If it doesn't work, then we roll back. Part of what we try to do is have incremental releases, where we're actually putting small slices into production where you're not rolling back a whole – from modern back to legacy. It's more of you have a week's worth of work that's going into production that's for one of the thin slices, like Chris mentioned. If that doesn't work where there's something that is unexpected about it, then you're rolling back just a small chunk. You're not really jumping off a cliff for modernization. You're really taking baby steps. If it's a two step forward and one step back, you're still making a lot of really good progress. You're also gaining confidence as you go that in the end in two years, you're going to have a completely shiny new modern system and you're comfortable with it, because you're getting there an inch of the time, as opposed to taking a big leap. [0:30:58.8] CU: I think what's interesting about a lot of large organizations is that they've been so used to doing big bang releases in general. This goes from software to even process changes in their organizations. They’ve become so used to that that it often doesn't even cross their mind that it's possible to do something incrementally. We really do often times have to get spend time getting buy-in from them on that approach. You'd be surprised that even in industries that you’d think would be fantastic with managing risk, when you look at how they actually deal with deployment of software and the rolling out of software, they’re oftentimes taking approaches that maximize their risk. There's no way to make something riskier by doing a big bang. Yeah, as Shaun mentioned, the specifics of the swift are to find a way, so that you can understand where and get a roadmap for how to carve out incremental slices, so that you can strangle a large monolithic system slowly over time. That's something that's pretty powerful. Once someone gets bought in on that, they absolutely see the value, because they're minimizing risk. They're making small changes. They're easy to roll back one at a time. You might see people who would stop somewhere along the way, and we wouldn't necessarily say that that's a problem, right? Just like not every app needs to be modernized, maybe there's portions of systems that could stay where they are. Is that a bad thing? I wouldn't necessarily say that it is. Maybe that's the way that – the best way for that organization. [0:32:35.9] DC: We've bumped into this idea now a couple of different times and I think that both Chris and Shaun have brought this up. It's a little prelude to a show that we are planning on doing. One of the operable quotes from that show is the greatest enemy of knowledge is not the ignorance, it is the illusion of knowledge. It's a quote by Stephen Hawking. It speaks exactly to that, right? When you come to a problem with a solution in your mind that is frequently difficult to understand the problem on its merit, right? It’s really interesting seeing that crop up again in this show. [0:33:08.6] CU: I think even oftentimes, the advantage of a very discovery-oriented method, such as Swift is that it allows you to start from scratch with a problem set with people maybe that you aren't familiar with and don't have some of that baggage and can ask the dumb questions to get to some of the real answers. It's another phrase that I know Shaun likes to use is that our roles is facilitator to this method are to ask dumb questions. I mean, you just can't put enough value on that, right? The only way that you're going to break that established thinking is by asking questions at the root. [0:33:43.7] OP: One question, actually there was something recently that happened in the Kubernetes community, which I thought was pretty interesting and I'd like to get your thoughts on it, which is that Istio, which is a project that operates as a service mesh, I’m sure you all are familiar with it, has recently decided to unmodernize itself in a way. It was originally developed as a set of microservices. They have had no end of difficulty in getting in optimizing the different interactions between those services and the nodes. Then recently, they decided this might be a good example of when to monolith, versus when to microservice. I'm curious what your thoughts are on that, or if you have familiarity with it. [0:34:23.0] CU: What's actually quite – I'm not going to necessarily speak too much to this. Time will tell as to if the monolithing that they're doing at the moment is appropriate or not. Quite often, the starting point for us isn't necessarily a monolith. What it is is a proposed architecture coming from a customer that they're proud of, that this is my microservice design. You'll see a simple system with maybe hundreds of nano-services. The surprise that they have is that the recommendation from us coming out of our Swift sessions is that actually, you're overthinking this. We're going to take that idea that you have any way and maybe shrink that down and to save tens of services, or just a handful of services. I think one of the mistakes that people make within enterprises, or on microservices at the moment is to say, “Well, that's not a microcservice. It’s too big.” Well, how big or how small dictates a microservice, right? Oftentimes, we at least conceptually are taking and combining services based on the customers architecture very common. [0:35:28.3] SA: Monoliths aren't necessarily bad. I mean, people use them almost as a pejorative, “Oh, you have a monolith.” In our world it's like, well monoliths are bad when they're bad. If they're not bad, then that's great. The corollary to that is micro-servicing for the sake of micro-servicing isn't necessarily a good thing either. When we go through the Boris exercise, really what we're doing is we're showing how domain-based, or capabilities relate to each other. That happens to map really well in our opinion to first, cut microservices, right? You may have an order service, or a customer service that manages some of that. Just because we map capabilities and how they relate to each other, it doesn't mean the implementation can't even be as a single monolith, but componentized inside it, right? That's part of what we try really hard to do is avoid the religion of monolith versus microservices, or even having to spend a lot of time trying to define what a microservice is to you. It's really more of well, a system wants to behave this way. Now, surprise, you just did domain-driven design and mapped out some good 12-factor compliant microservices should you choose to build it that way, but there's other constraints that always apply at that point. [0:36:47.1] OP: Is there more traction in organizations implementing this methodology on a net new business, rather than current running businesses or applications? Is there are situations more so that you have seen where a new project, or a new functionality within a business starts to drive and implement this methodology and then it creeps through the other lines of business within the organization, because that first one was successful? [0:37:14.8] CU: I'd say that based on the nature of who our customers are as an app transformation practice, based on who those customers are and what their problems are, we're generally used to having a starting point of a process, or software that exists already. There's nothing at all to mandate that it has to be that way. As a matter of fact, with folks from our labs organization, we've used these methods in what you could probably call greener fields. At the end of the day when you have a process, or even a candidate process, something that doesn't exist yet, as long as you can get those ideas onto sticky notes and onto a wall, this is a very valid way of getting – turning ideas into an architecture and an architecture into software. [0:37:59.4] SA: We've seen that happen in practice a couple times, where maybe a piece of the methodology was used, like EventStorming just to get a feel for how the business wants to behave. Then to rapidly try something out in maybe more of a evolutionary architecture approach, MVP approach to let's just build something from a user perspective just to solve this problem and then try it out. If it starts to catch hold, then iterate back and now drill into it a little bit more and say, “All right. Now we know this is going to work.” We're modernizing something that may be two weeks old just because hooray, we proved it's valuable. We didn't necessarily have to spend as much upfront time on designing that as we would in this system that's already proven itself to be of business value. [0:38:49.2] OP: This might be a bit of a broad question, but what defines success of projects like this? I mean, we mentioned earlier about cost and maybe some of the drivers are to move off certain mainframes and things like that. If you're undergoing an application transformation, it seems to me like it's an ongoing thing. How do enterprises try to evaluate that return on investment? How does it relate to success criteria? I mean, faster release times, etc., potentially might be one, but how was that typically evaluated and somebody internally saying, “Look, we are running a successful project.” [0:39:24.4] SA: I think part of what we tried to do upfront is identify what the objectives are for a particular engagement. Often, those objectives start out with one thing, right? It's too costly to keep paying IBM or Oracle for WebLogic, or WebSphere. As we go through and talk through what types of things that we can solve, those objectives get added to, right? It may be the first thing, our primary objective is we need to start moving workloads off of the mainframe, or workloads off of WebLogic, or WebSphere, or something like that. There's other objectives that are part of this too, which can include things as interesting as developer happiness, right? They have a large team of a 150 developers that are really just getting sick of doing the same old thing and having new technology. That's actually a success criteria maybe down the road a little bit, but it's more of a nice to have. In a long-winded answer of saying, when we start these and when we incept these projects, we usually start out with let's talk through what our objectives are and how we measure success, those key results for those objectives. As we're iterating through, we keep measuring ourselves against those. Sometimes the objectives change over time, which is fine because you learn more as you're going through it. Part of that incremental iterative process is measuring yourself along the way, as opposed to waiting until the end. [0:40:52.0] CC: Yeah, makes sense. I guess these projects are as you say, are continuous and constantly self-adjusting and self-analyzing to re-evaluate success criteria to go along. Yeah, so that's interesting. [0:41:05.1] SA: One other interesting note though that personally we like to measure ourselves when we see one project is moving along and if the customers start to form other projects that are similar, then we know, “Okay, great. It's taking hold.” Now other teams are starting to do the same thing. We've become the cool kids and people want to be like us. The only reason it happens for that is when you're able to show success, right? Then other teams want to be able to replicate that. [0:41:32.9] CU: The customers OKRs, oftentimes they can be a little bit easier to understand. Sometimes they're not. Typically, they involve time or money, where I'm trying to take release times from X to Y, or decrease my spend on X to Y. The way that we I think measure ourselves as a team is around how clean do we leave the campsite when we're done. We want the customers to be able to run with this and to continue to do this work and to be experts. As much as we'd love to take money from someone forever, we have a lot of people to help, right? Our goal is to help to build that practice and center of excellence and expertise within an organization, so that as their goals or ideas change, they have a team to help them with that, so we can ride off into the sunset and go help other customers. [0:42:21.1] CC: We are coming up to the end of the episode, unfortunately, because this has been such a great conversation. It turned out to be a more of an interview style, which was great. It was great getting the chance to pick your brains, Chris and Shaun. Going along with the interview format, I like to ask you, is there any question that wasn't asked, but you wish was asked? The intent here is to illuminates what this process for us and for people who are listening, especially people who they might be in pain, but they might be thinking this is just normal. [0:42:58.4] CU: That's an interesting one. I guess to some degree, that pain is unfortunately normal. That's just unfortunate. Our role is to help solve that. I think the complacency is the absolute worst thing in an organization. If there is pain, rather than saying that the solution won't work here, let’s start to talk about solutions to that. We've seen customers of all shapes and sizes. No matter how large, or cumbersome they might be, we've seen a lot of big organizations make great progress. If your organization's in pain, you can use them as an example. There is light at the end of the tunnel. [0:43:34.3] SA: It's usually not a train. [0:43:35.8] CU: Right. Usually not. [0:43:39.2] SA: Other than that, I think you asked all the questions that we always try to convey to customers of how we do things, what is modernization. There's probably a little bit about re-platforming, doing the bare minimum to get something onto to the cloud. We didn't talk a lot about that, but it's a little bit less meta, anyway. It's more technical and more recipe-driven as you discover what the workload looks like. It's more about, is it something we can easily do a CF push, or just create a container and move it up to the cloud with minimal changes? There's not conceptually not a lot of complexity. Implementation-wise, there's still a lot of challenges there too. They're not as fun to talk about for me anyway. [0:44:27.7] CC: Maybe that's a good excuse to have some of our colleagues back on here with you. [0:44:30.7] SA: Absolutely. [0:44:32.0] DC: Yeah, in a previous episode we talked about persistence and state of those sorts of things and how they relate to your applications and how when you're thinking about re-platforming and even just where you're planning on putting those applications. For us, that question comes up quite a lot. That's almost zero trying to figure out the state model and those sort of things. [0:44:48.3] CC: That episode was named States in Stateless Apps, I think. We are at the end, unfortunately. It was so great having you both here. Thank you Duffie, Shaun, Chris and I'm going by the order I'm seeing people on my video. Josh and Olive. Until next time. Make sure please to let us know your feedback. Subscribe. Give us a thumbs up. Give us a like. You know the drill. Thank you so much. Glad to be here. Bye, everybody. [0:45:16.0] JR: Bye all. [0:45:16.5] CU: Bye. [END OF EPISODE] [0:45:17.8] ANNOUNCER: Thank you for listening to The Podlets Cloud Native Podcast. Find us on Twitter at https://twitter.com/ThePodlets and on the http://thepodlets.io/ website, where you'll find transcripts and show notes. We'll be back next week. Stay tuned by subscribing. [END]See omnystudio.com/listener for privacy information.

This week on The Podlets Cloud Native Podcast we have Josh, Carlisia, Duffie, and Nick on the show, and are also happy to be joined by a newcomer, Brian Liles, who is a senior staff engineer at VMWare! The purpose of today’s show is coming to a deeper understanding of the meaning of ‘stateful’ versus ‘stateless’ apps, and how they relate to the cloud native environment. We cover some definitions of ‘state’ initially and then move to consider how ideas of data persistence and co-ordination across apps complicate or elucidate understandings of ‘stateful’ and ‘stateless’. We then think about the challenging practice of running databases within Kubernetes clusters, which effectively results in an ephemeral system becoming stateful. You’ll then hear some clarifications of the meaning of operators and controllers, the role they play in mediating and regulating states, and also how important they are in a rapidly evolving but skills-scarce environment. Another important theme in this conversation is the CAP theorem or the impossibility of consistency, availability and partition tolerance all at once, but the way different databases allow for different combinations of two out of the three. We then move on to chat about the fundamental connection between workloads and state and then end off with a quick consideration about how ideas of stateful and stateless play out in the context of networks. Today’s show is a real deep dive offering perspectives from some the most knowledgeable in the cloud native space so make sure to tune in! Follow us: https://twitter.com/thepodlets Website: https://thepodlets.io Feeback: info@thepodlets.io https://github.com/vmware-tanzu/thepodlets/issues Hosts: Carlisia Campos Duffie Cooley Bryan Liles Josh Rosso Nicholas Lane Key Points From This Episode: • What ‘stateful’ means in comparison to ‘stateless’.• Understanding ‘state’ as a term referring to data which must persist.• Examples of stateful apps such as databases or apps that revolve around databases.• The idea that ‘persistence’ is debatable, which then problematizes the definition of ‘state’. • Considerations of the push for cloud native to run stateless apps.• How inter-app coordination relates to definitions of stateful and stateless applications.• Considering stateful data as data outside of a stateless cloud native environment.• Why it is challenging to run databases in Kubernetes clusters.• The role of operators in running stateful databases in clusters.• Understanding CRDs and controllers, and how they relate to operators.• Controllers mediate between actual and desired states.• Operators are codified system administrators.• The importance of operators as app number grows in a skill-scarce environment.• Mechanisms around stateful apps are important because they ensure data integrity.• The CAP theorem: the impossibility of consistency, availability, and tolerance.• Why different databases allow for different iterations of the CAP theorem.• When partition tolerance can and can’t get sacrificed.• Recommendations on when to run stateful or stateless apps through Kubernetes.• The importance of considering models when thinking about how to run a stateful app.• Varying definitions of workloads.• Pods can run multiple workloads• Workloads create states, so you can’t have one without the other.• The term ‘workloads’ can refer to multiple processes running at once.• Why the ephemerality of Kubernetes systems makes it hard to run stateful applications. • Ideas of stateful and stateless concerning networks.• The shift from server to browser in hosting stateful sessions. Quotes: “When I started envisioning this world of stateless apps, to me it was like, ‘Why do we even call them apps? Why don’t we just call them a process?’” — @carlisia [0:02:60] “‘State’ really is just that data which must persist.” — @joshrosso [0:04:26] “From the best that I can surmise, the operator pattern is the combination of a CRD plus a controller that will operate on events from the Kubernetes API based on that CRD’s configuration.” — @bryanl [0:17:00] “Once again, don’t let developers name them anything.” — @bryanl [0:17:35] “Data integrity is so important” — @apinick [0:22:31] “You have to really be careful about the different models that you’re evaluating when trying to think about how to manage a stateful application like a database.” — @mauilion [0:31:34] Links Mentioned in Today’s Episode: KubeCon+CloudNativeCon — https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/Google Spanner — https://cloud.google.com/spanner/CockroachDB — https://www.cockroachlabs.com/CoreOS — https://coreos.com/Red Hat — https://www.redhat.com/enMetacontroller — https://metacontroller.app/Brandon Philips — https://www.redhat.com/en/blog/authors/brandon-phillipsMySQL — https://www.mysql.com/ Transcript: EPISODE 009 [INTRODUCTION] [0:00:08.7] ANNOUNCER: Welcome to The Podlets Podcast, a weekly show that explores Cloud Native one buzzword at a time. Each week, experts in the field will discuss and contrast distributed systems concepts, practices, tradeoffs and lessons learned to help you on your cloud native journey. This space moves fast and we shouldn’t reinvent the wheel. If you’re an engineer, operator or technically minded decision maker, this podcast is for you. [INTERVIEW] [00:00:41] JR: All right! Hello, everybody, and welcome to episode 6 of The Cubelets Podcast. Today we are going to be discussing the concept of stateful and stateless and what that means in this crazy cloud native landscape that we all work. I am Josh Rosso. Joined with me today is Carlisia. [00:00:59] CC: Hi, everybody. [00:01:01] JR: We also have Duffie. [00:01:03] D: Hey, everybody. [00:01:04] JR: Nicholas. [00:01:05] NL: Yo! [00:01:07] JR: And a newcomer to the podcast, we also have Brian. Brian, you want to give us a little intro about yourself? [00:01:12] BL: Hi! I’m Brian. I work at VMWare. I do lots of community stuff, including sharing the KubeCon+CloudNativeCon. [00:01:22] JR: Awesome! Cool. All right. We’ve got a pretty good cast this week. So let’s dive right into it. I think one of the first things that we’ve been talking a bit about is the concept of what makes an application stateful? And of course in reverse, what makes an application stateless? Maybe we could try to start by discerning those two. Maybe starting with stateless if that makes? Does someone want to take that on? [00:01:45] CC: Well, I’m going to jump right in. I have always been a developer, as supposed to some of you or all of you have who have system admin backgrounds. The first time that I heard the stateless app, I was like, “What?” That wasn’t recent, okay? It was a long time ago, but that was a knot in my head. Why would you have a stateless app? If you have an app, you’re going to need state. I couldn’t imagine what that was. But of course it makes a lot of sense now. That was also when we were more in the monolithic world. [00:02:18] BM: Actually that’s a good point. Before you go into that, it’s a great point. Whenever we start with apps or we start developing apps, we think of an application. An application does everything. It takes input and it does stuff and it gives output. But now in this new world where we have lots of apps, big apps, small apps, we start finding that there’s apps that only talk and coordinate with other apps. They don’t do anything else. They don’t save any data. They don’t do anything. That’s what – where we get into this thing called stateless apps. Apps don’t have any type of data that they store locally. [00:02:53] CC: Yeah. It’s more like when I envision in my head. You said it brilliantly, Brian. It’s almost like a process. When I started envisioning this world of stateless apps, to me it was like, “Why do we even call them apps? Why don’t we just call them a process?” They’re just shifting back data and forth but they’re not – To me, at the beginning, apps were always stateless. They went together. [00:03:17] D: I think, frequently, people think of applications that have only locally relevant stuff that is actually not going to persist to disc, but maybe held in memory or maybe only relevant to the type of connection that’s coming through that application also as stateless, which is interesting, because there’s still some state there, but the premise is that you could lose that state and not lose the functionality of that code. [00:03:42] NL: Something that we might want to dive into really quickly when talking about stateless and stateful apps. What do we mean by the word state? When I first learned about these things, that was what always screwed me up. I’m like, “What do you mean state? Like Washington? Yeah. We got it over here.” [00:03:57] JR: Oh! State. That’s that word. State is one of those words that we use to sound smarter than we actually are 95% of the time, and that’s a number I just made up. When people are talking about state, they mean databases. Yeah. But there are other types of state as well. If you maintain local cache that needs to be persistent, if you have local files that you’re dealing with, like you’re opening files. That’s still state. State really is just that it’s data that must persist. [00:04:32] D: I agree with that definition. I think that state, whether persisted to memory or persisted to disc or persisted to some external system, that’s still what we refer to as state. [00:04:41] JR: All right. Makes sense and sounds about like what I got from it as well. [00:04:45] CC: All right. So now we have this world where we talk about stateless apps and stateful apps. Are there even stateful apps? Do we call a database an app? If we have a distributed system where we have one stateless app over here, another stateless app over there and then we have the database that’s connected to the two of them, are we calling the database a stateful app or is that whole thing – How do we call this? [00:05:15] NL: Yeah. The database is very much a state as an app with state. I’m very much – [00:05:19] D: That’s a close definition. Yeah. [00:05:21] NL: Yeah. Literally, it’s the epitome of a stateful app. But then you also have these apps that talk to databases as well and they might have local data, like data that – they start a transaction and then complete it or they have a long distributed type transaction. Any apps that revolve around a database, if they store local data, whether it’s within a transaction or something else, they’re still stateful apps. [00:05:46] D: Yup. I think you can modify and input data or modify state that has to be persisted in some way I think is a stateful app, even though I do think it’s confusing because of what – As I said before, I think that there are a bunch of applications that we think of, like not everybody considers Spark jobs to be stateful. Spark jobs, for example, are something that would bring data in, mutate that data in some way, produce some output and go away. The definition there is that Spark would generally push the resulting data into some other external system. It’s interesting, because in that model, Spark is not considered to be a stateful app because the Spark job could fail, go away, get recreated, pick up the pieces where it left off or just redo that work until all of the work is done. In many cases, people consider that to be a stateless application. That’s I think is like the crux – In my opinion, the crux of the confusion around what a stateful and stateless application is, is that people frequently – I think it’s more about where you store – what you mean by persistence and how that actually realizes in your application. If you’re pushing your state to an external database, is your application still stateful? [00:06:58] NL: I think it’s a good question, or if you are gathering data from an external source and mutating it in some way, but you don’t need data to be present when you start up, is that a stateful app or a stateless app? Even though you are taking in data, modifying it and checking it, sending out to some other mechanism or serving it in your own way, does that become like a stateless app? If that app gets killed and it comes back and it’s able to recover, is it stateful or stateless? That’s a bit of a gray area, I think. [00:07:26] JR: Yeah. I feel like a lot of the customers I work with, if the application can get killed even if it has some type of local state, they still refer to it as stateless usually, to me at least, when we talk about it because they think, “I can kind of restart this application and I’m not too worried about losing whatever it may have had.” Let’s say cached for simplicity, right? I think that kind of leads us into an interesting question. We’ve talked a lot on this podcast about cloud native infrastructure and cloud native applications and it seems like since the inception of cloud native, there’s always been this push that a stateless app is the best candidate to run or the easiest candidate to run. I’m just curious if we could dive into that for a moment. Why in the cloud native infrastructure area has there always been this push for running stateless applications? Why is it simpler? Those kinds of things. [00:08:15] BL: Before we dive into that, we have to realize – And this is just a problem of our whole ecosystem, this whole cloud native. We’re very hand-wavy in our descriptions for things. There’re a lot of ambiguous descriptions, and state is one of those. Just keep that in mind, that when we’re talking today, we’re really just talking about these things that store data and when that’s the state. Just keep that in mind as you’re listening to this. But when it comes to distributed systems in general, the easiest system is a system that doesn’t need coordination with any other system. If it happens to die, that’s okay. We can just restart it. People like to start there. It’s the easiest thing to start. [00:08:58] NL: Yeah, that was basically what I was going to say. If your application needs to tie into other applications, it becomes significantly more complicated to implement it, at least for your first time and in your system. These small applications that only – They don’t care about anybody else, they just take in data or not, they just do whatever. Those are super easy to start with because they’re just like, “Here. Start this up. Who cares? Whatever happens, it happens.” [00:09:21] CC: That could be a good boundary to define – I don’t want to jump back too far, but to define where is the stateless app to me is part of a system and just say it depends for it to come back up. Does it depend on something else that has state? [00:09:39] BL: I’ll give you an example. I can give you a good example of a stateless app that we use every day, every single one of us, none of us on this call, but when you search Google. You go to google.com and you go to the bar and you type in a search, what’s happening is there is a service at the beginning that collects that search and it federates the search over many different probably clusters of computers so they can actually do the search currently. That app that actually coordinates all that work is a stateless app most likely. All it does is just splits it up and allows more CPUs to do the work. Probably, that goes away. Probably not a problem. You probably have 10 more of them. That’s what I consider stateless. It doesn’t really own any of the data. It’s the coordinator. [00:10:25] CC: Yeah. If it goes down, it comes back up. It doesn’t need to reset itself to the state where it was before. It can truly be considered a stateless because it can just, “Okay. I reset. I’m starting from the beginning from this clear state.” [00:10:43] BL: Yes. That’s a good summary of that. [00:10:45] CC: Because another way to think about stateless – What makes an app stateful app, does it have to be combined or like deployed and shipped together with the part that maintains the state? That’s a more clear cut definition. Then that app is definitely a stateful app. [00:11:05] D: What we frequently talk about in like the cloud native space is like you know that you have a stateless app if you can just create 20 of them and not have to worry about the coordination of them. They are all workers. They are all going to take input. You could spread the load across those 20 in an identical way and not worry about which one you landed on. That’s stateless application. A stateful application is a very different thing. You have to have some coordination. You have to say how many databases can you have on a backend? Because you’re persisting data there, you have to be really careful about that you only write to the master database or to the writing database and you could read of any other memories of that database cluster, that sort of stuff. [00:11:44] CC: It might seem that we are going so deep into this differentiating between stateful and stateless, but this is so important because clusters are usually designed to be ephemeral. Ephemeral means obviously they die down, they are brought back up, the nodes, and you should worry as least as possible with the state of things. Then going back to what Joshua is saying, when we are in this cloud native world, usually we are talking about stateless apps, stateless workloads and then we’re going to just talk about what workload means. But then if that’s the case, where are the stateful apps? It’s like we have this vision that the stateful apps live outside the cloud native world? How does it work? But it’s supposed to work. [00:12:36] BL: Yup. This is the question that keeps a lot of people employed. Making sure my state is available when I need it. You know what? I’m not going to even use that word state. Making sure my data is available wherever I need it and when I need it. I don’t want to go too deep in right now, but this is actually a huge problem in the Kubernetes community in general, and we see it because there’s been lots of advice given, “Don’t run things like databases in your clusters.” This is why we see people taking the ideas of Google Spanner and like CockroachDB and actually going through a lot of work to make sure that you can run databases in Kubernetes clusters. The interesting piece about this is that we’re actually to the point where we can run these types of workloads in our clusters, but with a caveat, big star at the end, it’s very difficult and you have to know what you’re doing. [00:13:34] JR: Yeah. I want to dovetail on that Brian, because it’s something that we see all the time. I feel like when we first started setting up, let’s call them clusters, but in our case it was Kubernetes, right? We always saw that data level always being delegated to like if you’re in Amazon, some service that they hosted and so on. But now I think more and more of the customers that at least I’m seeing. I’m sure Nicholas and Duffie too, they’re interested in doing exactly what you just described. Cockroach is an example I literally just worked with recently, and it’s just interesting how much more thoughtful they have to be about their cluster operations. Going back to what you said Carlisia, it’s not as easy as just like trashing a cluster and instantiating a new one anymore, like they’re used to. They need to be more thoughtful about keeping that data integrity intact through things like upgrades and disaster recover. [00:14:18] D: Another interesting point kind to your point, Brian, is that like, frequently, people are starting to have conversations and concerns around data gravity, which means that I have a whole bunch of data that I need to work with, like to a Spark job, which I mentioned earlier. I need to basically put my compute where that data is. The way that I store that data inside the cluster and use Kubernetes to manage it or whether I just have to make sure that I have some way of bringing up compute workloads close to that data. It’s actually kind of introducing a whole new layer to this whole thing. [00:14:48] BL: Yeah! Whole new layer of work and a whole new layer of complexity, because that’s actually – The crux of all this is like where we slide the complexity too, but this is interesting, and I don’t want to go too far to this one definitely. This is why we’re seeing more people creating operators around managing data. I’ve seen operators who are bringing databases up inside of Kubernetes. I’ve seen operators that actually can bring up resources outside of Kubernetes using the Kubernetes API. The interesting thing about this is that I looked at both solutions and I said, “I still don’t know what the answer is,” and that’s great. That means that we have a lot to learn about the problem, and at least we have some paths for it. [00:15:29] NL: Actually, that kind of reminds me of the first time I ever heard the word stateful or stateless – I’m an infrastructure guy. Was around the discussion of operators, which there’s only a couple of years ago when operators were first introduced at CoreOS and some people were like, “Oh! Well, this is how you now operate a stateful mechanism inside of Kubernetes. This is the way forward that we want to propose.” I was just like, “Cool! What is that? What’s state? What do you mean stateful and stateless?” I had no idea. Josh, you were there. You’re like, “Your frontend doesn’t care about state and your backend does.” I’m like, “Does it? I don’t know. I’m not a developer.” [00:16:10] JR: Let’s talk about exactly that, because I think these patterns we’re starting to see are coming out of the needs that we’re all talking about, right? We’ve seen at least in the Kubernetes community a lot of push for these different constructs, like something called a stateful [inaudible 00:16:21], which isn’t that important right now, but then also like an operator. Maybe we can start by defining what is an operator? What is that pattern and why does it relate to stateful apps? [00:16:31] CC: I think that would be great. I am not clear what an operator is. I know there’s going to be a controller involved. I know it’s not a CRD. I am not clear on that at all, because I only work with CRDs and we don’t define – like the project I worked on with Velero, we don’t categorize it as an operator. I guess an operator uses specific framework that exists out there. Is it a Kubernetes library? I have no idea. [00:16:56] BL: We did it to ourselves again. We’re all doing these to ourselves. From the best that I can surmise, the operator pattern is the combination of a CRD plus a controller that will operate on events from the Kubernetes API based on that CRD’s configuration. That’s what an operator is. [00:17:17] NL: That’s exactly right. [00:17:18] BL: To conflate this, Red Hat created the operator SDK, and then you have [inaudible 00:17:23] and you have a Metacontroller, which can help you build operators. Then we actually sometimes conflate and call CRDs operators, and that’s pretty confusing for everyone. Once again, don’t let developers name anything. [00:17:41] CC: Wait. So let’s back up a little. Okay. There is an actual library that’s called an operator. [00:17:46] BL: Yes. There’s an operator SDK. [00:17:47] CC: Referred to as an operator. I heard that. Okay. Great. But let me back up a little because – [00:17:49] D: The word operator can [00:17:50] CC: Because if you are developing an app for Kubernetes, if you’re extending Kubernetes, you are – Okay, you might not use CRDs, but if you are using CRDs, you need a controller, right? Because how will you do actions? Then every app that has a CRD – because the alternative to having CRDs is just using the API directly without creating CRDs to reflect to resources. If you’re creating CRDs to reflect to resources, you need controllers. All of those apps, they have CRDs, are operators. [00:18:24] D: Yip [inaudible 00:18:25] is an operator. [00:18:26] CC: [inaudible 00:18:26] not an operator. How can you extend Kubernetes and not be qualified [inaudible 00:18:31] operator? [00:18:32] BL: Well, there’s a way. There is a way. You can actually just create a CRD and use a CRD for data storage, you know, store states, and you can actually query the Kubernetes API for that information. You don’t need a controller, but we couple them with controllers a lot to perform action based on that state we’ve saved to etcd. [00:18:50] CC: Duffie. [00:18:51] D: I want to back up just for a moment and talk about the controller pattern and what it is and then go from there to operators, because I think it makes it easier to get it in your head. A control pattern is effectively a way to understand desired state and real state and provide some logic or business code that will allow you to converge those two states, your actual state and your desired state. This is a pattern that we see used in almost everything within a distributed system. It’s like within Kubernetes, within most of the kind of more interesting systems that are out there. This control pattern describes a pretty good way of actually managing application flow across distributed systems. Now, operators, when they were initially introduced, we were talking about that this is a slightly different thing. Operators, when we introduced the idea, came more from like the operational burden of these stateful applications, things like databases and those sorts of stuff. With the database, etcd for example, you have a whole bunch of operational and runtime concerns around managing the lifecycle of that system. How do I add a new member to the cluster? What do I do when a member dies? How do I take action? Right now, that’s somebody like myself waking up at 2 in the morning and working through a run book to basically make sure that that service remains operational through the night. But the idea of an operator was to take that control pattern that we described earlier and make it wake up at 2 in the morning to fix this stuff. We’re going to actually codify the operational knowledge of managing the burden of these stateful applications so that we don’t have to wake up at 2 in the morning and do it anymore. Nobody wants to do that. [00:20:32] BL: Yeah. That makes sense. Remember back at KubCon years ago, I know it was one in Seattle where Brandon Philips was on stage talking about operators. He basically was saying if we think about SysOp, system operators, it was a way to basically automate or capture the knowledge of our system administrators in scripts or in a process or in code a la operators. [00:20:57] D: The last part that I’ll add to this thing, which I think is actually what really describes the value of this idea to me is that there are only so many people on the planet that do what the people in this blog post do. Maybe you’re one of them that listen to this podcast. People who are operating software or operating infrastructure at scale, there just aren’t that many of us on the planet. So as we add more applications, as more people adopt the cloud native regime or start coming to a place where they can crank out more applications more quickly, we’re going to have to get to a place where we are able to automate the burden of managing those applications, because there just aren’t enough of us to be able to support the load that is coming. There just aren’t enough people on the planet that do this to be able to support that. That’s the thing that excites me most about the operator pattern, is that it gives us a place to start. It gives us a place to actually start thinking about managing that burden over time, because if we don’t start changing the way we think about managing that burden, we’re going to run out of people. We’re not going to be able to do it. [00:22:05] NL: Yeah. It’s interesting. With stateful apps, we keep kind of bringing them – coming back to stateful apps, because stateful apps are hard and stateless apps are easy, and we’ve created all these mechanisms around operating things with state because of how just complicated it is to make sure that your data is ready, accessible and has integrity. That’s the big one that I keep not thinking about as a SysOps person coming into the Dev world. Data integrity is so important and making sure that your data is exactly what it needs to be and was the last time you checked it, is super important. It’s only something I’m really starting to grasp. That’s why I was like these things, like operators and all these mechanisms that we keep creating and recreating and recreating keep coming about, because making sure that your stateful apps have the right data at the right time is so important. [00:22:55] BL: Since you brought this up, and we just talked about why a state is so hard, I want to introduce the new term to this conversation, the whole CAP theorem, where data would typically be – in a distributed system at least, your data will be consistent or your data can be available, or if your distributed systems falls in multiple parts, you can have partition tolerance. This is one of those computer science things where you can actually pick two. You can have it be available and have partition tolerance, but your data won’t be consistent, or you can have consistency and availability, but you won’t have partition tolerance. If your cluster splits into two for some reason, the data will be bad. This is why it’s hard, this is why people have written basically lots of PhD dissertations on this subject, and this is why we are talking about this here today, is because managing state, and particularly managing distributed, is actually a very, very hard problem. But there’s software out there that will help us, and Kubernetes is definitely part of that and stateful sets are definitely part of that as well. [00:24:05] JR: I was just going to say on those three points, consistently, availability and partition tolerance. Obviously, we’d want all three if we could have them. Is there one that we most commonly tradeoff and give up or does it go case-by-case? [00:24:17] BL: Actually, it’s been proven. You can’t have all three. It’s literally impossible. It depends. If you have a MySQL server and you’re using MySQL to actually serve data out of this, you’re going to most likely get consistency and availability. If you have it replicated, you might not have partition tolerance. That’s something to think about, and there are different databases and this is actually one of the reasons why there are different databases. This is why people use things like relational databases and they use key value stores not because we really like the interfaces, but because they have different properties around the data. [00:24:55] NL: That’s an interesting point and something that I had recently just been thinking about, like why are there so many different types of databases. I just didn’t know. It was like in only recently heard of CAP theorem as well just before you mentioned it. I’m like, “Wow! That’s so fascinating.” The whole thing where you only pick two. You can’t get three. Josh, to kind of go back to your question really quickly, I think that partition tolerance is the one that we throw away the most. We’re willing to not be able to segregate our database as much as possible because C and A are just too important, I think. At least that’s what I’m saying, like I am wearing an [inaudible 00:25:26] shirt and [inaudible 00:25:27] is not partition tolerant. It’s bad at it. [00:25:31] BL: This is why Google introduced Spanner, and Spanner in some situations can get free with tradeoffs and a lot of really, really smart stuff, but most people can’t run this scale. But we do need to think about partition tolerance, especially with data whenever – Let’s say you run a store and you have multiple instances across the world and someone buys something from inventory, what is your inventory look like at any particular point? You don’t have to answer my question, of course, but think about that. These are still very important problems if fiber gets cut across the Atlantic and now I’ve sold more things than I have. Carlisia, speaking to you as someone who’s only been a developer, have you moved your thoughts on state any further? [00:26:19] CC: Well, I feel that I’m clear on – Well, I think you need to clarify your question better for me. If you’re asking if I understand what it means, I understand what it means. But I actually was thinking to ask this question to all of you, because I don’t know the answer, if that’s the question you’re asking me. I want to put that to the group. Do you recommend people, as in like now-ish, to run stateful workloads? We need to talk about workloads mean. Run stateful apps or database in sites if they’re running a Kubernetes cluster or if they’re planning for that, do you all as experts recommend that they should already be looking into doing that or they should be running for now their stateful apps or databases outside of the cloud native ecosystem and just connecting the two? Because if that’s what your question was, I don’t know. [00:27:21] BL: Well, I’ll take this first. I think that we should be spending lots of more time than we are right now in coming up community-tested solutions around using stateful sets to their best ability. What that means is let’s say if you’re running a database inside of Kubernetes and you’re using a stateful set to manage this, what we do need to figure out is what happens when my database goes down? The pod just kills? When I bring up a new version, I need to make sure that I have the correct software to verify integrity, rebuilt things, so that when it comes back up, it comes back up correctly. That’s what I think we should be doing. [00:27:59] JR: For me, I think working with customers, at least Kubernetes-oriented folks, when they’re trying to introduce Kubernetes as their orchestration part of their overall platform, I’m usually just trying to kind of meet them where they’re at. If they’re new to Kubernetes and distributed systems as a whole, if we have stateless, let’s call them maybe simpler applications to start with, I generally have them lean into that first, because we already have so much in front of us to learn about. I think it was either Brian or Duffie, you said it introduces a whole bunch more complexity. You have to know what you’re doing. You have to know how to operate these things. If they’re new to Kubernetes, I generally will advise start with stateless still. But that being said, so many of our customers that we work with are very interested in running stateful workloads on Kubernetes. [00:28:42] CC: But just to clarify what you said, Josh, because you spoke like an expert, but I still have beginner’s ears. You said something that sounded to me like you recommend that you go stateless. It sounded to me like that. What you really say is that they take out the stateless part of what they have, which they might already have or they might have to change and put the stateless. You’re not suggesting that, “Oh! You can’t do stateful anymore. You need to just do everything stateless.” What you’re saying is take the stateless part of your system, put that in Kubernetes, because that is really well-tested and keep the stateful outside of that ecosystem. Is that right? [00:29:27] JR: I think that’s a better way to put it. Again, it’s not that Kubernetes can’t do stateful. It’s more of a concept of biting off more than you can chew. We still work with a lot of people who are very new to these distributed systems concepts, and to take on running stateful workloads, if we could just delegate that to some other layer, like outside of the cluster, that could be a better place to start, at least in my experience. Nicholas and Duff might have different – [00:29:51] NL: Josh, you basically nailed it like what I was going to say, where it’s like if the team that I’m working with is interested in taking on the complexity of maintaining their databases, their stateful sets and making sure that they have data integrity and availability, then I’m all for them using Kubernetes for a stateful set. Kubernetes can run stateful applications, but there is all this complexity that we keep talking about and maintaining data and all that. If they’re willing to take on their complexity, great, it’s there for you. If they’re not, if they’re a little bit kind of behind as – Not behind, but if they’re kind of starting out their Kubernetes journey or their distributed systems journey, I would recommend them to move that complexity to somebody else and start with something a little bit easier, like a stateless application. There are a lot of good services that provide data as a service, right? You’ve got dataview as RDS is great for creating stateful application. You can leverage it anytime and you’ve got like dedicated wires too. I would point them to there first if they don’t want to take on like complexity. [00:30:51] D: I completely agree with that. An important thing I would add, which is in response to the stateful set piece here, is that as we’ve already described, managing a stateful application like a database does come with some complexity. So you should really carefully look at just what these different models provide you. Whether that model is making use of a stateful set, which provides you like ordinality, ensuring that things start up in a particular order and some of the other capabilities around that stuff. But it won’t, for example, manage some of the complexity. A stateful set won’t, for example, try and issue a command to the new member to make sure that it’s part of an existing database cluster. It won’t manage that kind of stuff. So you have to really be careful about the different models that you’re evaluating when trying to think about how to manage a stateful application like a database. I think because it’s actually why the topic of an operator came up kind of earlier, which was that like there are a lot of primitives within Kubernetes in general that provide you a lot of capability for managing things like stateful applications, but they may not entirely suit your needs. Because of the complexity with stateful applications, you have to really kind of be really careful about what you adopt and where you jump in. [00:32:04] CC: Yeah. I know just from working with Velero, which is a tool for doing backup and recovery migration of Kubernetes clusters. I know that we backup volumes. So if you have something mounted on a volume, we can back that up. I know for a fact that people are using that to backup stateful workloads. We need to talk about workloads. But at any case, one thing to – I think one of you mentioned is that you definitely also need to look at a backup and recovery strategy, which is ever more important if you’re doing stateful workloads. [00:32:46] NL: That’s the only time it’s important. If you’re doing stateless, who cares? [00:32:49] BL: Have we defined what a workload is? [00:32:50] CC: Yeah. But let me say something. Yeah, I think we should do an episode on that maybe, maybe not. We should do an episode on GitOps type of thing for related things, because even though you – Things are stateless, but I don’t want to get into it. Your cluster will change state. You can recover in stuff from like a fresh version. But as it goes through a lifecycle, it will change state and you might want to keep that state. I don’t know. I’m not the expert in that area, but let’s talk about workloads, Brian. Okay. Let me start talking about workloads. I never heard the term workload until I came into the cloud native world, and that was about a year ago or when they started looking in this space more closely. Maybe a little bit before a year ago. It took me forever to understand what a workload was. Now I understand, especially today, we’re talking about a little bit before we started recording. Let me hear from you all what it means to you. [00:34:00] BL: This is one of those terms, and I’m sure like the last any ex-Googlers about this, they’ll probably agree. This is a Google term that we actually have zero context about why it’s a term. I’m sure we could ask somebody and they would tell us, but workloads to me personally are anything that ultimately creates a pod. Deployments create replica sets, create pods. That whole thing is a workload. That’s how I look at it. [00:34:29] CC: Before there were pods, were there workloads, or is a workload a new thing that came along with pods? [00:34:35] BL: Once again, these words don’t make any sense to us, because they’re Google terms. I think that a pod is a part of a workload, like a deployment is a part of a workload, like a replica set is part of a workload. Workload is the term that encompasses an entire set of objects. [00:34:52] D: I think of a workload as a subset of an application. When I think of an application or a set of microservices, I might think of each of the services that make up that entire application as a workload. I think of it that way because that’s generally how I would divide it up to Brian’s point into different deployment or different stateful sets or different – That sort of stuff. Thinking of them each as their own autonomous piece, and altogether they form an application. That’s my think of it. [00:35:20] CC: To connect to what Brian said, deployment, will always run in the pods, which is super confusing if you’re not looking at these things, just so people understand, because it took me forever to understand that. The connection between a workload, a deployment and a pod. Pods contain – If you have a deployment that you’re going to shift Kubernetes – I don’t know if shift is the right word. You’re going to need to run on Kubernetes. That deployment needs to run somewhere, in some artifact, and that artifact is called a pod. [00:35:56] NL: Yeah. Going back to what Duffie said really quickly. A workload to me was always a process, kind of like not just a pod necessarily, but like whatever it is that if you’re like, “I just need to get this to run,” whatever that is. To me that was always a workload, but I think I’m wrong. I think I’m oversimplifying it. I’m just like whatever your process is. [00:36:16] BL: Yeah. I would give you – The reason why I would not say that is because a pod can run multiple containers at once, which ergo is multiple processes. That’s why I say it that way. [00:36:29] NL: Oh! You changed my mind. [00:36:33] BL: The reason I bring this up, and this is probably a great idea for a future show, is about all the jargon and terminology that we use in this land that we just take as everyone knows it, but we don’t all know it, and should be a great conversation to have around that. But the reason I always bring up the whole workload thing is because when we think about workloads and then you can’t have state without workloads, really. I just wanted to make sure that we tied those two things together. [00:36:58] CC: Why can you not have state without workloads? What does that mean? [00:37:01] BL: Well, the reason you can’t have state without workloads is because something is going to have to create that state, whether that workload is running in or out a cluster. Something is going to have to create it. It just doesn’t come out of nowhere. [00:37:11] CC: That goes back to what Nick was saying, that he thinks a workload is a process. Was that was you said, Nick? [00:37:18] NL: It is, yeah, but I’m renegading on that. [00:37:23] CC: At least I could see why you said that. Sorry, Brian. I cut you off. [00:37:28] BL: What I was saying is a workload ultimately is one or more processes. It’s not just a process. It’s not a single process. It could be 10, it could be 1. [00:37:39] JS: I have one final question, and we can bail on this and edit it out if it’s not a good one to end with. I hope it’s not too big, but I think maybe one thing we overlooked is just why it’s hard to run stateful workloads in these new systems like Kubernetes. We talked about how there’s more complexity and stuff, but there might be some room to talk about – People have been spinning up an EC2 server, a server on the web and running MySQL on it forever. Why in like the Kubernetes world of like pods and things is it a little bit harder to run, say, MySQL just [inaudible 00:38:10]. Is that something worth diving into? [00:38:13] NL: Yeah, I think so. I would say that for things like, say, applications, like databases particularly, they are less resilient to outages. While Kubernetes itself is dedicated to – Or most container orchestrations, but Kubernetes specifically, are dedicated to running your pods continuously as long as they will, that it is still somewhat of a shifting landscape. You do have priority and preemption. If you don’t set those things up properly of if there’s just like a total failure of your system at large, your stateful application can just go down at any time. Then how do you reconcile the outage in data, whatever data that might have gotten lost? Those sorts of things become significantly more complicated in an environment like Kubernetes where you don’t necessarily have access to a command line to run the commands to recover as easy. You may not, but it’s the same. [00:39:01] BL: Yes. You got to understand what databases do. Disk is slow, whether you have spinning disk or you have disk on chip, like SSD. What databases do in a lot of cases is they store things in memory. So if it goes away, didn’t get stored. In other cases, what databases do is they have these huge transactional logs, maybe they write them out in files and then they process the transaction log whenever they have CPU time. If a database dies just suddenly, maybe its state is inconsistent because it had items that were to be processed in a queue that haven’t been processed. Now it doesn’t know what’s going on, which is why – [00:39:39] NL: That’s interesting. I didn’t know that. [00:39:40] BL: If you kill MySQL, like kill MySQL D with a -9, why it might not come back up. [00:39:46] JR: Yeah. Going back to Kubernetes as an example, we are living in this newer world where things can get rescheduled and moved around and killed and their IPs changed and things. It seems like this environment is, should I say, more ephemeral, and those types of considerations becoming to be more complex. [00:40:04] NL: I think that really nails it. Yeah. I didn’t know that there were transactional logs about databases. I should, I feel like, have known that but I just have no idea. [00:40:11] D: There’s one more part to the whole stateful, stateless thing that I think is important to cover, but I don’t know if we’ll be able to cover it entirely in the time that we have left, and that is from the network perspective. If you think about the types of connections coming into an application, we refer to some of those connections as stateful and stateless. I think that’s something we could tackle in our remaining time, or what’s everybody’s thought? [00:40:33] JR: Why don’t you try giving us maybe a quick summary of it, Duffie, and then we can end on that. [00:40:36] CC: Yeah. I think it’s a good idea to talk about network and then address that in the context of network. I’m just thinking an idea for an episode. But give us like a quick rundown. [00:40:45] D: Sure. A lot of the kind of older monolithic applications, the way that you would scale these things is you would have multiple of them and then you would have some intelligence in the way that you’re routing connections down to those applications that would describe the ability to ensure that when Bob accesses a website and he authenticates, he’s going to authenticate to one specific instance of this application and the intelligence up in the frontend is going to handle the routing to make sure that Bob’s connection always comes back to that same instance. This is an older pattern. It’s been around for a very long time and it’s certainly the way that we first kind of learned to scale applications before we’ve decided to break into maker services and kind of handle a lot of this routing in a more resilient way. That was kind of one of the early versions of how we do this, and that is a pretty good example of a stateful session, and that there is actually some – Perhaps Bob has authenticated and he has a cookie that allows him, that when he comes back to that particular application, a lot of the settings, his browser settings, whether he’s using the dark theme or the light theme, that sort of stuff, is persisted on the server side rather than on the client side. That’s kind of what I mean by stateful sessions. Stateless sessions mean it doesn’t really matter that the user is terminating to the same end of point, because we’ve managed to keep the state either with the client. We’re handling state on the browser side of things rather on the server side of things. So you’re not necessarily gaining anything by pushing that connection back to the same specific instance, but just to a service that is more widely available. There are lots of examples of this. I mean, Brian’s example of Google earlier. Obviously, when I come back to Google, there are some things I want it to remember. I want it to remember that I’m logged in as myself. I want it to remember that I’ve used a particular – I want it to remember my history. I want it to remember that kind of stuff so that I could go back and find things that I looked at before. There are a ton of examples of this when we think about it. [00:42:40] JR: Awesome! All right, everyone. Thank you for joining us in episode 6, Stateful and Stateless. Signing off. I’m Josh Rosso, and going across the line, thank you Nicholas Lane. [00:42:54] NL: Thank you so much. This was really informative for me. [00:42:56] JR: Carlisia Campos. [00:42:57] CCC: This was a great conversation. Bye, everybody. [00:42:59] JR: Our new comer, Brian Liles. [00:43:01] BL: Until next time. [00:43:03] JR: And Duffie Cooley. [00:43:05] DCC: Thank you so much, everybody. [00:43:06] JR: Thanks all. [00:43:07] CCC: Bye! [END OF EPISODE] [0:50:00.3] ANNOUNCER: Thank you for listening to The Podlets Cloud Native Podcast. Find us on Twitter at https://twitter.com/ThePodlets and on the http://thepodlets.io/ website, where you'll find transcripts and show notes. We'll be back next week. Stay tuned by subscribing. [END]See omnystudio.com/listener for privacy information.

This week on BSDNow, Allan is back from his UK trip and we'll get to hear his thoughts on the developer summit. That plus all the This episode was brought to you by Headlines FreeBSD 11.0-RC1 Available (https://lists.freebsd.org/pipermail/freebsd-stable/2016-August/085277.html) FreeBSD is marching onwards to 11.0, and with it the first RC1 was released. In addition to the usual amd64 architectures, you may want to give it a whirl on your various ARM boards as well, as it includes images for the following systems: 11.0-RC1 amd64 GENERIC 11.0-RC1 i386 GENERIC 11.0-RC1 powerpc GENERIC 11.0-RC1 powerpc64 GENERIC64 11.0-RC1 sparc64 GENERIC 11.0-RC1 armv6 BANANAPI 11.0-RC1 armv6 BEAGLEBONE 11.0-RC1 armv6 CUBIEBOARD 11.0-RC1 armv6 CUBIEBOARD2 11.0-RC1 armv6 CUBOX-HUMMINGBOARD 11.0-RC1 armv6 GUMSTIX 11.0-RC1 armv6 RPI-B 11.0-RC1 armv6 RPI2 11.0-RC1 armv6 PANDABOARD 11.0-RC1 armv6 WANDBOARD 11.0-RC1 aarch64 GENERIC For those wondering the list of changes between this and BETA4, we have that as well: A NULL pointer dereference in IPSEC has been fixed. Support for SSH Protocol 1 has been removed. OpenSSH DSA keys have been disabled by default. Users upgrading from prior FreeBSD versions are urged to update their SSH keys to RSA or ECDSA keys before upgrading to 11.0-RC1. PCI-e hotplug on bridges with power controllers has been disabled. A loader tunable (hw.pci.enablepciehp) to disable PCI-e HotPlug has been added. A VESA panic on suspend has been fixed. Google Compute Engine image publication has been fixed. An AES-ICM heap corruption typo bug has been fixed. A regression in pf.conf while parsing the 'interval' keyword has been fixed. A ZFS/VFS deadlock has been fixed. RC2 is delayed while some issues are sorted out (https://lists.freebsd.org/pipermail/freebsd-stable/2016-August/085323.html) RC2 is looming large, but was pushed back a few days while the following bugs are sorted out: Issue with IPv6 UDP traffic being sent from wrong MAC address Layer2 violation with IPv6 *** OpenBSD just added initial support for the RaspberryPi 2 and 3 devices (https://marc.info/?l=openbsd-cvs&m=147059203101111&w=2) It's a good time to be an ARM and BSD enthusiast. In addition to all the ARM images in FreeBSD 11.0, we also have word that initial support for RPi2 and RPi3 has started to land in OpenBSD. Mark Kettenis has posted the following with his Commit: Initial support for Raspberry Pi 2/3. All the hard work done by patrick@, I just cleaned things up a bit. Any bugs introduced in that process are entirely mine. This doesn't work yet. But when it does, you'll need recent firmware from the Raspberry Pi Foundation git repository at: https://github.com/raspberrypi/firmware The device tree for the Raspberry Pi is somewhat in flux as bits and pieces to support the Raspberry Pi 2 and 3 are committed to the mainline Linux kernel.“ + Exciting news! We will of course keep you informed as to when we have images to play with. Running OpenBSD / PF on a RPi does sound intriguing. drm-4.8-rc2 tagged in drm-next (https://lists.freebsd.org/pipermail/freebsd-x11/2016-August/017840.html) Remember when FreeBSD lagged so far behind in Graphics support? Well, those days are rapidly coming to an end. Matt Macy has posted an update to the FreeBSD X11 list with news of his DRM branch being caught up all the way to Linux 4.8-RC2 now. This is a huge accomplishment, with Matt commenting: As of this moment sys/dev/drm in the drm-next tree is sync with https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the subset of drivers that FreeBSD supports - i915, radeon, and amdgpu). I feel this is a bit of a milestone as it means that it is possible that in the future graphics support on FreeBSD could proceed in lockstep with Linux. For those who want to try out the latest support, you can build from his branch at the following GitHub location: (https://github.com/FreeBSDDesktop/freebsd-base-graphics) Or, if compiling isn't your thing, TrueOS (The re-branded PC-BSD) will be releasing the a new ISO based upon his update to Linux 4.7 in the coming days, with 4.8-RC2 to follow in the next week or two. *** Installing FreeBSD for Raspberry Pi (https://www.freebsdfoundation.org/freebsd/how-to-guides/installing-freebsd-for-raspberry-pi/) People have been running FreeBSD on various RPi devices for a while now, however there are still a lot of people who probably need a hand to get boot-strapped on their RPi system. The FreeBSD foundation has put together a nice tutorial which walks even the most novice user through getting FreeBSD up and running. In particular this could become a good way for students or other FreeBSD newcomers to try out the OS on a relatively low-cost platform outside of a VM. The tutorial starts of with a check-list of the specific items you'll need to get started, for RPi 1 (a/b) or RPi 2 hardware. From there, instructions on how to get the downloaded images onto a sdcard are provided, including Mac and Windows image burning details. With this done, it's really only a matter of plugging in your device to be presented with your new RPi + FreeBSD system. The most important details (the default username/password) at also provided, so don't skim too quickly. *** Interview - Drew Gurkowski Foundation Intern: First time FreeBSD User and Writing Tutorials *** News Roundup FreeBSD's ipfw gets a NAT64 implementation (https://svnweb.freebsd.org/base?view=revision&revision=304046) A new feature has been added to FreeBSD's native firewall, ipfw2 The new loadable module implements stateless and stateful NAT64 “Stateless translation is appropriate when a NAT64 translator is used in front of IPv4-only servers to allow them to be reached by remote IPv6-only clients.” With this setup, you map specific IPv6 addresses to the corresponding IPv4 address, allowing IPv4 only servers to be reachable on the v6 network. “Stateful translation is suitable for deployment at the client side or at the service provider, allowing IPv6-only client hosts to reach remote IPv4-only nodes.” This configuration allows many IPv6 only clients to reach the “legacy” internet. The FreeBSD cluster has been waiting for this feature for a while, because they have limited IP addresses, but many service jails that require access to services like GitHub that are not IPv6 enabled. The work was sponsored by Yandex, the Russian search engine and long time FreeBSD user Example configurations for both types are included in the commit message If you would find this feature useful, please take the time to set it up and document the steps and contribute that to the FreeBSD Handbook. *** Update on using LLVM's lld linker in the FreeBSD base system (https://lists.freebsd.org/pipermail/freebsd-toolchain/2016-August/002240.html) Ed Maste has written a lengthy update on the progress being made towards using LLVM's lld linker as a replacement for GNU's ‘ld'. Ed starts off by giving us some of the potential benefits of using lld vs the 2.17.50 ‘ld' version FreeBSD currently uses: AArch64 (arm64) support Link Time Optimization (LTO) New ABI support Other linker optimization Much faster link times Maintained code base Ed also gives us an update on several of the major blockers: Since the last update in March several lld developers have implemented much of the missing functionality. The main blockers were symbol version support and expression evaluation in the linker script expression parser. Both are now nearly complete“ A detailed plan was also articulated in respect to switching over: Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. Add the bmake build infrastructure, installing as /usr/bin/ld.lld on the same architectures that use Clang (amd64, arm, arm64, i386). I don't think there's a need for a WITH_LLD src.conf knob, but will add one if desired. Update lld again (most likely to a snapshot from upstream SVN) once it is able to link an unmodified FreeBSD kernel. Modify the boot loader and kernel builds to avoid using features not implemented by lld. Introduce a WITHLLDAS_LD knob to have /usr/bin/ld be a ld.lld hardlink instead of /usr/bin/ld.bfd. Request ports exp-runs and issue a call for testing with 3rd party software. Fix issues found during this process. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using architectures. Add a WITHOUTLLDAS_LD knob to switch back to GNU ld. *** How to install FreeBSD with ZFS filesystem on DigitalOcean (https://github.com/fxlv/docs/blob/master/freebsd/freebsd-with-zfs-digitalocean.md) I know we've mentioned using FreeBSD + ZFS on digital ocean in the past, but today we have a nice HowTo by Kaspars Mickevics (fxlv) on GitHub. Before getting started, kaspars mentions some pre-reqs. First up he recommends starting with a Minimum of 2GB of RAM. (The $20/mo droplet). This is to ensure you have plenty of cushion to avoid running out of memory during the process. It is possible to use ZFS with less, but depending on your desired workload this does make sense. From there, checking out “mfsBSD” is discussed, along with details on how to make it suitable for a DO installation. (Mostly just disabling DHCP for the network device) For good measure ‘pkg-static' is also included. With that done, using mfsBSD you will create a tar file, which is then extracted on top of the running system. After rebooting, you will be able to run “bsdinstall” and proceed to installing / formatting your disk with ZFS as normal. A good tutorial, something I may need to do here in the near future. User manages to get OpenBSD and FreeBSD working with Libreboot (https://lists.nongnu.org/archive/html/libreboot/2016-08/msg00058.html) In a short drive-by post to the Libreboot mailing list Piotr Kubaj gives a quick notice that he managed to get OpenBSD and FreeBSD both booting. > I know GNU people don't like BSD, so let me make it quick :) > > > I've succeeded in booting FreeBSD 11.0-RC1 using txt mode on my X200 > with the newest Libreboot. > > To get installer to boot, I used: > kfreebsd (usb0,gpt3)/boot/kernel/kernel > set FreeBSD.vfs.mountfrom=ufs:/dev/da1p3 > boot > > I didn't try to install yet. > The trick looks relatively simple (looks like GRUB), manually loading the kernel with ‘kfreebsd' and then setting the vfs.root.mountfrom variable to find the USB stick. In an update he also mentions booting OpenBSD with ‘kopenbsd' instead of ‘kfreebsd' (again GRUB syntax) Now somebody will need to test installation of the system (he didn't) and see what other issues may crop up in running BSD on a free BIOS. *** Beastie Bits: The ACPICA (ACPI Component Architecture) coding language AML now in DragonFly BSD (http://lists.dragonflybsd.org/pipermail/commits/2016-July/624192.html) Release announcement for 4.3BSD Tahoe from 1988 (https://groups.google.com/forum/#!topic/comp.sys.tahoe/50ManvdM1-s) Feedback/Questions Mike - Jail Uptime (http://pastebin.com/FLpybL6D) Greg - Router Hardware (http://pastebin.com/RGuayhB3) Kristof writes in (http://pastebin.com/NT4zmHiG) Ty - Updates and Logs (http://pastebin.com/CtetZdFg) Benjamin - MTA Bug (http://pastebin.com/Qq3VbQG2) ***