Solace Developer Spotlight: Heiko Henning

General Discussions
1

image.jpg
image.jpg280×329 64.2 KB

Hometown: Thun, Switzerland

Years of being a developer: 18 years as a professional developer

Primary programming language(s): Java, Typescript

How did you start as a developer?

I started as a classical web developer and turned more and more to enterprise software.

What is your typical day like?

As a messaging architect, I review concepts of developer teams and give best practices for the dev team’s problems. I also provide solutions to common problems.

What is your favorite thing about being a developer?

Having the opportunity to look into several business domains and helping to understand the problem and find the solutions.

What project are you currently working on?

I’m setting up a messaging network based on a micro broker architecture for an advanced micro service landscape.

What new skills or technologies are you learning?

Last year I had a closer look at Golang and real-time big data processing.

What cool tech trends are you seeing?

In general, I try to avoid following hypes. But I am happy to see technologies like Kubernetes, Spring, Angular have made the steps to be stable enterprise ready software and hope those will survive for a while.

What advice do you have for other developers?

Think big, act small.

If you could retire now, what would you do?

Provided my children are already leaving the house, I would buy a small RV and grab my wife and see the world.

If you were a Solace Developer Community admin for one day, what would you do?

Try to make AsyncAPI a little more public.

What is your Solace wish?

Don’t grow too fast. Keep your customer needs oriented team.

Read more:

2

Thanks for sharing @GreenRover! Exciting to learn a bit more about you!

Last year I had a closer look at Golang and real-time big data processing.
I’d be curious of your opinion after taking a closer look at Golang, do you think it will be joining your list of “stable enterprise ready software” with K8s, Spring & Angular?

Try to make AsyncAPI a little more public.
Thanks for the suggestion. Definitely something I would like us to do as well :wink:

3

What is a “micro broker architecture” …?

4

@GreenRover Awesome!!! .

5

@Aaron a big zoo of microservices, where each micro services own its own broker.
Because the life cycle of the broker is tight to the life cycle of the micro service.

This leads to a big ammount of smaller broker but those are strong meshed to allow communication on well defined apis

6

@GreenRover thanks for the reply! ?

Each microservice has its OWN broker?? Wow…! Not very “micro services” if it’s a whole broker! haha

Which broker are you using for that architecture? IIRC, the creator of ZeroMQ had something similar in mind.

7

We use mostly solace private cloud 1k ha.
But if there is we gui involved 10k

But yes the definition of a micro service is floating. For us a micro service has max 5 developer.

The reason to give each appliance a broker is:

  • isolating the applications
  • not update anything within a life cycle
    The main goal is to have a really high uptime.

Because a down time of more then 15min means the public transport if a whole country will start to collapse.
If you are interested in further details, contact your sales team, for an appointment.

8

Thanks, those are some interesting reasons. But yes, I understand the need/requirement for really high uptime, we have a lot of critical infrastructure customers running over Solace. Just wondering about architectural complexity / tradeoffs…?

I’ll ping Henrik and have a chat with him.

Thanks for taking the time to respond to my questions…! ?

9

The main problem is how to connect those many brokers to each other.
The best solution would be DMR or multi level DMR. Now multilevel DMR ist not available (not yet) and plain DMR has a connection limit of 15.
So as we currently face ~200 broker an growing.
DMR is not an option.

Those we choose an hub an spoke architecture , here all those micro broker are connect to an hub/concentrator and those concentrator to each other have a meshed bus.
Meshed to scale out and bus, because data is only allowed to flow from production to development stage and not vice versa.

Now you face the problem that you only want to transport messages that where you have a subscription on.
To solve this we invented a api management portal. Here you can publish an open api. This will allow the topics defined in the api, to flow in direction hub/concentrator.
If some one signs up this api the data will flow in his direction. There for the api portal have to configure all bridge queues automatically.

Because of sometimes complicated update pathes, we decided not to update broker. Meaning we have to create a new broker and delete the old one.
There for we created a self service portal to enable the dev teams to manage their own broker, on to of solace cloud, to be multi client (micro service owner) capable.

Next problem, you will be able to roll out your broker configuration like queues, clien and acl profiles, ….
There for we enable the teams to create zip artifacts containing json files describing those.
Allowing those json containing variables for von name, stage ….
This functional to allow to release a broker configuration tied to a micro service release, fast and easy.
We add this functionality to out self service portal.
This was allot of work, to read out current configuration and apply the div to the to state.

And allot of other small issues

10

Super interesting, thanks for sharing @GreenRover