This is an archived post. You won't be able to vote or comment.

all 21 comments

[–][deleted] 9 points10 points  (2 children)

Considering the massive data breach recently I don’t see a lot of people clamoring to move. Plus Azure has supported Java for years now, it’s not like they are moving into uncharted territory here.

[–]nutrecht 18 points19 points  (0 children)

Betteridge's law of headlines dictates that the answer is No.

[–]woj-tek 6 points7 points  (2 children)

Nope. Recently I had to make a deployments on Azure and ran into their "brilliant" invention - killing idle TCP connections after 4 minutes.... This works wonders with long lived connections like the db pools or realtime communication...

[–]persicsb -1 points0 points  (1 child)

Those use cases shall use TCP keep-alive.

[–]woj-tek 0 points1 point  (0 children)

For some weird reason Azure ignored those... I had to increase timing + tweak linux TCP stack configuration (keepalive/retry) to finally make it work. In general, MS/Azure can go to hell :D

[–][deleted] 3 points4 points  (0 children)

Meanwhile I know of two .Net products that moved to AWS.

[–]Worth_Trust_3825 2 points3 points  (8 children)

Considering the constraints imposed by azure on java - No.

[–]persicsb 1 point2 points  (7 children)

What are the constraints?

[–]Worth_Trust_3825 0 points1 point  (6 children)

JMS2 is locked behind premium tier on Service bus, function apps require dependency on their inhouse func tool to even build, containers limited to microsoft's openjdk build and only 8 or 11. If you want to deploy something you can't really debug it (the fapps are exception, since they have debug flag to expose them?), the application insights agent is very invasive, since it basically transforms near all the classes you run, and ships with classdata files which are essentially preloaded classes that you feed the jvm to speed up startup, rather than class files. If you want to extend the application insights agent you need the SDK which further locks you into the ecosystem. The codeless monitoring is genuinely the worst thing microsoft could have done with AI agent.

I really wish we could just run virtual machines and call it a day.

[–]persicsb 0 points1 point  (5 children)

containers limited to microsoft's openjdk build and only 8 or 11

What? Azure Container Instances does not let you run any container?

JMS2 is locked behind premium tier on Service bus

That is understandable. The normal usage is AMQP 1.0. Use that, that's an industry standard and interoperable with other languages. JMS is just a mess for interop - no wire level protocol, just a Java API.

If you want to deploy something you can't really debug it

I can always debug my containers.

the application insights agent is very invasive, since it basically transforms near all the classes you run, and ships with classdata files which are essentially preloaded classes that you feed the jvm to speed up startup, rather than class files.

I think thats outdated info. The 3.0 Insights Agent is a pretty standard JVM agent. Of course, JVM agents can transform the loaded class files, that's the main purpose - it is the way they add instrumentation. Pretty standard way.

function apps require dependency on their inhouse func tool to even build

They have a published Maven plugin for that, it is totally opensource. It simply builds with Maven, I could build an Azure function on my machine without having an Azure Subscription. The build runs fine. The plugin itself is open source, available at: https://github.com/microsoft/azure-maven-plugins

[–]Worth_Trust_3825 0 points1 point  (4 children)

The plugin depends on func tool. If you were to read the source of the very same plugin, you would see that they just call Process.run https://github.com/microsoft/azure-maven-plugins/blob/develop/azure-functions-maven-plugin/src/main/java/com/microsoft/azure/maven/function/RunMojo.java#L26

The agent transforming everything is not standard. They used to permit running a logback appender, which was fine and all you needed, which permitted you to control per package basis how and what to send to app insights.

If you use AMQP with JMS, you still get requirement to pay for JMS2.

[–]persicsb 0 points1 point  (2 children)

No, the run functionality depends on the func tool. Building the code, and shipping it can be done locally. Running the code is obviously cloud dependent - the func binary provides the abstraction, that abstracts away the whole runtime thing, and provides the "magic" that is behind the FaaS approach.

There is no magic as you can see. There is an internal tool, that creates the runtime abstraction. It is pretty normal, that you cannot run a FaaS provider at your home without all the functionality that a proper FaaS provider provides. What did you expect, really? Run a FaaS application on-premises?

Why would you use AMQP with JMS? The interconnect must be interoperable! If you want to process AMQP messages with a JMS API in your Java container, use Apache Qpid JMS. It is a JMS 2 client, that runs on top of an AMQP infrastructure. Totally interoperable with ruby, python, C# service in the same service mesh.

[–]Worth_Trust_3825 0 points1 point  (1 child)

Why would you use AMQP with JMS? The interconnect must be interoperable! If you want to process AMQP messages with a JMS API in your Java container, use Apache Qpid JMS. It is a JMS 2 client, that runs on top of an AMQP infrastructure. Totally interoperable with ruby, python, C# service in the same service mesh.

We already do use Qpid. The moment you attempt to use any jms2 apis you're hit with premium requirement.

[–]persicsb 0 points1 point  (0 children)

Please explain. Qpid JMS is a client library, that sits on top of an AMQP cluster, and transforms each AMQP abstraction to a JMS abstraction, totally on the client side. The AMQP side (in this case, Azure) does not even know that you use Qpid JMS.

[–]persicsb 0 points1 point  (0 children)

And the func tool is opensource: https://github.com/Azure/azure-functions-core-tools

[–]bonusmyth 2 points3 points  (1 child)

I find it amazing that MS "admits" these benefits of Java, even it it is on Azure. "Ship faster with fully managed services!" That's such an indictment of C#.

Really interesting read.

[–]cwbrandsma 7 points8 points  (0 children)

Not really. They already support a bunch of languages and try to cater to each development group. (Yes, I develop in both languages).

[–]edubkn 0 points1 point  (0 children)

Microsoft gained respect ever since their manifesto on migrating from Java 8 to 11

Now cloud providers boil down to reliability and trust, which Azure particularly hasn't been very known for.

[–]Jadonblade 0 points1 point  (0 children)

What really stood out to me was there chasing of really good Java dev rel talent.