HN Theater @HNTheaterMonth

But can they add the birthday date to the settings page? https://www.youtube.com/watch?v=y8OnoxKotPQ

I was just feeling down as I completed a 3 hour code screen where I was supposed to be recording my screen the whole time I worked, but somehow I botched it and don't have any recording to show. Awkward and my own fault...

Those chicken diagrams got a legitimate smile and chuckle out of me though. Thanks for the day brightener!!

Reminded me a bit of this "Microservices" youtube sketch which also includes a surreal architecture diagram (and is very funny):

https://youtu.be/y8OnoxKotPQ

https://www.youtube.com/watch?v=y8OnoxKotPQ ("Microservices" by KRAZAM)

But, parody aside, I'm with you: there must be one for every route in their API, and then another 250 for doing schema validation. I was being funny when I wrote that, but in the far left of their diagram is a circle named "apimeta"

>microservices

I never miss an opportunity to share my favorite piece of comedy this decade:

https://youtu.be/y8OnoxKotPQ

⬐ dijit

it's too close to reality.

There is a good talk that is also comedic as it comes from the perspective of someone who wants to fail at doing microservices.

https://www.youtube.com/watch?v=GWgRw5jiYy0

⬐ smcleod

Thank was pretty funny, thanks.

Feels like it would fit right in to this architecture: https://www.youtube.com/watch?v=y8OnoxKotPQ

Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have.

It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to add the work to their roadmap and get back to it in a few quarters. Relevant Krazam: https://www.youtube.com/watch?v=y8OnoxKotPQ

At a small start-up, if the GET /foo/:fooId/bar/ endpoint is missing a field baz you need, you can usually just add it yourself and move on.

⬐ the_mitsuhiko

In many ways you also need to be a massive tech company to not create a massive scalability problem. The first time someone ships a shitty query to a large user base on a mobile app you are now dealing with the consequences of a frontend engineer creating a bad query you can not kill quickly any more.

Making scalable, well performing queries work is nontrivial, particularly with the current ecosystem of GraphQL libraries. The main workaround for this provided appears to be directly mapping GraphQL to an ORM.

⬐ makeitdouble

I used to see GraphQL (and to an uglier respect Soap like interfaces) as complicated solutions to that problem you describe.

But more and more, I think Backend For Frontends solve this issue in a much better way. And of course that idea isn’t new and Yahoo for instance had that kind of architecture.

Frontend teams get to adjust by themselves a simple interface to their needs, and backend teams can provide more info through internal APIs with less restrictions than if it was directly exposed to the outside.

⬐ kbumsik

You can use GraphQL for BFF btw.

⬐ no_wizard

Do you have any reference material for the Yahoo architecture?

⬐ makeitdouble

It was pretty basic so I’m not sure how much it was talked outside of Yahoo. I see this presentation http://www.radwin.org/michael/talks/php-at-yahoo-zend2005.pd... providing an overview, but otherwise the basic principle was to have each addressable web server host an apache with a routing module, and that module will map a request path to a cgi file.

With that structure you can have any number of layers with your front call and the different business abstractions all representated by an API (let’s say you want a user’s average engagement with a service, you’d hit the high level API, which will fetch access stats from another API, which rely on a lower level API which goes through another separate layer managing DB cache etc.

Most of these call are of course internal to a data center.

⬐ gedy

I'm not following if you think GraphQL is a bad fit still, but we used GraphQL with the BFF pattern, and it was nice to use from Frontend to BFF. The backend services would use REST or whatever appropriate behind the BFF.

⬐ makeitdouble

I see GraphQL as unneeded if you already have a BFF managed by front teams.

Going with basic REST gives you simpler caching/optimisation paths, more straightforward mapping between the front request and the backend calls, and it makes it easier for other teams to look at what you’re doing and comment on/fix stuff as needed. GraphQL would be pure syntax sugar, and I’m not sure it would be worth the trade-off.

⬐ gedy

> more straightforward mapping between the front request and the backend calls,

I disagree, at least compared to something like Apollo Server or Hasura. The mapping is much easier, especially if you consider things like resolvers having parts of the schema going to different backend servers, API endpoints, separate caching, etc.

We tried to do this manually via a REST server, and found that we were just reinventing something like Apollo, but badly.

⬐ masklinn

I think an other thing with graphql is it reduces friction when trying to discover what your API should be.

So what you can do is some sort of generative graphql thingie when doing your initial iteration, with the client hitting whatever is convenient (in that situation you'd just expose the entire backend unprotected).

Once the needs have gelled out you strip it out and replace the graphql queries by bespoke API endpoints.

⬐ coffee_beqn

I just have never had this as a problem having worked on many APIs at many companies. Usually we decide what we want to work on and the frontend/full stack can read the documentation / chat with the backend engineers if it’s not clear. At no point is “discoverability” a issue

⬐ masklinn

The discoverability I’m talking about is not about knowing what the API is, it’s finding out what the API should be.

⬐ ryanbrunner

In my experience, "let's do something non-scalable and obviously wrong while we're exploring the problem space and replace it with something better before shipping" reduces to "let's do something non-scalable and ship to production" 100% of the time.

⬐ Aeolun

So you are saying it works? At least all the production systems where we’ve done this work fine, they’re just inefficient, feel vaguely dirty, and are unpleasant to work on. They’re still bringing in boatloads of money though.

⬐ ryanbrunner

I think the risk with unrestricted access to your database via GraphQL is that it's potentially a very easy DOS attack sitting waiting to be abused, and potentially a security risk if there's some information you shouldn't be exposing (as a very easy example, allowing unrestricted access to a user database would reveal password hashes, reset tokens, etc. which should never be available in a API).

I'm a fan of YAGNI, but basic security and leaving your system trivially vulnerable to attacks are a couple of exceptions in my mind.

⬐ danabrams

100% agree that it’s about dependence on other teams. That said, I’d much rather that we were communicating across a well defined api boundary, rather than a graphql api. You could, of course, very easily do this with an api layer in the middle.

⬐ YZF

Nobody seems to get the idea of building software out of pieces with well defined APIs any more </rant>. I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it.

The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the teams. It seemed for a while Amazon had things right both in terms of boundaries of teams and in terms of forcing people to use APIs- not sure what they do these days.

⬐ ako

What is a well defined API to access a lot of related datasets if you have 100s of external users, using it for 10s of different types of use cases?

Compare it to a database, what if you couldn't use random queries with SQL, but only had the option to call stored procedures?

⬐ YZF

It's the narrowest abstraction fitting those use cases. A database by its nature is a generic component. So sure, the piece of your software that's "SQL database" has a SQL interface, pretty quickly you'd want some abstractions on top of that around the different uses of that database.

The problem is when genericity diffuses its way into a large system it becomes impossible to maintain. How do you refactor a code base when everything everywhere is just SQL queries. If you want to change the schema how do you know you're not breaking anything? The short answer is you don't and so the software becomes incredibly brittle. The common workaround is testing but you can never test everything and now your tests also become coupled to everything else making things even more difficult to change.

The database in your example, while being generic is already an abstraction of sorts. Now if you're building lessay gmail the external users should see "create email", "get all emails", vs. issuing SQL queries to the database. That makes it easier to change the two pieces (client and server in this simplified example).

⬐ cmckn

Coral is still kickin’.

⬐ pphysch

This is one of the strengths of gRPC, it forces and centralizes the (mostly type safe) API design from the get-go.

Also tends to use a lot less bandwidth.

⬐ withinboredom

The biggest issue with GRPC is that it is only suitable for stateful languages (iow, languages that can hold values and share them between requests). GRPC is basically worthless for stateless languages and unusable. These stateless languages also don’t work well for websockets either, so it is what it is.

Until they solve the stateful part, I’m not using it or recommending it to be used anywhere. Bandwidth is cheap, type safety is overrated, and compute is expensive.

⬐ pphysch

Is this bait? Lol

⬐ YZF

What's a "stateful language"? Can you give an example here? gRPC is orthogonal to whether an API relies on state or not.

⬐ jonhohle

If that field isn’t populated aren’t you in the exact same spot?

⬐ vikR0001

Let's say you need to get a field back that is already in the database table, but that wasn't previously returned by the GraphQL endpoint. All you have to do on the front end is ask for it and GraphQL will populate it for you on the server.

⬐ sholladay

A world where the front end can access any database field it wants sounds like a security / privacy nightmare to me.

Of course there are ways to prevent data from being returned but that’s fragile.

⬐ purerandomness

How does GraphQL help here?

⬐ netik

This isn’t remotely a problem. Field by field granular security is trivial to implement in GraohQL

⬐ hamandcheese

I have to disagree with you there. It is possible, but it causes other annoying problems.

For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable.

Checking every field can also easily lead to performance issues, because it’s not uncommon for a large, complex graphql request to have hundreds or thousands of fields (particularly when displaying lists of data to a user).

⬐ dragon-hn

> unless you change your schema to where everything is nullable

At my current job, this was done before I was involved. It isn’t a deal breaker, but it throws away one of the best features of GraphQL.

In the end you just have every client implement the rules that should have been in an API tier (if they are competent), or worse no validation that gets you a giant mess.

⬐ withinboredom

Not to mention GraphQL wasn’t designed with security and user-state in mind. It was an afterthought that was bolted on, varying from framework implementation to implementation.

⬐ jfengel

How the heck was that not on their minds from day 1? It's the most obvious question to ask about a project like that.

⬐ necovek

GraphQL is mostly concerned with the query semantics.

A proper solution to security/privacy issues should have sensitive data never reach the outermost GraphQL layer.

So the problem is with the existing tooling that enables GraphQL implementations, but like anything else, if that tooling is deficient, the entire approach is on the shaky ground too.

⬐ withinboredom

It’s from before the https-everywhere days, or around the same time letsencrypt was started up, IIRC. Back then, I feel like security wasn’t as big of an issue, at least for less sensitive things. Like literally the entire site would be http until you got to checkout and the only reason you had the certs was to be PCI compliant.

⬐ BerislavLopac

Assuming the backend actually supports mapping of that particular field.

⬐ _3u10

For external users of the API this can be quite helpful when you’re looking for the password column on the users table.

For some reason I don’t think graphql actually works this way. Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

⬐ charcircuit

>Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

Privacy

⬐ HelloNurse

Putting passwords in a database, and that database behind some kind of service that allows queries, is a stupid mistake that can be implemented with SOAP, CORBA, a remote shell, or any other protocol or API style.

I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users

⬐ jonhohle

Ancestors of your post are suggesting exposing entire DB schemas (I would assume mechanically). While that could also be the case in other protocols, typical an IDL is used to separately define the API layer. Of course it’s completely possible to generate a WSDL, etc. from a DB schema, in practice I’ve never seen it done.

⬐ HelloNurse

My point is that passwords shouldn't be stored in the "normal" database where some clever architect might expose entire DB schemas to external access.

If clever architects manage to expose the carefully segregated database of the small and secure authentication module, they cannot claim it was an accident or someone else's fault,

⬐ ahepp

Why not just query the database directly then?

⬐ eatYourFood

None

⬐ dragon-hn

If your GraphQL schema is just a mapping of database tables, in my experience you are in for a world of hurt in the future.

⬐ vidarh

It's possible to do this without it getting painful, but you need to annotate the database schema with a lot of meta data.

We don't use GraphQL, but we do use an API that is mostly generated from meta data about the schema and permissions on a per field basis, with the ability to override on a per table basis.

To the API consumer it's invisible if they're referring to something that refers directly to a real database columns or to a method on a model class that doesn't correspond directly to the database (e.g. the user "password" attribute is

Effectively there are two schemas: the API schema and the database schema, it's just that the API schema is "prepopulated" from introspecting the database schema using Sequel (Ruby ORM), with the model classes translating between the two, with a synthesised default mapping.

The "API schema" includes more granular type information suitable for the frontend, and permissions, including type information returned to the frontend to provide default client side form rendering and validations (also enforced on the server, of course). It also auto-generates documentation pages with example data, inspired by Airtable's doc pages.

But key to avoiding what you describe is that these are all easily overridable defaults, and the permissions default to allowing no columns, so while the db schema introspection makes it quick to expose things where a direct mapping makes sense, it also makes it easy to avoid.

Unlike GraphQL we explicitly avoided allowing you to request arbitrary complex sets of data, but what you can do is expose queries by defining model metadata for them that either wraps suitable views or custom queries. We have a UI to allow us to define and store custom queries and views for e.g. reporting needs, so we can prototype new API needs in the browser writing just queries with some metadata annotation.

It gets us the flexibility of being able to quickly return exactly the desired data, while retaining control over the queries and complexity.

⬐ crispyalmond

At my workplace they made this decision before I started and I can fully agree with this. It's essentially a typed REST without any of the benefits. No joins, everything is multiple calls away to perform a "full" query.

I don't even want to think about undoing this mess.

⬐ NeedMoreCowbell

+1 This is it. Great for internal API's, not so much for public facing ones.

⬐ demarq

That's the theory. In my experience at both large and small organisations is that NONE of the theory makes it into practice.

Some reasons:

- Front end devs save time by.... sharing queries. So component B ends up fetching records it has no use for because its sharing GQL with component A.

- Backenders never optimise column selection. You may think you are really optimising by sending a GQL query for one column, but the backend will go ahead and collect ALL the columns and then "filter" down the data that was asked for.

- Backenders can also forget to handle denormalisation. If you query related many to many records but the GQL only asks for related ids of implementations will go ahead and do a full join instead of just returning results from the bridge table.

- Frontenders aren't even aware you can send multiple graphql GraphL requests simultaneously.

GraphQL is great, but any technology is limited by how well people can extract its value. I personally feel sometime we'd be better off with REST, or at least make sure people receive the training to use GraphQL effectively.

⬐ squidsoup

> Front end devs save time by.... sharing queries. So component B ends up fetching records it has no use for because its sharing GQL with component A

An unfortunate problem that really only exists with Apollo. Facebook’s graphql client, relay, does not have this issue as it requires each component to explicitly declare its data dependencies.

⬐ acdha

> Facebook’s graphql client, relay, does not have this issue as it requires each component to explicitly declare its data dependencies

In the scenario described, wouldn't this lead to the same problem because someone copied the code or reused a utility from another project and so they have at least the superset of those dependencies plus whatever new ones they added?

⬐ zbentley

> really only exists with Apollo

Citation needed. If two components call into the same data fetching utility for expediency's sake, and that utility queries data that one or both components do not need, you have this problem. What makes that uniquely likely with Apollo?

⬐ andrewingram

It’s more that compared to Relay, which is explicitly designed around preventing components using data they didn’t explicitly declare as a dependency, Apollo (along with most other GraphQL clients) doesn’t go that extra mile.

Whether it’s a React component, or a just a plain old function, Relay has mechanisms to prevent the kind of problem you’re describing. It has a steep learning curve, but it’s very well considered.

it is insane to me that this channel is being discussed today because literally 2 days ago it was recommended to me on youtube.

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ coffee_beqn

It is very much inside jokes for professionals in the tech industry. Very underrated gem

The one about microservices is incredible: https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ WelcomeShorty

So... that's me. FCUK. I really need to listen to these "work life balance" types more.

⬐ wizofaus

Gold!

⬐ jamil7

2 Years later I still have trouble watching this one, hits too close to home for an old job I had.

⬐ epolanski

Reminds me when I had to sort some payments FE-wise which was a very trivial array sort (there was at most 50 payments per page, nothing impactful performance-wise) on a json array which had a timestamp value, but CTO got involved with this triviality for some reason and started blabbering of how business logic had to be on the backend.

I literally had a working feature branch in 10 minutes, but it ended up being a 6 weeks job involving architects, devops, 3 backend engineers to have a microservice implemented in GO (which basically no backender knew) to handle those payments sorting. I'm not kidding.

I didn't got a promotion to staff engineer or architect few months later because CTO was fixated with "micro services experts" which basically consisted of anyone putting Go on their CV and having an AWS certification.

The guys hired were so sweet, they would spend like months repeating in the daily every day they were doing analysis and understanding our architecture, just to produce after 8 weeks a pdf of few pages with their in-depth analysis of Kafka vs RabbitMQ which was basically a summary of their landing pages lol.

I love the information economy.

⬐ tmpz22

Reading your story I can't stop thinking of the "Become the founding engineer at a startup" Ad on the HN frontpage.

Obligatory repost: https://www.youtube.com/watch?v=y8OnoxKotPQ&ab_channel=KRAZA...

"First we have to call the bingo service, see bingo knows everybody's name-o, so we get the users-id out of there..."

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ stevebmark

My favorite part of this video is how it accidentally shows the benefits of silly names: "Bingo knows everyone's name-o" is clever and easy to understand what it does. If this was called the "name service" no one would have any idea what it did from the service name alone. You have to learn what both services do regardless of descriptive or silly name, and Bingo is arguably easier to remember.

Classic satire on the topic:

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ dboreham

I assume this is "Galactus"?

⬐ echelon

Not sure why you were downvoted. My brain immediately went to this. Didn't even need to click the link to know what it was.

Good viewing for everyone, much like "webscale".

100% agree with that.

Also, obligatory reference to https://www.youtube.com/watch?v=y8OnoxKotPQ

There should really be a surplus of software developers. Most companies are solving problems they don't have, employing a team of 10x more developers than they need - because of course microservices, Kafka, Kubernetes, you name it - cargo culting the shit out of it.

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ dt3ft

That video is story of my life. Microservices to the brim!!!

Usually a link to a humorous YT video would be inappropriately uninteresting on HN, but this classic and brief satire of microservices is actually quite on point about precisely what is so dangerous about a microservices architecture run amok

https://www.youtube.com/watch?v=y8OnoxKotPQ

Summary: really trivial sounding feature requests like displaying a single new field on a page can become extremely difficult to implement and worse, hard to explain to stakeholders why.

TL;DR they invented Galactus https://www.youtube.com/watch?v=y8OnoxKotPQ

Yep.

With an addendum: it's not that they do "nothing", and that's the "problem". The end result is minimal, but the amount of work is still significant.

In any saner place it would amount to almost nothing, but for certain companies it is an Herculean task. And developers know it.

However due to the fact that the company hired thousand of coders, their communication overhead is now too massive. Their architecture also suffers due to the needs of handling those thousands of developers, so there's also a lot of work to be done in coding.

But the pressure is still there. Why hasn't your team changed the color of the button yet? "Why is it so hard?", "Why is it taking so long", etc etc

Jokes have been made about it: https://www.youtube.com/watch?v=y8OnoxKotPQ

The answer to all that was known since the 70s. Fred Brooks wrote a great book about all that.

I imagine the process going a bit like https://youtu.be/y8OnoxKotPQ

⬐ christophilus

I knew what that was before I clicked it. Never disappoints.

Sometimes new roll-out causes outage, sometimes, roll-out are delayed due to the overall system architecture. Reading the post-mortem, I could not help but be reminded of this issue as described here: https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ anonu

One of my favorite videos. And yes, slack is way more complex than I could ever imagine

Exactly, scaling doesn't help you solve product-market fit. It adds operational complexity/overhead with, in this specific case, no benefits, and solidifies the product that doesn't have market fit. Watch this for a laugh: https://youtu.be/y8OnoxKotPQ

Which is why I wont be able to find true love and I’ll die alone. I’ll die alone, without ever knowing it’s my birthday… [0]

0: https://youtu.be/y8OnoxKotPQ

https://youtu.be/y8OnoxKotPQ

Relevant comedy video:

https://www.youtube.com/watch?v=y8OnoxKotPQ

This recent video they put out is pretty good, too:

https://www.youtube.com/watch?v=kHW58D-_O64

I think this is more a revolt against unnecessary complexity, which I think is a discussion to be had. I am not solving drastically more difficult problems than I did twenty years ago, yet the amount of complexity, maintenance, and overhead is staggering. Why? Oh, because "that's how they do it at the FAANG".

https://www.youtube.com/watch?v=y8OnoxKotPQ

"Product Spec: Surprise and delight users by displaying their birthday on the settings page"

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ Sohcahtoa82

Still waiting on those ISO timestamps from OmegaStar.

⬐ Apocryphon

And what will you truly feel when you finally deliver value?

https://www.youtube.com/watch?v=DYvhC_RdIwQ

i think everything is already covered with this video https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ cbkeller

> I’m still not understanding this… why is it so hard to display the birthday date on the settings page?

Here's a great (but comedic) example: https://www.youtube.com/watch?v=y8OnoxKotPQ

Talk of naming conventions puts me in mind of https://youtu.be/y8OnoxKotPQ

Wingman is cool and all, but OmegaStar is really holding things up - still waiting on ISO timestamp support:

https://www.youtube.com/watch?v=y8OnoxKotPQ

https://www.youtube.com/watch?v=DYvhC_RdIwQ

Shout out to the Galactus team!

⬐ stingraycharles

This comment and the relevancy of the videos make no sense to me. Am I the only one?

⬐ dunefox

It's because a microservice in the video is also called Wingman.

Did someone say Microservices?

https://www.youtube.com/watch?v=y8OnoxKotPQ

Reminds me of this classic: https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ Sohcahtoa82

How have I not seen this channel before?

I'm realizing that the YouTube algorithm has no idea I'm a software/security engineer. It thinks I'm only into gaming, face plants, and dash cam videos.

Some of the other good krazam vids:

Microservices https://youtu.be/y8OnoxKotPQ

The Hustle https://youtu.be/_o7qjN3KF8U

Makro https://youtu.be/xubbVvKbUfY

⬐ geoduck14

I would attend BALMERCON

Obligatory Krazam: https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ geoduck14

Oh. That hits close to home!

⬐ rsj_hn

Check out "designer" https://www.youtube.com/watch?v=WqjUlmkYr2g

Nanoservices? Snark semi intended.

(edit) What could go wrong? https://www.youtube.com/watch?v=y8OnoxKotPQ

Like this? https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ dimitrios1

Exactly like that.

Where did parent mention microservices? NSI (No Snark Intended).

(edit) A parody about those: https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ dolni

I gathered the bit about microservices from

> I try to extend the simplicity of golang all the way to the network architecture.

⬐ chrismarlow9

That's a fair take from my words but it wasn't the intent. Really I just meant stick with consistent hashing, queues and the like. I guess really the "leverage existing tools and patterns" would have covered it sufficiently. I'm by no means a micro service fan. It reminds me of people abusing containers the way people abused the nosql movement. It has its place. I think we agree at the end of the day, and it's difficult to put into words.

Software names are the worst. Even "highly respectable" library/framework/etc names sound ridiculous. I found the microservices[1] joke video to be funny (in a you have to laugh or you're going to cry kind of way) mostly because the names are so off the wall and true to life in a way that the muggles probably wouldn't believe is accurate.

Saying, "Sorry guys, I just can't get past the names," is totally a legitimate thing to do. At some point you have to be able to talk to other people about this stuff and it's going to help a lot if you can say the names of the things you're working on without dying of shame. And it's not just about common decency. People are going to believe you're messing with them if you say something like, "Oh yeah, I've been working on getting `buttplug` to send ip packets correctly, however it's been giving me some problems."

[1] - https://www.youtube.com/watch?v=y8OnoxKotPQ

https://www.youtube.com/watch?v=y8OnoxKotPQ

LMNOP reminds me this: https://www.youtube.com/watch?v=y8OnoxKotPQ

Not knowing AWS, this sub-thread reads like a real-life version of the Microservices sketch: https://youtu.be/y8OnoxKotPQ

⬐ GSGBen

For anyone skimming the comments and considering skipping this video: do yourself a favor and don't. Krazam's tech comedy is unparalleled.

⬐ arolihas

The day in the life one was amazing as well.

⬐ celim307

It hit too close to home. It described me and everyone I knew age 22 - 30 in tech to a T. We really aren’t as original as we’d like to believe

⬐ arolihas

The lack of originality hurts I guess. What was more biting was the faux productivity, tech addiction, and social isolation and alienation of such a mundane daily routine.

⬐ corpMaverick

LOL. That is not a sketch. I swear it is real life in the back end world. The good news is that now we have Micro front ends for the enjoyment of the UI engineers.

Here's the actual video:

https://www.youtube.com/watch?v=67sfZfreOrU

These guys have a lot of relevant content for HN types, they're really funny.

https://www.youtube.com/watch?v=_o7qjN3KF8U

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ beaconstudios

I knew I recognised the name KRAZAM from somewhere These guys are hilarious.

⬐ darioush

finally, someone funny on the internet. haven't seen that since early 2000's

⬐ yellowapple

"Senior Engineer" is what I aspire to be someday: https://www.youtube.com/watch?v=eSqexFg74F8

⬐ headbee

I knew I recognized that name. Glad EFF is sticking up for them, they're not a huge channel.

⬐ craftinator

This brings me back to Snowcrash and Altered Carbon so hard...

⬐ monksy

ROBINHOOD IN 2021?!!

Also he forgot .. stocks only go up.

⬐ pjfin123

These are awesome

⬐ seppin

Topic aside that is an excellent comedy video. If SNL made this as a "digital short" it would be the best thing they'd had done all year.

⬐ grenoire

The goddam microservices video is an absolute masterpiece.

⬐ prepend

Great video. I’m going to use this the next time I want to communicate how clever names aren’t as clever as I think they are.

⬐ dominotw

It should be required periodic viewing at most software shops. Def keeps me grounded.

⬐ ccvannorman

it's.. it's literally like they were there, at my 8 months stint as a corporate developer .. I FEEL SEEN!

⬐ cbkeller

I think that video may have legitimately improved my understanding of the potential pitfalls of microservices

In the event you haven't already seen it, you may find this skit amusing and/or sob-inducing. https://youtu.be/y8OnoxKotPQ

Ed: I'm an idiot.

⬐ oblio

Link?

⬐ andrewflnr

Fixed. Oops!

https://youtu.be/y8OnoxKotPQ

⬐ potta_coffee

Too good!

What developers think when they hear 'aggressive timeline': https://www.youtube.com/watch?v=y8OnoxKotPQ

What managers think: https://youtu.be/-TKjwblp1XI?t=1373

Point being, nobody gets a documentary about themselves made for delivering against a boring deadline.

⬐ mulmen

I was in a come to Jesus meeting where they literally played https://youtu.be/ry55--J4_VQ and said “this is what we need you to do”.

⬐ sitkack

That is excellent, did you feel like you were inside some real-life meeting performance art? Did you brew the coffee?

⬐ whoisburbansky

Kind of amusing to find out that Myers declared personal bankruptcy, losing his stake in C.C. Myers and going on to found Myers and Sons instead. C.C. Myers (the old company) then went on to become employee-owned and later declare bankruptcy itself in 2016. Myers and Sons seems to still be going strong.

⬐ jldugger

Wikipedia at least suggests that the bankruptcy was unrelated. I'm not gonna spend the time to find out tho.

⬐ ZephyrBlu

> What managers think

You're telling me that isn't satire?

⬐ hinkley

Who needs a documentary written about them?

People say they want to be famous, what they want is the adoration of their peers. When they find out the two aren't the same thing, they often have a hard time of it. Being famous means you can't have a slice of cake in peace while you contemplate the news your doctor just gave you. It means everyone gets to have an opinion about every setback you experience from then on.

Famous people are hated all the time. Or adored by people who are a worse fate than being hated.

A PM and an engineer walk into a meeting room to discuss why the feature request cannot be implemented with their microservice architecture:

https://youtu.be/y8OnoxKotPQ

His microservice video [1] is also pretty awesome!

[1] https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ balfirevic

My favorite, Resolving Conflicts: https://www.youtube.com/watch?v=FDoH15ylAeo

That slide is just shocking. Freddie Mercury? It's like this sketch but real life

https://youtu.be/y8OnoxKotPQ

⬐ bombcar

What's scary is Hue bulbs are some of the MORE performant of the IoT stuff I have - and work when offline.

That second part is the key - so much stuff is designed "cloud first" and that introduces lots of delays and errors when the Internet isn't working perfectly.

⬐ aequitas

Or simply deny to work without an internet connection, like Chromecast, even though you just want to stream local content when your internet is down.

⬐ Jaruzel

Yup, If you are prepared to crank out some JSON to your Hue hub, you can 100% control them offline. I do this via scripts for my Hue based outside lights. My Hue Hub is blocked from accessing the internet too.

Real life Microservices documentary https://www.youtube.com/watch?v=y8OnoxKotPQ

"These trials are designed to surprise and delight our customers"

https://youtu.be/y8OnoxKotPQ

> Honestly when I read comments like this I have to wonder, do you really believe that thousands of companies spend trillions of dollars a year for something that doesn't work?

Joking/not-joking. Have you ever been to the Bay Area?

Yes. Emphatically yes it is the case companies spend trillions of dollars unnecessarily.

We've seen this with people who didn't know how to build microservices and farcical "LMNOP" [1] type services that might as well be a joke. We've seen it with gigantically-valued unicorns that over-engineered tons of crap and hired too many people and still can't make a profit. We've seen it with CMOs and massively overpriced marketing technology because budgets and statuses are related. We'll see it with tons more iterations of this exact same affluenza.

The history of our industry is that the margins on software are so good that people can afford to do crazy nonsense.

[1] https://www.youtube.com/watch?reload=9&v=y8OnoxKotPQ

⬐ dcgudeman

Just so I don't misunderstand your point: "Yes, companies without coordinating are collectively spending vast sums of precious resources on a product/service, BUT they are all misguided and wasting their money because look at these unrelated events where individuals misplaced their efforts/ money". Is that correct?

⬐ abernard1

> wasting their money because look at these unrelated events where individuals misplaced their efforts/ money

They're not unrelated. They're all related to fat 60-80% profit margins on SaaS. And no coordination is necessary to spend money on silly, make-work activities if you have margins like that.

Software has extremely low, borderline zero, variable costs. A lot of these companies that spend money on examples like I've given probably could hire nobody at all and still have crazy growth because of the unit economics. (Not coincidentally, the companies most in want of "Big Data" solutions tend to be past this point.)

I can get 1M QPS on a silly Aurora setup with replicas. Best tool for all jobs: no. But don't tell me that dollar-for-dollar a data architecture with like 25 different components is dramatically superior to an OLTP db, OLAP offline store + batch jobs, and a streaming system.

⬐ Sevii

That video is great, I've actually worked on a project where we tried to federate customer databases across 3+ mergers. Started before I joined the company and after 3-4 iterations they shipped something (that worked) around 3 years later right before I left.

⬐ mgraczyk

Yeah I mean this misses the main argument I'm making.

I have vast amounts of firsthand evidence from randomized controlled trials that non-financial data can be used to create value. This is enough evidence for anyone in the industry.

Presumably the commenter doesn't have access to this evidence. Instead he has to rely on other heuristics, like the weaker argument that companies spend trillions on data and analytics.

Companies sometimes waste money, and maybe microservices are an example of this. But companies collectively spend 3-4 orders of magnitude more money on "all data that does not have USD units" than on microservices, so the commenter should take that as strong evidence that data can be used to create value.

⬐ abernard1

His quote was:

> Is there any evidence that the vast amounts of clicks and user interactions companies have been collecting are worth anything at all?

And for the huge majority of companies, it is not. Even many 1B+ dollar companies. Most value produced by businesses still could exist with boring ETL or BI concepts that have been around forever, because the hardware powering it is so fast. Many if not most of those businesses probably would be better off.

So yes, companies blow a lot of money on stuff with questionable ROI. I don't discount your experiences and that there are cases where the complexity might have a payoff. But honestly, we've seen periods of excess complexity and waste in software before: it's the norm.

Microservices:

https://www.youtube.com/watch?v=y8OnoxKotPQ [this is a link comedy video about microservice architectures, it should be safe for work except maybe for Uber employees]

This is how I feel every day in my new job, there are 3 (depreciated) ways to do everything, and the current way is never feature-complete.

Reference: https://www.youtube.com/watch?v=y8OnoxKotPQ

I revisit this video every now and then.

⬐ celim307

This one always cuts too close to home

https://youtu.be/_o7qjN3KF8U

⬐ matiasfernandez

Can't wait for BallmerCon this year. The XLOOKUP meta is going to spice things up.

https://www.youtube.com/watch?v=xubbVvKbUfY

⬐ matiasfernandez

It's all I could think of while reading the article. The spiraling-down into complexity and service names had me smiling all the way. The "we should have predicted this" in last paragraph sealed the deal. And the HN comments saying they should have known better and used ZingBing from the start had me rolling.

"You think you know what it takes to tell the user it's their birthday?!"

> It's much easier to discuss and reason about complex systems when the names are self-explanatory

For example:

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ 2sk21

This is gold :-)

If you're up for a humoristic take on microservices, you could have a look at this video: https://www.youtube.com/watch?v=y8OnoxKotPQ

> it's incredibly difficult (and relatively rare) to be able to turn non-programmers into Computer Scientists

Yet the premise is the vast majority of jobs don't need a computer scientist. They need a programmer who can understand a complex code base and explain why is it taking so long to display user's birthday on the settings page [1]

[1] https://www.youtube.com/watch?v=y8OnoxKotPQ

Microservices

https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ thrwaway69

That channel is legit underrated

Relevant comedy: https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ ecnahc515

I knew this would be in the comments before even opening the page. This thing has been getting shared a ton lately since it was just uploaded 2 weeks ago. I think it kind of goes to show how many people empathize with the video.

⬐ tcgv

Great satire! haha

There should be one of these videos for reactive programming as well. Misuse of observable pattern can quite quickly turn an app into a mess, making code navigation / minor change requests a nightmare.

⬐ aledalgrande

Great video, also in a couple of clicks I got to this, which is equally hilarious: https://www.youtube.com/watch?v=5WL_jkFS2gw

⬐ ablekh

Hilarious video (and most likely very true). Thank you for sharing.

⬐ hinkley

Do you think he ever found love?

⬐ ablekh

I was referring to technology aspect only. Regarding love, you'd have to ask him. :-)

⬐ Frost1x

This made my day, thank you.

⬐ hn_throwaway_99

Hah, I have seen this before but this was the first time I actually notice the PRODUCT SPEC at the beginning:

GOAL: Surprise and delight users by displaying their birthday on the setting page.

DELIVERABLES: Display User Birthday on Settings Page

"Surprise and delight" has definitely become one of my new bullshit bingo favorites.

This might all be pedantic, but in this vein: one draft horse can pull 8,000 pounds, while two horses together can pull 24,000 pounds [1], even more if the horses have worked together.

Horses do not become exponentially more powerful as you add additional horses. Similarly, if you had me make something by myself I could do some work, but if you had me make something partnering with someone with complementary skills (for me a good frontend designer) then the result would be more than 2x what I would do alone. This also does not scale... you can't add a chef and an ops person and a ballet dancer and a plumber to the team and keep getting better results.

But maybe you add a whole ops team, and now I can do work and almost forget about that task, and the work is more effective and our little team stays little and the big ops team is professional and reliable so that once something is up it is up. Can whole teams complement each other?

So you get all matrixed [2] and that's good and bad, but you can only have so many of these groups. Maybe you go long and blow everything up into microservices [3], but it can't go forever.

Can whole business units become complementary? Or are there other ways to break it up? I haven't read the article so I'm not sure if it answers this ;) But from skimming it, it seems Malthusian in its perspective, hell-is-other-people, that scaling up is unfortunate instead of a process of becoming something new.

[1] https://timmaurer.com/2012/01/16/horse-sense/

[2] https://en.wikipedia.org/wiki/Matrix_management

[3] https://www.youtube.com/watch?v=y8OnoxKotPQ

⬐ inertiatic

I couldn't find a citation for that fact though, the one about horses. I found a lot of people referencing the article you mentioned but no original source.

⬐ ianbicking

Yeah, getting clear information is hard.

This bulletin on horses and horsepower from 1926 is pretty great, though it also doesn't answer the question very clearly: https://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=1466&...

There's a bunch of load pull tests there, but they are only done on teams, never on a single horse.

⬐ burlesona

I just wanted to say thank you for letting me know that a horse can pull that much, and even more for letting me know that two horses can pull 12 tons. Just, wow.

Best TIL I've had in a while :D

⬐ nkassis

This was linked to me right after coming out of a meeting with my product team where I was the engineer in this video. Worse, I had a large hand in defining how our software architecture is designed so I can't even blame other people. It's largely my fault.

⬐ makstaks

Thanks for sharing this, not easy to admit. In retrospect what would you have done differently though?

⬐ bsaul

"why i screwed up" is the kind of talk you don't see often, and yet it's probably as instructive as the other ones.

⬐ nkassis

That's a good question, a lot of the issues we hit now are mostly due to early assumption informed by our business requirements at the time that didn't hold true long term (argh blaming the business trope sorry). Our company being a a startup still learning market fit for our product went from being SASS first to doing mostly on prem and private cloud installations for example. That changes a lot of how I would have approached the design to reduce operational complexity had that been obvious early on.

Similarly, we did a lot of learning from the tools we used that is probably very much just something you earn with battle scars. For example the behavior and issues we hit with our choice of core stack components (celery, redis, rabbitmq, kubernetes,...) are often things you learn by using them and gaining experience.

The next thing is there were a lot of conscious tradeoffs that I would still argue we would take today. We prioritized speed of building features to make the product viable and attractive to customers at the expense of quality of those features and reliability. Doing the hard real world testing instead of relying on simple unit/integration tests before shipping. That's something we now are having to address but the question is was that something we should have done differently? No sure I would, we may not be around now if we hadn't built the feature we needed to sell the product and prove market viability.

On the topic of this video. I think the issue it not using microservices or building a monolith but controlling complexity. The biggest thing I dislike about our current infrastructure is the cognitive load and complexity that a new engineer joining has to deal with to be productive. That can happen in any architecture if you aren't careful. Sure having to run multiple services, tracing and testing acrross them (basically the usual gripes about microservice architectures) dealing with inter-service calls, performance tradeoff etc.. is not as good as I'd like it to be but it could be improved. What sucks most is there a lot of raw edges we left exposed that trip new people and that I think was a mistake we should be prioritizing fixing those as they come up and think of them while buidling up our core framework and components more thoroughly.

⬐ raghava

Is there a method/framework to measure/manage architectural complexity?

Please share any pointers you might have!

⬐ nkassis

Observe how well and quickly new engineers come up to speed in your system. What problems do they hit? Think about them while designing. For example what hinders them from solving issues as they come up with customers.

Their experience in my view is a representation of the architectural complexity and cognitive load you are inflicting with your design.

⬐ fugazithehaxoar

This was my exact experience working at Nike 4 years ago. In this scenario, I was the guy sitting. I got this type of "talking to" when I submitted a bug ticket because jQuery was being loaded 3 times on the same page.

The Nike.com software group was over 1,000 employees working on a microservices mess that performed horribly on the customer side. They could have built a much better product with about 50 competent software professionals.

⬐ pdr2020

Webpack 5's modules federation ;)

⬐ capableweb

Brooks's Law in effect, same as in all the other places where managers believe that 9 women working together could make a baby in one month. https://en.wikipedia.org/wiki/Brooks%27s_law

⬐ woofie11

For every microservices system I've seen, this feels about right.

It oversimplifies things a bit, though.

It's odd; I've never seen a "monolith" simplified by moving to microservices, but everyone seems to be doing them.

⬐ KorematsuFred

Microservice design was not meant for [only] a simpler system but ease of dividing people into smaller teams where a team could focus on a single objective without worrying about rest of the company.

If the microservice architecture has made you less productive than the top leadership is to be blamed.

⬐ Johnie

Conway's Law applies here [1]. Poor architectural design can be rooted to how managers organize the team. If you want to see the architecture designed a certain way, organize the team structure along that line and the architecture desired will naturally emerge from the teams. If you have a misalignment of teams and architecture, you're always bound to hit friction along the way.

As you move up in leadership, the tool that you have is organizational design. Doing it right and you have a highly efficient org. Do it wrong, and you'll constantly hit roadblocks.

[1] https://en.wikipedia.org/wiki/Conway%27s_law

⬐ ryanbrunner

I think it often can, but I've seen plenty of teams where things were split into microservices despite only having 4-5 developers in relatively close collaboration, mostly due to trend-following and it being the "right" way to architect software.

⬐ bartread

...ease of dividing people into smaller teams where a team could focus on a single objective without worrying about rest of the company.

How's that working out for you?

In most cases, and I'm talking right up to the scale of very large enterprises[1] you don't need that much complexity to scale technically and, if you avoid the complexity, you don't need that many people either.

And I don't think you can ever afford to be myopic if you want to effectively deliver solutions to real business problems.

[1] 90k employees, specifically, but also, specifically, not a tech company. A traditional company with a tech function.

⬐ woofie11

This is absolutely correct. The best teams I've worked on understand both the business and the technical domain, and are able to leverage synergies to keep things simple.

⬐ ramenmeal

I think most slow downs are due to single teams owning many (20+) services. Usually it's their own choice too.

⬐ owenmarshall

This is absolutely right in my experience.

Microservices are all about scaling development agility in exchange for increased technical overhead.

In many cases this tradeoff is atrocious. If you can say "we can easily take on (large feature XXX) and deliver that", microservices are all pain and no gain.

Where they really start feeling good is when your "two week sprints" turn into about two days of available dev work because the remaining time is spent regression testing your changes and trying to keep the build from breaking because of tests you didn't touch failing (spooky action at a distance is real and it hurts). A clear API contract that both sides of the fence can develop against means that you can keep making progress.

At least until it's time to integrate against the real world, not your mock ;-)

⬐ bhburke

I think there are plenty of examples of monolithic architectures that also have huge technical overhead, builds breaking for unrelated changes, huge amounts of regression testing, not to mention the build times...

Microservices can be a great pattern to deliver quickly _and_ maintain high availability/low technical overhead, that's their point. I think the problem arises when developers try to over-optimize or over-engineer a system, or they want to get promoted so they write a new service, ending up with huge entangled webs like in the sketch.

Individuals and interactions over processes and tools, every time

⬐ owenmarshall

> I think there are plenty of examples of monolithic architectures that also have huge technical overhead, builds breaking for unrelated changes, huge amounts of regression testing, not to mention the build times...

Yes – I was talking about those same monolithic architectures in that comment ;-)

⬐ jayd16

I've seen the same thing in monoliths when I was a young contractor. Inheritance hell is usually also involved at that point.

⬐ bob1029

We simplified a monolith by having discrete services within it. Each a self-contained vertical unit of functionality, but in a shared namespace with perfect type visibility & enforcement across every service. So, we can dispense with all of the fanfare and just do direct method invocation across 1 DI scope in a single fat binary. It works perfectly. No contract issues to negotiate and developers can work in parallel with zero fear of breaking shared components, as long as intended interface changes are discussed up-front.

From a high-level perspective, is there really any difference between DMI and HTTP/gRPC/et.al. if you could hypothetically run all of your services on a single logical node? If your entire production stack runs on your macbook, why cant you just wire it all up as a single binary and throw it on a nice powerful server? I guarantee it will run better without all that ridiculous network glue in the middle.

If I am being modest, I would say that we feel really, really stupid from where we are sitting right now. Primarily for having previously spread this implementation across 10+ services talking HTTP for absolutely no good reason. I am growing into a mindset where the entire business system needs to fit into 1 binary image. Perhaps duplicated across more than 1 physical host with differing features enabled per, but at least sourced from the same solution/repository.

⬐ woofie11

That's how I like to code. That's just called good abstraction.

What microservices allow is for different teams to use different technologies and to upgrade components independently. On service might by Python+postgresql, another Ruby, and third also Ruby but two versions ahead.

It feels fast and agile in the short-term to decouple teams like this. In the long-term, it's almost always a maintenance nightmare. You end up with way too many different technologies.

I usually break up my projects into libraries (in Python, independent pip-installable packages) with their own unit tests, and some pretty weak glue in the middle. The service layer is omitted. I design things to scale horizontally too.

I've built apps with a few services, but I've never seen a good example of a microservice architecture that beat good old-fashioned clean abstractions in libraries.

Every few years, someone comes up with a new way to do abstraction, and compares that to no abstraction (rather than good abstraction with the previous model. Microservices seems like the dumbest of the bunch I've run across in my career.

⬐ codr7

Modular software is a great idea, always was; and fundamentalism doesn't make software better, never did. Good ideas are compromises.

The latest system I designed professionally was an ordering system that's divided into two parts; a local application with a database and an HTML document and a PHP script on a server.

The application itself doesn't need internet access to work.

The data needed for the online customer order module is uploaded to the server via FTP as needed. Online orders are stored on the server and polled via FTP on request from the local application.

The result is modular, very easy to maintain, and performance is good enough to be considered a feature.

But the reasons for the choices I made are all about the problem being solved, not organizing developers and keeping them from stepping on each others toes.

⬐ Jugurtha

We haven't gone through the "microservices" craze for pretty scientific reasons: I dislike smug talking "Chief Wizards/Architects/Scientists" who've been writing posts and giving talks on architecture, clean code, and refactoring, based on that one project in the eighties. Reminds me of those phony martial arts "gurus" who are all about abstract ideas and "energy" channeling, complicating the simple to sell seminars and subscriptions.

Anytime something is discussed, we ask ourselves if that change will improve users' lives. I am sure these are useful for other people at different maturity levels of software, but it is not for us, right now.

This is why we don't use React, Angural, Webpack and a ton of other things and libraries that are useful for others but add no value to us and only increase. We avoid adding complexity unless it's really worth it, and worth it for the users, not to give us pleasure of using a new library. We have side projects for that.

⬐ stepbeek

I've recently been using StimulusJS [0] and found it to be a really nice mid-point between spaghetti and a heavier framework. It has conventions out of the box, it does things in a reasonably disciplined way then it disappears.

[0] https://stimulusjs.org/

⬐ alixedi

The only 2 valid reasons I have come across for using microservices based system architecture:

1) There is a codepath in the application that has radically different load characteristics.

2) We want to give each team in the organisation ownership of (most of) their stack, release cadence, SRE etc.

(2) seems like an attempt at engineering but is often about management - empowering the teams yada yada.

There is a thread here about: "Technology opinion-sphere is a FAANG monopoly" aka "Dude, we got like 3 paying customers!". I'll leave that for another day.

⬐ imtringued

Actually 1) isn't a good argument. There is nothing wrong with having regular sized services. Most applications already do that. They separate databases from web servers.

⬐ Mountain_Skies

The current trend of adding microservices all over the place feels an awful lot like DLL Hell. Don't know if it will ultimately end up that way, but it sure sounds like a rhyme.

⬐ fareesh

I remember reading a blog post some months ago here from a former AirBnb employee where they talked about how some senior manager in the company wrote an incredibly detailed spec for a CRUD feature which required them to invent a datatype because they insisted on using no more than N bytes to store some inconsequential field. There was also a description of how the author had to crawl through a parking garage to escape a meeting wherein he insisted that nobody was allowed to leave.

I feel like there is no accountability for these clowns. They'll inevitably switch jobs and ruin the work lives of so many developers with their stupidity. There is a culture of not wanting to name your abuser for some reason. It's weird.

⬐ Nextgrid

I feel like the technology industry as it stands promotes over-engineering and encourages it. There are a lot of developers out there that built their entire careers working on (or designing) over-engineered balls of mud and thus will bring that way of thinking into any new role they join, thus spreading the problem to their next company (if they don't have this problem already). There can't be "accountability" when nobody considers this behaviour a problem to begin with and actually hires based on how many over-engineered things you delivered in the past.

At a previous employer I remember they had someone build a React front-end which talks to a GraphQL proxy which itself talks to a REST-based API and seemed proud of his creation. There was absolutely no reason why the front-end couldn't talk to the REST-based API directly (it was on the same domain, and the front-end already had a valid auth token), but now there's one extra moving part in the system that can (and did) fail.

At another place they for some reason decided that they needed React despite only a single page of the application actually needed to be "real time". 9 months later they still didn't even have a functional registration form and then it took them over a day for the basic feature of displaying the QR code for two-factor auth enrolment. The same signup form would take me less than a day to do in its entirety using "boring" HTML pages and forms (which our framework already had lots of helpers for, so the backend code for it would've been around 100 lines).

⬐ tabtab

Surgeons usually recommend more surgery and pharmacists more pills. It may not be conscious bias, but human nature tilts each to favor solutions toward their own skill sets.

My manager want's "pretty URL's" even though it's not a good idea to bookmark CRUD detail pages. It creates internal code messes to keep them pretty. It's yet another me-too feature that bloats the stack. I proposed a compromise, but he really wants them pretty.

There are too few K.I.S.S Cops in IT; the Bloat Mafia reigns. Warren Buffett says part of the secret to getting rich is confidence and conviction to say "no" when the logic and numbers don't support an idea but peer pressure says "yes". https://news.ycombinator.com/item?id=22795294

⬐ stronglikedan

> There is a culture of not wanting to name your abuser for some reason.

No one wants to burn bridges. The world gets really small at the most inconvenient times.

⬐ loopz

Like with any cult, the victim get double abused, evicted and the people remaining justify why it had to be so. This is the normal behaviour.

You really have to work within the system, and in the end, become the same system.

⬐ khaledtaha

I believe this was at Snap Inc. I’ll try to find the link later.

⬐ fareesh

My bad!!

⬐ maxmouchet

This is it: My Time at Snap https://news.ycombinator.com/item?id=21122123

⬐ techsin101

Hey let's design looking backwards and ignore all future needs. Everyone will be happy. Because they all are about saving face and give minimum effort, enough to keep things working as is. It doesn't matter if it sacrifices future opportunities nobody can test that. Then it will be just a matter of fact. We will all just pretend this was unavoidable inherent complexity.

Imagine playing competitive RTS game and decisions were made with this attitude, tomorrow-not-my-problem as others don't have domain expertise to tell otherwise or they don't simply care to put themselves as opposing force and do your work to find better solution. In game you'd be doing seemingly ok and then get destroyed all of the sudden.

⬐ gshulegaard

Sounds like League of Legends to me.

(Edit: at the casual level)

⬐ raghava

As an engineer, I am finding i very difficult to decide on things like capability/modularity boundaries, layering constraints etc w.r.t architectural decisions for a B2B, cloud native, SaaS software solution. No matter what resource I refer to, there's a lot of conflicting info.

Is there an equivalent of "cyclomatic complexity"(McCabe count of code) for cloud/distributed systems/μServices architecture? Cant find any such objective measure, apart from a few dated research papers.

IMO, it could be useful for many of us. Sometime back, I had tweeted tagging @copyconstruct and @kelseyhightower asking this question, but haven't got a response - may be it went unnoticed.

Would love to get to know if there's any such method/framework to measure and manage architectural complexity, for the world in cloud.

⬐ 2T1Qka0rEiPr

I think if you don't know, don't. That's a good place to start :)

⬐ haolez

Not exactly related to the video, but why do some people choose gRPC and others choose event sourcing for microservices communication? Is it just a matter of unneeded complexity in event sourcing? Are there performance issues as well?

⬐ socksy

I can heavily recommend the book "Designing Data Intensive Applications" by Martin Kleppmann for a great overview and deep dive into the trade-offs in both of those approaches (and others)

⬐ jbreiding

It's the difference between service orchestration and choreography, respectively.

There are pros and cons to each approach, and the details matter with regard to how services will be scaled and the coordination of that scaling happens.

There are lots of finer points in the details, but knowing the difference between the two approaches can help with the decision making process on which path the adopt.

⬐ saamhaz

I’ve watched this only about 50 times nbd

⬐ occsceo

hits too close to home.

⬐ Hokusai

I love the joke. But, it is a serious problem.

One key part is that naming is important. This is always a fight I am willing to take. Acronyms, fantasy names, names of teams or legacy names that does not represent the functionality of the micro-service plague many companies.

If you will not name a method "Jimmy" or a local variable "Galactus", why developers are naming their micro-services in such a bad way?

I do not know what I find more frustrating, the bad naming per se. Or the fact that the same developers would lose their shit if they saw this:

  class Galactus {
    boolean Jimmy;

    void turnOn() {
      Jimmy = true;
    }

    void turnOff() {
     Jimmy = false;
    }
  }

Sometimes it feels that software development is more a religion that an engineering discipline. That there is rights and wrongs based in tradition instead of sound practices. That is why worse than the naming is the lack of self-introspection that let us here.

⬐ SarikayaKomzin

> One key part is that naming is important. This is always a fight I am willing to take. Acronyms, fantasy names, names of teams or legacy names that does not represent the functionality of the micro-service plague many companies.

> If you will not name a method "Jimmy" or a local variable "Galactus", why developers are naming their micro-services in such a bad way?

There was a post on the front page today about the "principle of least astonishment." It could not be more applicable than this example.

For those that missed it => https://wiki.c2.com/?PrincipleOfLeastAstonishment

⬐ Yhippa

> One key part is that naming is important. This is always a fight I am willing to take. Acronyms, fantasy names, names of teams or legacy names that does not represent the functionality of the micro-service plague many companies.

This has been happening way before microservices became popular but it's gotten out of hand. Teams have nonsensical names as do their services. Outsiders coming in have a huge hill to climb to learn the domain because god knows why.

⬐ contravariant

I reckon people might be copying the trend of giving nondescript names to particular software/services. Which isn't bad per se (I mean there's only so many ways you can rephrase 'webserver' before you run out of options), but if you split up your organisation and do the same thing to each subpart then it gets confusing.

⬐ hirsin

We have something between 3 and 8 user profile services that you might interact with on a daily basis depending on where you sit. If they all had "good" names they'd all have roughly the same name. It's dumb for onboarding, but I have to say I see how "racoon" became a name.

⬐ cgarvis

PG has an essay on keeping your identity small. It high lights the fact that when there is no way to prove one answer is correct, it’s then subjective which is the “right” answer. He uses the example of politics. Good read.

⬐ monocasa

So I'll throw out the argument that responsibilities of a service evolves as the product evolves. The fact that names like Galactus are blank slates can be a benefit so that you don't have to explain to some poor new grad:

"Well, you see, the identity service isn't actually the source of truth for identities anymore ever since the oauth service started taking that responsibility and the plan was to move all the endpoints into the other service but some other priorities came up, but that was five years ago..."

That is, if agility of architectural development is one of the goals of microservices, names that don't get out of date because they never meant anything except "name for this codebase" in the first place might have some benefit.

Does that overrule the benefit of a common lingo you can talk about without the domain knowledge of your system? Probably heavily depends on way many variables than even HN can hash out, but there's an argument to be made here for these naming conventions at least.