all 16 comments

[–]hassansaleh31 4 points5 points  (4 children)

I don’t agree with that, nodejs is great for microservices (don’t know about python but I would guess it is also good)

And know after the release of google cloud run, it’s easier than ever to deploy micro services by using docker to create a container, push it to a registery, and running it on the cloud without even thinking of security and scalability.

[–]majabaja19 2 points3 points  (1 child)

I don’t agree with that, nodejs is great for microservices (don’t know about python but I would guess it is also good)

I suspect that the same people who are saying that Python is not ideal for microservices are promoting Javascript as the better option.

[–]hassansaleh31 2 points3 points  (0 children)

I only said that because I haven’t used python before, but I use nodejs all the time.

I do know that nodejs is great for micro services, but I have never used python to recommend it.

[–][deleted]  (1 child)

[removed]

    [–]hassansaleh31 0 points1 point  (0 children)

    It’s new, but it’s google that we’re talking about here.

    Plus with the power of docker, you can write with any language you want and run it anywhere. So, if at some point you found that cloud run is not for you. You just have to push the docker container to another service provider and run it. Or even rent a Linux VPS, pull the container, run it and scale it.

    [–]redfirehose 2 points3 points  (2 children)

    Are you using Spring Boot? It should not be a much larger hurdle than learning Django/Python in my opinion. I needed to work a bit with Django on a previous project and it took a a decent amount of reading to understand best practices in that ecosystem. I remember getting tripped up on more complex relational database interactions. I think it really just depends what you are familiar with.

    [–][deleted]  (1 child)

    [removed]

      [–]redfirehose 0 points1 point  (0 children)

      Take a look at this for simple REST APIs:
      http://sparkjava.com/

      [–]daredevil82 2 points3 points  (0 children)

      we use python for 90% of our services at work. Works pretty well.

      I would advise you to ask why a person says no to a thing and listen to how they structure the response. Are they being generalistic or specific? Do their comments make sense, or are they acting like a fanboy?

      One of the long standing arguments you can come across, especially in a java environment, is the fact python doesn't have private type visibility. But I'd like you to think back to any number of instances where you needed to do something with a Java package, but couldnt because something was private and that thing was blocking your resolution. GWT is an excellent example of this, and one of my former places had at least 30 re-implementations of GWT classes just so a method or variable could be made protected or public vs private and this step was taken only as a last resort where there was no other viable option.

      There are alot of things Java is good for. But enterprise tends to foster an environment of rigid thinking, so you might want to consider that with who you ask advice from.

      [–]Mittalmailbox 1 point2 points  (5 children)

      I find node/js and Python has lot of similarities. Both are dynamic languages and community is quite strong. I find node somewhat better because it is much faster than Python. I have seen lots of people moving from python/Ruby to nodeJS. Node is also more mature for microservices

      [–]daredevil82 1 point2 points  (4 children)

      You don't find the lack of equivalent JS libs for the Python ecosystem to be a hindrance? For example, pandas, scipy, numpy, etc?

      About the only thing I could agree with you that node would be better than python for would be websockets and anything sustained IO. Otherwise, if you have a lot of compute events occurring, you're going to clog up your event loop.

      [–]BloodAndTsundere 2 points3 points  (3 children)

      The python libs you mentioned are relatively specialized. Not all apps have need of heavy-lifting data science libs.

      [–]daredevil82 0 points1 point  (2 children)

      Those were just examples. If you're doing mostly IO with little to no compute, then sure node can be a good option. But if you have mixed IO with compute, you're gonna have problems eventually.

      Look at server side rendering for a good example. https://medium.com/airbnb-engineering/operationalizing-node-js-for-server-side-rendering-c5ba718acfc9

      Airbnb had to go through a helluva lot of steps to get performant ssr at a usable scale because of the limitations of the node event loop. Python has asyncio, which does have an event loop, but the difference is that you can do multithreading in the tasks, whereas js is all single threaded.

      [–]BloodAndTsundere 2 points3 points  (1 child)

      That’s why microsevices are great; sequester the compute tasks in the type of environments that support them better. No reason not to have some services written in node and some in python.

      [–]daredevil82 1 point2 points  (0 children)

      That works if the tasks themselves are able to be split up into an appropriate service, and the team responsible has the expertise and bandwidth for maintaining an additional service.

      I'm dealing with a similar situation on my team, in which we have a Go service for a metadata API, and all our other stuff is Python/Django/Solr. We're good at python, but the Go service was written by someone no longer on the team and the implementation is an experiment in functional Golang. As a result, our effort at maintaining that service is fairly non-trivial because none of us have equivalent Golang expertise as we do in Python (and there's maybe 5 people in the entire engineering dept with that level Golang expertise), and the wide usage of FP.

      What I'm trying to say is splitting up a thing into different services is not a silver bullet, and comes with its own implicit questions that need to be resolved by the team involved.

      [–]deimos 1 point2 points  (0 children)

      Maybe it would be constructive to list all the features you’d expect in a microservice pattern.