Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoliths Are the Future

changelog.com

Post reply on HN
Print view View original

211–220 of 567 posts

Re: Monoliths Are the Future

#211

Post by notJim »

closeparen wrote: post #57

My employer adopted microservices for a very specific reason: it became nearly impossible to deploy the monolith. With hundreds of commits trying to go out every day, probability that at least one would break something approached 1. Then everything had to be rolled back. Getting unrelated concerns into separate deployable artifacts rescued our velocity. It came with many of its own challenges, too! A great deal of in…

Wouldn't continuous deployment and rolling forward be better than switching your entire application architecture?

In this scenario, you deploy ~30 times a day. If there's a bad commit, you revert it, and then do another deploy. So there's no rollbacks, you don't lose as much velocity, and since deploys are safe and a reverted commit is just a new commit, the revert is safe too.

Re: Monoliths Are the Future

#212

Post by joefkelley »

willvarfar wrote: post #190
BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

https://prestosql.io/ It can access all those different databases. You can also make your own connectors that make your services appear as tables, which you can query with SQL in the normal way. So if the new accounts micro-service doesn't have a database, or the team won't let your analysts access the database behind it, you can always go in through the front-door e.g. the rest/graphql/grpc/thrift/buzzword api it ex…

It's been about 4 years since I've been in this world, but I remember there being several products all doing a very similar thing: Presto, Hive, SparkSQL, Impala, perhaps some more I'm forgetting. Is the situation still the same? Or has Presto "won out" in any sense?

Re: Monoliths Are the Future

#213

Post by baq »

thrower123 wrote: post #58
eternalny1 wrote: post #35

What is old is new again. I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess. Sometimes, if it's not broke, don't try to "fix" it. I can say th…

I can't imagine your level of cynicism. I've only been at this for ten years, and the number of times I've seen the wheel come full circle and old ideas come back into vogue, the problems with them rediscovered, reactions to those problems, and then the thing that preceded them again take precedence is somewhat depressing. At best I feel like we are grinding ahead a few inches each cycle.

Same boat, same feeling.

Re: Monoliths Are the Future

#214

Post by tootie »

BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

This is what gave rise to data lakes. The typical data lake maturity model I see in enterprise is:

1. Pay a ton of money to Microsoft for Azure Data Lake, Power BI, etc.

2. Spend 12 months building ETLs from all your microservices to feed a torrent of raw data to your lake.

3. Start to think about what KPIs you want to measure.

4. Sign up for a free Google Analytics account and use that instead.

Re: Monoliths Are the Future

#215

Post by 0x8BADF00D »

one2know wrote: post #83

Perhaps the solution is a single server where one can drop a zip file containing their microservice and have it automatically deploy without the hassle of setting up a new pod/server/container. Congratulations you have reinvented java servlets 1.0 circa 1996.

It already exists: AWS Lambda.

Re: Monoliths Are the Future

#216

Post by davnicwil »

eightysixfour wrote: post #113

Monoliths and Microservices are technical expressions of organizational structure. Talking about them in only a technical sense misses the forest for the trees, IMO.

Completely agree and actually think this is the root of the problem.

People look at what really big successful companies are doing and draw inspiration from that. Problems come when they mix up cause and effect, and then view things through the wrong lens.

As you say, microservices are a mostly organisational, partly technical, effect of having to scale a huge techincal org. But then when taking this end state and viewing it purely through a technical lens (as, naturally, technical people are wont to do) it's rather easy to convince yourself that it's actually the cause of this huge technical org's success.

Re: Monoliths Are the Future

#217

Post by notJim »

tynpeddler wrote: post #181

There are two big reasons to go to microservices (note that the exact definition of microservice can vary a lot). 1. Organizational streamlining. If the team working on the monolith becomes to large, then coordinating and pushing out changes quickly can become incredibly difficult. One rule of thumb I've heard is the two pizzas rule. If two pizzas can't feed the team working on a system, it's time to break up the sys…

Regarding point 1, why is coordination required? I think that continuous deployment, where you're integrating dozens of times per day solves this problem much better.

Re: Monoliths Are the Future

#218

Post by NicoJuicy »

wtetzner wrote: post #207
echelon wrote: post #140

Earlier quoted context omitted.

> But you do not simply go and poke your reporting fingers into individual service databases. This is why I distrust all of the monolith folks. Yes, it's easier to get your data, but in the long run you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. Monoliths are undisciplined and encourage unhealthy and unsustainable engineering. Microservices enforce separat…

> you create unmaintainable spaghetti that can't ever change without breaking things you can't easily surface. How does creating a tangle of microservices (effectively distributed objects) really solve the problem?

Constructed good, it's Ravioli and not spaghetti.

Re: Monoliths Are the Future

#219

Post by baq »

uncletaco wrote: post #109
9dev wrote: post #50

Earlier quoted context omitted.

I'm totally with you here, but from my experience with a chaotic team, people end up doing weird things when they have access to the full database from every microservice: say you have an authorization service and several applications with a public API that rely on tokens signed by that service. Suddenly we get a requirement to automatically generate a user account when something happens in another application. I did…

> The developer even went the extra mile to copy-paste the token generation method into their code. I had to make an authorization service and the idea to use a single authorizer to handle token generation and authorization was shot down by management due to worry about "lambda startup times". I complained that the startup time is less than a second (for nodejs) and honestly would not be an issue. They gave the task…

Why is management making engineering and architectural decisions? Reeks of micromanagement. Tell them to solve people problems and let engineers solve technical problems. Update your resume regardless of outcome.

Re: Monoliths Are the Future

#220

Post by tootie »

closeparen wrote: post #57

My employer adopted microservices for a very specific reason: it became nearly impossible to deploy the monolith. With hundreds of commits trying to go out every day, probability that at least one would break something approached 1. Then everything had to be rolled back. Getting unrelated concerns into separate deployable artifacts rescued our velocity. It came with many of its own challenges, too! A great deal of in…

The solution to this is just writing modular code and using an artifact repository. It's a model I've rarely seen attempted even though it's much easier than microservices and serves the same purpose.

You can have individual dev teams, with their own repo ,backlogs, own stakeholders, etc all working at their own paces. They build modules (jars, nuget packages, npm modules) and deploy semver versioned artifacts to a repo like Nexus or JFrog. Any frontend/consumer applications can build towards versions of those modules and upgrade on their own schedule. Only the consumers need to worry about deployment.

This gives you the organizational flexibility but not the infrastructure overhead.

The discriminating factor that makes microservices necessary if these individual services have divergent hardware needs.

Post reply on HN