Discussion on "Terraforming an Early Stage Startup (Part 1)"

Marcelo Uemura · 2021-04-29T22:04:23.157Z

Ever since I moved back to Brazil in 2010, I've worked mostly for scale-up companies past the startup stage, struggling with the growing costs of technical debt. They were looking for someone with the experience of having seen and lived how some tech...

Who has access to the source code for a completed, large-scale multiplayer online Android and iOS game developed by a major gaming company? The game must have top-notch graphics. I will not accept games developed by individuals. I am willing to pay a high fee to purchase it for learning and research purposes. Contact me q791864008q@gmail.com

Great content! When will we have the second part of this article?

Thanks Eduardo! The second part will be online next week. Stay tuned.

Although this blog post ends up focusing on the infra side of things, a promising alternative to the monolith/microservices/serverless architectures I stumbled upon recently is Polylith. In essence, you use a single repository to store your application's code but structure your project in a way that lets you have multiple deployable artifacts when/if the need arises, so your system is only optionally distributed, there's no need for big rewrites and monolith->microservices migrations everyone's doing, and you end up alleviating the initial infra set up costs!

Felipe, I love the idea of a monorepo, one thing that most definitely cannot happen is that a monorepo causes a monolithic build or monolithic deployment. At least on the build side of things, tools like Bazel helps a lot. I haven't heard of Polylith but it seems to solve the problem of monolithic deployment, so I'll check it out.

One thing that I still find cumbersome to work with monorepo is implementing proper access control. Although I subscribe to the idea of giving as much access to developers as possible, being a Fintech means that we deal with a lot of sensitive data, so applying the principle of least privilege is very important to us.

For now, we are adopting a model where one repository equals one unit of deployment. And to determine if something is a single unit of deployment is not only being a service but also if there are different roles that can perform that deployment, for example, devs that can perform changes to the production infrastructure.

But rest assured that I'll explore this topic in more detail in one of the future posts of this series.

Great article Marcelo!

I have been part of many teams in my career and all of them suffer from the same problem, coupling. The team is composed of very talented engineers that give their best to build the software in the best way they know and in the quickest way possible. What they don't do is think about the future and think that the solution they are building at the moment will need to change for a variety of reasons.

So the final product is always coupled. And with many types of coupling:

Library coupling: "Let's use this library with 22 stars on GitHub, we can deliver this feature a lot faster". Until you realize that this library also depends on other n libraries and will not be updated making you stuck with your current versions of even unrelated libraries.

Infrastructure coupling: This happens especially when the team decides to go microservices to "reduce" the coupling but in the end, services are totally coupled to databases, pub subs, and many other services from the cloud provider. In a way that when you change the schema o something in one service, it breaks other services that depend on that schema.

Coupling is what makes everything hard to change and I think that the only way to mitigate that is by having guidance and alignment since the beginning from experienced people so this become part of the culture and values of the whole engineering team and the existing team members can pass it to the new members that arrive.

Hi Geison, so nice to hear from you. How are things in Germany?

Coupling is an interesting question. The reality, in my opinion, is that you are always coupled to something. The moment you call into another piece of code, you are essentially coupled into that code.

What you can do, however, is to choose what you are coupled to and control the degree of coupling you are to these things. Let me start defining the degree of coupling first.

What I mean by the degree of coupling is essentially the number of places in your code base that you reference a dependency directly. For example, you can use the Redis client directly all over your codebase, or you can create an abstraction layer, and reference this abstraction layer around instead. In the first case, you have a high degree of coupling with the Redis client. In the second case, you have a high degree of coupling with your abstraction.

In general, is better to have a high degree of coupling with things that you have control over or you better have a high degree of confidence that the thing you are depending on is really stable.

However, if your abstraction layer is poorly designed, you may end up with the worst of both worlds: having to spend time to create and maintain the abstraction layer while still being coupled to Redis, for example. This happens in particular through leaky abstractions:

joelonsoftware.com/2002/11/11/the-law-of-leaky-ab…

Now back into choosing what you're coupled to. The way I think about dependencies is just like marriage. Is this something that I'm confident that I'll be happy ever after, or should I have a prenup agreement (like an abstraction layer)? What if the dependency brings their family to live with us (the library dependencies)?

As I mentioned before, at the end of the day, it is unavoidable that you are going to be coupled into something. The important thing is to choose carefully with whom you will have a high degree of coupling.

Excellent insights. Thanks for sharing!

Great articule Uemura, and I loved the mindset applied for the infrastructure team: build usable stuff.

PS: very useful and friendly the drawings about monolith, keeping it simple and acccesible 👏🏾

Hi Marcelo, it's nice to hear from you too. Things are good around here, despite the lockdown since December.

I agree with everything you said, and to decrease the degree of coupling and facilitate the management of dependencies is why we have SOLID, Design Patterns, and other architectural patterns.

My point is how often I see projects that simply marry with a database or a framework making everything hard to test and hard to change, and how important it is to have guidance and alignment since the beginning of the project to disseminate a culture of code quality.

Discussion

Terraforming an Early Stage Startup (Part 1)

Responses(5)

Recent in Forum

Search Hashnode

Terraforming an Early Stage Startup (Part 1)

Responses(5)

Recent in Forum