81–90 of 140 posts
Don’t have dozens of micro services. This is a serious comment.
Earlier quoted context omitted.
I'm a midlevel dev at a large company. I don't even have access to make a presentation to the true stakeholders. I can only make suggestions to my lead/boss and have them move it up the chain. On a side note, I've tried moving up th chain when I felt appropriate, but apparently a SQL injection vulnerability with full schema level privileges that was not being prioritized for remediation was not important enough to wa…
Meta comments tend to get downvoted. Try editing the complaints out?
Earlier quoted context omitted.
I'm a midlevel dev at a large company. I don't even have access to make a presentation to the true stakeholders. I can only make suggestions to my lead/boss and have them move it up the chain. On a side note, I've tried moving up th chain when I felt appropriate, but apparently a SQL injection vulnerability with full schema level privileges that was not being prioritized for remediation was not important enough to wa…
Time for a job change? Lots of red flags.
Earlier quoted context omitted.
I don't build microservices anymore. All of the reasons listed in this thread tend to cause bottlnecks. I aim for domain services. Define your domains, and build a program to service it.
That's microservices. Microservices handle a bounded domain. At least in traditional advice for splitting microservices. The microservice provide an api for that domain.
If you need to keep track its probably too late. What makes them services is that they should be able to be deployed without a bunch of orchestration of other services. You can solve this by having backwards compatible apis. That said, to know what changes would actually break things you'd ideally have a suite of tests.
True, but you absolutely should still be versioning/tagging your releases for each service. It's not to provide sophisticated orchestration; but just to know each of your releases and be able to roll back to them.
Also I'll point out that some loose coupling between services is unavoidable even in the best case scenario. Sometimes breaking changes happen, or new features need to be taken advantage of. This necessitates some level of (perhaps ad-hoc) "orchestration." If you add a new feature to a microservice and rely on it elsewhere, there's an implicit dependency to that version (or later) of the microservice now.
Feel free to ask question or reach out :)
Earlier quoted context omitted.
One "wisdom" I hear is that the benefit of microservices is organizational: One microservice per team, so you cut down on intra-team friction, and the team can manage their own releases.
What people miss is that micro services/SOA is an organizational concept more than anything. At Amazon, SOA is tied to the concept of the two pizza team. Each 2PT completely owns a collection of related services, owns the roadmap for those services, and can make deployments independently of any other team. If your company doesn’t have enough engineers to justify at least say 5-10 scrum teams then you might not be lar…
Earlier quoted context omitted.
Right now I don't think microservice management is 'viable' even at larger companies. The custom deployment scripts & yaml to manage building, package/artifact repository, versioning, and deployment tends to be Too Damn Big, at least at the shops I've seen.
Oof. I haven't seen micro services much but, what I have seen makes me wonder what value people are actually expecting to get back. I hope the next iterations of this idea work better.
I don't keep track. All microservices use continuous deployment pipelines. If you check in code and it passes all the tests, it will make it out to prod some time in the next few hours.
Do you ever release serious errors into prod?
The idea of deploying every commit all the way to prod is is very questionable.