
Microservices [video] - abhisuri97
https://www.youtube.com/watch?v=y8OnoxKotPQ
======
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.

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

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

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

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

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

~~~
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](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.

~~~
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
;-)

------
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/](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.

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

~~~
maxmouchet
This is it: My Time at Snap
[https://news.ycombinator.com/item?id=21122123](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?

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

