12 ms·

Here's a quote from https://grugbrain.dev/ https://grugbrain.dev/ (discussed here on HN a while ago) which seems very appropriate: > Microservices: grug wonder

• ducharmdev 4y ago
  grug is the peak of SWE wisdom to me
• nostrebored 4y ago
  Seems like grug only works on tiny teams and on undifferentiated problems
  • forgetfulness 4y ago
    Well yeah, there's cases where it makes sense. I was once on a team dedicated to orchestrating machine learning models and their publishing in a prediction service. The training-to-publishing process was best kept an atomic one, and its Scala codebases separate and distinct from the Java monolith that called it, despite being the only caller and not benefiting from asynchronicity in the call, this design, implementation and operation of a very profitable part of the business was way more convenient than having tried to shove the prediction logic inside the caller. But there are teams that will be splitting every damned endpoint of a service into their own process, that's just unnecessary overhead from whichever way you look at it; network, deployment, infrastructure, monitoring, testing, and deployment again because it bears repeating that it complicates rollouts of new features.
  • roflyear 4y ago
    You miss the point. Fucking up your infrastructure isn't a solution to organizational problems.
    • benreesman 4y ago
      Bingo. In the long tradition of COM/CORBA, XML World, capital-A Agile, micro-services are hard to argue against because people fucking freak out if you push hard, because it’s a career path.
• LewisVerstappen 4y ago
  If you have a large engineering team (hundreds+ devs) with a large codebase then having a monolith can slow down developer velocity. There’s massive scope with the monolith, build tools start to strain, etc
  • strix_varius 4y ago
    Interesting. I found working on FB’s monolith to have, on average, higher velocity and fewer blockers, than working on microservicified systems at other places 2+ orders of magnitude smaller in both engineering and codebase size.
    • roflyear 4y ago
      Agreed.
    • ddenchev 4y ago
      It is not fair to compare the Facebooks monolith and the monolith at the average company, as they are not really the same thing. The tooling available at Facebook is built and maintained by a team larger than the engineering departments at most companies. There comes a point, where regular off the shelf tooling does not scale sufficiently well for a monolith. Tests suits and builds start to take too long. Deployments get increasingly complicated. Developers start to get into each other's way, even when working on unrelated features. Additionally, if you are using an untyped, interpreted language, keeping a large app well organized can also be a problem. Microservices is a tool for dealing with complexity and certainly not the only one. However, building the tooling and infra for a large and sophisticated monolith is not simple and not guaranteed to be an easier solution to the problems listed above.
      • strix_varius 4y ago
        How is this relevant? My comment is in response to an observation about "large engineering teams," not "the monolith at the average company." At the average company, standard tools will work fine, while companies with large engineering teams have the resources to maintain custom tooling.
• cosmic_quanta 4y ago
  I didn't know about this website. It's hilarious. Thank you for sharing.
• ren_engineer 4y ago
  fundamental problem is cargo cult developers trying to copy massive companies architectures as a startup. They fail to realize those companies only moved to microservices because they had no other option. Lots of startups hurting themselves by blindly following these practices without knowing why they were created in the first place. Some of it is also done by people who know it isn't good for the company, but they want to pad their resume and leave before the consequences are seen. same thing applies to Leetcode style interviews, no startup should be using them honestly. They are for established companies that have so many quality applicants they can afford to filter out great candidates
  • vinnymac 4y ago
    I have seen the resume padder on many occasions, and have had to clean up after they left. It's amazing to see a team become visibly happier with their day job when you move to sensible foundations based on sound reasoning. The teams that were the most efficient, and happiest with their day to day were the ones which picked frameworks with good documentation, a plethora of online resources, and ignored the latest shiny toy on the market.
    • hinkley 4y ago
      What's amazing is how often people have to see it to believe it. One of my running jokes/not jokes is that one day I'm going to hire a personal trainer, but then instead of having them train me, I'm just going to ask them a million questions about how they convince people who have never been 'in shape' how good it's going to feel when they are. Because that's what it often feels like at work.
    • robocat 4y ago
      Wouldn’t it be an engineer’s hell working at a place that employs based on resumes from resume driven developers? You learn the latest shiny tech, then change jobs to a new company using your sparkling resume, self-selecting for companies that like the beautiful sparkles in your resume, then you get to work with other like-minded sparkle tech lovers. At what companies do resume padders end up in? Quote from elsewhere in thread: “Whatever is the new thing, jump on it hard and fast like your life depends on it.”
• ezekiel11 4y ago
  5 years ago this was very much true but with serverless services, it drastically lowered the cost of overhead. It is more work but the goal is always to move away from monolith and to reap the benefits. We are past the Backbone.js phase of Microservices from jQuery phase into React phase. An established standard with dividends that pay later is being realized. I just no longer follow these microservice bashing tropes in 2022, a lot has changed since that Netflix diagram went viral
  • pclmulqdq 4y ago
    You still pay that cost with your wallet, it's just hidden from you when you look at your code. The main monetary benefit of serverless is that you can truly scale down to 0 when your service is unused. Of course, writing a nice self-contained library that fits into your monolith has the same benefit.
    • ezekiel11 4y ago
      • mattmanser 4y ago
        They already run cloud VMs sharing CPU, the sharing already happens so why would it be somehow magically cheaper? And how do you think they make money? Every second of a serverless architecture is probably 100s or 1000s times more expensive than a second of a traditional server. Use your brain for 10 seconds, it's obviously going to be ridiculously overpriced for the compute you actually get. That's how they make money. And on top of that they have to do so much more orchestration and overhead to run it. And bonus points, you're now locked into their architecture too! If you have enough load to have a dedicated machine running at 10% CPU load on average, it'll be cheaper running a dedicated machine than anything else, you probably looking at old school VMs costing 2x more, cloud servers 10x more expensive and serverless would probably be at a minimum 20x more expensive. We're not luddites, you're just a sucker.
        • 4y ago
• reidjs 4y ago
  I translated this to plain english! https://github.com/reidjs/grug-dev-translation https://github.com/reidjs/grug-dev-translation
• com2kid 4y ago
  I once worked with a system where all local functions calls had parameters serialized to XML, sent over, then deserialized by the calling functions. The framework was meant to be network transparent, remote calls looked the same as local calls, everything was async, and since everything used service discovery you could easily refactor so that a locally provided service was spun off to a remote computer somewhere and none of the code that called it had to change. So anyway 50% of the CPU was being used on XML serialization/deserialization...
  • pulse7 4y ago
    IBM has a hardware for that and it is called "IBM WebSphere DataPower SOA Appliance". It has special hardware-accellerated XML processing...
    • sonthonax 4y ago
      How does such a thing work? Parsing XML is full of branches and dynamic allocations that general purpose CPUs are good at.
      • kqr 4y ago
        I would assume it works by encoding primarily a strict, predictable format. And when decoding, primarily accelerating the stricter, more predictable parts, and including some regular CPUs for the difficult bits.
    • indymike 4y ago
      There was also a version that would automatically turn JSON into XML and vice versa. When REST started pushing out SOAPy stuff, we actually had a meeting where the sales guy (at the behest of our XML loving CTO) showed us a diagram that was roughly this: Web ------------- Premisis JSON ---> || ---> XML JSON <--- || <--- XML Price was $9,600 for the 2U appliance that makes all your non-enterprisy JSON into something fitting of today's modern enterprise, circa 2001. To this day, I laugh when I think about it.
  • codethief 4y ago
• wvh 4y ago
  At first, you're ignorant. Then, dogmatic. And then you learn what to apply and when. Due to the average age of programmers, a lot of people fall into the first two categories.
  • hinkley 4y ago
    An analogy that seems to connect with some people at least: You know the Martial Arts movie trope where 20 minutes into the movie, the master tells the student never to do X, and then in the final battle the student only triumphs by doing X? That's because what you can do and what you should do changes as you figure out what you're doing. The rule applies to you until you understand why the rule doesn't apply to you/this situation. The subtlety here is in knowing the difference between "the rules don't apply to me" and "I understand the situation where the rule is reasonable, and safe, and either this is not one of those situations, or 'safe' doesn't address an even bigger danger." The former is the origin story of the villain, the latter the origin story of the unlikely hero. Or less dramatically, it's Chesterton's Fence.
• Tabular-Iceberg 4y ago
  Is there ever a good reason to change from monolith to microservices unless you have already solved the factoring problem in the monolith? The factoring problem doesn't get easier because you add network calls into the mix, but being well factored first makes adding the network calls a lot easier. If you're lucky your framework or platform already has that part figured out. Maybe one exception is if you absolutely must change the programming language at the same time, but even then I would suggest doing the rewrite as a monolith first for the same reason, so you again don't have to deal with network calls at the same time as solving an already insanely hard problem. There's the argument that microservices lets you gradually replace the old monolith piece by piece, but there's nothing special about microservices for that, you can do that with two monoliths and a reverse proxy. And at the end of either you might find that you didn't need microservices in the first place, you just needed to factor the application better.
  • Thetawaves 4y ago
    The benefit of microservices is that you can divide areas of responsibility among teams and (theoretically uncouple the change processes for each)
    • majormajor 4y ago
      Dividing areas amongst teams is only a theoretical benefit if you haven't solved the factoring problem. Otherwise teams are still going to be cross-dependent on other teams constantly. But if you've solved the factoring problem, your team and another team can happily work next to each other in the same codebase with less back-and-forth anyway. And the question reduces largely to if you deploy it all at once or not. Sometimes all at once is much easier anyway. I've seen microservices used by management as a way to force engineering into factoring their shit correctly far more often than I've seen it done because things were already factored well (because cross-team coordination in different services is much harder than just jumping around in the monolith's single repo in a single PR). It's an easy lever for management to pull, too, because most devs don't see it as something they're being forced to do, they think they're getting their wish at rewriting and modernizing things. ;)
• GnomeSaiyan 4y ago
  Off topic, how is the .dev domain hosted? Does anyone know? I bought a .dev to host my own website but found out Bluehost doesn't support hosting .dev websites.
  • bussierem 4y ago
    I have a .dev domain that is hosted through Google Domains. I _think_ that Google owns that TLD, or something. They run https://get.dev https://get.dev too.
  • arcdigital 4y ago
    There's nothing special about hosting a .dev domain except for the HTTPS requirement. .dev domains require you to enable TLS on your site.
  • justinludwig 4y ago
    There's nothing special about .dev domains, other than they're automatically included on Chrome's HSTS preload list (so Chrome won't let you connect to a .dev website unless it has a valid HTTPS cert). If Bluehost says they "don't support" them, they probably don't know what they're doing. This is what you'd typically do to point a custom domain (eg example.dev) that you've registered through one DNS-hosting company to a website that you've set up with a different web-hosting company: https://docs.netlify.com/domains-https/custom-domains/configure-external-dns/ https://docs.netlify.com/domains-https/custom-domains/config...
• hedora 4y ago
  > Pick something easy to start with, like edge services that have little overlap with the rest of the monolith. You could, for instance, build an authentication microservice and route login requests as a first step.