Microservices is, essentially, a distributed systems architecture with individual components being small – for some definition of small. This is a top-level, overarching architecture for a system as a whole. But what about the individual components, do they not have architecture as well? It cannot be "microservices all the way down", so what can we do to describe the realization of the components?
Over the years many models of concurrent and parallel systems have been created: event-loop-based, now often labelled reactive, is very popular just now. However there is also actors, dataflow, CSP, data parallel, active objects, to name just a few. The component nature of a microservice architecture means that a system can involve many different programming languages. Different programming languages often support different idiomatic models of event and data processing: the way you think of things is Go is very different to the way using Java, C++, Python, Scala, Rust. At the heart of this is whether to use sychronous or asynchronous approaches.
In this session you will take a whirlwind tour of some of the major issues via some prototype examples.
YOU MAY ALSO LIKE:
On the Architectures of Microservices
Russel is an ex-theoretical physicist, ex-UNIX system programmer, ex-academic, ex-independent consultant, ex-analyst, ex-author, ex-expert witness and ex-trainer. Russel is still interested in programming and programming languages, and all things parallel and concurrent. And build. He's actively involved with GPars, Me TV, and various bits and pieces of SDR. Russel likes working with Python, Ceylon, Kotlin, D, Go, Rust, and C++17.