Need some advice, feeling depressed about the direction of our industry
We all know technology constantly changes and progresses, and I've always thought that's fine, I'll be happy to learn whatever replaces Java because it will be better, right? I've seen Go coming along, Kotlin too. But I've been hit like a brick in the face to realize where we're headed. AWS. The cloud. I'll get to the point. I hate it. I've seen it happen personally at two companies now. The transition to the cloud. Where we throw away everything we've spent years learning to reinvent the wheel. We throw away relational databases for MongoDB. I love SQL. I'm good at it. But no one cares. MongoDB is "in" now. I'm good at Java. Years of experience and I finally feel good in my abilities and speed with the frameworks, ORM's, best practices, etc. We're just throwing it out like it's nothing. For AWS products. Lambdas written in Typescript (why Typescript, I don't know, the same reason I don't know why MongoDB). Files of YAML configuration, and Kubernetes and a lot of other things I don't care about, just to create the same CRUD apps we've always been creating.
I've been buying power tools and learning how to use them. I've started taping and patching drywall. I've cut down trees. I want tools that won't change every 5 years. I want tools that I can master and will be relevant in 50 years. Maybe I'm too old to be a carpenter, or tradesman. I just need some advice. The worst thing is, developers are embracing this AWS trend and seem to love it. No one seems to mind. Software engineers are cursed. Just when we've established a best practice and it's a solved problem, we throw it out and reinvent a new way to do it.
Please let me know if I'm not alone, or if it's just me and I need to adapt or get out of the way. I will predict this though: AWS is a mistake. It's not fun. It's not "software engineering" and it won't be here in 10, 15, 20 years. All your mastery of Kubernetes will be for nothing. It will be tossed aside like trash. And the worst part is when that day comes everyone will act like it was never that great all along. They'll also embrace the next trend like it's the greatest thing ever. Because software engineers are cursed.
131 comments
[ 5.3 ms ] story [ 221 ms ] threadAs much as I love setting up single instances and deploying directly on it, it does not scale and the quality of the deployment is very dependent on the developer. The quality and even existence of documentation for the same too.
And the reason is indirection. They are two layers away from the business, shielded first by product people, then by product developers. As a consequence, they live in a bubble where nothing matters except a good starter repo or a new standard to push onto all the recalcitrant idiots that work on _products_.
You are right about one thing though, I've seen enough undocumented deployment crap held together by hot glue prone to cause the next incident whenever someone hits the wrong button that my relationship with developers that dabble in ops is at least somewhat adversarial.
Note that this is different from developers that have a need they don't immediately know how to solve (and is not covered by a platform team) and either ask an architect (those are different from platform for us, by the way) or invest the time. That still often leads to cognitive overload or eternal temporary fixes, but it's still better than "why do you care, it works, I only had to punch 10 holes into the firewall and commit one service account key to git" type developers.
This core team was busted after a few years, its head fired and replaced by an oppressive junkie that started spewing corporate standards and imposing frameworks with the speed of an office printer.
You really have to have a special mindset to be willing to join a core team, and this mindset is opposite to what people that deliver a working product have.
There is a reason why "premature optimization is the root of all evil" is the motto of many generations of programmers. From their perspective, core teams are personified evil, because their only purpose is to optimize, prematurely.
We then eventually rewrote the platform from an "everything is implicit" approach (branch leads to deployment with stable URL x, logs end up at Y, metrics get scraped at Z) to "everything is explicit but we have a second component that emulates the old way unless overruled". Nothing changed for developers, except that they got a lot more levers.
Then that company was merged back into the mothership (it was a "moonshot startup make an online shop for us" kind of company) and everyone there that could be enthusiastic about technology was excited about the stack, considering they were stuck in the 2000s before. The tech turned out to be flexible enough to accomodate the needs of modern Scala/Node services and legacy PHP alike (with the help of a base image that included a little go proxy to add standard HTTP metrics).
Unfortunately there was a change in leadership to someone who wanted to essentially recreate a tech stack they had used elsewhere. Akamai to Cloudflare, AWS to GCP, Slack to Teams... unilaterally. The team imploded within a year and a large Kubernetes vendor came in to get developers on "standard tooling".
As far as I can tell, 2 years later, our infrastructure survives though. We built it pretty tough and I guess none of the other "standard tooling" solutions really fit. The vendor even ended up asking if they could open source the system. Unfortunately nobody in legal cared enough to figure that one out. I'd have liked it to survive somewhere.
It's a very unique story of a platform that actually evolved mostly organically, and I realize that most attempts at platforms don't work that way. I always try to take learnings from this into new attempts, and it has been working pretty well. Getting someone from platform to work in development teams is probably the most useful thing I'd recommend.
There are two types of problematic teams in these companies. Those that never want to change anything, and those that chase new technologies for the sake of it - maybe they want to learn something relevant for the future. If you're unlucky, your leadership is too far in one of these directions too.
I can, for instance, tell you that Kubernetes is a worthwhile investment if you're large enough and you never have to touch 99% of it. People often get it wrong and throw a kubernetes endpoint at developers and then wonder why there's cognitive overload and everyone just does the most minimal thing that works without taking any advantage of the new environment.
There are plenty of places that do Spring now and manage to let developers do the things they're good at without constant interruption. You just need to find one. You also may need to learn Kafka, since that is where most of the data in large constructs ends up in now.
https://news.ycombinator.com/item?id=31790226
Greed is taking over.
I've heard some interesting takes in sister companies. Just a few months ago someone explained how continuous delivery is a pipedream and nobody does it because it's unfeasible, but they would like to not have every release (literally) signed off by management. I guess my work in the past 4 years was all a lie.
Look, the alphabet soup of technologies that we read about here on Hacker News don't really represent the reality of what gets put into production and actually works. There are really only about four or five stacks that really matter, I'll leave it as an exercise for the reader to figure out which ones they are.
Relational databases are the result of 50+ years of computer science research. They're beautiful, focused, precise. They're pretty damn close to perfect. They are a solved problem. They're one of those few stable tools I was talking about wanting so badly. So what do we do? Throw it away. I'm too disgusted to continue.
also, jobs that aren't about doing cloud stuff config do exist, if you really dislike that, you can change jobs (unless you can't? what with financial stability, depending on your situation)
if you're skilled at programming, even if you've only ever used one language, you should be able to program in another, you might not be as skilled as your preferred language, at least initially, but that shouldn't be a problem in the long run
I don't know how to fix it because it seems like an industry wide problem, a very deep cultural problem that absent some outside force will not change. Just as a note, the curse was called "CADT" by jwz back in the late 90s to early 2000s so it's been a part of the industry for a while and likely won't dissipate any time soon.
But there are also other technologies that have their merits. I understand that you find it frustrating to look at them and you feel like it's a huge wall to climb to also learn these technologies after you have invested so incredibly much time in mastering the Java ecosystem.
My advice to you is: Don't stress out over it. Explore these other technologies without having to think about how you will use them in your professional life. Take away the pressure and focus on the enjoyment of learning something new. Eventually you will learn enough for it to be useful. And as stated previously: The Java ecosystem is not going anywhere.
You might also want to check out Clojure. It's a very different language but it uses the Java ecosystem, so you will still feel at home. https://clojure.org/
ClojureScript -> React Native
ClojureDart -> Google Dart
Clojure -> GraalVM
Four if you consider Unity via Arcadia on Clojure's .net implementation
Most businesses I come across use React Native via CLJS
What makes development 'worse' today I think, is much more of it is just integrating with myriad other systems, tools, etc, which can be dull and frustrating, and I'm sure no-code will just make it much worse.
And then there's scrum.
What has changed is that the complexity required of software has vastly increased. And perhaps there's an argument that the tools and languages have not kept up.
But try developing anything today with an old version of any language or tools, and it's not better, else obviously that's what everyone would do.
However I would add that sticking to one technology stack for your whole career is probably just not possible in today's environment. There's still plenty of places that are using Java, but they won't be the cutting-edge startups. Frankly, you may not want to work at a startup anyway, the pay is lousy, the equity is usually worthless, and job security is low.
I encourage you to methodically look at your skills, which Industries and segments they're valuable in, and what you need to learn going forward depending on which segment you end up focusing on.
"Lambdas written in Typescript [...] Files of YAML configuration, and Kubernetes and a lot of other things"
Building my next side project with https://www.radicalsimpli.city/
Sure there is lots of rubbish out there.
You probably shouldn't touch Lambda with a 40-ft pole, Go is mostly just C v2, Node.js will make you question the life choices that led you to using a jank scripting language on a server. MongoDB don't even, just no.
However not everything in the last ~10 years is useless. AWS EC2 and S3 are awesome services. k8s is actually good, assuming you have competent administrators (otherwise stick to GKE, or EKS if don't have ability to go to GCP).
There is nothing wrong with building a modern Java app on k8s and PostgreSQL. You might even come to like the standard runtime environment that k8s provides. It integrates fairly nicely into the Spring way of doing things. You can also do containers in Java better than pretty much any other language, take a look at Google's jib tool.
I think k8s (or something like it) is here to stay because it transitions to the runtime to be declarative. i.e it's the SQL to the Mongo-like (not entirely true but close enough) in the infra world.
Cheer up mate. You will find places/people that respect your knowledge and aren't rushing to upend good solid boring tech for no reason.
My advice would be to find whatever motivates you in your life. What makes you happy? Challenge yourself and everything you've got.
There actually hasn't been any real trend away from current tech since about 2015. People are still using the same TypeScript/Node/Python/Go and GraphQL/MongoDB/Postgres stacks, still using Docker/Kubernetes, and still using React/Vue for frontends.
The trend towards cloud-based services was also started around 2015. People are still using Heroku despite it largely being considered stagnant. Cloud services like AWS are just more convenient for teams that don't own hardware.
I don't see any of this tech going away or being replaced because I don't think anyone can think of any better abstractions right now. Hardware and platforms would have to fundamentally change in order for software engineers to start thinking up new ways of abstracting them. Current tech stacks will of course be endlessly tweaked and "improved", but I don't think anything major will change for a long time.
The newest thing that I can think of is just a CSS class library called Tailwindcss. That's literally the only change in my basic stack in the past few years.
I also don't believe any core tech is being thrown out. As others have said, the initial excesses of the web tech whirlwind are receding back quite a bit.
Perhaps it would be good to get more into the theory of the algorithms rather than specific implementations.
It is why computer science undergrad education does not emphasise programming as much as the theory, in 50 years the theory will stay.
I can recommend you to watch YouTube videos and watch people like Alan Kay (watch all the videos), Hal Abelson, Jerry Sussman and others pioneers of our industry. You should quickly notice that what we have now is a local maximum of some trends and much much more is waiting to be (re)discovered.
Hint: AWS and K8s are poor attempts to create real Object Oriented system. There will be much more like them in the future, but of a higher quality and based on some real rules, not accidental connections with HTTP messages.
But isn't that slowing down?
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?
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.
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 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 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.
* 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.
Software engineering isn't just knowing the tools, I think it's also seeing the patterns. Consider a queue. It doesn't matter if you're using Kafka or SQS or a jobs table in PostgreSQL read by a monolithic application, you're still going to wrangle with similar concepts: dead-letter queues, at-least-once delivery and idempotence, updating the schema of your in-flight messages, timeouts and retries, transactional all-or-none message delivery, large replays if your consumer went down, physical capacity running out. Knowledge around these problems won't expire, although it might become more niche or less useful.
I don't think AWS is a particularly loved ecosystem, it's just a well bundled set of tools.
On the other hand cloud architects or whatever are like a modern day Pied Piper with so-called visionaries following them and burning money until their business runs out of runway. Once they realize they should have spent way their resources on diversifying their partnerships and creating a non shitty product instead of investing a gazillion on splitting a smelly monolith into 13 smelly parts, it is often too late.
Have a plan B at all times and you'll be able to sleep well.
I thought Java was bullshit, it's basically just some strange dialect of C running on a poorly written virtual machine. Everything you wrote was dog-slow. (I can't remember if the security problems were there from the beginning or were a 2000s thing.)
I was sure it was a passing trend and in 10, 15, 20 years it won't be there. And - compared to the great fanfare and hype of 1999 - it really did quiet down A LOT since then.
I hope this helps at least with some perspective. I agree with you that "the cloud" is a dead-end. I wish you the best of luck.
Really? I feel like it's the inevitable meta...
Too many stakeholders, from users to companies to governments, have their interests aligned in using cloud tech, and the biggest barrier to viability for any application is bandwidth.
But I hope you're right since I would consider using some hypothetical cloud OSaaS dystopian. :p