Microservices Are Something You Grow Into, Not Begin With • Hacker News Board

Re: Microservices Are Something You Grow Into, Not Begin With

#91

Post by ovi256 » Fri, Oct 19, 2018, 2:11 PM UTC

yakshaving_jgt wrote: post #50

ovi256 wrote: post #48

Earlier quoted context omitted.

The load per user can be widely different in different application. We don't have a great measure for that, one cound use a combination of requests per user per day, and the sum of CPU-seconds used to serve them. The sum of CPU-seconds should contain the periodic (e.g. cron-like, not directly request-answering) tasks too. At one extreme, you have applications that need horizontal scaling from day one (Scientific comp…

Yes, that is a reasonable response and I should have preempted that. For context: the product at my day job does something likely at an equivalent level of complexity to Shopify. It's just another SaaS business that handles payments, invoicing, etc. If anything, Shopify is more complex.

So the fact that Shopify succeeds doing that in Rails, not in C with assembler optimized code, is even more impressive!

Re: Microservices Are Something You Grow Into, Not Begin With

#92

Post by ex-aws-now-goog » Fri, Oct 19, 2018, 2:12 PM UTC

eropple wrote: post #83

ex-aws-now-goog wrote: post #62

Earlier quoted context omitted.

Your job is whatever you agreed to when accepting that job. Some companies require managers to aid in the technical development of employees, some don't. Some provide a lot of latitude in how that's done, some don't.

> Some companies require managers to aid in the technical development of employees, some don't. It's not about what a company "requires". It's about the moral duty you take on when you manage people.

I'm not sure why you think that striving only to achieve business objectives could be considered to be a moral duty. Are you perhaps perhaps thinking of fiduciary duty?

If a company decides that technical development of engineers is good for retaining engineers and you as a manager refuse to do that, then no moral argument is going to help you when you get dinged in your performance review.

edit: Upon rereading the thread, I suspect that we may agree more than we disagree. My comment was directed at asknthrow's comment and I wanted to make the point (which other posters have more eloquently made in the meantime) that if technical development is part of your job as manager, you don't have a choice in the matter and your job is not just "to lead the team in the most effective direction in order to fulfil business objectives" (to quote asknthrow).

Re: Microservices Are Something You Grow Into, Not Begin With

#93

Post by netcan » Fri, Oct 19, 2018, 2:15 PM UTC

adamdrake wrote: post #21

Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…

Reality is also confusing.

People can see that in a one day hackathon, the same bunch of people can produce more stuff than they do in a year otherwise. Why? Are they lazy? Did they use better tools?

My niece Shelly added address book integration to her hobby app in an afternoon, while drunk. WhyTF are we 640 man hours deep into "identity architecture coordination" meetings?!! Just do with Shelly did!

Those things don't make total sense, even to even the saltiest of developers. They know to expect it, but can't understand it. Neither can I, honestly. It's not surprising this gets so many people.

A lot of the hairy, abstract rabbit holes we climb into (whether organisation, like agile, or architectural, like microservices) are an attempt to solve the "100+100=6, wtf!" problem.

Re: Microservices Are Something You Grow Into, Not Begin With

#94

Post by js4ever » Fri, Oct 19, 2018, 2:26 PM UTC

collyw wrote: post #35

js4ever wrote: post #3

What I love about microservices is isolation and forcing you to do thing well from the beginning. Monoliths tend to become horrible to maintain after few years. On the opposite change one small 50 lines microservice is a lot less risky!

Not if you know how to architect one properly. How is a small microservice with one purpose different from a class / module with one purpose?

A simple syntax error in a monolith means the whole monolith is crashed. Bug anywhere in the monolith could mean border effect in the rest of the code anywhere. With microservices you guaranty isolation so a bug in one microservice won't have impact on the rest of the api

Re: Microservices Are Something You Grow Into, Not Begin With

#95

Post by SonnyWortzik » Fri, Oct 19, 2018, 2:28 PM UTC

adamdrake wrote: post #21

Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…

You make quite a lot of assumptions with 2 and 4. I was one of those inexperienced. Not as a developer but of the architecture of micro-services. As a technical lead I did not have the visibility of the cost and organizational effort into a micro-service architecture. I just started developing an architecture for our current project domain because we needed the flexibility of deploying these components separately.

But upon pitching the idea to an Organization Solution Architect VP he quickly stopped me and demonstrated me the cost of this effort and he did not have to demonstrate the effort because I went through similar challenges with in my team, and so expanding that effort into the entire organization would have been a massive undertaking.

So he did not shoot down the idea he just wants to take it down a notch and start with compartments, and not the entire organization.

Re: Microservices Are Something You Grow Into, Not Begin With

#96

Post by __comrade__ » Fri, Oct 19, 2018, 2:30 PM UTC

collyw wrote: post #34

icebraining wrote: post #20

Earlier quoted context omitted.

Or a framework like Django.

We love to reinvent wheels in this industry.

And the result generally looks more like a square than a circle

Re: Microservices Are Something You Grow Into, Not Begin With

#97

Post by arminiusreturns » Fri, Oct 19, 2018, 2:30 PM UTC

adamdrake wrote: post #21

Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…

I would just like to add that I consider there to be two types of microservices, one is developer focused, which is what most people are talking about when they say the word, but the other is operations focused, which is some sysadmins have finally been embracing.

When it comes to the sysadmin version, since you may be wondering, it mostly means decoupling entangled services into seperate, less centralized bins, bringing more resilency and quicker diagnosis timeframes when problems occur.

Re: Microservices Are Something You Grow Into, Not Begin With

#98

Post by yakshaving_jgt » Fri, Oct 19, 2018, 2:44 PM UTC

nickjj wrote: post #64

yakshaving_jgt wrote: post #41

Interesting that the article mentions Shopify supporting over 600,000 users with a Rails monolith. At my day job, one of the justifications for us adopting microservices is that we want to horizontally scale. We have fewer than 8,000 users. Hubris, eh?

Author here. Keep in mind Shopify does scale horizontally in terms of servers. They are just scaling a monolithic application. Those 600k shop owners results in Shopify's platform handling over 80,000 requests per second according to stats that are publicly available[0]. It's one of the largest scale Rails apps in production. [0]: https://twitter.com/dhh/status/885776244532551680

Thanks for the clarification, but it doesn't negate my point. It supports the idea that "scaling" is a lousy motivation for my team to adopt microservices.

Re: Microservices Are Something You Grow Into, Not Begin With

#99

Post by madeuptempacct » Fri, Oct 19, 2018, 2:45 PM UTC

My problems with microservices irl:

1. Sharing models - the models can be moved out to another repository or a NuGet package, but guess what happens when you have to modify them? Inevitably, devs duplicate models.

2. Debugging across five different code bases - have fun changing all the environment variables to point to your local every time, or running five different applications at the same time for local development.

3. Docker and Kubernetes add a LOT of overhead.

4. Multiple front-end apps combined into one "coherent" site always leads to routing problems...and token management problems.

5. Web Components cause bloat by pulling in web component scripts and the fact that each web component needs to fit the style of the whole site. Since shadow dom is isolated, each component pulls in styles again - slow. Again, debugging and checking in web component code is a pain.

6. Finally, siloing is inevitable.

Imo, this doesn't make sense at all for a smaller web app.

Re: Microservices Are Something You Grow Into, Not Begin With

#100

Post by yakshaving_jgt » Fri, Oct 19, 2018, 2:47 PM UTC

z3t4 wrote: post #88

yakshaving_jgt wrote: post #42

Earlier quoted context omitted.

Why do you believe development would be faster and cheaper? Because the individual services are smaller? Come on. The system is as large and as complex as will be necessary. Separating components with network calls doesn't make them any less interdependent.

There's a saying that if it takes one man one year to build a wall, you hire 20,000 workers and the wall would get built in a couple of seconds. That's the monolith thinking. Now if we make several small teams, and each team build a very tiny wall anywhere they like, each team could iterate faster, and quickly rebuild that tiny wall if needed, that's the thinking of micro-services. The later plan is of course not so…

Your allusion to The Mythical Man-Month is completely orthogonal to the debate between monoliths vs micro-services.

It's just not at all relevant.