2016: Top trendy IT words/phrases that drive me crazy > stdout.in Ievgen Kuzminov IT blog

2016: Top trendy IT words/phrases that drive me crazy

Apr 12, 2016, 10:35:07 AM
  • In The Cloud
  • Microservices
  • Node.js is enterprise ready/backed
  • Rails Ways / It is by Default in Rails

What started a short list became quite a big description, more details inside the post.

In The Cloud

Strange, but "in the Cloud" means "on server in Internet" for me. Marketing meaning of the "cloud" degraded any value of these words nowadays. There is no just a simple "hosting" anymore - only "Clouds". Cloud became a synonym of Unlimited and Unbreakable: storage, capacity, etc.

Do you know my biggest disappointment on AWS in those early days it appeared? It's when I got that I am just provisioning a VPS. And those super scaling and stability is just ... what I can EVENTUALLY get with these services.

"Cloud" is not just running a Docker container inside VPS (and don't think it is strange to run virtualization inside virtualization?). "Cloud" can not make you unscalable web app "scalable". All "silver bullet" solutions requires your app to be written specially for this solution. You will need to pay the cost anyway. Cloud is making a world of Servers a little bit easier and automated. That's it.

Microservices

The idea of Microservices is walking through dev community for recent years - to create a small isolated single purpose services. To keep the whole "Zoo" more stable with independent releases. But for some reason Microservice became a synonym to Docker - Linux Containers. People think that they can just put their "Majestic Monolith" in Docker and they'll get Microservices. But Docker introduces the whole new layer of issues - to maintain Docker cluster stability (plus bare Servers stability). Going further - add Service discovery layer.

But there is still no clear understanding how to make Microservices and not to kill the performance.
Till that time I haven't found any clear description how to handle shared data between the Microservices. There should not be shared data? Agree! But for example all parts of the system needs user info. Posts, Comments, Message etc. that all could be a separate Microservice, but to show them we need to Join user info. Should I do via REST service request and manual mapping or shoud I break an isolation and allow to access users DB all the services?

Another issue is REST API obsession for Microservices. How to communicate – of course via API. Let's waste CPU resources and time on serializing/deserializing all the way! Why not?

Unfortunately yes. It seems that Microservices idea got it's initial implementation in totally wrong way. While Erlang has the solution for about a 20 years with OTP. That solves all issues of maintaining processes stability and recovery, service discovery, removes the need of serialization.

Node.js is enterprise ready/backed

It's is really not so bad, but...

About 5 years it was in 0.x version. About 2 years dev community was separated on Node.JS and IO.JS. Ecosystem just crashed because of one unpublished package. And that's not all things to count yet.

With all respect to things that became real thanks to Node - like great JS building tools, Electron and Atom, really cross-platform tools and apps. It takes so much efforts to push it forward and to keep stable what is already done, that personally I have a big doubts as for the "enterprise" future. As an applied tool - Node.JS is perfect, but it still doesn't seem to be relevant stable investment. At least as a general purpose server side language. Node definitely has it's niche, but newcomer languages like Go and Elixir has much more to aim modern server side challenges in more stable and predictable fashion.

The only fact that big-old companies like IBM are investing in Node.JS companies (like StrongLoop) is not making Node.JS much more reliable. It is just one of numerous investments of Giants to keep in touch with modern shiny things.

Rails Ways / It is by Default in Rails

Making a technological choices like CoffeeScript, SASS, RSpec, etc. with the single motivation - "because it comes by default in Rails" seems more than strange. No, I have nothing against most of these technologies, except of one thing - It should be a thoughtful choice. The path of trials and clear understanding.

Explaining some technical decision in RoR app by "Rails Way" looks for me as acceptable as apology of a criminal due to "Original sin". It just doesn't work that way, at least in a modern society. In the same way we can't just blindly follow any Rails way. More over if you do some architectural decision or rather "not doing any architecture except MVC" (hm... do you know that MVC is not an architecture? :) ) it can't be motivated by "just because it is so in Rails by default". Come on, turn on your own brains! Take a critical eye on what are you doing and why.

comments powered by Disqus
Ievgen
Kuzminov "iJackUA"
Web Team Lead
at MobiDev (Kharkiv, Ukraine)
Code in Ruby and Elixir, but still love PHP. Explore ES6 and Vue.js. Explore databases, use Ubuntu and MacOS, think about IT people and management

Notes


Gor tool for capturing and replaying live HTTP traffic into a test environment in order to continuously test your system with real data. It can be used to increase confidence in code deployments, configuration changes and infrastructure changes.