241–250 of 376 posts
Earlier quoted context omitted.
What's wrong with having your infrastructure as code and storing it in Git?
YAML isn't code. Same as your reply, YAML has very little awareness of context.
Earlier quoted context omitted.
What's wrong with having your infrastructure as code and storing it in Git?
Nothing. Even if it's objectively terrible (thousands of lines of templated YAML, or thousands of lines of spaghetti bash), being in Git as code is still better. At least you know what it is, how it evolved, and can start adding linting/tests.
Earlier quoted context omitted.
Define "no one". If you mean small shops, maybe. If you mean large organizations, I haven't seen even one in the last 5 years that wouldn't use them in one way or another.
It was meant to be ironic
Earlier quoted context omitted.
Raw intelligence is of limited help when working in an area that requires lots of highly depreciating domain specific knowledge. Relatively few graduates know their way around the Snowflake API, or the art of making an electron app not perform terribly. Even sending an email on the modern internet can require a lot of intuition and hidden knowledge. > There's over 30 microservices in our org to every 1 engineer I won…
> I wonder if this a factor in making onboarding of new hires difficult? Surely it's because they focused on making onboarding easy? New hires just make a new microservice for every task they get, don't need to know the broader scope just the specs for the service.
For example, a developer asked to change the payments processor from the Stripe API to the Adyen API needs to know about:
1) credential scoping across microservices and test environments 2) impacts on billing, tax management and customer support 3) the organisation's approach to external dependencies (e.g do they use some kind of internal registry)
Microservices don't inherently make this kind of change more difficult. A well isolated payments microservice might even help. But having hundreds or thousands of microservices spread across several code repos makes it quite difficult to figure out how your change will affect other services.
I acknowledge I've picked an extreme example that wouldn't be asked of a new hire. However, smaller versions of the same challenges will happen in the smaller API upgrades & migrations that make up a big part of what the average CRUD developer does.
The new thing is "event driven architecture" (or whatever they can pass off as that hype). In a lot of cases, it's a better architecture. For fhe remaining batches, we are running against S3 buckets, or looking at no SQL entries in a specific status in a DB. And we still use a little SQS, but not that often.
I can offer one data point. This is from purely startup-based experience (seed to Series A). A while ago I moved from microservices to monolith because they were too complicated and had a lot of duplicated code. Without microservices there's less need for a message queue. For async stuff, I used RabbitMQ for one project, but it just felt...old and over-architected? And a lot of the tooling around it (celery) just was…
In my experience monoliths don't reduce complexity, they just shift it. The main issue with monoliths is that they don't have clear and explicit separation of concern between domain concerns, therefore it's very easy for your monolith codebase to devolve into a mess of highly interconnected spaghetti code with time. This is especially true if you're building something large with a lot of developers who don't necessar…
You can achieve exactly the same with simple individual libraries.