The article is comparing 2 scenarios that have other explanations: a fire sale of a large fleet and Tesla which has an image problem because of its leadership.
I’m not saying the article is wrong I’d just like to see broader representation (Chevy bolt, lucid air, etc).
Worse than that, the main vehicle it compares everything to is the Model Y. There may have been one or two things related to Tesla this year, and not other EVs, that might have hurt resale values for some reason...
A vocal minority are freedom loving. A significant number are hooked on consumer debt. I feel like any sweeping generalization is going to be wrong… especially when referencing the USA which is basically 50 countries and has a population exceeding all of Western Europe.
> especially when referencing the USA which is basically 50 countries and has a population exceeding all of Western Europe.
Germany is basically 16 countries (federal states [Bundesländer]). Europe is a whole countinent - here a suitable American analogue miht be USA+Canada+Middle America. Or if we talk about the EU, a suitable analogue would be NAFTA (the EU also started as a set of free trade agreements).
And they counted an even lower percentage of Eurasia. It might matter for a given conversation. It might not. What's your point (i.e., what are you actually trying to ask)?
> I am a backend developer using Spring Boot and Java.
If your goal is speed to market use what you know which is Spring Boot and Java.
If your aim is to learn something new then go with Django or sprinkle in some Kotlin incrementally (eg tests). I don’t think it’ll matter in the long run which you choose.
Conflating I want to learn something new with I want to deliver quickly will give you a suboptimal outcome for both.
Feels like a bad point in the curve to try and sell them. “Oh our internal hypecycle is done… we’ll put them in the market now that they’re all worn out.
I find it mildly devious when numbers are inflated by changing the period from seconds to days.
Aeron and NSQ have slightly different design principles. Which can easily be identified in their feature list. Aeron’s origins are exchanges for fintechs and focus on predictable low latency with a tight standard deviation. NSQ puts heavy emphasis on being a distributed broker less message queue. Performance alone probably isn’t a good basis to measure their utility.
we have hundreds of clients most on k8s or openshift. Many of them are shifting to smaller team or division oriented clusters so that they can move at their own pace in consuming capabilities, tools, security practises, etc. It also simplifies distribution of operational expenses, yea there’s tools out there to help with that but it’s a whole lot easier to hand someone a sub-account in AWS and call it a day. Additionally it reduces your fault boundary. It isn’t as sexy as saying you have a 5000 node cluster with 100k+ pods running but it can make life a whole lot less stressful when it comes to upgrades and changes.
So basically, doing to infrastructure the microservices approach?
a) if you're going to intentionally make the trade-off to have higher costs in exchange for reducing ops load and simplifying administration within an account, where services make network calls across accounts, then adopting ECS/Fargate is probably a significant improvement over Kubernetes.
b) The underlying engineering / financial reality is still there and very much a leaky abstraction that will show up on your AWS bill. Cross-VPC, cross-region, and cross-AZ networking costs are very real overhead that you must consider; you either still have centralized network planning with shared VPCs and subnets or you basically decide to give up and let AWS send you the bill when teams create their own VPCs, their own subnets, etc.
c) setting up DNS / service discovery and network controls within a single cluster is simple. Doing so across account boundaries is not, and deciding to set up solutions like AWS Transit Gateway incur their own costs.
I'm sure it simplifies some things for some people, but Finance is going to get upset pretty quickly. Once you start to go down that path, it's very difficult to back out.
Everything’s benefits and tradeoffs. With this model there’s a clear ownership model. I’m not suggesting it’s right for everyone but it is a trend we’ve noticed with a number of clients over the last 2-3 years.
imo you've just traded one set of centralized costs (developing tools, security practices that work for all and educating people) for a distributed set of costs with everyone managing their own clusters and duplicating all this work. You've just pushed the cost onto other teams - which can be a fine approach for reducing the central teams stress, but is net more costly to the business. EDIT: Im not saying its necessarily a bad choice, just much more expensive.
It’s all swings and roundabouts has been since the broad adoption of computers. I expect in a few years time when everyone’s forgotten the pain points that drove them to decentralize there’ll be a big move to centralize again. Someone will get a gold star for coming up with the idea and being able to demonstrate the “cost savings”. Of course it’ll completely ignore the general disruption to all of the product teams as they adapt to the new world order but what’s a company without a little busy work.
Comparing a single function to an entire ecosystem is crazy. Making an LTS imposes a skew of compatibility and support to all downstream vendors as well as the core team. The core team has done a great job on keeping GAed resources stable across releases. Understand there’s more to it than that but you should be regularly upgrading your dependencies as par-four the course not swallowing an elephant every 2 years or whenever a CVE forces your hand. The book Accelerate highlights this quite succinctly.
