Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Haha, I'm facing same problem.
After using mongodb once I used it for all of my projects. And someone told me similar thing that you should not try to to fit nosql everywhere but as I still don't have much experience, I think he is totally right and this post too. Hope I will learn much about this things in upcoming months. -
@Salmakis I think pretty much every company out there has done the same with docker. Containerisation has been the buzz word out there which every one wanted to get their hands dirty with. 😄
-
I always like to consider the bigger picture, especially that even in more modern agile-devops driven organisations, someone will still have to support and make sure productions stays up and running
Considering Ops, I tend to standardize on couple of techs rather than re-invent the wheel and use shiny new things every time.
Still good practice to keep testing out things in dev/staging to make sure that truly across the board beneficial tech gets implemented
PS: big fan of micro-services these days! -
@KuMa couldn’t agree more. I am all in for anything that does a value addition in the context that an organisation operates in. The context is the key word there. And it’s a mix of variables, unique to each organisation irrespective of the domain and the market they serve.
The issue is when someone reads a blog post over the weekend, barely scratches the surface of that for less than a week and comes up with a proposal that switching over will solve every problem that is currently out there. -
@a-n00b haha week-end blog post, story of my (product lead) life!!
If all you have is a hammer, everything looks like a nail!
This was something which my tech lead used to tell me when I was so obsessed with nosql databases a few years back. I would try to find problems to solve that has a use case for nosql databases or even try to convince me(I didn’t realise it back then) that I need to use nosql db for this new idea that I have, without really thinking deep enough whether the data in question is better represented using an sql schema or not.
Now, leading a team of young developers, I come across similar suggestions from few of my team members who just discovered this new and shiny tech and want to use it in production projects.
While I am not against new and shiny, it’s not a good practice to jump right in to it without exploring it deep enough or considering all the shortcomings. The most important question to ask is, whether some of the problems you are trying to solve can be solved with the current stack.
Modifying your stack requires more than just a week’s experience of playing around with the getting started guide and stack overflow replies. This is something which need to be carefully considered after taking inputs from the people who would be supporting it, that include operations, sysadmins and teams that are gonna interface with your stack indirectly.
I am not talking about delaying adoption by waiting for long list of approvals to get some thing that would bring immediate value, but a carefully orchestrated plan for why and how to migrate to a new stack.
Just because one of the tech giants made a move to a new stack and wrote about it in their engineering blog doesn’t mean that you need to make a switch in the same direction. Take a moment to analyse the possible reasons that motivated them to do it, ask yourself if your organisation is struggling with the exact same problems, observe how others facing the same issue are addressing it, and then make an informed decision.
Collect enough data to support your proposal.
Ask yourself again if you are the one holding the hammer.
If the answer is no, forge ahead!
undefined
shiny new
decision making