Hacker News Reader

Comment by shaneprrlt | Hacker News Reader

> With this transformation, microservice architectures have become the standard for building cloud native applications, and it is predicated that by 2022, 90% of new apps will feature microservice architectures.

What do other engineers think of this statement with regard to startups and MVPs? Am I wrong for thinking that monolithic architectures are still the best way to get started from 0? Is it simply a matter of better tooling to make creating a micro-service architecture as easy as spinning up a rails or django api?

View on HN

As an architect, and one using primarily Microsoft technologies at that, I really doubt Microsoft's 90% figure.

Microservices have their place, but I really think monolithic architectures are far more suitable for the vast majority of cases.

Every time I've seen microservices in use in the enterprise space, it's been a complete mess - no documentation, incredibly brittle services written in a multitude of languages using just as many idioms, devs scared to touch anything lest they break it, no standardised logging... doing microservices "right" requires a highly disciplined team with processes and DevOps enshrined in the company.

> I really doubt Microsoft's 90% figure.

In fairness, it's from IDC, not Microsoft.

The same report predicted that "500 million apps" will be created between over the 2018-2023 timeframe, which looks suspiciously like someone saying "100 million a year, what do you think Frank?" and then getting the nod because "a billion" is even more clearly absurd.

I think it is crazy. Why would 90% of new apps need to feature microservice architectures for any other reason beside padding out resumes?

You don't need microservices if you think your business will eventually fail. On the other hand, if its a success then at some point microservices are much more maintainable. Its extremely difficult to change a monolith to microservices. Right now there is a heavy infrastructure prices to pay for microservices but if that gets solved then why would you not start with microservices?

Microservices are for scaling development teams. They're not inherently better to maintain.

You just can't reliably work on one artifact with dozens of people without creating a lot of complexity, this is why microservice architectures can be better in some cases.

If you're not going to increase the development team beyond a single smallish group of people, you'll be much more productive and your service will be way faster as a monolith.

I'm pretty sure most SaaS companies want to scale their development teams, so it's basically a given that most want to use microservices as well.

Individual microservices are definitely easier to maintain than a monolith. Ever experience a big ball of mud? Every monolith I've worked with, turned into one.

Sounds like you are arguing that for small teams a monolith is better. No one would argue that they are not. If you read my post, I talked about business that become a SUCCESS meaning that they grow beyond that initial small team. Once your team becomes large, if you started with a monolith, you will eventually need to either break it apart into microservices or try to manage the monolith across many teams.

IF microservices could be as easy to develop from day 1 as a monolith, why would you start with a monolith? Isn't that what technologies like Dapr are trying to do? Make developing microservices easier?

> Individual microservices are definitely easier to maintain than a monolith. Ever experience a big ball of mud? Every monolith I've worked with, turned into one.

Can we just create a Visual Studio extension that allows you to pretend the various components of your software are "microservices"?

"Sorry, you're trying to stuff too much functionality into your XYZ class. You'll need to break it off into another class if you want the Pseudo-Microservice plugin not to complain."

Too much functionality in your XYZ class is not generally the problem. Its the dependencies between the classes and the way the frameworks (looking at you spring and hibernate) can make it too easy to couple your code via transactions, ORM graphs, etc.

All modern ides analyse dependencies. Spagheti is usually built when there are too many people working on one project. Microservices is to scale people, no need for microservices when your company has very few employees.

This is an engineering argument that's disguised as a business argument. In reality a monolith had way less overhead when starting a new product or business and makes a lot more sense than sinking resources into something that isn't even needed at the time. Not to mention that from an engineering standpoint you can't even know for certain which components need to be broken out onto a microservice without the evidence of traffic.

Following your logic to its ultimate conclusion, you may as well also over-hire on staff, get a super expensive office, crazy benefits packages, etc. Why not? You dont need that stuff if you think your business will eventually fail.

If you read my post I never argued against starting out with a monolith. Of course they have lower overhead. I argued that if your successful like say Twitter, then you will eventually have a problem with your system all tied together in a monolith.

> Its extremely difficult to change a monolith to microservices

I beg to differ. It's completely straightforward, for the most part. You split them out, one by one. That's a big part of the reason for its popularity.

If it's really that difficult, maybe it's not a great fit for the problem at hand.

OK agree to disagree then. I spent a year on a team trying to break a monolith into microservices generally we failed. We ended up with microfrankenservices that had no clear seams. Problem is generally the state gets mixed up throughout the app. Unrelated entities participating in the same transaction for example. References to domain objects everywhere in the monolith.

No, the problem is it can be extremely easy to break services into microservices, especially using the slick tools I've seen in Azure (I'm sure other providers have them as well). They just work, and they're cheap!

But then you realize debugging and refactoring is way harder, and you aren't getting any real benefits from splitting things apart like that.

The system you build initially when you're not exactly sure how your product or business are going to work should definitely not be the system that you then take and "scale up" to 100+ developers. Any expectation of doing that is foolhardy and a sure recipe for never emerging from the tarpit of microservice complexity.

What on earth makes people think the responsibility divisions they make on day 1 are going to be the right responsibility divisions further down the line? Transplanting parts of your data model across boundaries is a complex and painful job.

The first developer (who was fired) of the startup I am working for exactly presented this arguments. Not having any experience in developing and maintaining any real system and reading some consultants' blog he was confident that the microservice architecture will solve all the problems. The product got delayed by months, extremely buggy and (god knows why) it was an asynchronous architecture (the front-end would have to poll for basic CRUD operation). This costed us losing a big customer.

If you are starting out, please make sure the complexity and development overhead for a microservice is worth it. Don't listen to hypes.

They don’t NEED to

It will be made so trivial to do so it will be impossible to avoid it

Medium will be awash in howtos, github will have 9,000 CLI tools to generate yml templates for all this shit

Nothing stopping us from taking advantage of this and building local hosted Docker/Kube setups importing from github what they need to run private social media portals for friends and family, with dynamic DNS and other tools for finding each other

No. The real use cases for true microservices are only 10% but at this point in the hype cycle you would be crazy to even suggest that would design/develop a monolith. You will be looked upon as someone from another generation. This is so unfortunate but it’s the reality in a lot of organizations that I see.

Also read as serverless and you will understand the hype. I think depending on the type of application I'm building I would use either approach. I also am a fan of having both approaches where sensible, but only if I'm already deploying to the cloud. If I'm on local hardware I don't care it can all be monolithic until something in my service requires more dedication.

Monoliths can be serverless, too. On Azure you can just shoot something off to an app service, for instance.

I dont consider app service serverless. Azure has Functions as their serverless offering. I consider App Service as a shared hosting platform.

I think this really begs the question of what exactly is meant by a microservices architectures. In my mind this is one of those subjects that is almost infinitely variable, producing a range of responses from everyone you ask. Personally, I contribute to this mess by thinking that a great way to start an MVP is as a monolith organized into microservices, that is, to adopt some of the the build-time organizational concepts but to just run it like any old monolithic app, without the runtime complexity of a "true" microservices stack.

i think anybody saying the word "microservices" is bullshitting. it's just services. if you are doing api requests anywhere from inside your app - you're already doing "microservice architectures". db is a "microservice", kv store is a "microservice", etc. that 90% figure relates to something so vague that it's possible to argue it's already true, no need to wait until 2022.

I also think it's crazy. Even in JVM land, spring boot is quite fast at getting a POC done. Setting up infra for microservices when you are rushing for demos is too much.

(not an expert)

I think that's exactly wrong. Microservices might end up winning because there will be no infra to set up. Microservices communication and scaling is a pretty generic problem: it is automated and cloud providers offer managed solutions (eg Serverless). In the end, you just deploy code.

At the other side of the room, monoliths always need some custom provisioning and deployment. If it has to evolve into more than a monolith (queue, workers...), it's that much more infra to setup and maintain.

I don't think people talking about microservices for POCs and MVPs are talking about maintaining your own cluster and handling scaling yourself. You go for managed solutions that allow you to focus on delivering value.

For startups that matter, the need to break up the monolith will surface pretty quickly. When a single database can no longer handle the traffic anymore, and/or the eng team size grow past 100 or so.

Also, as tooling improve, developing microservice is not that much harder than developing monolith.

Why does scale suddenly warrant microservices when we’ve had countless examples of successful sites that scale without them? I agree microservices seem to be a reasonable decision to make if you find yourself with 100 engineers. But let’s not conflate something that falls out of conways law with the idea that it’s also necessary to get computers to serve more users.

Interesting. One of the heavily marketed advantages of using micro-services is the ability for individual sub-systems to scale independently of one another, which is obviously a cost optimization that matters once you reach a certain scale, but is isolating components to dedicated teams the larger advantage?

The comment you replied to mentioned "startups that matter" that have significant scale and have 100+ engineers. I think if you're at that point it makes sense, but when you're finding product/market-fit and have 1-2 founding engineers working on a codebase, is it safe to assume micro-services are a premature optimization that unnecessarily add to a founding team's already heavy workload?

Conway's law.

The only real reason for microservices is a big team.

Microservices should reflect your organisation.

A monolith is a small team.

Microservices and their infrastructure are shit to maintain on a small team. There is more overhead in that than monolithically designed software. The best use of microservices on a small team is for appropriate reusable services with low maintenance or almost no maintenance at all.

> One of the heavily marketed advantages of using micro-services is the ability for individual sub-systems to scale independently of one another, which is obviously a cost optimization that matters once you reach a certain scale, but is isolating components to dedicated teams the larger advantage?

It's not like this is a new and unknown opinion... It's been repeatedly pointed out for years now.

Conway's law just names the reasoning behind it ;)

https://en.m.wikipedia.org/wiki/Conway%27s_law

For sure, I was just hoping to get some clarification. I'm by no means a micro-service expert.

You can have diferent components scale differently in a monolith.

Reply on news.ycombinator.com