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
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.
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.
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
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.
Tech Industry
9h
1458
How can my idiot brother who does real estate afford this
Tech Industry
Yesterday
1044
Be nice to H1B people
Today I Learned
Yesterday
1231
My understanding of the Holocaust was incorrect!
Tech Industry
10h
2038
Are tech workers as rich as they think we are?
Tech Industry
Yesterday
353
If you had the choice between two
Wow you have public slack channels with useful information? And you can run stuff locally instead of having to deploy to a dev environment?