4 ms·

You feel depressed about the direction of the industry, but how do you feel about the direction of Java? I think Java and spring boot has improved by A LOT the

by likis 4y ago

You feel depressed about the direction of the industry, but how do you feel about the direction of Java? I think Java and spring boot has improved by A LOT the last couple of years. And I enjoy that direction. We are still running java+spring boot, even though we are moving from on-prem datacenters to GCP. We are moving from VMs to kubernetes/containers, still using java. We are using SQL, but managed CloudSQL databases from google. We are also moving to more asynchronous programming using events with google PubSub. The developers are now responsible for setting up their databases using terraform, aiming for more DevOps. We used to throw things over the fence, but now the developers create their own infrastructure instead of relying on other teams. They create their own metrics and alerts and have a lot better insight and overview of their applications. To me, as a java developer, I think it has grown more interesting, and I feel like I am in more control of my environment. The majority of development is still in java, the business logic is in the java. That won't go away. I'm not sure if my comment is helpful, but I actually like the direction where we are going. Maybe you can try to find the nice parts and focus on those?

jpgvm 4y ago
Direction of JVM, Java and the other guest languages (Kotlin and Clojure mostly) is probably the bright spot of tech right now.
clouded 4y ago
I'm sorry to be negative but people who think like you is what I was referring to. I can't relate to your embracing of us being asked suddenly to do a second job that isn't software development. I don't care about the infrastructure from a setup or configuration sense. It's too much for me. Isn't it enough if I actually manage to be a pretty damn good developer? That's not easy. Why isn't that enough, unless you are the company then you'd love to have me doing the job of two people. I do like where Java is at, that's why I hate AWS. I feel it invalidates the need for Java. Just script to the AWS engine. I could be way off, but I see AWS being what kills Java.
- the_gipsy 4y ago
  Maybe you're not a darn good developer, if you just want to throw whatever code over the fence. Code isn't just a PR in a vacuum, a closed ticket, another class. A good developer knows how their code runs and behaves in the real world, and cares about it.
  - clouded 4y ago
    Good point. It's maybe hard to see when you yourself aren't very good at something. Even harder when you really like doing it.
    - the_gipsy 4y ago
      The downside of DevOps is that you now have to spend time on something that's not writing code. The upside is that you suddenly have a lot more power. You can add and remove pieces of infrastructure without having to get approval and waiting for some other "sys admin" team. Cloud providers are very proprietary and specific in nature, which is very off-putting to me personally. Putting some abstraction over it, like terraform, makes it much less specific. It seems less like "wasted niche knowledge". I have never used MongoDB, just watched it fail spectactularly in other teams. I don't get it. If I know my data structures, relational is obviously the right choice. If not, I won't expect any meaningful document queries either. A simple key/value store should be good, whether that's in my RDMS or something like Redis. Go is just a fresh Java, without all the cruft. Also dumbed down, which is a bit sad, but on the other hand very quick to move around in. I don't get how anybody can stand all the crazy tooling and configuration and setup around Java, Spring, etc.
      - soco 4y ago
        You definitely have more power, you're right. With great power comes also great responsibility, which wasn't there before. Example: instead of the experienced DB guy who was checking the logs to tell you exactly which query goes too slow and what you could do on your side to improve it (and do things on his side to scale the DB better), now you must build the knowledge to do all this properly by yourself.
soco 4y ago
Yeah developers are now responsible for things formerly taken care by professionals in their area. The memory space i could use for better learning my framework is now used to store K8 tricks. The time I could use to fix some user reported bugs is now used to figure out Elasticsearch query parameters so it works properly over shards. No really, I can't imagine why this is such a good thing, diluting the programmer/dba/devops skills.
- likis 4y ago
  I don't see how your example of querying elasticsearch has anything to do with the above. I do agree that it requires the developer to at least understand the basic concepts of kubernetes, if you are running your application in kubernetes. I rather like to think of it that certain things that was handled by other professionals are now managed or automated with cloud technology. Take Google PubSub for example, a message bus with pretty much zero operational overhead. You simply create your topic and subscriptions and it just works. Compare that to running and maintaining a system like Redis or Kafka on your on-premise hardware. As a developer you still need to understand the interfaces of the products you are working with, regardless if it is a database, a messagebus, a REST api or kubernetes.
  - soco 4y ago
    Ok here's the short version: as a programmer I'm also now responsible for maintaining and upgrading all that environment around my program. Which I wasn't before, a time when understanding its interfaces was enough. Can this be denied?
    - likis 4y ago
      For managed products, upgrades are often automatic and there is almost no maintenance that needs to be done. At least that is my impression when running stuff in GCP. For example: * CloudSQL Postgres, automatic minor/patch upgrades, they working on seamless major upgrades. Automatic disk increase. You would only need to make sure that you have enough resources in terms of CPU/Memory. * PubSub, no maintenance or updates required. It is more work to keep java and the related dependencies up to date. We use renovatebot to help us automate things like that. In my experience it is very easy to change and setup the managed products, I declare them in code using terraform and then I don't have to do much at all. This is what is so awesome with the cloud managed products. If you are trying to be cloud agnostic, then you are just treating the cloud as another datacenter, and then you don't really get any of the benefits of using cloud specific managed products. Then you need a professional to keep maintaining your infrastructure.

by likis 4y ago

jpgvm 4y ago

Direction of JVM, Java and the other guest languages (Kotlin and Clojure mostly) is probably the bright spot of tech right now.

clouded 4y ago

I'm sorry to be negative but people who think like you is what I was referring to. I can't relate to your embracing of us being asked suddenly to do a second job that isn't software development. I don't care about the infrastructure from a setup or configuration sense. It's too much for me. Isn't it enough if I actually manage to be a pretty damn good developer? That's not easy. Why isn't that enough, unless you are the company then you'd love to have me doing the job of two people. I do like where Java is at, that's why I hate AWS. I feel it invalidates the need for Java. Just script to the AWS engine. I could be way off, but I see AWS being what kills Java.

the_gipsy 4y ago
Maybe you're not a darn good developer, if you just want to throw whatever code over the fence. Code isn't just a PR in a vacuum, a closed ticket, another class. A good developer knows how their code runs and behaves in the real world, and cares about it.
- clouded 4y ago
  Good point. It's maybe hard to see when you yourself aren't very good at something. Even harder when you really like doing it.
  - the_gipsy 4y ago
    The downside of DevOps is that you now have to spend time on something that's not writing code. The upside is that you suddenly have a lot more power. You can add and remove pieces of infrastructure without having to get approval and waiting for some other "sys admin" team. Cloud providers are very proprietary and specific in nature, which is very off-putting to me personally. Putting some abstraction over it, like terraform, makes it much less specific. It seems less like "wasted niche knowledge". I have never used MongoDB, just watched it fail spectactularly in other teams. I don't get it. If I know my data structures, relational is obviously the right choice. If not, I won't expect any meaningful document queries either. A simple key/value store should be good, whether that's in my RDMS or something like Redis. Go is just a fresh Java, without all the cruft. Also dumbed down, which is a bit sad, but on the other hand very quick to move around in. I don't get how anybody can stand all the crazy tooling and configuration and setup around Java, Spring, etc.
    - soco 4y ago
      You definitely have more power, you're right. With great power comes also great responsibility, which wasn't there before. Example: instead of the experienced DB guy who was checking the logs to tell you exactly which query goes too slow and what you could do on your side to improve it (and do things on his side to scale the DB better), now you must build the knowledge to do all this properly by yourself.

soco 4y ago

Yeah developers are now responsible for things formerly taken care by professionals in their area. The memory space i could use for better learning my framework is now used to store K8 tricks. The time I could use to fix some user reported bugs is now used to figure out Elasticsearch query parameters so it works properly over shards. No really, I can't imagine why this is such a good thing, diluting the programmer/dba/devops skills.

likis 4y ago
I don't see how your example of querying elasticsearch has anything to do with the above. I do agree that it requires the developer to at least understand the basic concepts of kubernetes, if you are running your application in kubernetes. I rather like to think of it that certain things that was handled by other professionals are now managed or automated with cloud technology. Take Google PubSub for example, a message bus with pretty much zero operational overhead. You simply create your topic and subscriptions and it just works. Compare that to running and maintaining a system like Redis or Kafka on your on-premise hardware. As a developer you still need to understand the interfaces of the products you are working with, regardless if it is a database, a messagebus, a REST api or kubernetes.
- soco 4y ago
  Ok here's the short version: as a programmer I'm also now responsible for maintaining and upgrading all that environment around my program. Which I wasn't before, a time when understanding its interfaces was enough. Can this be denied?
  - likis 4y ago
    For managed products, upgrades are often automatic and there is almost no maintenance that needs to be done. At least that is my impression when running stuff in GCP. For example: * CloudSQL Postgres, automatic minor/patch upgrades, they working on seamless major upgrades. Automatic disk increase. You would only need to make sure that you have enough resources in terms of CPU/Memory. * PubSub, no maintenance or updates required. It is more work to keep java and the related dependencies up to date. We use renovatebot to help us automate things like that. In my experience it is very easy to change and setup the managed products, I declare them in code using terraform and then I don't have to do much at all. This is what is so awesome with the cloud managed products. If you are trying to be cloud agnostic, then you are just treating the cloud as another datacenter, and then you don't really get any of the benefits of using cloud specific managed products. Then you need a professional to keep maintaining your infrastructure.