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.

Stefan Tilkov: Skip the Monolith, Start with Microservices

During the last months many have claimed that a microservices architecture should always start with a monolith, among others Martin Fowler and Sam Newman, but Stefan Tilkov is convinced this is often wrong, building a well-structured monolith with cleanly separated modules that later may be moved out as microservices is in most cases extremely hard, if not impossible.

Tilkov, co-founder and principal consultant at innoQ, agrees though with the idea that distributed system should only be selected when there are reasons for doing so. For him the most important reason is enabling fast and independently delivery of individual parts of a large system. He believes that the main benefit for microservices are creating clear and strict boundaries between different parts of a system, minimizing the risk of connecting disparate parts which would increase the coupling. He notes that this is possible also with a monolith using strong discipline but in his experience this is rarely happening.

For Tilkov the basic idea of a monolith is to couple things to each other. From a technical view all parts are using the same platform, abstractions and libraries with communication based on everything being in the same process. From a business perspective all domain objects are available everywhere, the same persistence model is used with transactions always available to span over all changes made. All these are facts that for him increase the coupling and he again emphasizes that it’s extremely hard to pull apart an existing monolith.

Instead of always starting with a monolithic design Tilkov believes that when a system is large enough we from the beginning should think about individual subsystems, building them as autonomous as possible.

As an example of a system made up by microservices Tilkov refers to Otto.de, a German e-commerce site, about which he held a presentation at QCon London last year.

Tilkov earlier compared characteristics of different types of systems and coined the term Self-Contained System (SCS) to describe an autonomous service significantly larger than a microservice but still responsible only for one specific business domain.

Community comments

The myth of independence

Your message is awaiting moderation. Thank you for participating in the discussion.

With micro-services we go back to the myth of independence and SOA. In services do not forget input and output data; it is what will break all your dreams. And a small service will necessarely need to collaborate with many other ones...another dream brearker.So yes it's always important to have 'not too big' services but the real 'problem' is the semantic links that exist between the business concepts...and you cannot change it.