Modern software development with Cloud, Microservices, Kubernetes and Domain-Driven Design
Cloud, Microservices, Kubernetes, and Domain-Driven Design is amongst the most trending topics within modern Software development. Topics that ProData consultant Jens Andresen juggles with every day on his current assignment at DFDS. In this article, he shares his experiences and talks about the synergies that exist between the technologies mentioned above and trends.
Interview with Jens Andresen, senior developer and system architect on assignment at DFDS
From Monolith to Microservices
In recent years, DFDS has undergone an extensive modernization and transformation to cloud-based systems. This has been done to make the IT infrastructure more flexible and adaptable to the market and across all business areas. Jens' work has been to break down critical business systems of DFDS into smaller applications and further to contribute to the implementation of a state-of-the-art microservice-based architecture.
"You could say it was a two-legged journey. I was brought on to help DFDS get started with Cloud adoption, but also to break down the Monoliths, the old architecture, but it has also been a journey with a shift to a microservice-based IT landscape. In the past, you made big applications - more commonly known as Monoliths - and added all kinds of functionality, and over time they became massive and difficult to work with. Now there's a wave of microservices, where the goal is to break it all down into smaller chunks that can still talk but are still confined. It allows you to focus on issues in isolation."
Thanks to much of this work, the development departments in DFDS (and many business units) have gained more freedom and flexibility in the process. Each business area can now be developed as new needs arise:
"For instance, if we were to create new functionality, then we can do it in isolation in a separate microservice. We even have the autonomy to decide which technologies it should be based on as needed. You are able to choose the appropriate database yourself or whether other 'Off The Shelf' software should be included to execute the task. A team can even put it all together via a modern cloud provider."
The large-scale phasing out of the monoliths in favour of a modern solution with microservices has opened up for new possibilities. This has provided a completely different flexibility to the respective business units around DFDS.
Modern developers should master the art of limitation
It can seem daunting when faced with a transformation of this magnitude. The usual, well-tested and safe is all in high demand. Because with today’s many opportunities, even the most experienced IT people, can find themselves overwhelmed.
“This is when people begin to look a little pale. Modern clouds, with their seemingly limitless supply of services, can be overwhelming for even the most experienced IT consultants. You will never reach the point where you can say that you are an expert in AWS or Azure. It all changes so fast."
If one considers new cloud products solely coming from the big three (Amazon, Microsoft and Google), each of these companies release more than 500 new services every year, but if you ask Jens, no one needs all of those:
“More isn’t always better. There is something beautiful about being able to limit yourself. You don’t future proof anything by adapting all the latest features. The trick is to know when to use something over something else – and especially when NOT to use something.”
Although things are evolving rapidly within software development with new methods and solutions almost every day, it is not a new issue. It just goes even faster than before. Understanding the whole, keeping an overview and making an informed and calculated decision is, therefore, the key to the best result.
Kubernetes was a boost for DFDS in their cloud journey over to AWS
Back in 2017, it had been decided to make a switch from Microsoft Azure to AWS. There was a need to market the idea internally and a need for something intelligent (but also easy) that could get developers on board and convince them that this cloud journey was not just a lot of unnecessary trouble. Kubernetes was the eye-opener and solution that was needed.
In that same period, Kubernetes was very hyped, and one November evening in 2017 Jens was so inspired that he found himself playing with the software at home. Because maybe this specific piece of software could be the answer DFDS needed to get developers on board and facilitate a smoother transition to cloud-based microservices:
"I was in love. It had the potential to be a PaaS solution at DFDS, and it would limit the amount of hassle that developers would have to deal with. It can seem incredibly daunting when you go from having an entire operations department running things on-premise to instead running your solutions on a public cloud yourself."
Kubernetes made the shift to cloud easier
For developers who have no experience with cloud technologies, it may seem impossible to get started. But the beauty in choosing Kubernetes and the whole idea behind it was that you still only have to deal with building your business application, and in addition, only have to learn a few things in order to get it in the cloud. Which was exactly what DFDS needed:
"By limiting the new stuff to something that looked like the old, you would not have to deal with practical cloud-details like virtual machines, networks, disks, etc. In principle, you would do as you normally would. That made it easy to tell people and get them on board."
These days Kubernetes has become the 'default runtime' platform for development teams in DFDS. The implementation of Kubernetes has become such a success story that DFDS now prioritizes having a separate team whose job it is to maintain the Kubernetes platform and build services on top. Asked whether it makes one proud to be able to influence the development processes in a company as large as DFDS, Jens replies:
"It's pretty cool! It is definitely not something I can take all the credit for at all because it certainly has not been a solo trip. A lot of hard work goes into rolling out Kubernetes, and there are many sharp edges in Kubernetes, but it has been great project to be involved with all the way."
And now the approach to Kubernetes has also shifted 180 degrees:
"Things have changed - and it has almost become a matter of principle - now you really have to have a good reason for NOT putting your services on Kubernetes."
Event-Driven Microservice Architecture
The architecture of DFDS has also been on Jens' agenda. After the introduction of Kubernetes, Jens went on to promote another of his great passions; event-driven architecture:
"With event-driven architecture, you are able to build reactive systems. It fits well into a large company like DFDS, which has many business areas. Often, the products of DFDS are spread across many business units. They are then pieced together into a business process, which in the end results in a sale to the customer."
The advantage of this kind of programming is that a modern company can create processes that make it adaptable to new needs. Having an architecture where components can react to each other, creates a good starting point for making automated processes:
"It makes it easy to build on. You can continuously add new components that are listening to the stream of events and then react to them. It is wonderfully disjointed and clearly the way forward."
In a modern world where companies need to be adaptable, it is a definite advantage if you have built event-driven and reactive systems. The reactive can become proactive. The classic adoption of Microservices was characterized by being based to a greater extent on synchronous API-based communication, which means that services are exposed in an API that others can call:
"A service first calls one service, then it calls another, after that it might call a third, and so on. That is the classic adoption of Microservices. In comparison, the event-driven and reactive works asynchronously. Here, the service would report that there is a change when an event has occurred, and then there may be other services that listen and react to it. Effectively making the various services more flexible and incredibly loosely linked.”
Domain-Driven Design is relevant again
The popularity of event-driven microservice architecture has sparked new interest in a philosophy and approach to software design known as Domain-Driven Design (DDD) that was introduced in 2003:
"When Domain-Driven Design emerged in 2003, it gained relatively modest popularity. Then when we experienced the whole wave of Microservices, people suddenly started thinking of DDD again, and the popularity exploded. Because those two things complement each other exceptionally well. DDD provides an overall direction for Microservices - how to split monoliths. I usually tell the different teams to try and see if they can get some inspiration from DDD when they need to solve a challenge. It gives some really good guidelines on how to make distributed systems, and how to approach software design in general."
Jens explains that DDD is an especially good fit with a large company such as DFDS. Unlike in the past, where everything needed to fit one understanding and fit a single model, the approach in DDD is to recognize that differences exist in a business and that there probably is an underlying cause for them. And if they are beneficial, then there are significant advantages in supporting these differences, rather than homogenizing:
"The idea of DDD is that you support the differences in the business all the way down into the code. It is essential to adopt the same language and terminology in the code as the one found in the business. A company such as DFDS operates within several business areas, thereby spanning several domains, such as the logistics- and passenger domain. You start off by supporting the differences and nuances already present. This is where you can attach a direction and let the domain act as the driver for the design."
When asked whether this approach to software design has been a success, Jens says there is still a little way to go. He often finds that there is a tendency among developers to start working on the solution too quickly, before settling into the problem that needs to be solved. It all revolves very quickly around the technical and the selection of technology:
"Understanding the business is always the most important thing. When we as developers receive demands from the business, there is a tendency to immediately start thinking in terms of code and database tables which do not matter in principle. We might end up choosing a completely different database, where things are done completely different - and then we have not achieved anything."
It is a basic premise that the business comes before technology whether you refer to Cloud, Kubernetes, Microservices or Domain-Driven Design. And while modern software solutions are fantastically smart and bring a wealth of opportunities with them, there is now more than ever a greater need for a method and a direction that can guide today's distributed systems:
"It is definitely the right way, I think. Because it is not just about breaking monoliths into pieces – you need to have a software design.”
Consultant Jens Andresen
Jens Andresen is a senior developer and system architect with very strong competences in software design, technology and platform selection in large scale IT projects – including leading agile development processes through Scrum.
