Topics

Featured in Development

Alex Bradbury gives an overview of the status and development of RISC-V as it relates to modern operating systems, highlighting major research strands, controversies, and opportunities to get involved.

Featured in Architecture & Design

Will Jones talks about how Habito, the leading digital mortgage broker, benefited from using Haskell, some of the wins and trade-offs that have brought it to where it is today and where it's going next. He also talks about why functional programming is beneficial for large projects, and how it helps especially with migrating the data store.

Featured in AI, ML & Data Engineering

Katharine Jarmul discusses research related to fair-and-private ML algorithms and privacy-preserving models, showing that caring about privacy can help ensure a better model overall and support ethics.

Featured in Culture & Methods

This personal experience report shows that political in-house games and bad corporate culture are not only annoying and a waste of time, but also harm a lot of initiatives for improvement. Whenever we become aware of the blame game, we should address it! DevOps wants to deliver high quality. The willingness to make things better - products, processes, collaboration, and more - is vital.

Featured in DevOps

Service mesh architectures enable a control and observability loop. At the moment, service mesh implementations vary in regard to API and technology, and this shows no signs of slowing down. Building on top of volatile APIs can be hazardous. Here we suggest to use a simplified, workflow-friendly API to shield organization platform code from specific service-mesh implementation details.

Relearning Functional Service Design for Microservices: Uwe Friedrichsen at microXchg

The opening talk of the microXchg microservices conference was delivered by Uwe Friedrichsen, and discussed the core concepts of “Resilient Functional Service Design”. Key takeaways included: microservice developers should learn about fault tolerant design patterns and caching, but not utilise them to mitigate fundamentally bad (overly-coupled) system design; understanding Domain-Driven Design (DDD) and modularity is vital; and aim for replaceability of components rather than reuse.

Friedrichsen, CTO at codecentric, began the presentation by stating that the goal of software development is to deliver business value, and for this to be realised the software must be run in production and be (highly) available. Modern architectural styles, such as microservices, mean that everything is now distributed (most likely spanning at least a local area network), and therefore failures within the system are normal and not predictable.

Developers should familiarise themselves with fault tolerant design patterns, such as circuit breakers, bulkheads, timeouts and retries, which has been popularised by Michael Nygard’s “Release It!” book. Caching, although useful, should be deployed with care, and not used simply to overcome bad system design, such as a long activation path involving many dependent services.

Friedrichsen presented a series of ‘foundations of design’ for microservices (pictured below), which included a series of design principles focusing on high cohesion, low coupling, and separation of concerns. This principles are especially crucial across system boundaries, and even though the theory has been well documented in the 70s by David Parnas (PDF link), it is still often misunderstood.

Domain-Driven Design (DDD) is a useful tool, but many developers overly focus on the static context model of domain, something Friedrichsen refers to as ‘Entity DDD’. The dynamic behaviour of the system is often more illustrative of the business activities, domain events, and flow of data.

Don’t start with the static domain model, the magic is in the dynamic behaviour of the system.

Microservice developers should not strive for reusability, and instead aim for replaceability. Quoting Fred Brooks, Friedrichsen discussed the promise of software reuse that has been chased by developers for many years. Brook’s suggested that work effort required to create a reusable component (over one that is fit for purpose for a single case) is typically multiplied by three, meaning that any return on investment for reusability is only seen when a component has been used without modification at least four times.

The communication paradigm used within a microservices system also greatly influences the functional service design, and Friedrichsen suggested that care should be taken with upfront architectural choices that may limit future modification and extensibility.

The concluding message and core takeaway from the talk was that developers and architects need to relearn functional service design when implementing distributed systems like microservice, as the properties of these systems expose and multiply the effects of design issues we have known about for many years.