Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News How Serverless Impacts Design: Gojko Adzic at DDD Europe

How Serverless Impacts Design: Gojko Adzic at DDD Europe

This item in japanese

Serverless architectures are increasingly becoming mainstream and can significantly reduce both time to market and operational costs. But to benefit from them, applications must be designed around the constraints of this deployment architecture. At the recent DDD Europe 2020 conference in Amsterdam, Gojko Adzic discussed his experience using serverless, future trends, and how Domain-Driven Design (DDD) and a serverless architecture will impact the design of an application.

Adzic, partner at Neuri Consulting, started by noting that in the DDD community we are very precise about the language used, but when we talk about design, he claims that it mostly is about modelling. In the context of his talk, he defines modelling as building a theory about the world we want to represent. Design is about how we capture the theory and translate it into software, although he points out that there is a lot of overlap in the two terms. Finally, he defines a server as either a physical machine or a program that operates a socket — a web server, a message server or something similar. In a serverless context, a server is commonly something connected to a socket, and for Adzic the whole idea of serverless is that the provider of the platform owns and terminates the socket. He therefore prefers the term socketless instead of serverless.

Adzic notes that today the cloud is not only an execution mechanism, but increasingly an integration mechanism driven by events happening in our cloud environment. The providers also allow customers to customize their platforms by adding functions that run when something interesting happens. This means that we don't have to build for instance our own user management platform just because a small amount of our business logic differs from a standard platform; instead, we can use a generic service and customize it to our specific business needs. This allows us to focus on the core in our business and is an integration pattern Adzic thinks will become increasingly interesting. He notes that there already are second level providers like Atlassian that are working on adding their specific functions to a serverless platform and reselling it as a service.

Since the cloud providers own the sockets, they also handle things like scaling, monitoring and similar things. They also own the security, reliability and similarly important aspects, which means a lot of the standard devops responsibilities are taken care of by the provider.

The pricing model for serverless is where things become really interesting for Adzic, because you only pay for utilization, never for idle time. This means you don’t have to plan for capacity which removes an architectural constraint we have had for 60 years — reserving capacity, and paying for this reserved capacity. Earlier, we designed services for isolation, but coupled them in deployment to lower the number of servers and save money. Now, we pay for number of requests, and Adzic notes that:

Serverless financially rewards good design (instantly, not in some potential distant future)

Adzic cofounded in 2013, and in 2016-2017 they migrated from Heroku where they used reserved instances to AWS lambdas. During the move, the number of active users increased by 50% but their operational cost decreased by 50%. They also became much faster in deploying new business functionality because they were able to focus on core parts instead of generic parts in the system. Adzic thinks that this type of cost reduction will put pressure on companies to adopt serverless.

In order to utilize the serverless world, Adzic points out that we have to start thinking completely differently about modelling and design. Deployment becomes critical, something he thinks we tend to ignore both in modelling and design. We are not paying for reserved capacity so there is no benefit in thinking in big applications anymore. We can therefore change from working with one application to many tasks, where each task can scale independently. From a DDD perspective, this means we can move from a single critical core to many tiny kernels. Another benefit is that we now gain control of the cost of every task, and for each one we can decide if it’s worth the money.

Despite all the benefits, Adzic points out there is a big disadvantage. Even a simple application like a "hello world" application is now highly distributed, and we must know how to design such an application from the start. We cannot ignore distribution, and he refers to Martin Fowler and his first law of distributed computing:

Don't distribute your objects

What Fowler means with this from a DDD perspective is that you shouldn't have a single aggregate on multiple machines at the same time because you can't guarantee consistency. A challenge is designing applications to obey to this law and avoid creating a distributed monolith. For Adzic, the intended deployment has to influence the model in a serverless world — we have to know which parts will be deployed separately and design aggregates after this, and he sees this as a real challenge.

Adzic thinks a solution will be to let events become mini-aggregates, designed for a specific purpose or task. A key challenge will be to design events that are not coupled to the receiver implementation, but still contain enough information to avoid chattiness, and generic enough to allow decoupling and reuse.

The slides from Adzic's presentation are available for download. Most presentations at the conference were recorded and will be published during the coming months.

Rate this Article