Hacker News Reader

> There are good reasons to use microservices, like when you have 100+ engineers

Its enough to have 2 that work in different domains with different constraints and different tools. Company scale is completely irrelevant here.

> But if you are a normal company, you will probably never have enough engineers to make microservices worthwhile in the first place

Many "normal" companies use microservices and common reason is that they simply cannot function otherwise.

> But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem,

The fact that some site doesn't function for 5 minutes may not be a problem, the fact that any change requires many people agreeing on deployment time often is.

Its enough to have 2 that work in different domains with different constraints and different tools.

Wouldn't that be more or less be just two monoliths?

If they both work for the same organization to achieve common goal, communicate through some interface they agree on, having to coordinate occasional changes that affect both codebases, than no.

If they are completely isolated, than yes, but its really rare scenario.

A common example would be a website that gathers/presents some data from users, and a service that provides analytics of said data. Both domains may require completely different technologies.

Agree, it seems silly to bash microservices as if all (new) companies decide to use them. They are a tool for medium and bigger companies to solve the problems those companies have. Fundamentally it's adding some complexity to the overall system by breaking it into components that have smaller scope and are easier for fewer people to wrangle. So one reason services can make sense when the complexity of an initial monolith has grown beyond what the average engineer can be expected to learn in a few months; or if a similar growth trajectory is happening because the engineering team is big enough to write code faster than everyone can keep up with understanding the important changes.

You can have services, just not micro. Splitting into few services that are obviously conceptually separate is enough. If you are a typical web company, you can have a dedicated service for search, maybe a separate service for internal tools and the main app. Granular enough that teams in charge can be focused on on their area and wide enough to avoid complexity.

Imo, that is identical to "microservices" but you're right that there's no reason to go any more than what you need. I always felt the whole microservice hype/movement was simply about defining multiple services as a useful pattern you'll want to use and how to build infrastructure to make it easy.

But I agree wholeheartedly. You don't need 100+ services to get the benefits of converting your tool chain to handle deploying n services even if n=3.

I think prefix “micro“ confuses me :) Opens up a debate as to how granular you need to go. Another thing that confuses me is whether microservice architecture is conceptually different to SOA. Some say it is, some view it as another iteration of SOA.

In that case I'd say it's unlikely you are truly embracing microservices in the manner that their evangelists intended (and don't misunderstand me, you are probably right not to). One of the characteristics of microservices is that they are small enough that they can be completely written in a couple of weeks.

Like every other fad in technology the nuances and practicalities are lost along the way.

Now that we have all started bashing microservices can we all take a minute to reflect on what a steaming pile of shit monoliths can turn into without a huge amount of respect for the artificial boundaries and interfaces that you create.

Where was it stipulated that a characteristic of a microservice is that it can be completely written in a couple of weeks?

If I remember correctly it's mentioned in Building Microservices - Sam Newman. I confess I don't have it on me at the moment to confirm that though.

Thanks for the reference.

I've always felt the "micro" terminology just meant that a service might be that small and that's ok. I don't think of it as a requirement. I don't really read any comments recommending I break up services more than I need. Usually its a conversation about "hey sometimes its better to have n services and you should spend a little time making that easy."

> But for most small to medium companies, a planned 5 minute downtime in the middle of the night is completely no problem, so all that zero-downtime-upgrade work is just wasted effort.

The first half of that is true, but the conclusion overlooks a couple of much bigger issues:

1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently. (See the yearly state of devops reports for further research about this.)

2. Not all downtime is planned downtime. Being able to handle a true crash gracefully is very important to achieve reasonable response times in the high nines.

I'm not a proponent of service-oriented architectures -- my opinion is that enforcing API boundaries is useful, but can be done at the source level rather than application level. I do however think there is great value to being able to deploy/restart your application with virtually no downtime.

> 1. There are few indicators of effective software engineering so strong as deployment frequency and lead time for changes. Being able to go from issue to fix in production in minutes rather than days opens up completely new paths for feedback and allows you to operate your service much more efficiently

This is only true under certain assumptions. E.g. if your business is not a public facing website, you often don't have the immediate feedback in case of errors, to make the above observation applicable. I have a customer with an application that gather date for a whole year, and then does alot of stuff with it. Then, there are no short feedback cycles in production, no matter how often a day you deploy. Then, it is important to assure quality before a change reaches production. Otherwise it might replace your data with background noise and you only discover it at the end of the next year.

This is a symptom of the general tendency in developer circles to assume that personal findings apply to everyone at every time in every situation. Which is obviously ridicoulous. But somehow completely acceptable if you generalize from something one Google employer has posted about.

There's a point to what you're writing that I hadn't considered, but I'd still hold that building "software used every day, or at least every week" constitutes far more of our collective engineering time than "software used once a year or more rarely."

Even if the latter category is more numerous, I think we spend much less time working on it. And software that's used semi-frequently can benefit from a shorter feedback cycle, even if it doesn't have one right now. Sometimes there's an insurmountable technical barrier to that (e.g. code on a solar orbiter) but it's even in those cases worth investigating.

> Also, the ability to do rolling restarts and no downtime upgrades by running multiple versions in parallel adds a lot of work and complexity.

You don't need (micro)services to do upgrades without downtime. You just need a couple of load-balanced servers instead of one, and some planning to be sure that the two versions can coexists for some time.

This can be a bit tricky until you get used to it, but depending on the company and the customers it can be even easier than organizing a maintenance window.

To be truly useful at smaller scale, most of the services needs to be third party components you just drop in, and we need near zero effort orchestration first so splitting up your services doesn't just shift the burden to devops.

Neither is really there, and so I agree with you today, but it could change with the right tooling.

Very good point, thank you. My take is we're actually getting there pretty quickly and 3rd party drop-in components where you can mix and match is indeed the future.

or the past ;-)

If you have a mono-repo and a maintenance window you could just make cross service updates in a single commit and do the maintenance deploy of all services too. Microservices alone don't prevent any of that.

Important nuance in your comment why microservices are useful:

3:00-3:30 in your timezone ;)

It's still possible to do live upgrades without microservices