If you are testing a microservices "ball of mud", you can (and probably should) setup a testing environment and do your integration tests right there, against real dependencies. The tool seems nice for simple dependencies and local testing but I fail to see it as a game changer.
Interesting. It's my impression too. I understand that CPU limit will artificially throttle CPU, when not necessarily needed, wasting CPU cycles I could use.
(Java programs in my case but I imagine it's comparable to Go ones)
Do you recommend to disable CPU limit? In the general case.
I'm always a bit confused about the CPU limit (for the pod), some guides (and tools) advice to always set one, but this one [0] doesn't.
Ops people I worked with almost always want to lower that limit and I have to insist for raising it (no way they disable it).
Is there an ultimate best practice for that?
I guess it means more modern implementation (rust).
ripgrep is faster than grep, but there are some differences, not exactly the same flags, for example.
If you use grep on big files regularly it worth a try.
- Eclipse type hierarchy view (and quick view) was nice
- Google-Java-Format plugin integration was better
- The default color scheme of Eclipse was better (not sure why but I can't use a dark theme with Java)
But Eclipse had too much strange behaviors where I had to restart it and IntelliJ has those warnings/suggestion about code quality and better auto-completion IMO.
I worked at two big companies in Chile since the last 3 years and I see microservices everywhere, it's huge here, almost a standard right now from my point of view.
We have still some monoliths, like some EARs in some Jboss on-premise but the cloud+kubernetes+microservices trend seems the obvious way to go for everybody.
Those monoliths are minimally maintained, new features go to microservices, and the end goal is to throw them out, it take years though.
It is very likely than microservices are way too small IMO, I've seen microservices just doing an IF, just doing an SQL select, or just adding some credentials in a HTTP header, stuff that could work in one service are sometimes splitted in tens of microservices.
Althought these microservices are Java/Spring Boot or Node/Express ones most of the times, despite the fact that you could potentially use the best tech for each microservice, managers want to maintain a limited tech stack where they can easily find cheap developers, basically Java and Javascript, some Python or Go maybe but not so much.
What strikes me the most is that it seems to work, till now at least, each developer have to maintain like between 3 and 10 microservices, but very simple ones.
Merging two microservices into one never happens.
Writing a new microservice is almost more frequent than evolving an existing one.
Is it a worldwide trend or am I living in a particularly excessive bubble?
We used SumoLogic at my last job, really nice for dashboards IMHO, much easier than Grafana, it's log oriented but works with any structured data you throw at it.
I think it was expensive though.