The story of Curve began about 5 years ago. This is the story of Curve Engineering, where it all began. Here we lay out what tech stack was used and how we have evolved to our 100 plus strong team. 

Team structure evolved with service ownership

Our team structure was very different to what we see today. Initially it was one team, with a few contractors. As time went on, the size of the team grew and then split to focus engineering efforts more efficiently. Responsibilities split with the teams. Initially a singular developer could be responsible for a whole service, so if someone asked for a new feature, it would be put into whatever service they were familiar with or “owned”. This led to business logic being scattered out and with multiple engineers contributing to core parts of the application at the same time. This led to developers having less of an understanding of the overall system due to its chaotic nature.

Some of those services still exist and are almost looked down upon because of their history. It was sloppy. The onboarding of engineers at that point wasn’t easy. Multiple people were developing in their own ways, and on the services they knew best. This was unproductive as services were not standardised, they used different libraries, they had different behaviour. It led to a lot of frustration.

How Engineering grew up

Yet, the benefit of having such a small team was we had a full quorum for meetings such as design authority, everyone was in there. You could get everyone to buy into and share ideas. It became more challenging to share those ideas more broadly as the team grew.  Even if someone was not directly involved in a project, they had a broad understanding of what was happening.

That's where discussion around standardisation came up. These led to design sessions around how the structure of the application should look like. Starting from the structure, the naming conventions, and what they should represent. That's where we come up with the internal folder, that holds all the business logic, and then you would have the repository folder for the concrete implementation of the database. Testing was also discussed, unit vs integration. Then came documentation to describe all these decisions.

The aim was to have a good solid foundation with standards and best practices to help guide everyone. But what really shaped our best practices were the developers who were building things in parallel, who had big ideas, who brought new ideas and solutions to the table.

Starting off as a small team, there was a lot of early adoption, including new tools such as Istio. We were willing to try new things, move fast and break things. Today, we have to be a lot more sensible. We have targets to meet in terms of stability. The company has grown up and we've had to grow up. We can still experiment, but we have to ensure our customers have a stable and reliable service at the same time. 

Language evolution

As business logic and ownership of services was scattered, a conversation around language arose.  Curve started as a PHP monolith. It was chaotic; the system would work on some people’s machines, but not on others.  A group of engineers didn’t want to work on PHP anymore and were eyeballing new languages. 

Consideration went into Python, Go, Java, Rust and the team finally settled on Go. The reason behind this was that it is a simple language, easy to deploy, quite easy to learn, and it’s fast. It also comes with a lot of tooling such as Go Kits, that help plug in components to deploy microservices and make it work out-of-the-box with http server and middlewares.

Deployment

Initially we had dedicated machines for each service. The Go services were the first to be deployed in Kubernetes. CI at the time was Jenkins, their EC2 instances deployed with the code and load balancers in front of them. But quite soon afterwards, we had Kubernetes being tried with the Go apps first and then rolled out Kubernetes fully. Docker was there from the beginning with the PHP apps. The trajectory we had of Microservices, then Go and then Kubernetes made sense. It’s almost evolutionary.

Looking forward

The future for engineering at Curve is to build on our growing number of Go services. This will allow engineers and the Product team to rapidly deploy new features and services for customers whilst maintaining a high standard of reliability, availability and security.

Building a new service should be simple; using standardised libraries and paths that enable us to concentrate on the business logic and features, rather than the plumbing. Deployments to our Kubernetes cluster should be frictionless and future upgrades of libraries, drivers and underlying infrastructure will be continuous, empowering our engineers with the applications we build. 

Clear ownership of services, observability tooling to chart the health of services and their inter-relationships will allow for profound understanding of how our services provide value to the customer.

These tasks are facilitated by our enablement teams who are growing in number and are empowering our engineers to work better, more efficiently and with more confidence. 

Looking forward, our engineers should be self assured, continuously learning and building the best.