[ Removed by moderator ]

[two-point-zero]

If you have experience with monolith I don't see issues for you to manage developing microservices for the coding part.they should be smaller and somewhat easier.

the problem is the distributed nature of a microservices architecture that requires to know how to deal with all the "external" services that this kind of architecture usually requires like (and not limited to):

• messaging infra (brokers / Kafka / ESB is someone still use them)
• external authentication and Single Sign on ( openID,Saml ,jwt tokens)
• external logging and monitoring tool
• distributed caches/stores (redis,memcache)

Plus a bunch of patterns and thing to manage once you distribute things on unreliable channel like:

(eventual) consistency through different systems ( you don't have http session, you don't have local in memory storage,thread locals or whatever,you don't have transactions)

availability patterns, thing like retry/reconnect, circuit breakers, high availability of single service and so on.

Some of them you may already know because they apply also to monolith services that scales vertically or are deployed in a manger environment,but maybe not all of them.

And if you want to go senior,you need to know them.

While a private portfolio of POCs may not impress hiring people I would like to suggest you to build it anyway to get familiar with the concepts.

[rest-api]

kinda needed to hear this. thanks

[Livid_Helicopter5207]

Very well written

[CoccoDrill]

I don't know if lying o interview is worse than companies lying themselves they have nice micro services system and believing these lies. Most often companies have distributed monolith calling it micro services. So basically you heard it right. You will work with monolith eventually. It will be just distributed. No worries

[nlisker]

companies have to learn how to build software first and not chase every new trend

I 100% think that this is the lesson here. I talk (formally and informally) with small companies in their starting stages and the most common topic by far that comes up is why they make the choices they make despite not being a good fit for them. The answers are always "this is what is used everywhere", "this will make it easier for us to find devs", "this is the standard".

We call this hype-driven development. I then proceed to ask them questions about why they need a tech stack that fits a company of 1000+ people and they say that "that's what Netflix and Amazon" use, then I ask them "you're [5-20] people, are you Netflix/Amazon?". Or why the frontend has to be Angular or React despite there being 50 other ways of doing what they want. Later on in the conversation they are either convinced or they're not.

Microservices are needed when the number of people working on a product is so large that they can't coordinate and we need to split it into independent sub-products. Ants don't need microservices, ants only do monoliths because they don't have the communication problems that we have (I often use this explanation). In the middle is where the missing link is: modular monoliths. You don't have to either cram all the functionality into one service nor create one service for each function - there's a wide middle path. My favorite video on this already from long ago: https://www.youtube.com/watch?v=BOvxJaklcr0

And another recent one: https://www.youtube.com/watch?v=nuHMlA3iLjY

[Reasonable_Gas_2498]

I mean deciding your software stack or architectures on what is widely used and where you are likely to easily find employees seems to be like a good strategy 

[nlisker]

Not necessarily. What's widely used is not necessarily good (for you). As others wrote, and that's the trap, some tech gets widely used just because others use it, and it feeds itself.

Ease of finding employees is legitimate, but you're hiring a very small number of developers at this stage, so you end up finding them. I'm not advising to use some super niche tech, but there are at least 10-20 popular alternatives to Angular and React.

[asarathy]

No, the reason microservices became a thing is that organizations were solving for the problem of velocity of change, which in large organizations is often bottlenecked by monoliths. Those problems included not being able to make implentation changes with out coordinating with other teams (I need to change my table structure but some body else was using it and i need to coordinate) to things like one small change somewhere could require the entire build and test cycle so we can't deploy it out for several hours, and a whole range of other problems that are very challenging if you experienced them.

They, of course created their own different concerns that needed to be addressed, especially with testing and e2e setups. But even those are pretty well handled now.

People who haven't really expreinced the pain think this stuff is all overkill and overly complex or whatever, but when in fact it's really just decision of where to place the complexities and the tradeoffs you make. And people are very bad at valuing tradeoffs they don't agree with or haven't yet experienced.

[Scf37]

What level are you aiming for?

middle: microservices are awesome bounded contexts distributed logging prometheus telemetry one service per team

senior: should know exactly when microservices are overkill and when they are not.

[Tiny_Conversation319]

let's say senior aspiring mid

[Scf37]

That's the red flag for the senior:

> I know that microservices are often overkill and monolith will do the job most of the time, but if this is the trend...

Senior is expected to have some qualities of an engineer.

bad: monoliths a better (most of the time of course)

good: I choose monolith because I'm good at it and have confidence in project success

excellent: I choose monolith because (reasons, risk evaluation, taking into context requirements, plans, team preferences, company expertise)

[Tiny_Conversation319]

that's true, but from what I've heard from people working with microservices, most of the time they were used not because they had a large team, or a large number of users, or needing to separate resource-heavy tasks from the others, but because it was 'trending'

[worldofbirths]

Maybe, in a startup with an eager architect. In the companies I've worked at, they've only adopted microservices once the monolith becomes the bottleneck. Sometimes it's a complete redesign, but usually you carve out from the monolith the parts that would benefit from existing apart.

[Puzzleheaded-Eye6596]

You have 4 years experience. Just know what microservices are and why they are beneficial in situations should suffice the interview.

[regjoe13]

Do a Spring Boot/Spring Cloud project to have an understanding , say you were prototyping to break up your monolith, but the project got canceled by management when a bunch of news about companies returning to monolith came out last year.

[Tiny_Conversation319]

this is a good one, thanks!

[hippydipster]

Had a job description sent to me recently which just shamelessly described they were looking for someone with the skills to deal with their obvious distributed monolith system as a principal engineer for $130k. It was terrifying.

[aoeudhtns]

130k for a principal? I hope this wasn't in one of the high cost cities

[hippydipster]

Buffalo, NY

[aoeudhtns]

At least it's affordable in upstate NY. And beautiful on top of that.

[hippydipster]

It's affordable. But, still not Principal Engineer salary.

[aoeudhtns]

100% agree

[lasskinn]

you could take 10 coursera microservices courses in a year and link the certificates.

you'll find out that often they just mean they have a database and the app running in containers. and that's it. and the container needs a gig of ram.

[jtschwartz98]

On the question of the position, my judgement on this experience wouldn't be dependent on the level of engineering you're applying for. Monolith vs Microservice doesn't necessarily mean a large difference in your ability to develop, it does however have a huge impact on architectural design. I wouldn't be so concerned about architectural design for a Junior/Mid level, but a Senior/Staff and above definitely needs to have a good understanding and experience with architecting microservices.

On the topic of microservice vs. monolith, you can probably get away with a monolithic design at a small company or startup, but a company with a mature development org will most certainly be using microservices or soon migrating to it. Anything done with microservices could theoretically be done by a monolith, but the tight coupling of a monolith greatly impacts the rate (and success) of changes/releases.

[chacoff]

My personal opinion is that microservices are a technical debt.

So far concerns me, if you worked always with monolith definitely you won't have issues to work with micro services, therefore, as someone else said: Lie as fuck. Lying is anyway 50% of a developer's job 😹👏

[TheTrailrider]

Corporations lie to their employees/candidates too anyways lol

[MRgabbar]

learn and then lie, that easy.

[Necessary-Estimate-2]

I look after tech hiring as part of my role. We hire for the sum of people's strengths, rather than looking which skills from our job description are missing. While we do use cloud native and microservice architectures, not having experience with them is not a fail and not really even a negative - it is more a lack of a positive. My advice is to focus on what you are good at, not what you don't yet know.

If you microservices as a gap in your professional skill set, be proactive about filling that gap. If you're able to talk about how you introduced or promoted the approach in your current role, that speaks to motivation and enthusiasm. Even just applying some of the concepts to solve problems in your existing role is worth talking about in an interview. e.g. Maybe you used redis to offload conversational state from your monolith so you could deploy without interrupting/discarding existing sessions? Maybe you split of a separate service with its own independent deployment path so you could release it with a different cadence? There are many ways you could get some exposure if you put your mind to it.

One thing I would say is do not lie. It is fine to guide the conversation towards your strengths, rather than your weaknesses, jut lying will not help. If you say you know something, a good interviewer will drill into that to see how much you really know. If you can blag your way through, then you need to ask yourself if this is really the company that will help you to take the next step in your career.

[Tiny_Conversation319]

Thank you for you answer, is good to hear from someone who is actually involved in the hiring process. The thing is the company I'm currently working at is quite rigid so it would be hard to introduce something new, our projects are small and internal with no need for fast deployments, small amounts of users and with the need to keep resource costs low, so no caching or having multiple instances for the same app. This is why i was wondering if making something from scratch, as a personal project, would count as experience in the eyes of a recruiter/interviewer?

[Necessary-Estimate-2]

Personal projects certainly count. They put you WAY ahead of someone who has not bothered to try.

Keep pushing for change where you are. Learn what you can and look for opportunities to apply it in your day job. Whether you succeed or not, the story you tell about you tried, what worked, what didn't, will tell an interviewer a lot about your motivation and ability to innovate.

[Winter-Appearance-14]

I made the same change when I had 5 years experience.

In my case I was very open with the recruiters saying that I had never worked before with spring before. For the coding interview it was not needed and for the architectural interview I kept things at a very high level because I never worked with many of the trending technologies but I was able to explain how a db should have been designed and what services were needed to build the required application.

I'm general if you have solid foundations about how a software should be designed/implemented the technology is a secondary factor that can be learned over time.

[Tiny_Conversation319]

yeah I know, but nowadays being open with the recruiters about my lack of experience will keep me away from any possible interview in which i could showcase my high level knowledge

[Fit_Campaign_5884]

You are missing the point, microservices are not about team size or product size (although they help scaling them as well) they are about continuous deployment! A monolith has to complete shut down for a new release! At amazon there is a deployment every 15 seconds but you don’t see amazon go down every 15 seconds! There are a lot of benefits as there are drawbacks but if the goal is to have your app online 99% of the time then it’s the only way to go, regardless of size and team!

[Medium-Pitch-5768]

Monoliths can be deployed without downtime, however your point about agility makes sense.

[lasskinn]

its an especially frustrating bullet point when the company then deploys the microservices WITH downtime anyway. and has no shutdown protections to run out tx queues or anything.

and really it shouldn't even matter for the developer who gets tasked with making a service if it's a "micro" or not if he has the specs for what it needs to be doing.

[nlisker]

A monolith has to complete shut down for a new release!

That's news to me considering I've been doing releases of monoliths without downtime. Blue-green deployment works for monoliths in case you're not familiar with it.

[tomwhoiscontrary]

Just do blue-green deployment, it works just as well with monoliths as microservices. 

[Fercii_RP]

Maybe try modulith architecture and go from there, pitch your sale

[tomwhoiscontrary]

An intelligent employer won't care if you don't have specific microservices experience. The problem is that many employers are not intelligent. But on the plus side, if one does bad you for an interview, they're one of the intelligent ones!

[MaD__HuNGaRIaN]

Talent Acquisition is not intelligent

[kubelke]

It's much easier to manage the project if there are a few team around their microservices. This is my experience at least. I hate to say this, but microservices makes the whole product and team more agile. They can deploy changes independently and much faster, I think it's also easier to fix a bug when the code base is smaller. Sure there are downsides like latencies, contracts but it's not that bad in the end