Things to remember while building Microservices
Microservices are much more than an engineering problem to solve and let's look at some key engineering and non-engineering things to remember while building them.
Growth Opportunity
Microservices are a great growth opportunity given there are so many engineering and non-engineering challenges to solve. Every engineer or early leader should grab this opportunity to showcase his/her prowess and earn leadership brownie points.
Conflicts are inevitable
Engineers are passionate, and intra-team and inter-team conflicts are inevitable. But the conflicts should be gracefully by
taking data-driven informed decisions
consulting senior engineers
sometimes moving on without creating a fuss
Architecture Evolves
Vision evolves and so would our architecture. The decisions we took while building it might not be the best today and hence we should be okay with the code getting scrapped and seeing some dramatic changes in the flow.
Technical Debt
We cannot always build a Microservice in the best way possible. Engineering teams are always running against time and aim at delivering things quicker.
This requires us to cut some corners and make some inefficient decisions and this is called Technical Debt. Over time such debt piles up and reduces the development velocity.
It is important to clean up technical debt periodically, by reserving ~10% of the bandwidth of every engineer every sprint.
Enforcing Standardizations
Standardizations are essential for microservices as it provides a clear set of guidelines to use for building them.
To ensure that every team is not building and setting up their conventions from scratch, we create a Template that everyone can use and build on top of it. This aligns with the DRY principle ensuring we do not waste time doing repeated things.
Some engineers and teams might see standardization as strangling, and hence we might see a potential backlash. In order to ensure this is adopted smoothly
we should have a forum that decides the standards instead of a central team
the forum should have proper reasoning behind every decision taken for the template
This would help us keep such templates and best practices inclusive while ensuring a positive sentiment all around.
Business over Engineering
This is offensive, but it is true. Engineering exists because the business does and hence while building microservices we should always remain aligned with the strategic goals.
For example, if the business priority is profitability we should not have over-provisioned microservices that leak money.
Here's the video of my explaining this in-depth 👇 do check it out
An engineer working on Microservices should not only just focus on engineering; there are so many other aspects to look at that holds the potential to create massive impact. To be honest, Building microservices is much more than an engineering problem to solve. There are many pitfalls to avoid and decisions to make and build a solid functional high-performing team in the process.
In this video, we look at some engineering and non-engineering things to remember while building Microservices, like it is a massive Growth Opportunity, everyone should be okay with architecture evolution, the importance of periodically addressing Technical Debt, and striking the right balance to keep engineering and business aligned to the same strategic goals.
Outline:
00:00 Agenda
02:53 Massive scope for growth
05:11 Conflicts are inevitable
11:15 Architecture Evolves
13:36 Technical Debt
16:39 Backlash while enforcing standardization
20:47 Business more critical than engineering
You can also
Subscribe to the YT Channel Asli Engineering
Listen to this on the go on Spotify
Thank you so much for reading 🖖 If you found this helpful, do spread the word about it on social media; it would mean the world to me.
You can also follow me on your favourite social media LinkedIn, and Twitter.
Yours truly,
Arpit
arpitbhayani.me
Until next time, stay awesome :)