Tech Talk Instead of Buzzword Bingo: Tech-telmechtel with Microservices [Interview]

Tech Talk Buzzword Bingo Microservices Tech-telmechtel
Mirco Gatz, tech lead at dotSource

New month. New series of articles. Welcome to our new Handelskraft format: Tech-telmechtel (a blended word consisting of »tech« and the German word »Techtelmechtel«, meaning a short relationship/flirt). From now on, there will be plenty of first-hand tech insights every week  That would already be too many buzzwords for Mirco, but he took part in the first episode anyway. Not only is Mirco good at what he does, but he can also explain incredibly well what he does – even to (semi-)amateurs like me.

Find out in this article what Mirco – married, two children, house builder, passionate racing cyclist and tech lead at dotSource – has to say about the long-running topic of microservices, where the journey is going and why he even bothers with it.

Tech Talk with Mirco, Tech Lead and Buzzword Critic

Mirco Gatz has been part of the dotSource family since March 2012. Amongst other things, he is responsible for the development and implementation of microservices projects.

Mirco, what’s behind it? Commerce? Interfaces?

Yes, I work mainly on e-commerce projects. In other words: setting up large digital platforms.

And what’s behind microservices?

Where do I start? What are distributed applications?

In the end, it’s about planning and creating systems for the client. Individual processes aren’t carried out by one large application, but by many small ones that complement each other and are each responsible for only one specific thing.

Do you have a concrete example?

Usually, the best example is product data provision. This means that there’s one service that’s responsible for product data and another one for pricing. The two services then interact with each other to deliver the final result, for example the product detail page.

Tech: Who? How? What for?

OK, and the technologies you work with are?

commercetools.

In terms of development, I work with JavaScript and Java.

Who needs microservices and why?

It’s actually more a question of who decides to use them. Who decides in favour of a platform consisting of distributed applications?

Very technology-driven companies, for example, which also have their own development department and want to be able to better scale development capacities. Companies that have already experienced that a large application causes a lot of structural problems and is very difficult to maintain. They try to make this complexity more visible and easier to maintain by using distributed architectures.

You were talking about product data and pricing. Does this mean that such distributed architectures are particularly suitable for companies with many products?

Yes, but not exclusively. The publisher C.H.Beck, for example, has millions of products and large amounts of data. You can tailor a service so that it can handle a lot of product data without having a problem with large shopping carts, for example.

Tech Talk with Mirco: Microservices Are Not an All-in-One Solution

What added value do clients and users get from microservices?

The main goal here is to be more efficient and perform better, which will benefit the user. But be careful: a lot of improvements and drops in performance happen in the front end. No matter how fast interfaces may be: if the front end doesn’t work well or isn’t well developed, the same process won’t work equally well everywhere.

What does that mean?

You have to look left and right. Microservices and distributed applications aren’t an all-in-one solution. It’s a lot of buzzword bingo, but ultimately there’s technology behind it.

You have to know your requirements. You have to know them very well. Then you have to develop and also test. In a distributed architecture, you have to make sure that you test holistically. If the product API is very fast and the price API is very slow, you have to build a front end that doesn’t wait for the prices.

So it’s the product first, then the price?

This is quite common in B2B. It doesn’t even have anything to do with the system. The principle that some data isn’t loaded right away so that the actual page is fast at first is an absolute standard.

OK, I’ll summarise this for B2C and B2B.

This means that when you use such a technology in B2C (like C.H.Beck, for example), it’s mainly about speed. This is the case because users in B2C are simply used to having the price of a product available quickly.

In B2B, however, companies opt for a distributed architecture in order to better map all the entangled relationships and complexity?

Exactly. The advantage is that these complex dependencies and processes you have, which are borrowed from classic sales (If This Then That, graduated discounts, individual prices for each customer, order history, etc.), can also be mapped in B2B e-commerce.

Mapping these processes in a large system has the disadvantage that you see the dependencies very poorly. In a distributed architecture, you have individual components, each one with its own task. Network communication takes place there. The dependencies are more transparent, more comprehensible. You could even display them graphically.

This doesn’t change anything about the complexity; it is still a complex process, but it takes the complexity to another level where I can better recognise and handle it.

Tech Trends of the Future

Mirco, where is the journey going?

In terms of distributed systems? Definitely service meshes.

There’s a lot of magic between these many small applications. You have to operate all of them, they all need resources, they do network communication, you have logs. When you develop new versions, you want to test them first; you have many repetitive tasks that bloat the application, and the list goes on an on.

You embed your applications in these »networks«. The mesh does everything around it. It takes care of all the repetitive stuff. This allows you to focus on the business process and develop your interfaces more efficiently.

OK, so it’s basically a distribution for the distribution?

It’s about making the execution of code more and more efficient, less and less dependent on how or where it was executed. The service mesh takes care of everything that has to take place between applications.

Tech Fan and Developer Through and Through

Why do you do this? Is it your passion? How did you get into it?

I do this because I have a personal interest in understanding how things work. I like to deal with the latest technologies and dislike large standard systems where you are only busy trying to understand what others want from you and you never develop things the way you want.

I’m in control and can make my own decisions.

By the way, Mirco prefers developing things on his own in his private life as well. Whether it is a terrace, a garden playhouse for his boys, paving the driveway or building a garage: he decides how, when and where.

Tech Talk to Be Continued

In our next episode, you’ll get to know Markus – our expert for customer experience, multi-cloud projects, migration and SAP. See you then!

(14 vote(s), average: 4.71 out of 5)
Loading...

Leave a Reply