> Now you went from writing bad code to building bad infrastructure
just write bad infrastructure as bad code. Get on with the times
Monoliths Are the Future
281–290 of 567 posts
Re: Monoliths Are the Future
#282There 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…
I have this idea for a new framework/language. I'm sure if it either already exists or it's a dumb idea in practice but anyways. You build a monolithic application. Everyone works on the same code base. Things are broken up into modules/classes/packages. From the programmers point of view it's just like working on a standard Java project or something similar. The magic happens at the method and module boundaries. Whe…
Why exactly do you want to independently scale a hot code path? If its hot, its already using most of the resources in your monolith. Take your monolith, distribute it to more servers, and it will reduce the load of your other servers regardless of which parts of your code are causing the load.
Re: Monoliths Are the Future
#283Earlier quoted context omitted.
I do not claim expertise here, but it would seem like microservices would add significant performance costs. Stitching together a bunch of results from different microservices is going to be a LOT more expensive than running a query with joins.
If you already can't serve your requests from one DB, and you already want to factor out the analytics stuff, the long running background queries, modularize the spaghetti, scale the maintenance load, CI build + testing time, etc... That's what SOA and microservices is supposed to solve. At that scale you do reporting from a purpose-built service. Allegedly.
We do a lot of reporting that when. Then the users are unhappy that the data is slightly "stale". It serves some purposes, but not all purposes.
Re: Monoliths Are the Future
#284Microservices are only useful when your engineering org is too large and you need to enable the engineering process to scale. If you're at the point where you can't deploy code because the engineering team is stepping on each other, that's the point where microservices come in handy.
But it also requires a heavy investment in dev-ops and on-call issues. Because when one small thing fails, it becomes catastrophic in ways you can't imagine. So there's a huge tradeoff between engineering convenience and actually customer impact and uptime risk.
Re: Monoliths Are the Future
#285Earlier quoted context omitted.
Kelsey Hightower is a rather pivotal person in the Kubernetes world. It's unusual that he's basically cautioning people not to use the system he's so involved in. His point is that many people are doing microservices wrong
Kubernetes is a deployment strategy. It should be orthogonal to microservices. I'll delete the comment if I was unnecessarily cruel or missed the sarcasm. It was not intentional. But it is important to understand that you want to think of persistence and deployment coupling as independently of your microservices strategy as possible. The vast majority of problems we see with people implementing microservices is peopl…
>K8S's great. It's just not relevant here.
It is very relevant though as it has become so tightly connected with microservices and if you are one of the most well known people in the Kubernetes world you will see a lot of applications that should not be microservices.
Re: Monoliths Are the Future
#286My experience is that devs, devops and admins are striving for better and more robust operations and software development workflow that in the end will help out company in multiple ways. So they read what's new and learn and adopt new approaches and tools. But BI department just want to keep working with Excel because they don't know and don't want to spend any effort learning anything new. So now you have a conflict. Scary microservices vs good old comfy db select queries and excel.
Re: Monoliths Are the Future
#287Earlier quoted context omitted.
The author is a Kubernetes expert, so perhaps you are the student and not the master? https://github.com/kelseyhightower/kubernetes-the-hard-way
A person’s perceived status shouldn’t win them an argument.
No, but the dude works at google and has written that and other books about Kubernetes so obviously he knows about scaling parts of a system and huge organizations working on software together.
That is not what he is commenting on here though. It is that microservice architecture is starting to become the default pattern on how to build applications for a lot of people. Instead it should be an exception when you reach those very specific problems that most people don't have.
Re: Monoliths Are the Future
#288The title mentions that Monolith is the future, but fails to explain why. Either way, let's focus in two items:
> We’re gonna break it up and somehow find the engineering discipline we never had in the first place.
Indeed. I worked in a company that had a monolith, but the project was structured in modules. Every module had a Facade, which was the official way of communicating. Although in practice you could access other modules' entities, you weren't allowed to do that. As you can imagine, this rule was broke many, many times. Developers would look at the entity and see the data they want was there and ignore the facade right way, plain and simple.
If you split your project into separate services, and those services aren't in the same runtime application, there is no way to break this rule anymore. The team that didn't follow the rules has no other choice, it has to go through the APIs. Even better, they won't design the API themselves most of the time. Whoever maintain the service will want it to be cohesive, and will not care that much about the other team need to an urgent fix. Putting workaround becomes way harder, and this change alone improves design a lot.
The second point is that anyone that shared the same service/application with another team probably faced the situation where you couldn't deploy (or was too afraid to do so) because the other team pushed a lot of new code to master. You suddenly don't know if the deploy will break everything or not. When you see, you're spending a lot of time coordinating with many people about whether you can deploy it or not. Something that should be in production if a few minutes sometimes get delayed for days.
Of course that microservices are not a silver bullet, and there are teams that will benefit a lot from a monolith. With that said, I find hard to believe that monollith will come back in companies where the development team grew to be more than a few developers, because the trade-offs are not worth it.
Re: Monoliths Are the Future
#289Earlier 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…
> It can be done wrong, but when executed correctly [...] Quite the self-fulfilling prophecy there. > Yes, it's easier to get your data, but in the long run [...] Systems can and should be evolved and adapted over time. E.g. deploying components of the monolith as separate services. You can't easily predict what the requirements for your software going to be in say 10 years. And depending on the stage a company is, e…
> easy access to data for business decisions outweighs engineering idealism
I think there are different levels of sophistication of "engineering idealism". GP talks about "data ownership", and I get the desire to keep the data a microservice is responsible for locked in tightly with it. But let's be precise why it's good: because isolating responsibility reduces complexity. Not because code has some innate right to privacy.
In my own engineering idealism, there's no internal data privacy in the system. Things should be instrumentable, observable in principle. If an analyst wants to take your carefully designed internal NoSQL document structure and plug it into an OLAP cube for some reason, there must be a path to doing that; if that's an expected part of the business, the service needs to have it on the feature list, that this should be doable without degrading the service.
Software needs to be in boxes because otherwise we can't handle it mentally, but the boxes really shouldn't be that black.
Re: Monoliths Are the Future
#290My 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 r…
My previous company went this direction. I wouldn't recommend it.
Say you version each module and pull in specified versions. It'll work fine, right up until two modules both try to pull different versions of a third module. In practice, you have to update multiple modules at once to avoid conflicts, which, in turn, can require updating other team's code.
It also turns out some tools like Maven don't prevent conflicts by default. You can end up exploring pom.xml files in Eclipse, trying to add exclusions, or figure out which repo is dragging them in.