Designing the backend right from day one

So Martin, what are the first things one should think about when designing a customer-centric backend?

It’s always tempting to look at the existing customer base and backend solution ­and build from that. However, we believe it’s more important to look to the future from day one and design a backend solution that can accommodate a client’s needs moving forward. This doesn’t mean discounting an existing system, but rather being open to change.   

Of course, the size of a company will impact this decision. We work with both large and small-scale organisations, some of them have well-established infrastructures, while others are in early stage development. The same also goes for service requirements; our global partners may have tens of thousands of requests per second as a starting point, while it may be more like a thousand requests per day for smaller clients.  

There’s always a temptation to take shortcuts when choosing how to design the backend for a small-scale service, and when building the minimum viable product (MVP) this can be the right approach. But as soon as possible, we recommend migrating to the cloud.   

What might a typical cloud scenario be for a smaller organisation?

We offer a private cluster and scalable cloud-based solution to all our clients even when a project is newly launched and has a small user base. This can be a private or public cloud or it can be hosted in a customer’s existing cloud service. 

Our developers are experts in building scalable micro services in Node and Ruby using Docker and Kubernetes, which offers endless scalability for an application. When designed correctly, there is almost no extra cost involved, just a few extra hours of setup at the beginning of the project.

Can you explain what you mean by clustering? 

A cluster is basically several computers working together as one. When you require improved performance, you simply add more machines to the bottom of the stack. I like to think of it as ants in a nest whereby the workers are small, plentiful and productive, which makes for a powerful cooperation. 

Clustering in the cloud can be hard to get your head around since everything is virtual and you have many layers of software and operating systems stacked on top of each other. But in the end the goal is quite simple: you have a number of CPUs (or virtual CPUs) with network, disk and memory, and you get them do as much as possible as cost effectively possible.

What are the benefits of using a cloud-based service as opposed to having traditional in-house servers?   

Well for one thing it’s more cost effective for our clients. The smallest Kubernetes cluster costs about as much as a small Linux web server. It handles a substantial amount of load by itself, and is performant enough for many small applications. Additionally, software development is cost efficient since multiple versions of the application can co-exist on the same hardware. And as soon as user uptake grows, and the service needs to be scaled, the platform really starts to shine.

Why is scalability from day one so important? 

Building scalability into an application from day one means we don’t have to start developing a new solution when a service starts to become popular and the number of users increases. A small and humble cluster can grow in size with more CPUs, higher memory and more machines sharing the load. Splitting micro services in smaller applications over time is also a great way to gain more control over performance and costs.  

For services that handle an uneven amount of traffic – with peaks at certain times of the day or week or on specific dates or occasions – you can direct the cluster to automatically scale and then shrink back to size once the event is over.  

How do you manage and optimise scalability? 

Scaling a backend service is not always the same as adding more hardware. Some applications have to handle a large number of small requests, while others are there to crunch mass data. As traffic grows, simply throwing more CPU and memory at it might not solve bottleneck issues. In reality, this can mean that in some instances you get more throughput by spawning additional service instances, while at other times you may need to add another virtual machine. The best way to find out is by load testing and reviewing performance statistics.  

Our clusters can grow or scale in every direction. By that I mean that we can turn lots of dials to maximise performance while minimising the cost. It’s a case of not using a “sledgehammer” to solve a problem when you only need to flip a switch.

You mentioned cost effective development earlier, are there any other development benefits?  

At Daresay we are firm believers in release early and release often. An agile, fast moving cloud-based application is ideal for this approach, and small iterations are crucial to ensure nothing breaks. By building services directly in the cloud, each version and stage of an application – i.e., development and prototyping, staging, and production – can be deployed simultaneously.  

In development and prototyping we can build a service with well proven or the latest and greatest technologies. This is automatically deployed and tested using a continuous integration machine. The service can safely fail in this environment.  

During staging we work on the next release. This environment is typically used by testers and stakeholders. Things can safely break here but they shouldn’t. We can even auto deploy updates directly at this stage but it’s not advisable to do it too often.   

In production we release the customer-ready version of a service. As it’s been thoroughly tested in the cloud there is no transitional downtime between approval and release. You just press go!  

The great thing with this agile method is that features trickle down through the versions and any bugs get “squished” along the way. Our customer usability testing follows the same pattern, which allows us to verify new features along the way and make early changes if needed.  

There’s a lot of talk about security nowadays, how do you manage this?  

When we talk about security at Daresay we generally mean  security of operation and data protection. We  work closely with our customers to make sure data privacy regulations are met and when we build a solution it’s with the aim of delivering zero downtime to ensure the customer experience isn’t interrupted. 

Fortunately, we have a few security experts here at Daresay who have recently been involved in developing SDKs for the world’s first secure system for remotely validated driving licences digitally. Having this inhouse expertise is a great asset. 

My final reflection…

Having worked as an arborist before co-founding Daresay I know just how important a good foundation is. Equally important is the need to cultivate and prune in order to stimulate growth. It’s this type of thinking that I believe should be applied to a backend solution. Build right from the beginning. Be agile and accommodate for change.