Swe. Company infra unproductive. Is it just me?

So my company recently moved to SOA, and since then my existence as a product engineer has been just aweful. Instead of building features, I'm building service infrastructure outside my domain of expertise and interest. Our mesh infrastructure is a mess -- to dev I run multiple services and my computers cpu usage consistently idles near 90% since we run our services w/ docker. Documentation is scarce, often found only in slack public conversations. Question: is this normal? Is this how it just is to be a swe in the year 2020? My friend at Amazon tells me they're experiencing the same thing where ~half of dev time is spent dealing with infra. Am I justified in wanting to jump ship over infra or am I being a spoiled engineer who will experience the same story at any company I go in 2020? Only full stack / backend feature engineers need reply to the below poll

Poll
39 Participants
Select only one answer
Freddie Mac fredmac Jul 21, 2020

Wow you have public slack channels with useful information? And you can run stuff locally instead of having to deploy to a dev environment?

Better Mortgage thiccest Jul 21, 2020

We have a lot of the same pains. Microservices are necessary because at some point you can’t just keep stuffing things in the monolith, but people underestimate the cost of running additional services. As a system grows and becomes distributed the ops load is gonna grow, and it’s challenging to automate away pain points and it can become idle tech debt easily. You can quickly begin drowning in integrations/network calls/dependencies every time you want to make a change. There are ways to deal with the shitty dev process like isolating changes as much as possible with good mocking. Or letting dependencies resolve to the service running in staging so you don’t have to spin up locally. Depending on the change you’re making there’s probably gonna be some point where you’ll need to run multiple things and integrate, but you can minimize the pain at least.

New
orderby Jul 21, 2020

it's normal. especially when companies first break up their monolith. some companies are better than others though. working at a startup right now that proactively invested in dev tooling before it got bad. local dev env is in kubernetes. takes <1 hour to set up and only breaks every other week. still a resource hog though. that's the best i've experienced. i wouldn't say it's worth leaving a company over poor dev experience, but it's definitely something to ask about in interviews. poor dev experience can be a sign of underlying architectural problems, or a lack of respect for engineer time, or both.

Amazon ugkr404 Jul 21, 2020

Have come across such scenarios in my previous startup, we were initially using containers to spin up all the services locally. Luckily we quickly realized that this would be a huge resource hog, and created separate dev instances of all services which can be connected to from local service instances

Procore 5bananas Jul 21, 2020

Others have said it, I will repeat and add more: it’s normal, especially at companies breaking up their monolith. Similarly, it’s normal when working on green-field projects. Things will get better as the infra is setup across-teams. Internal DevTool / SRE teams/members typically bring together and/or create shared dev environments and other tools to make your life easier AND your applications’ resource management more effective. I suggest you read (or listen to) The Phoenix Project, The Unicorn Project, other related material. They’re entertaining and relevant.