Scribd
Upload
3 views

Beerup Microservices

Uploaded by

probakukac
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
3 views

Beerup Microservices

Uploaded by

probakukac
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 23

Microservices-like architecture

in an embedded system
(Stretching definitions)

Presenter: Alex Badics


About me


Badics Alex
Avatar online:

“System Engineer”

“System” architect

Requirement “engineer”


Working at


Code shown was written by colleagues

Opinions are my own.
Definition of man


“Featherless biped”
Definition of Microservices

Micro: Service:

Single purpose 
Self contained components

Small enough to be maintained by a 
Encapsulated state
small team 
Loose coupling

Message passing

Service contracts


Split along business requirements
Layered design vs. service oriented design

Frontend
Frontend

Something in the middle, idunno


Functionality 1 Functionality 2

Something else in the middle


Some common
thing to do
Storage? “BusinessValue-
HelperFactory”
Is this a man?
Is this a microservice architecture?
The core V2X protocol stack

Written in C99 and some C++11

Around 50 components

Around 150 threads

Components mainly communicate through
a custom RPC framework

Remote procedures

Publish/subscribe/notify

Can be split up to run on multiple CPUs
connected over ethernet

Highly resource-sensitive
The RPC framework

Interface declaration: simple C functions

“Protocol”: Packed C structs with no pointers

Network-enabled using TCP and simple framing

Message queues and event loops in C++

RPC magic hidden behind macros

Calling code does not care about the physical
location of called code

Optimized data-passing when in-process


Remote API is just a set of exposed RPCs
Subscribe/notify


Implemented on top of RPC (not an integral part of it)

All notifications have a “type id” (e.g. message type)

Subscribers can subscribe to “all” or only specific ids

Any number of subscribers, using callback funtions

Most importantly: Notification sending code does not “know about”
or “depend” on notification using code

Used for: messages, station info, navigation data
Is this a man?
Is this a service interface definition?
Behind srv_wsmp_send: request part
Behind srv_wsmp_send: “server” part
But why?


Internal RPC == Remote API

Generated API bindings for Python and Java

This format is easily parseable

Type declarations

Well-formed “service declarations”
Is this a man?
Is this “message passing”?

srv_wsmp_send(...)
BSM sender module WSMP sender module
What is message passing anyway?
“Message passing is a technique for invoking behavior. The invoking program sends a message to a component
and relies on that component and its supporting infrastructure to then select and run some appropriate code.
Message passing differs from conventional programming where a process, subroutine, or function is directly
invoked by name.”


The caller code does not know what will happen in runtime

The “callee” decides on what code to run based on incoming parameters

Caller code does not depend on execution semantics

Simplest form: virtual functions on objects

See also: Smalltalk
Synchronous RPC calls in our system


If staying within process

Simple function call

Zero copy on parameters and data

No context switch, good cache coherency

If called component is in different process

Data serialized onto network

Parameters and result travel over network

Caller blocks until result


Code does not need to change when changing component/process splits
Is this a man?
Is this a microservices talk?

Microservice Service-oriented OOP Our stuff


architecture architecture
Self-contained components ✓ ✓ ✓ ✓
Loose coupling ✓ ✓ ✓ ✓
Message passing ✓ ✓ ✓ ✓
Spans multiple processes ✓ ✓ ✓
Components encapsulate state ✓ ✓ ✓ ✓
Components can be tested in isolation ✓ ✓ ✓ ✓
Self-registration and discovery ✓ ✓ ✓
Organized around business requirements ✓ ✓
Is this a microservices talk?

Microservice architecture Our stuff

Per-component technology stack ✓


Independent scaling ✓
Independent deployment ✓
Independent teams ✓
Failure isolation ✓ ✓
Good for your specific use-case as-is
Conclusion


“Microservice architecture” is not about
“micro and “services”


Service-oriented modular architecture is
possible in C at almost zero cost

You might also like