Context

For ~4.5 years I’ve written software for a large(ish) e-commerce company in Zurich. They moved from a large monolithic application to a distributed microservice approach. I was there when it happened and I’d like to take note of my learnings there.

Team A

In team A, I worked as a full-stack programmer on the shopping cart, checkout, and order overview features. All features were integrated as part of a large, monolithic, .NET MVC application that also included all of our back-office software for warehouses and such.
It was a mess. Running tests took >10 minutes therefore most uf us just did not write tests. Bugs in production were quite common and every year we were making bets if the system would keep it together for black friday. It usually didn’t.

Direct read/write access to our humongous MsSQL db from everywhere made concepts code being “owned” by a team practically impossible. This was ok when everyone in the company knew everyone else. But it did’t work with >100 people.

But I sure was able to get things done amazingly fast. No choices were needed to be made. All things routing, caching, logging, translation and everything else were already made for me. All I needed to do was to somehow connect the data with the frontend application and make sure it won’t crash.

The people I worked with were very competent engineers and a joy to work with. I trusted each and everyone to achieve any goal together. This is the reason the thing got as big it got in the first place. They created a great service and grew rapidly.

Learnings

💡 Code & data owenership needs to be managed if you have >100 people (or even with less)
💡 Shared data is even worse than shared code
💡 If tests take too long to run, people won’t test
💡 You can go insanely fast if you don’t care about quality - until you can’t
💡 With great people, processes and particular technology don’t matter a lot

Team B

After two years working with the monolith for team A, I decided to join a good friend of mine in the founding of Team B. Team B was created specifically to deal with off-site digital advertising.
This means making your page rank high in organic search results and using paid adverisements for your products on price comparison services and such.
Check out my other post about SEO to learn how to make your page rank well on Google (no clickbait).

In team B, we started pretty much from scratch. Our main task was to create a system that could export our product catalog to third party websites like price comparison services. We decided to start our own microservice, with its own persistence layer, its own deployment, etc.

This was nice, because the code base was relatively small and easy to navigate. We were able to run all our tests within a few seconds. All the technical decisions were up to our team. How to sturcture our deployments, what persistence technology we want, etc. It felt like working for a hip tech company vs maintaining some antiquated enterprise application.

There were a few hiccups in the beginning of the teams life. Our database for example, was our own. Only we could read and write to it. But the virtual machine hosting the db was shared between teams. So if my team forgot to create an index, for example, it would mean killing the other teams db as well.

When I look at the time spent coding, I see: * In Team A >90% of the time was used to solve business problems. * In Team B ~30% of the time was used to solve business problems. The rest was used to edit yaml files, changing from one messaging technology to another, fixing memory leaks, ftp access issues, etc. Especially in the first half of my time there.

Again, my team was highly skilled and I learned a lot in this time. Together we were able to lay a solid foundation to solve business problems and scaling our marketing efforts to multiple countries and millions of users. And though our speed might have been slow in the beginning due to technical enabling work, I do think it was worth the effort.

Learnings

💡 (Technological) freedom of choice can and will slow your team down
💡 Invest time and effort in getting foundations right (e.g., public interfaces, system design, monitoring)
💡 Invest time and effort in developer experience.
💡 To make teams work in autonomous microservices, infrastructure needs to be seperated
💡 When in doubt, ask an expert (e.g., in database questions)

In Conclusion

There is a trade-off between developer choice and productivity. You should be free to make the really impactful decisions. But it’s nice when the unimportant things are decided for you, so you don’t need to spend time arguing about them.

And most importantly: the most important factor to a projects success is the individual quality of each team member and the bond between them.

so long

comments powered by Disqus