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.

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.

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?

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.

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

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.

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.

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 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.

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.

I don't think it has ever been enough to JUST look at the java. You said you were pretty good at SQL, so you must think about the performance of your queries, what indexes you use and such.

You can try to improve your java performance as much as you want, but if your database can't handle the load, then you need to look at the database. In my opinion it is NOT enough to look at just the code, you need to look at all of the parts of the system.

Just declaring that you want a database instance in code, using something like terraform should not be an overwhelming thing. Most of the management would be handled by the cloud vendor, you would just need to make sure that it has enough cpu/ram for example. There are probably even easier products where you just store data with some kind of API and you don't even need to bother with the performance of the data store.

But if you just want to write your java code and not care about anything else... Then yeah, maybe the direction of the industry is not aligning with the direction you want to go.

I love relational databases. I think they are among the greatest products to come out of the entierty of computer science, ever. You're right, I do care about application performance and index tuning and query optimization. But it would make no sense to ask me to be a DBA.

What would the role of the DBA be if you are the one creating tables, tuning indexes and optimizing your queries?

I thought about how to reply to this, but database roles vary so differently from company to company, it's a bit of a rabbit hole to go down. Whether you call what I described being a DBA or not, I don't think it's reasonable that a software developer would now "own" the database and all that entails. It just so happens that the database fits nicely into being "owned" and managed in AWS. And it also may neatly obviate the need for the DBA role. Although, I think that's debatable too.