arrow-leftarrow-rightarrow-to-bottomcamera-circlecamerachevron-leftchevron-rightfile-altglobegrid-bgimageinfolinklistlogo-systemlogistics-payofflogo-systemlogisticsplay-circlesearchsocial-facebook-fsocial-facebooksocial-instagramsocial-linkedin-insocial-linkedinsocial-twittersocial-youtubetagthtimesuploadvideo
 The technology behind a cloud-based WMS - 12 questions for Kilian Hammesfahr

The technology behind a cloud-based WMS - 12 questions for Kilian Hammesfahr

In an interview with Kilian Hammesfahr we talk about cloud-based software architectures, technologies used and development challenges. Kilian is significantly involved in the conception and development of the cloud-based WMS (Warehouse Management System) TOPAZ with which manual warehouses can be managed quickly, simply and at low cost.

 

Kilian, how old are you and where do you come from?

I’m 31 years old and I live in Regensburg.

How long have you been working for System Logistics GmbH in Wackersdorf and what did you do before?

I’ve been working for System Logistics for over five years now. Before that, I studied mechanical engineering and automation technology in Aachen, specialising in software development.

What are your duties?

As a developer I was involved in TOPAZ from conception until the finished product. I was involved in the design phase right from the very start and worked on developing a software architecture that would make stable and smooth operation possible in the cloud.

Kilian, why is cloud technology ideal for a service like TOPAZ?

With TOPAZ we offer a simple and uncomplicated service that allows rapid adoption of a digital warehouse management solution. Part of this is ensuring that as little software as possible needs to be installed on the customer’s premises, ideally no software at all. Cloud technology makes this very easy, of course. All you need is internet access and a device with a web browser.

Can you explain how this was achieved technically in more detail?

TOPAZ is a cloud service hosted by AWS (Amazon Web Services) in Frankfurt and developed on the basis of a microservice architecture. We mainly use Java with Spring Boot for the back end, and JavaScript and React for the front end. The user interface is provided entirely in a web browser. As a user, I don’t need to install any software whatsoever on my device.

What does the software infrastructure look like?

We operate TOPAZ in a Kubernetes Cluster hosted on AWS. While we could have also operated our components directly within the services provided by AWS, we wanted to develop our infrastructure as independently of the cloud provider as possible. We operate TOPAZ with a microservice architecture in the Kubernetes Cluster. We can scale individual microservices to account for load, allowing us to respond to demand in real time with tailored performance.

But we don’t just use the cloud for operating TOPAZ itself – we leverage the cloud for the development of TOPAZ. Our CICD (Continuous Integration and Continuous Deployment) pipeline is run on a Kubernetes Cluster. This allows us to dispense with costly local servers and also permits us to develop from anywhere in the world.

Can you explain the software architecture and the benefits it brings, as well as the challenges in programming it?

When developing TOPAZ we always aimed to develop a cloud-native application, because operating software in the cloud is only beneficial and cost-effective if you consistently leverage the benefits of the cloud. Resource scalability in relation to the specific load on the system at any given time is a crucial aspect, which is why the back end of TOPAZ consists of microservices. Each service handles very specific tasks relating to intralogistics processes. One of the challenges with this lies in how the microservices communicate with one another. When data is exchanged between what are essentially entirely independent services, we must ensure that the communication interfaces are always compatible with one another. Although it seems rather simple when you have a limited number of microservices, it becomes a complex challenge as the number of these services grows.

And we also took an innovative route with the front end, which is the user interface. Although most systems developed today have a microservice architecture for the back end, the front end tends to be more monolithic, combining all aspects of the application in a single software solution. We took the microservice approach even further and developed a micro front end architecture based on the very new HTML web components standard. This mean that, similarly to the division of microservices along functional lines, there are now also micro front ends. Of course, users don’t notice this. But for us developers, it provides us with the advantage of ensuring that changes and extensions only have a limited impact on the system as a whole. Potential errors can only affect a small part of the software. This makes the system more stable and more robust on the whole. On top of that, the code is much cleaner, allowing us to implement new functions usually much faster.

How was software engineering handled?

With the number of microservices and front ends that we have in TOPAZ, it is important to keep a handle on things and to test continuously. This is almost impossible if you operate entirely manually. But our CICD pipeline in the cloud enables us to perform most of the necessary tests automatically. This saves time and provides us developers with assurance that the system is running stably. With each code revision, the tests are repeated automatically and we are provided with quick feedback on errors or vulnerabilities. The pipeline also assists with deployment, which is the delivery of the functional changes. Thanks to the high degree of automation, this enables to provide new functions essentially at the push of a button. Of course, this all assumes that all the tests were successful beforehand.

If something doesn’t quite work as expected while the system is running, the alert mechanism lets us know immediately and we can respond right away. Usually, this is before the customer even notices that there’s a problem.

What were your greatest challenges in the development of TOPAZ?

Previously we had mainly developed warehouse management systems that were operated on the premises and were tailored to customer requirements. With TOPAZ, we have now developed a software solution that is entirely standardised and also runs not on the customer’s premises, but in the cloud. We had to rethink many aspects and familiarise ourselves with many new technologies. Because we geared the architecture towards the cloud, many tried and true approaches no longer worked, which meant that we had to take entirely new and unknown routes.

What specific benefits can customers expect from this technical approach?

Because TOPAZ is a cloud solution, the customer does not need to provide any server hardware, which eliminates the need for initial investments and for running costs for maintenance and operation. The application also works on any device with a web browser, meaning that you don’t need to invest in costly hardware such as forklift terminals at the start. We can also offer new functions and improvements without having to shut down the system. This means that customers can use TOPAZ around the clock without having to worry about maintenance periods.

What are you personally most enthusiastic about when it comes to cloud technology?

Cloud providers have developed many services in recent years that make it incredibly easy to make software available to a large customer group. Many services, including in the field of AI (Artificial Intelligence), have intuitive APIs (Application Programming Interface) that allow us as developers to solve complex problems and meet sophisticated needs with relatively little effort.

Where will cloud technology be in five years?

The technology is developing at a blinding pace. I think that the FaaS approach (function as a service) will continue to establish itself. This is where the cloud provider covers all aspects of infrastructure and operation. As a developer, I simply provide the code, which is automatically executed on the infrastructure of the cloud provider as needed.

Thank you for talking to us!

  • English
  • Italiano
  • Español
  • Français
  • Deutsch
  • English
  • U.S. English
  • Español
  • English