Inside Nedap: How Bram codes for the cloud – Java, Kotlin, Kafka & edge devices — a peek into Nedap’s hybrid cloud architecture.

The code you write in the morning can be live and used by clients that same day.

An interview with Bram Klein Gunnewiek from Nedap Security

At Nedap Security, cutting-edge technology and a people-centered work culture go hand in hand. The team develops innovative access control solutions that go far beyond traditional security systems. Their cloud-native platform, AtWork, is used by organizations around the world to manage physical access in a scalable, flexible, and secure way.

In this interview, we talk to Bram Klein Gunnewiek, Software Engineer at Nedap Security, about his experience building a cloud-native access control system with Kotlin, Java, and Spring Boot 3 — and what it’s like to work for Nedap in Groenlo.

Can you describe your role at Nedap Security?

As a back-end engineer, I work on AtWork, a cloud-native access control system. Our team builds a modern microservices architecture, primarily using Kotlin. For inter-service communication, we follow an event-driven design using Apache Kafka and stream processing with Kafka Streams.

As developers, we work very closely with our DevOps team, who also join our stand-ups. They provide the tools and infrastructure that allow us to easily run and monitor our applications, so we can focus on development.

What really motivates me in my daily work, besides the opportunity to work with innovative technologies, is that I get to actively contribute to discussions about the product and company strategy. It’s not just allowed; it’s expected. Communication lines are short, and input from everyone is genuinely valued.

Why did you choose to adopt Kotlin alongside Java?

Kotlin offers a more concise and expressive syntax than Java, which helps us reduce boilerplate and write cleaner, more readable code. Its null safety feature prevents many common runtime issues. It’s fully interoperable with Java, which means we can adopt it gradually without disrupting existing systems.

Kotlin’s support for coroutines is also a big advantage when working on concurrent logic. That said, new features in Java like structured concurrency and virtual threads are making Java more elegant in this space too.

What has the shift to a cloud-native setup taught you?

A lot! We underestimated how complex things can get in a microservices world. Tasks that used to be simple — like handling transactions — now involve patterns like Saga, which come with additional overhead and complexity.

What really stands out for me is how satisfying it is to see the impact of your work almost instantly. With automated pipelines in place, the code you write in the morning can be live and used by clients that same day.

We do face unique challenges, like securely connecting embedded hardware on-site to our cloud environment. Ensuring robust and reliable communication between field devices and our cloud services brings its own technical and security complexities.

But overall, the benefit is modularity. Services can be developed and deployed independently, which makes team collaboration much easier. But it does require robust tools, infrastructure automation (like with Terraform), and discipline in both code and architecture.

Is your architecture fully event-driven?

Not entirely. While we prefer event-driven solutions for their scalability and resilience, we also use gRPC for synchronous calls and REST for certain third-party integrations like Keycloak. The ideal is a fully event-driven setup, but in practice, you often need a hybrid approach.

How would you describe your DevOps setup?

We deploy all our services in Nomad clusters, and the underlying infrastructure — including Kafka, databases, and Consul — is managed by a dedicated platform team. That means we don’t have to worry about low-level infra and can focus on building and shipping features.

We follow cloud-native principles such as service discovery with Consul, service mesh with Consul Connect, event-driven design using Apache Kafka, and stream processing with Kafka Streams. This setup allows us to build decoupled, scalable services that communicate efficiently.

We use GitHub Actions for CI/CD. Every pull request runs a full pipeline with unit, integration, and end-to-end tests. If the pipeline succeeds, the change is automatically deployed to development. Staging and production deployments are also automated.

We follow DevOps practices closely and have dedicated people in the team who focus on deployment, monitoring, and stability.

How do you ensure code quality?

Every pull request must be reviewed by another team member — no exceptions. We also use Sonar for static code analysis and quality metrics. The combination of automated testing and strict review gates keeps our codebase clean and reliable.

Is there room for experimentation?

Definitely. We’re encouraged to explore new frameworks and tools — especially when we hit limitations with the current stack. That said, we try to keep our stack focused and maintainable. For instance, we chose to go all-in on Spring Boot 3 rather than mixing it with frameworks like Quarkus that serve a similar purpose.

We also explore reactive programming using Project Reactor and Spring WebFlux, and experiment with technologies like serverless computing and new deployment models.

What’s the culture like at Nedap Security?

One of the things I really value here is the level of trust and flexibility we’re given. We have the time and space to experiment, try out new ideas, and develop new skills. That keeps me motivated and inspired.

I work flexibly – sometimes from home, sometimes on-site in Groenlo. The campus is spacious, everyone has a flex desk, and there’s usually a good mix of people around — enough space to focus, but also enough brains to bounce ideas off.

People are helpful, and there’s always someone up for a second opinion or just a chat at the coffee machine.

How does Nedap support personal and professional development?

A great example is our annual TechKnow event. It’s an internal tech conference where colleagues give workshops and presentations on topics like machine learning, cloud security, GraphQL, Kotlin coroutines, and more. It’s incredibly inspiring and fosters a strong sense of community and shared learning.

Any advice for Java developers moving into cloud-native development?

Start by learning Kotlin — it’s a great language for writing clean, expressive, and safe code. Then get hands-on with Docker, Kubernetes (or Nomad), Spring Boot, and Kafka. Build real CI/CD pipelines and dive into monitoring.

And most importantly: learn from others. Watch conference talks, read about real-world architectures, and adopt best practices early. There’s no need to repeat mistakes that others have already learned from.

Want to learn more about Java and cloud-native engineering at Nedap?
Feel free to connect with us — or visit our J-Fall 2025 booth to meet the team!