The O'Reilly Media Podcast spreads the knowledge of innovators. At O’Reilly, a big part of our business is paying attention to what’s new and interesting in the world of technology. The O'Reilly Media Podcast features interviews with the people working on the forefront of technology.

O'Reilly Media Podcast

to listen

In this week’s podcast, Thomas Betts talks with Chris Richardson, a developer, architect, Java Champion and author of POJOs in Action. Before his workshop on Microservices w/ Spring Boot and Docker at QCon San Francisco 2016, Richardson took time to discuss his ideas on how to use DDD and CQRS concepts as a guide for implementing a robust microservices architecture.

Why listen to this podcast:

 - "Microservice architecture" is a better term than "microservices".   The latter suggests that a single microservice is somehow interesting
 - The concepts discussed in Domain-Driven Design are an excellent guide for how to implement a microservices architecture
 - Bounded Contexts correspond well to individual microservices
 - Event sourcing and CQRS provide patterns for how to implement loosely coupled services
 - When converting a monolith to microservices, avoid a big bang rewrite, in favor of an iterative approach

Notes and links can be found on: http://bit.ly/2hZ8TM1

11m:51s - Microservices must be loosely coupled, usually creating a model with one database per service.
12m:45s - There is a business requirement to maintain data consistency across services, and using an event driven architecture is a good way to achieve that.
13m:38s - Event sourcing is specific technique for persisting domain objects as a series of events.
14m:11s - Just as transactions don’t like to be split across microservices, queries cannot simply join across multiple data sources. CQRS provides a solution that accommodates querying via microservices and materialized views.

More on this:
Quick scan our curated show notes on InfoQ. http://bit.ly/2hZ8TM1

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

InfoQ Podcast

Show Notes

Chris Richardson on Domain-Driven Microservices Design

Wesley Reisz talks to Daniel Bryant on moving from monoliths to micro-services, covering bounded contexts, when to break up micro-services, event storming, practices like observability and tracing, and more.

Why listen to this podcast:

- Migrating a monolith to micro-services is best done by breaking off a valuable but not critical part first.
 - Designing a greenfield application as micro-services requires a strong understanding of the domain.
 - When a request enters the system, it needs to be tagged with a correlation id that flows down to all fan-out service requests.
 - Observability and metrics are essential parts to include when moving micro-services to production.
 - A service mesh allows you to scale services and permit binary transports without losing observability.

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2pFYBiT

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2pFYBiT

Daniel Bryant on Microservices and Domain Driven Design

In a recent episode of the O’Reilly Media Podcast, we spoke with George Miranda about the importance of service mesh technology in creating reliable distributed systems. As discussed in the new report The Service Mesh: Resilient Service-to-Service Communication for Cloud Applications, service mesh technology has emerged as a popular tool for companies looking to build cloud-native applications that are reliable and secure.

During the podcast, we discussed the problems a service mesh infrastructure solves and the service mesh features you’ll find most valuable. We also talked about how to choose the right service mesh for your organization, the challenges involved in getting it deployed to production, and the best ways for getting started with a service mesh.

How to Choose and Deploy a Service Mesh

Wes Reisz sits down and chats with Uncle Bob about The Clean Architecture, the origins of the Software Craftsperson Movement, Livable Code, and even ethics in software. Uncle Bob discusses his thoughts on how The Clean Architecture is affected by things like functional programming, services meshes, and microservices.

Why listen to this podcast:

* Michael Feathers wrote to Bob and said if you rearrange the order of the design principles, it spells SOLID.
* Software Craftsperson should be used when you talking about software craftsmanship in a gender-neutral way to steer clear of anything exclusionary.
* Clean Architecture is a way to develop software with low coupling and is independent of implementation details.
* Clean Architecture and Domain Driven Design (DDD) are compatible terms. You would find the ubiquitous language and bounded context of DDD at the innermost circles of a clean architecture.
* Services do not form an architecture. They form a deployment pattern that is a way of decoupling and therefore has no impact on the idea of clean architecture.
* There is room for “creature comforts” in a code base that makes for more livable, convenient code.
* “We have no ethics that are defined [in software].” If we don’t find a way to police it ourselves, governments will. We have to come up with a code of ethics.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Nebspj

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2Nebspj

Uncle Bob Martin on Clean Software, Craftsperson, Origins of SOLID, DDD, & Software Ethics

In this episode of the O’Reilly Media Podcast, Rachel Roumeliotis, VP of content strategy at O’Reilly, sat down with Daniel Krook, IBM developer advocate. They discussed how developers across industries can participate in the Call for Code initiative, the benefits of the program, support from its charitable partners—United Nations Human Rights and the American Red Cross—and the positive impacts IBM hopes to achieve by investing in Call for Code.

Developers Worldwide Will Collaborate on Solutions to Save Lives in Call For Code

This episode of the O’Reilly Podcast, features a conversation on serverless and Kubernetes, with Kelsey Hightower, developer advocate for Google Cloud Platform at Google (and co-author of "Kubernetes: Up and Running"), and Chris Gaun, Kubernetes product marketing manager at Mesosphere.

Kelsey Hightower and Chris Gaun on Serverless and Kubernetes

Martin Fowler chats about the work he’s done over the last couple of years on the rewrite of the original Refactorings book. He discusses how this thought process has changed and how that’s affected the new edition of the book. In addition to discussing Refactors, Martin and Wes discuss his thoughts on evolutionary architecture, team structures, and how the idea of refactors can be applied in larger architecture contexts.

Why listen to this podcast:

 -    Refactoring is the idea of trying to identify the sequence of small steps that allows you to make a big change. That core idea hasn’t changed.
 - Several new refactorings in the book deal with the idea of transforming data structures into other data structures, Combine Functions into Transform for example.
 - Several of the refactorings were removed or not added to the book in favor of adding them to a web edition of the book.
 - A lot of the early refactorings are like cleaning the dirt off the glass of a window. You just need them to be able to see where the hell you are and then you can start looking at the broader ones.
 - Refactorings can be applied broadly to architecture evolution. Two recent posts How to break a Monolith into Microservices, by Zhamak Dehghani,  and How to extract a data-rich service from a monolith by Praful Todkar on MartinFowler.com deal with this specifically.
 - Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2QbdHej

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2QbdHej

Martin Fowler Discusses New Edition of Refactoring, Along With Thoughts on Evolutionary Architecture

On today’s podcast, Wes Reisz talks with Jason Maude of Starling Bank. Starling Bank is a relatively new startup in the United Kingdom working in the banking sector. The two discuss the architecture, technology choices, and design processes used at Starling. In addition, Maude goes into some of the realities of building in the cloud, working with regulators, and proven robustness with practices like chaos testing.

Why listen to this podcast:

 - Starling Bank was created because the government lowered the barrier to entry for banking startups in reaction to previous industry bailouts.
 - The system is composed of around 19 applications hosted on AWS and running Java and backed by a PostgreSQL database.
 - These applications are not monolithic but are focused around common functionality (such as a Card or Payment Service).
 - Java was chosen primarily because of its maturity and long term viability/reliability in the market.
 - The heart of Starling is every action the system takes happens at least once and at most once. To help with these rules, everything in their system uses as a correlation id (UUID) and are used to make sure these two rules are met.

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq

Jason Maude on Building a Modern Cloud-Based Banking Startup in Java

At Google’s 2019 Cloud Next conference, I sat down with Stephen Thorne, site reliability engineer on Google’s customer reliability engineering team and co-author of "The Site Reliability Workbook," to talk about how organizations, both large and small, can use SRE to reduce operational costs, improve reliability, and create productive cross-functional teams.

How to Get Started With Site Reliability Engineering (SRE)

In this interview, Tim Craig and fellow Googler Gustavo Franco, a site reliability engineer (SRE), discuss the wide range of events that qualify as “incidents;” the need for a conscious, robust, and well-defined process for understanding them; the role of training; and how to get buy-in from management so you can spread incident response training throughout an organization.

Taming Chaos: Preparing for Your Next Incident

O'Reilly Media spreads the knowledge of innovators. At O’Reilly, a big part of our business is paying attention to what’s new and interesting in the world of technology. We have a pretty good record at having anticipated some of the big technology developments in recent history. For instance, we launched the first commercial Web site, GNN, in 1993; we organized the meeting at which the term “open source” was first adopted; we were early investors in Blogger, which helped launch the blogging revolution; and more recently, our Web 2.0 conference launched a world-wide meme. We call this predictive sense the “O’Reilly Radar.” And while we’re certainly not always right, we are, at least, good at making interesting guesses.

Our methodology is simple: we draw from the wisdom of the alpha geeks in our midst, paying attention to what’s interesting to them, amplifying these weak signals, and seeing where they fit into the innovation ecology. Add to that the original research conducted by our Research team, and you start to get a good picture of what the technology world is thinking about.

How to Choose and Deploy a Service Mesh

O'Reilly Radar