Episodes

Code[ish] • Tuesday, December 29th 2020
Code[ish] logo

105. Event Sourcing and CQRS

Andrzej Ludwikowski

Robert Blumen is a DevOps engineer with Salesforce, and he's joined in conversation with Andrzej Ludwikowski, a software architect at SoftwareMill, a Scala development shop. Andrzej is introducing listeners to the concept of event sourcing against the more traditional pattern of CRUD, which stands for create-read-update-delete. CRUD systems are everywhere, and are most typically associated with SQL databases. In comparison, event sourcing is a simply a sequential list of every single action which occurred on a system. Whereas in a database, a row may be updated, erasing the previous data in a column, and event source system would have the old data kept indefinitely, and simply record...

Details & Transcript →
Listen Now
Transcript Available
    Deeply Technical CRUD CQRS events database distributed systems architecture design patterns
Code[ish] • Tuesday, December 22nd 2020

Luke Kysow is a software engineer at HashiCorp, and he's in conversation with host Robert Blumen. The subject of their discussion is on the idea of a service mesh. As software architecture moved towards microservices, several reusable pieces of code needed to be configured for each application. On a macro scale, load balancers need to be configuring to control where packets are flowing; on a micro level, things like authorization and rate limiting for data access need to be set up for each application. This is where a service mesh came into being. As each microservice began to call out to each other, shared logic was taken out and placed into a separate layer. Now, every inbound and...

Details & Transcript →
Listen Now
Transcript Available
    Deeply Technical microservices Kubernetes service meshes containers gRPC VMs distributed systems architecture design patterns
Code[ish] • Thursday, December 17th 2020
Code[ish] logo

103. Chaos Engineering

Mikolaj Pawlikowski

Rick Newman interviews Mikolaj Pawlikowski, who recently wrote a book called "Chaos Engineering: Crash test your applications." The theory behind chaos engineering is to "break things on purpose" in your operational flow. You want to deliberately inject failures that might occur in production ahead of time, in order to anticipate them, and thus implement workarounds and corrections. Typically, this practice is often used for large, distributed systems, because of the many points of failure, but it can be useful in any architecture.

One of the obstacles to embracing chaos engineering is finding high level approval from other teammates, or even managers. Even after the...

Details & Transcript →
Listen Now
Transcript Available
    Deeply Technical chaos engineering distributed systems SRE DevOps Kubernetes observability testing
Code[ish] • Tuesday, December 15th 2020

Robert Blumen is a DevOps Engineer at Salesforce, joined by Ev Haus, Head of Technology at ZenHub. Together, they're going over a critique over several methodologies when writing code as part of a large team. First, there's DRY, which stands for Don't Repeat Yourself. It's the idea that one should avoid copy-pasting or duplicating lines of could, in favor of abstracting as much repeated functionality as possible. Then, there's DAMP, or Don't Abstract Methods Prematurely, which is somewhat in opposition to DRY. It advises teams to not create abstractions unless they are absolutely necessary. Last on the list is WET, or Write Everything Twice. This is the idea to...

Details & Transcript →
Listen Now
Transcript Available
    Deeply Technical architecture programming code refactoring testing coding
Code[ish] • Thursday, December 10th 2020

Host Joe Kutner is an architect working at Salesforce, and his guest is Cornelia Davis, the CTO of Weaveworks, a platform for infrastructures. Cornelia argues that most companies building complex web-based applications are doing so without fully understanding the unique operational challenges of that environment. Even several well-known patterns, such as adding circuit breakers or retry patterns, are not standardized across the industry, and certainly not across languages, let alone in frameworks and other easily consumable dependencies. In many cases, there are over reliances on infrastructure availability that only become obvious once a problem occurs. Cornelia gives the example of a...

Details & Transcript →
Listen Now
Transcript Available
    Deeply Technical Kubernetes cloud native GitOps microservices resiliency