Live data from Hacker News

New Grad vs. Senior Dev

ericlippert.com

371–380 of 392 posts

Re: New Grad vs. Senior Dev

#371
post #345

Earlier quoted context omitted.

k8s has no performance overhead and can be useful even for simple applications (like for reproducible dev environments and CI). Agreed, otherwise.

I'm not talking about performance overhead, I'm talking about architecture overhead. Kubernetes doesn't have any advantages over not using Kubernetes for simple applications. Reproducible dev environments and CI you can get easily without Kubernetes, without having to add complex solutions for logging, profiling and other introspection tools. One could argue that you need the reproducible dev environments and CI to b…

> Kubernetes doesn't have any advantages over not using Kubernetes for simple applications.

So out-of-the-box support for blue/green deployments and fully versioned deployment history with trivial undo/rollbacks are of no advantage to you?

> Reproducible dev environments and CI you can get easily without Kubernetes, without having to add complex solutions for logging, profiling and other introspection tools.

I'd like to hear what you personally believe is a better alternative to kubernetes.

And by the way, Kubernetes does not support not requires distributed tracing tools not "logging, profiling, and other introspection tools". That's somethings entirely different and separate, and something that you only use if for some reason you really want to and make it your point to go out of your way to adopt and use.

In fact, distributed tracing is only a thing not due to kubernetes but due to you operating a distributed system. If you designed a distributed system and get it up and running somewhere else, you still end up with the same challenges and the same requirements.

Re: New Grad vs. Senior Dev

#372

Earlier quoted context omitted.

You can have a monolith and still suffer form these problems and need these technologies, as soon as you introduce a load balancer.

If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.

If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern.

https://microservices.io/patterns/data/shared-database.html

Re: New Grad vs. Senior Dev

#373
post #308

Earlier quoted context omitted.

HN can be a very contrarian community when it comes to popular trends or common practices in the tech industry.

It's just mindless copying. Just because x worked for someone here in this specific situation doesn't mean we should throw out everything else.

No, contrarian is a good description of the problem. We see a lot of posters complaining loudly about problems they never had or tools they never used. Some appear to simply enjoy arguing for the sake of it.

Re: New Grad vs. Senior Dev

#374

Earlier quoted context omitted.

The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS and all". Long story short, one year and a half passes and the mvp is still not finished, the architect leaves the company and some poor guys (from an outsourcing company) are still going at it with the same architecture.

CQRS and microservices has so much overhead, I'm amazed at how many companies adopt microservices without having anyone know a single thing about distributed systems. I think people underestimate the glue required to make microservices be useful. I had a similar situation at my last company where they spent a year and a half converting their monolith into half ass microservices and it still wasn't working properly. T…

Why do people always associate cqrs with microservices?

I have a project where only 3 developers work; we re designed it to be cqrs. I was sceptical at first - I especially don't like some of the boilerplate it creates - but I'm now sold on it by combining it with the mediator pattern, now I can have validation, logging and performance checks on every command and query without repeating code, works like a middleware

And ofc being only 3 devs it would be nuts to have microservices so we are happy with a cqrs monolith

Re: New Grad vs. Senior Dev

#375

Earlier quoted context omitted.

If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.

If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern. https://microservices.io/patterns/data/shared-database.html

Martin Fowler lists the benefits of microservices as

Strong module boundaries

Independent deployment

Technology diversity

And with a single database you severely limit the benefits from strong module boundaries and independent deployments. Suddenly you have to synchronize deployments, and anyone can pull or change any data in the database which now must be enforced with discipline which gets you into the same boat as a monolith.

Re: New Grad vs. Senior Dev

#376
post #323

Earlier quoted context omitted.

With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late. It's priceless to see their expressions when senior mgmt. and business owners finally find out.

Can you explain why you lose that ability? It's not obvious to me.

One of the fundamental laws of microservices is that each service is responsible for storing its own state. Nothing else is allowed access to its backing store.

Given that, once you have more than one service in your architecture, you cannot coordinate transactions across the distinct storage mechanisms - they are distinct databases and are therefore subject to the CAP theorem and other complexities of distributed computing.

Of course, nothing's stopping you from putting all your features into one service to avoid this thorny problem. It's a wise approach for most of us.

When you do that you have a monolithic architecture, not a microservice one.

Re: New Grad vs. Senior Dev

#377

Earlier quoted context omitted.

Here's a tricky one that I encountered a year ago. A junior tried to advocate for browser test. Senior from the developer productivity team said browser test couldn't possibly be made non-flaky. I didn't know how to advice the junior because I agreed with them. Saying "something is infeasible/costly" is like a blanket statement. There was no way to quantify that. On a flip side, we couldn't justify the impact of brow…

My team went through the browser testing issue as well and agree they're hard tests to write. We ended up writing a few using selenium, but we don't have as much coverage as we'd like. Luckily, unlike an interpreter upgrade, we can add them incrementally.

This is the way it should be.

If the test is slow and hard to deflake, then let's add it slowly. Maybe only test the critical path. There are ways to manage it, instead of discarding it entirely.

Re: New Grad vs. Senior Dev

#378
post #12

Earlier quoted context omitted.

No checks regarding length of source and query - may end up dereferencing beyond the bounds of the string.

There is a dereference past the bounds of the query in one case in the last code sample, but there is no deference beyond the bounds of the source string. You're probably thinking in C# or Java; remember that in C the convention is that a zero char ends strings. If the source string is shorter than the query string then the code will encounter a zero char in the source string at the same time as it encounters a non-z…

No null checks in find. If source is null, dereferencing source[i] in the while condition will cause undefined behaviour. If just query is null, the same will occur in the first call to starts.

Re: New Grad vs. Senior Dev

#379

Earlier quoted context omitted.

If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.

If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern. https://microservices.io/patterns/data/shared-database.html

Yes, and what does that buy you? Instead of a single deployable unit that owns the database, there are many deployable units, none of which can own the database. That doesn't seem like an improvement.

Re: New Grad vs. Senior Dev

#380

Earlier quoted context omitted.

> briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again A fine concrete example of this is the Coppersmith–Winograd algorithm (and its derivatives), a matrix multiplication algorithm with impressive complexity properties, but which in practice always loses to the Strassen algorithm, despite Strassen's inferior complexity. [0][1][2] (Aside: the Strassen algori…

I always loved my algorithms and datastructures professor talking about Brodal queues[0] - a datastructure named after him. They're super interesting from a theoretical point of view, but they're not useful for anything. [0] https://en.wikipedia.org/wiki/Brodal_queue

That's a great example. Hadn't heard of it before.
Post reply on HN