Amazon frequently holds events for the technical leadership to come together and share their experiences. While it’s not a forum, it is a webinar to discuss on technical issues. The most relevant part of these webinars is the QnA where you can ask questions specific to your context and gain some insights from the event.

In this webinar, we are talking about the pros and cons of micro architecture, some common pitfalls to avoid, and how should you consider your migration over to the micro architecture.

Speakers

Rajesh Chandrashekaran - VP of Engineering at BukuWarung
Jeyandran Venugopal - Chief Product and Technology Officer (CPTO) at Flipkart
Mohammed Alabsi - Startup Advisor & Angel Investor | ex Amazon | Kellogg MBA

Moderator

Shivkumar Krishnan

Krishnan:

How does your engineering journey look like in the early days?

Rajesh:

Manage yourself first before you consider building your leadership management skills. Learn to build trust

Krishnan:

Hows your transition look like when you move from being in Amazon/big companies for 10 years to a startup?

Alabsi:

Treat yourself as a startup. Continuously evaluate your skillsets. What kind of skillsets are needed for startup scene and work towards that direction.

Jumping on customer support calls to hear first hand on their challenges and pain points. It gives a fresh perspective that builds the success of the organisation; beyond just writing code.

Go beyond the current scope of work, always think on behalf of your customers. Be impact driven that are customer centric.

Aside from cultural differences across companies, as a leaders, you have to play the multiplying factor. Being proactive to address customer’s needs.

Rajesh:

Be clear on what track you want to work on. How to scale thinks about how to delegate? How do you coach the next level of leaders?

Krishnan:

What are your early days? And do you have any multiply effects

Jey:

Find a spot where you like whatever you are doing as well.

Fusing business understanding into problem statements

Flipping your technical architecture

Share your thoughts on the evolution of technical architecture

Rejesh:

Software is born in business context. Software are like living organisms: it grows and evolves.

Spread out your logic into its domains from the start, so you can think of the architecture design’s scalability from the start.

Each services can have its own database, its own cache, and the separation designed from the start from a monolithe allows you to consider the evolution of architecture beyond the business context of today.

Pitfalls of microserv

Scaling considerations:

Scaling each of the clusters of services can be possible if you separate them properly.
Discovery of endpoints where service oriented architecture.

Rajesh:

People are not writing unit test for early startup.
The logic of the context that are in monolith will be further apart with micro service architecture.
Recreating production into staging will become impossible when you start to move microservice.

Alabsi:

anti pattern: nano-services. Don’t fall into this pitfall - one api for one service. Super complex.
Use Domain driven design to figure out the level of segregation for services
As deployment frequency increases, invest in automation. CI CD is important for scale.

Krishnan:

What are your motivations for taking the plunge into the startup scene?

Rajesh:

• the burst of learning
• Being in the thick of things
• building things from scratch

Jey:

• Level of transparency. Your rate of opportunities for you in a smaller setup/ or high growth setup.
• If you end up in a large company, the process is longer.
• Small company, your limitation is your ambition.
• Need to adapt to a new way of working.

Krishnan:

How does mentorship become important in the startup scene?

Rajesh:

• A buddy system
• Paired with a tech lead
• Biweekly learning
• Learning sessions
• Ensure alignment with your engineers’ own personal ambitions

Krishnan:

Anything specific on SEA/indonesia startup?

Alabsi:

• Adopting to local needs is important

Krishnan:

• What metrics can we measure the effectiveness of our architecture?

All:

• measuring uptime beyond service uptime alone. Customer side. How fast are your application being served to your customers.
• Number of post production bugs?
• effective: time to features. How long does it take to iterate and touch the least number of components
  • Pitchable feature. We can move extremely fast with concrete data

Krishnan:

How to transit from 1 DB to multiple DBs

Alabsi:

• Do in an incremental fashion. Look into your schema into more detailed tables.
• artisan your db tables as well.
• Have enough master and slave DBs.
• replicate your db across your other DB for the initial transition

Krishnan:

Can micro services become distributed monolith?

Alabsi:

• what does that even mean?
• High complexity with alot of microservices
• When there are customer issues, when there are alot of microservices, its difficult to trace the issue.
• Have tracking in place, have service discoverability in place.

Krishnan:

• Communication skills beyond delegation, how much communication skills matters compared to tech skills to get into technical leadership?

Jey:

• Emotional intelligence
• How you come across to people. People skills is kinda your Emotional intelligence.
• How can you communicate your knowledge to people different from you?
• when you are at a higher level, you will interact with people of other domains. Communicate the right things to the right people. Communicate differently based on whoever you are talking to.
• Respectful disagreement. Understand perspective. Understand your stance.
• Strong opinions loosely held. When people have evidence for alternate perspective, you can change your opinions accordingly when it makes sense.
• Personality builds your emotional intelligence.

Krishnan:

How to join startup as fresh grad

Jey:

• startups needs People of skill and develop fast
• Move fast, get things done.
• Self starts who can do things independently.

Krishnan:

Right in startup or into big tech companies first?

Jey:

• Personal decision
• Factors of decision making for startup: have energy, want to build things quickly, likes to explore, have energy level to pull it off. Accelerate your career. In 10 years become a VP level for example.
• Large companies, expectations are more set, the experiences required are more pre-determined.

This is my own personal question

Hi Im Joshua from Kinobi here. Thank you for the sharing thus far! We are currently an early stage startup, and resources are limited. I’ve heard the cost of moving into microservices increases up to x7 given the different allocation of services (not sure if that’s true) When do you think its time to move from monolith to a micro service?

• Consider Pros and cons of different architecture
• Pitfalls of microservices
  • Complexity, with large footprints, you need service discovery
• Before you achieve strong product market fit, then microservices might not make sense.
• If you need to rapidly scale, you need to have the components broken down quickly to make the transition easier.
• anti pattern: god component

2. Assuming, you are currently a 2 men engineering team, how will you organise the engineering team for scale, and how many engineers should you ideally have before you move to a microservice architecture?

What is the proper way to synchronize data across microservices? Is it using event sourcing? But it will lead to to the data duplication, is it ok? What’s the correct/best way to implement this?

3. Question for Jey

How do you play CPO and CTO and address the conflict of interest?

TDLR;

The take away is clear. While you do not need microservices from the start of your journey, set up your monolith to ease the transition when the opportunity arises. Keeping your application modularised but be wary of nanoservices where a small feature could easily become a service on its own.

This post serves mainly as an archive of some of the webinars I find interesting. Taking notes while moosing over the questions raised in the webinar can be a challenge, and I’m up for that challenge!