32 ms·

Don't start with microservices – monoliths are your friend

• paulsutter 5y ago
  Monoliths and microservices are two bad ways to develop software. Monoliths are rife with hidden dependencies and microservices tend to collapse from even simple faults Need to rightsize the modules. More than one, but just a few with boundaries chosen around recovering from faults
• k__ 5y ago
  No wonder, you have a bad time, if you associate microservices with k8s.
• baash05 5y ago
  I find with microservices, they are a fake separation of concerns. When I have to work on something, and it covers two or three services, I'm actually working on a mono app. I've found smaller "service" classes that do one job meet the same need. One or two public methods "perform" and "valid" seem to work perfectly.
• locallost 5y ago
  > What if the product (department) doesn’t give a damn about the underlying system architecture? I mean shall they? They should not. Either it works correctly, or it doesn't. Even buildings need to be useful, even though people might admire the architecture. No non-technical person will admire your microservice or whatever architecture.
• Aeolun 5y ago
  Don’t end with microservices either. Monoliths are your friend.
• kulikalov 5y ago
  Nice article! Although I think you are overdramatizing microservices complexity a little. - Kubernetes is rather a harder way to build microservices. - DB is not an obligatory part of microservices. - Kafka isn't as well. It's a specific solution for specific cases when you need part of your system to be based on an events stream. - Jenkins is not necessary, you can still deploy stuff with a local bash script and you need containerization whether you are on Microservices or Monolyth architecture - Kibana, Prometheus, Zipkin are not required. But I think you need both logs aggregation and monitoring even if you have just a Monolith with horizontal scalability. Also, all this is assuming you are not using out of the box Cloud solutions.
  • formerly_proven 5y ago
    > - DB is not an obligatory part of microservices. If the microservices don't have their own store, but are all mucking around in a shared data store, everything will be much harder. I wouldn't even call that a microservice, it's a distributed something. It can work, sure.
    • deepstack 5y ago
      DB is needed period, unless you want to go blockchain, DHT route, which is not the way to go with most applications.
      • laputan_machine 5y ago
        DB isn't needed. Our microservices pipeline either uses MQ, EFS or S3 for the destination for another pipeline to pick up. Unless you count those 3 as DBs ;)
        • deepstack 5y ago
          Yeah I would say those are key value document based DB. Just silicon valley hipster coming up with cool names to call something different so it is a bit easier for developer to use. Anything does permeant storage are DB.
          • laputan_machine 5y ago
            You could argue S3 is a key-value store, however ActiveMQ is a message queue, and EFS is essentially NFS. I certainly don't agree that 'anything that does permanent storage is a DB'. Not many people would call their hard drive a 'database' I personally think that they all have a place and are very useful tools for certain situations, depending on the problem.
    • makeitdouble 5y ago
      I'd see a "distributed something" that takes an input, processes it in multiple ways, possibly passing it around to some APIs or queuing it somewhere without ever needing to store it in its own dedicated area to be a good idea. That could probably the best instance of something that can be built outside of the monolith and can be manipulated separately.
• 02020202 5y ago
  the main issue with micro-services these days is that people write small applications and think they have a micro service. whereas in reality, they have SOA. a true micro service is a mere worker to process a queue, like send emails. create thumbnails for uploaded images. or delete obsolete data from database. so the truth is in the middle - have a monolith and if one machine can no longer handle your workers' load, move them out into separate MICRO services.
• ilayn 5y ago
  I can't understand why a blog has cookies and has facebook hooks at this point in time but then teaching architecture undermining whatever the main argument was at the moment of landing.
• jhoelzel 5y ago
  There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. Did you write a 150 repo application that can not be deployed seperatly anyway? welp thats a monolith. You can also build a microservice ecosystem without kubernetes on your local network. We have done it for years with virtual machines. Software defined networking just makes things more elegant. So dont stop using microservices because its "hard" or start writing monoliths because its "easy", because none of that is true in the long run. What is true is that you have a group of people trying to code for a common goal. The way you reach that goal together defines how you organize your code.
  • victor106 5y ago
    >monorepo/monolith/microservices/etc" is -just- the way you organize your code. It’s also about how you deploy your code. If you have 1000 micro services do you have 1000 deployment pipelines? If so how do you manage those pipelines? If not, you sacrifice independent deployment of each micro service.
    • VBprogrammer 5y ago
      I don't even think the deployment pipelines are the problem. If you have 1000 microservices you have 2^1000 possible states of your application based on any of those services being up or down (reality is much more complex). It is genuinely hard to keep that number of services up and running so you then need to be extraordinarily diligent about how you handle failures.
    • jhoelzel 5y ago
      yes and no. i totally get what you are saying but this problem has been solved lately in my opinion. Also deployment is part of code organistaion no? i like to point out the fact that i explicitly mentioned you do not need to decide, you can use both at the same time but i would like to try to answer your point anyway: Maybe I am just spoiled with go and github, but those deployment pipelines can be directly integrated into your repository. The same way I can counter argue that your build ci and deployment phase will take significantly more time too and if you change a variable from uppercase to lowercase you will wait for minutes too. I come from a c# background a long time ago and this has been true with it for eons: https://xkcd.com/303/ https://xkcd.com/303/ Another thing that I have noticed is that its easily scriptable too. What I end up doing is to provide a makefile into my repository too. This way i can define the build process amongst other things eaisly. In the end: We have a predefined spec that will create the desired state on a host of our chosing. Ansible really does not care if you deploy 1 or 1000 "services" for instance! Tools Like ArgoCD will also deploy stuff when you commit to your master. There is tooling for everyone available, but what happnes quite often is that the people in charge of the company expected the developers to be all knowing entities that need to define everything end to end. The Kubernetes Space is vast because we are still defining and communication its future. But recently? I am trying to think of something that would not be completly automateable in 2021
• adflux 5y ago
  Microservices aren't implemented to solve technical problems, rather they are used to solve organizational problems. Having 10 developers working on a single monolith? Probably fine. 100? Good luck managing that. Yes they add technical complexity. But they reduce organizational complexity.
  • BurningFrog 5y ago
    Yeah, I think this is right. Microservices is an organizational optimization. It can allow one team to manage and deploy their own subsystem with minimal coordination with other teams. This is a useful thing, but be aware what it's useful for. If each of your developers manages a microservice, that probably reflects that you do no actual teamwork.
  • kkjjkgjjgg 5y ago
    Wasn't git invented for that? In what way do Microservices even help? It seems to me you still have to synchronize to be sure that the Microservice from team B does exactly the things that are specified in the new version? Is it not easier to have a pull request that says "this will do thing x", you merge it into your monolith, and then you can see in the git log that this version will indeed to x? How do Microservice organizations even manage that? Is it the reason that Atlassian has a billion dollar evaluation, because people need it to keep track?
    • soylentgraham 5y ago
      The only thing you need to synchronise is API, no? Which is where version numbers comes in. To me, if youre working with a lot of modules/micro services, lots of modules should be able to sit on old versions and develop independently (which is the crucial part for 100 developer scenario)
    • kqr 5y ago
      Well, not git, but modularity was invented for that. You can have a modular monolith that works just as well with 100 people as something service-oriented would. The difference lies in the level of discipline needed. It's much easier to "just go in and make that field public because it makes my implementation easier" when you have a modular monolith. With microservices, you are more explicitly changing an external API by doing that. Yes, it's the same thing. But somehow, psychologically, people feel worse about changing a networked API than making an identifier public instead of private. Edit: I forgot, there's one more thing: with service orientation, you can deploy in finer grains. You shouldn't have heavily stateful services, but if you do (and you always do!), it can be cumbersome to redeploy them. At that point, it's nice to be able to deploy only the parts that changed, and avoid touching the stateful stuff.
• kkjjkgjjgg 5y ago
  Maybe I'm too old, but I don't even want to have to worry about all that. I think in terms of functions and I don't care if they are being called remotely or local. That was the promise back in the day of J2EE, and it seems to me Microservices are just a rehash of that same promise. Which never really worked out with J2EE - it was mostly invented to sell big servers and expensive consultants, which is how Sun made money? These days I sometimes don't even bother to make extra interface classes for everything. If I need it, I can still insert that, but no need to do it up front. And "DevOps" is just a ploy to make developers do more work, that was formerly done by admins. Writing every Microservice in a new language also seems like a huge headache. The only bonus is that you can attract developers by being able to promise them that they can work with some shiny new technology. Maybe that is actually the main reason for doing that? Otherwise, again, perhaps it is my age, but I prefer to minimize the dependencies. Do I really want to have to learn a whole new programming language just so that I can fix a bug in some Microservice. I personally don't want to.
  • verinus 5y ago
    I wholeheartedly agree on most parts, with DevOps being the exception. Devs only focusing on developing/writing source code is certainly not the way to produce sustainable, high quality software- at least in my opinion...
    • kkjjkgjjgg 5y ago
      It was a bit cheeky and off-hand. I am certainly interested in DevOps. If things can be automated, it is usually a good thing. Still I think having extra admins for server maintenance, or nowadays DevOps, also makes sense in my opinion. In theory I should be interested, but in practice, somehow I can not really get passionate about the details of how to host things. So it would be better to have specialists who really care. Ultimately there are also a lot of aspects that are different from the programming problems. It's difficult to keep up to date on both fronts.
      • verinus 5y ago
        Ok no argument from me there :) Maintenance and the automation of repetitive tasks are in my view part of DevOps, but not every dev in a team has to participate at the same degree...
• deniska 5y ago
  Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an example of such approach, even though we don't typically call these parts "microservices". A technical reason I can see is some component of a system actually having to be written in a different stack, or to be run in a separate location for business reasons (separate physical computer, separate VMs or containers don't count). Like a firmware running on an IoT system. Or most of the system uses python, but there's a really good library in java for solving some very specific problem, so let's use it. If neither of these reasons stands, you don't have a microservice architecture, you have a distributed monolith. You just replaced some function calls with RPC. RPC call which takes a much a longer time than a local one, and can randomly fail. Most of your microservices are written in a single stack, so you refactor common parts into a library, but then different services are stuck to use different versions of this library. You end up with a much slower and a much more fragile system which is harder to work on for no good reason.
  • bspammer 5y ago
    > no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “distributed monolith” like it’s a dirty phrase but I’ve found it actually a very pleasant environment to work in.
    • fasteo 5y ago
      >>> If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule I call this a worker.
    • goodoldneon 5y ago
• m_mueller 5y ago
  What has worked well for us, something that IMO combines the best out of both worlds: * break down the problem into sensible components. for a reporting system I'm working on atm. we're using one component per type of source data (postgres, XLSX files, XML), one component for transformations (based on pandas) and one component for the document exporter. * let those components talk through http requests with each other, including an OpenAPI specification that we use to generate a simple swagger GUI for each endpoint as well as to validate and test result schemas. * deploy as AWS lambda - let amazon worry about scaling this instead of having our own Kubernetes etc. * BUT we have a very thin shim in front that locally emulates API gateway and runs all the lambda code in a single process. - (big) advantage: we can easily debug & test business code changes locally. only once that is correct we start worrying about deployment, which is all done as IaC and doesn't give us trouble that often. - (minor) disadvantage: the various dependencies of lambdas can conflict with each other locally, so gotta be careful with library versions etc. doing so the scaling works quite well, there is no up-front infrastructure cost and code tends to stay nice and clean because devs CANNOT just import something from another component - common functionality needs to first be refactored into a commons module that we add in each lambda, which puts a nice point for sanity checking what goes in there.
• Havoc 5y ago
  I keep trying to do K8S at home but each time hit a wall of complexity and conclude this is ridiculous. I’m sure has its place for bigger applications though I do like a modular approach though (think docker rather than k8s) which I suppose is partial micro services
  • bdcravens 5y ago
    It has the disadvantages of lock-in, but this is why I love ECS. 80% of the advantages of K8S for 20% of the complexity. Even hosted K8S requires a lot of config and concepts that are just baked into ECS.
• armanm 5y ago
  Monolith and Micro-services at different times during the progression of a business can have their places. I have experienced the pains of having to work with both within the same company over 9+ years and here is what I think are forces that can pull you in either direction. A monolith makes developing initially a lot easier. Over 15 years though, you are bound to have developers of various calibre leave their mark on it. Many don't even understand good modelling and inevitably drive an otherwise healthy monolith with well defined boundaries into a soup of couplings between domain concepts that should not know about each other. In theory though it is totally possible to have micro systems within the same monolith code if you model things that way. Eventually, your team will flip the table and start thinking how to avoid the problems they are having with the monolith and decide to do down the micro-services way. In most situations developers are likely to face a lack of commitment from the business to spend time/money on a technical problem they do not understand but have to support the development of for a lengthy period of time. Most developers will compromise by building pseudo micro-services without their own databases which send requests to the monolith where the core business logic had to stay. The benefit of micro-services IMO is driven from being able to separate business domains in a way that keeps each responsibility simple to understand for a new comer and compact enough to not hide a great deal of complexity. It's worth saying this is a very hard thing to achieve and the average developer shop won't have the experience to be able to pull it off. This is all to say, regardless of Monolith or Micro-services architecture, the key is experience and discipline and without a good amount of both in your team the outcome is unlikely to be a success over a long enough period of time. This is the curse of a business that lives long enough.
  • marcosdumay 5y ago
    > Eventually, your team will flip the table and start thinking how to avoid the problems they are having with the monolith and decide to do down the micro-services way. So, yet another comment saying that modularity requires a distributed system.
    • armanm 5y ago
      That's not what I was saying. I'm saying your team is likely to want to do something drastic and is likely to go down the micro-services path. This is not a comment on correctness. This is a behavioral prediction.
• rory_isAdonk 5y ago
  I always do this, but how do when to re-architect or at what level of granularity to look for optimizations? Do we burn time looking at async processing, do we just scale the cluster, etc
• zuj 5y ago
  I remember reading sam newman and if I am not wrong, he says something along the lines of the team size, problem at hand and few other facts determine which one to choose. Nothing is a silver bullet. Trite, but it's having knowledge of multiple architectures and using the wisdom to choose when to use one.
• vbezhenar 5y ago
  Independent service monolith for each independent team in the company. If something screams to be moved into a separate project, do it.
• asimpletune 5y ago
  Your code base should reflect the organization of people working on it. Virtually all technical merits are outweighed by that.
  • jstimpfle 5y ago
    Or should the organization of people reflect the code they're working on? :-)
    • bdcravens 5y ago
      People are expensive, code is cheap.
      • jstimpfle 5y ago
        That could be an argument for what I said.
  • geoffjentry 5y ago
    This is Conway's Law. It is why the Reverse Conway is preached. Define your desired architecture, and fit your organization to fit it. At that point your code base will reflect the organization of people working on it, and the output will reflect the desired architecture.
    • asimpletune 5y ago
      Exactly! I avoided naming it in my comment, but that’s how I came to learn this as well.
• kryptiskt 5y ago
  I hate the idea of replacing function calls with network requests for organizational reasons, even for a fast network in the same datacenter you add several orders of magnitude of latency to the calls. If the problem is that groups can't work independently of each other in the monolith, it should be solvable with modularization and defining APIs for those modules.
• Aldipower 5y ago
  I am just using services with my medium sized application. They are not "micro", but they separate the domains and different concerns pretty well. I have the deployment setup more or less like a monolith, but still having separation of concerns with my services. And stateless service runners.. Fair enough I have the state in a single (mirrored) database. But this works perfectly fine for the medium sized app. Not sure why everything must be black or white.
  • unbanned 5y ago
    Service oriented architecture then...
  • qxmat 5y ago
    I've felt SOA is the easiest to grow because it encourages you to swap out concrete implementations as requirements change. For example, IUserService can start off with a "local" UserService implementation that makes direct calls to a database. Once you signup with an IdP this might become UserServiceAzureAD/Okta/Auth0. Unlike microservices, I keep my compile-time guarantees that IUser continues to have the properties I require without any tooling. Given the rhetoric here I worry that I'm the only person who's genuinely swapped out their implementation. The ol' "N-tier is stupid - you're never going to change the database" comment couldn't be more wrong.
• pdpi 5y ago
  More and more I think of OOP and services as the same thing at different scales. Objects are services, dependency injection is your service discovery/orchestration layer. Your monolith is already a microservice architecture. In the end, extracting a microservice from a monolith built this way is just a matter of moving the implementation of the object to a separate application, and making the object a frontend for talking to that application. The single biggest reason OOP gets a bad reputation is because lots of languages insist on treating OOP as the be-all end-all of code structure (Java and Ruby are particularly bad examples) and insist on trying to shoehorn this sort of logic into tiny dumb pieces of pure data.
• verinus 5y ago
  I'd sum up with: simplicity is your friend... recently I am getting more and more thoughtful about "accidental" complexity we add to our solutions in form of dependencies on external libs/module, frameworks such as IoC, log services anyone ;) and on the architectural side microservices etc.
• laichzeit0 5y ago
  > One or more (relational) databases, depending on whether you’re gonna go with single database per service or not This imho is where serious complications can come in. A single database for all services is a good trade off if you want the nice parts of microservice decoupling but not the headaches of a distributed system. Just perhaps don’t call it “microservices” to avoid having to deal with arguments from purists who want to explain why this is not true microservices, etc.
  • unbanned 5y ago
    >nice parts of microservice decoupling If you require microservices to enforce decoupling you're "doing it rong"
• usrbinbash 5y ago
  All ideas that are good in principle, become absurd the moment they are elevated to a kind of dogma, applied to every problem, no matter if it makes sense to do so or no. Microservices are no exception from that rule, and often repeat the same mistake as OOP did with its promise of "reusable code". Does it sometimes make sense to break some larger services up in smaller ones? Yes. Does it make sense to "factor out" every minor thing of the implementation into something that can individually be manhandled into a docker container because at some point in the far future, someone may save a few minutes of typing by talking to that service? No. Why not? Because on the 1:1000 chance that what the service does is actually exactly what that other thing requires, it will probably take more time to implement an interface than it would to simply implement a clone of the functionality.
  • marginalia_nu 5y ago
    I've seen organizations that have hundreds of developers organized in 5-10 man teams, each managing their microservice. I think it tends to happen when a large organization decides to get down with the kids and start to do microservices. Conway's law enters into it in a lot of ways. Because of the way the people are organized into tiny isolated teams, the code shares that shape too. There is an event horizon one team/service away, beyond which nobody knows what happens or who wrote the code. What you get is that the services actually don't do that much, except take a request from one service, translate it to an internal format, perform some trivial operation, then translate it to another external format and pass it on to another service. It's a lot of code, but it's not a lot of logic. Add to that maintaining the test and prod environments as code, and suddenly it looks like this is a lot of work, but you've essentially gotten a hundred people to do work that three people could probably accomplish if it wasn't for this pathological misapplication of an architectural pattern.
    • Joeri 5y ago
      Going for microservices without a central director role is indeed madness and leads to inefficiency. My employer has a landscape like that, hundreds of microservices each managed by a different team (some teams manage multiple). However, we have an enterprise architecture group whose job it is to keep an overview and make sure every microservice is meaningful and fulfills a clear role for the organization. Every project presents their architecture to this group as well as a group of peers and this often results in changes that increase cohesion and avoid redundant work. We had a few semi-interconnected monoliths before, and from what I’m told (I joined after the microservice transition) the new way is better. However, I still wouldn’t recommend microservices to a new team / org starting from scratch. IMHO microservices only make sense when the system grows so vast it cannot be understood in its entirety by a single person.
• pantulis 5y ago
  Microservices is kind of a superpower that allows you to choose where you want your complexity to be. You are supposed to start with something simple, so the microservices decision needs to come in later. Not starting full in with microservices is a good pattern.
• naranha 5y ago
  When microservices were new they brought a whole slew of new technologies and architecture patterns with them: SPAs, JWT authentication, micro frameworks, REST/Graphql, containerization. Things that solved problems people were having with the previous monolithic approach, all above the lack of maintainability and composability. So I see the term microservice today not as something that's measured in lines of code, but above all by embracing the new technology landscape that came from it.
• josefrichter 5y ago
  Just write it in Rails, if you ever reach Rails limits, it means you've made it :-)
  • montblanc 5y ago
    They will figure out monolith Rails makes a lot of sense eventually. Or maybe I'm wrong who knows.
• woutr_be 5y ago
  Doesn’t this highly depend on your use case? For example, right now I’m building a system that will take in a URL, crawls the webpage, and does some processing on the data. The whole process takes a good 10 seconds. I designed this as a micro service, simply because I know URLs will need to be queued up. Should this have been done as a monolith? Or am I right that micro services was actually the right approach?
  • baash05 5y ago
    In rails this would be an activejob (part of the mono), and spinning up workers would be trivial. The "workers" would pull off a redis queue, and you could add different jobs to the queue easy-peasy.
    • woutr_be 5y ago
      That's fair, maybe I'm already planning to far ahead. But I ended up using RabbitMQ and Node (since i wanted to use Puppeteer for this, I actually needed to render the webpage).
      • bdcravens 5y ago
        Put Puppeteer calls in a REST API using Express or the like, call API from Activejob/Sidekiq. (I've built this)
        • woutr_be 5y ago
          Does this then not classify as two different micro services?
          • bdcravens 5y ago
            Not, it's adding a single microservice to a monolith.
            • 5y ago
• Philip-J-Fry 5y ago
  The only issue I have with microservices is when you're dealing with atomic things. Like in a monolith you'd probably just stick it all in a database transaction. But I can't find any good reads about how to deal with this in a distributed fashion. There's always caveats and ultimately the advice "just try not to do it" but at some point you will probably have an atomic action and you don't want to break your existing architecture. Distributed transactions? Two stage commits? Just do it and rely on the fact you have 99.9% uptime and it's _probably_ not going to fail? Anyone else dealt with this headache?
  • mark254 5y ago
    Well, a simple solution is to only have one middleware that uses database connections, and have all other things around it be purely functional. (Though that may mean using their own databases, of course).
    • Philip-J-Fry 5y ago
      What do you mean by that? What if I have 2 services, each with their own databases, but the action is supposed to be atomic. E.g. there's a foreign key that links the data. They're both gonna do their own database functions.
  • Quekid5 5y ago
    IME the only sane way to do this is to a) redraw the transaction boundaries, aka. avoid it, or b) don't do it (see below), c) idempotency -- so you can just retry everything until you succeed. You can do distributed transactions, but it's a huge pain operationally. (b) is not always as far fetched as you might think. The vast majority of Real World (e.g. inventory, order fulfilment generally, etc.) systems are actually much more like Eventual Consistency in practice, so you don't gain anything by being transactional when your Source of Truth is a real world thing. Inventory is a great example. It doesn't matter if your DB says that an item is in stock if there simply isn't an item on the shelf when it comes time to fulfill an order for that item. Tracking such things is always imperfect and there already other systems overlaid which can handle the failure case, e.g. refund the order, place on backorder, have a CSR find a replacement item, etc. etc. (Of course you want reasonable approximate values for analytics, logistics, etc.)
• SamLeBarbare 5y ago
  Example of decoupling things in goblins framework (nodejs): one domain give one package/module, domains are now dependencies actors models can act as services, one actor in a domain is a service with an API communicating with other trought event loops or tcp/ip (microservice?) we can develop and debug the whole system in a mono-repo <- the monolith is the repository of code.
• p2t2p 5y ago
  Last five years I'm looking at how my colleagues are struggling to dismantle a king of monoliths to services to enable various teams to move at faster pace and scale different parts independently. Those people couldn't be more wrong. Monoliths are not your friend. Deployment times will be longer, requirements for hosts where you deploy it will be bigger, you will end up with _huge_ instances to rent because some parts of you monolith want more RAM and some want more compute. You'll have to scale more than you really need to because some parts of your monolith are more scalable than another, etc, etc, etc. You'll be unable to use different technologies to optimise that one particular use case, because it has to be deployed together with everything else and you totally don't have any infrastructure to call into another service. You'll be stuck with "one size fits all" technological choices for every component in your system. Monolith is good basically only on PoC stage. Once you have business running, you need to dismantle it ASAP. edit: grammar, spelling, formatting.
  • Mavvie 5y ago
    Good points, but I want to point out some caveats to a few of them. I overall disagree with your conclusion of "Once you have business running, you need to dismantle it ASAP". I think it's a case-by-case thing, and you're ignoring the significant complexity costs of a microservices approach. > Deployment times will be longer Not necessarily. I'd say that when you have multiple changes across boundaries that need to go out together, monolith deployments can actually be faster as you only need to do a rolling update of 1 container instead of N. But if by "deployment time" you mean the time between deploys, I agree. But also...so what? As long as your deployment times are good enough, it doesn't really need to be faster. > requirements for hosts where you deploy it will be bigger True > you will end up with _huge_ instances Not necessarily. Depends on the tech stack, framework, etc. I've seen .NET (and even Rails) monoliths that are huge and only use hundreds of MB/a GB or two of RAM. But I've also seen Java monoliths using 12GB+ to handle small amounts of traffic, so YMMV. > You'll have to scale more than you really need to because some parts of your monolith are more scalable than another A problem often easily fixed with throwing a bit of $$$ at the problem, depending on your scale and per-request profitability.
• dagss 5y ago
  In some companies teams are not divided in a way that follow technical faultlines, but rather after "product owners" so that the only valid divison lines are exteral facing superficial aspects. E.g. think a car company where you are not organized as "engine team" and "transmission team", but rather "sedan team" and "SUV team", and the engine and transmission just need to happen somehow. The microservices fad and "every team own their own services" fad combined can really get performance to a halt in such a setting. Product owners are suddenly the unwilling and unwitting chief architects. At least with a monolith, everything is reasonably standardized and people from different teams can be expected to contribute to larger parts of it..
• solididiot 5y ago
  microservices are such a bad idea for most companies out there. Specially for companies doing onprem SW that suddenly want to "go to the cloud with microservices" without realising that micorservices is the end destination of a long journey involving serious DevOps and a mentality radically different from onprem. It is just so easy to get it or implement it plainly wrong that it is a disservice to most company to suggest ms without a huge warning sign. But...it the CV zeitgeist as Design Patterns and SOLID were a decade ago. These days if you don't do ms and don't deploy to k8s you're not worth your salt as a dev. And if you're a company doing monolith you're not worth the time and money of worthy investors. Our field is pop culture. It's all about belonging and plain averse for history. Which is why we go in endless cycles of dogma/disillusionment. I'm sorry if I sound cynic but you get some cynicism when you see the same movie about the great silver bullet the 3rd or 4th time around.
• KronisLV 5y ago
  I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set of horizontally scaled instances with a few particular feature flags enabled (e.g. multiple web API instances) and maybe some others as vertically scaled monoliths (e.g. scheduled report instance). I wrote more about that approach on my blog, as one of the first articles, "Moduliths: because we need to scale, but we also cannot afford microservices": https://blog.kronis.dev/articles/modulith-because-we-need-to-scale-but-we-also-cannot-afford-micro-services https://blog.kronis.dev/articles/modulith-because-we-need-to... In my eyes, the good part is that you can work with one codebase and do refactoring easily across all of it, have better scalability than just a monolith without all of the ops complexity from the outset, while also not having to worry as much about shared code, or perhaps approach the issue gently, by being able to extract code packages at first. The only serious negatives is that this approach is still more limited than microservices, for example, compilation times in static languages would suffer and depending on how big your project is, there will just be a bit of overhead everywhere, and not every framework supports that approach easily.
  • daitangio 5y ago
    Thank you for sharing, and I agree with you- In my humble opinion microservices are "hot" because in theory you can scale a lot with them if you are able to do cloud provisioning. Microservices needs DevOps+Orchestration Service. A good example of microservices architecture is how K8s is designed: I think it is an overkill for most average needs, so think twice before entering in microservice trip tunnel.
    • KronisLV 5y ago
      Well in my eyes equating microservices with Kubernetes is a problem in of itself. I actually wrote about Docker Swarm as a simpler and more usable alternative to it (for smaller/simpler deployments), though some other folks also enjoy Hashicorp Nomad which is also nice (another article on my blog, won't link here not to be spammy myself). If you evaluate your circumstances and find that microservices could be good for you, then there are certainly options to do them more easily. In my eyes some of the ideas that have popped up, like 12 Factor Apps https://12factor.net/ https://12factor.net/ can be immensely useful for both microservices and even monoliths. So i guess it's all very situational and a lot of the effort is finding out what's suitable for your particular circumstances. For example, i made the page over at https://apturicovid.lv/#en https://apturicovid.lv/#en When the app was released and the page was getting hundreds of thousands of views due to all of the news coverage, scaling out to something like 8 instances was a really simple and adequate fix to not break under the load.
• bayesian_horse 5y ago
  I agree. The only addition: Often it is useful to design with microservices because it means you don't have to create and maintain them yourself. Even a database is a microservice. PhPMyAdmin (and similar) is a microservice, so are other Open Source projects I like: Celery, Sentry, Mailhog, Jupyter, Nextcloud even Caddy or Nginx. All could be considered microservices. Integrating them into your platform often makes a lot of sense.
• phgn 5y ago
  Related classic: https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html
• throw-7462637 5y ago
  At one of the hyperscalers myself. We are actively merging components for performance. We will keep internal modular boundaries where we can and there will be some small number of abstraction violations for performance.
• niros_valtos 5y ago
  It depends on the age of the company and the size of the products. A typical startup company can kick the tires with a monolithic architecture just to deliver a prototype quickly, but a more stable company that builds a products to scale will need to separate some of the services. They may have a big monolith chunk with a bunch of other “new” micro services.
• austincheney 5y ago
  These arguments are always full of assumptions, and typically revolve around some web middleware application connecting to a DB. This noise makes me hopeful that a decentralized model will come along to replace these generic boilerplate concerns with real problems to solve.
• vgchh 5y ago
  While it is easy to start with monolith, it's not easy to just go from monolith to Microservices in case it is determined that's the best path forward. Often organizations don't have the luxury to "learn" by doing a monolith first and then determining the boundaries. In most cases, market pressures, limited budgets keep monoliths monoliths. OTOH, my experience is that it is easier to combine overly granular Microservices into just right size Microservices on an ongoing basis. And yes, infra requirements are bigger for Microservices, but often it is highly automate-able. I think, one of the reasons, besides all the usual reasons, that keeps Microservices in vogue is the ability to align with organizational structure and enabling independent-ish teams.
• wodenokoto 5y ago
  Having worked on some cloud native/ cloud first apps, I would love to see a language or framework a long the lines of a class being a lambda/cloud function, and when calling a method of that class (it doesn’t have to be OOP, someone smarter than me must figure that out) the language itself will sort all the http requests and deployments and junk for you and your project becomes scalable, serveless services but with code that is actually coherent and readable.
  • hchasestevens 5y ago
    You'd probably be interested in Unison ( www.unisonweb.org ). It's a Haskell-style functional language, which aims to make the sort of distributed computing you're talking about easy. The central conceits are: 1. Functions are hashable 2. The codebase and runtime are deployed uniformly to every node 3. Networking these nodes allows functions to be cross-referenced and passed by their hash values Unfortunately, while the "Haskell-style functional language" part is already implemented, it's not clear to me between https://www.unisonweb.org/docs/faq#where-can-i-learn-more-about-unisons-support-for-distributed-computation https://www.unisonweb.org/docs/faq#where-can-i-learn-more-ab... and https://www.unison-lang.org/articles/distributed-datasets/ https://www.unison-lang.org/articles/distributed-datasets/ whether the "make distributed computing easy" part is.
• fnord123 5y ago
  Did someone say Microservices? https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
• ascendantlogic 5y ago
  The real pattern is to write a separate service for user auth and then put everything else into a monolith. The auth service is almost always the first one to be "broken out" so just get that out of the way first. Now you have maximum flexibility.
• jerrygoyal 5y ago
  Managed Microservices > Monoliths > Microservices
• francasso 5y ago
  For the life of me, I never understood, nor will ever understand, why people think making RPCs is easier or leads to better design than making normal function calls ("split your code into microservices, it will make your code modular, smaller and easier to understand!"). There are legitimate reasons to put a network between one piece of code and another, but "modularity" is not one of them.
  • ldiracdelta 5y ago
    Exactly. Injecting 2 NICs and the internet into a function call isn't a panacea. People talk of monoliths as if code libraries don't exist. You can have fantastic independent interfaces with libraries too, if you want them.
• revskill 5y ago
  The cost of starting with microservice is higher than starting witht monothlics. But the cost of splitting a monothlic into a microservice is x10, in some case, impossible.
• lincpa 5y ago
  Whether you choose microservices or monoliths, you can have maximum success by using "The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model". https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
• jcmontx 5y ago
  Discussed to death. Monoliths win unless you have >50 people team. We have to move on as a community.
• AtNightWeCode 5y ago
  Microservices are supposed to be autonomous. Independent services with an own lifecycle. What this article is describing sounds more like what is called a distributed monolith. Too many horizontal dependencies will create problems no matter where they are located. I worked on monoliths where the shortest theoretical amount of time from a commit to running in production is several hours. The way you in a controlled way can change small parts of system with microservices is incredibly useful. What I do see though is people making microservices too small. Like one table in a monolith database becomes one microservice. Microservices is not about having everything loosely coupled. Cohesion rules for modules still applies.
• itoocode 5y ago
  Choose your architecture. Worked with a huge monoliths, business critical, predictable usage, easy debugging, deployment simple, onboarding quick even with less documentation. Worked with microservices, business critical, predictable usage, less documentation here onboarding took long time spent on how it works, Hard to debug, never needed to scale up. (Why microservices ? ) Lessons learnt: Problem is never with the architecture. Why you choose one over the other is the question to ask when you start on.
• softwarebeware 5y ago
  Bad idea: 10 teams jointly maintaining a monolith. Good idea: 10 teams each with responsibility for a separate microservice. It always goes back to Conways Law.
• grouphugs 5y ago
  no
• pshirshov 5y ago
  All true, though monoliths themselves aren't a good alternative. The real alternative is "Roles". Here are my old slides about our DI tool for Scala, implementing Roles: https://github.com/7mind/slides/blob/master/02-roles/roles.pdf https://github.com/7mind/slides/blob/master/02-roles/roles.p... And a couple of talks: https://www.youtube.com/watch?v=o65sKWnFyk0 https://www.youtube.com/watch?v=o65sKWnFyk0 , https://www.youtube.com/watch?v=CzpvjkUukAs https://www.youtube.com/watch?v=CzpvjkUukAs And another post about the same approach from another prospective (monorepo vs multirepo): https://blog.7mind.io/role-based-repositories.html https://blog.7mind.io/role-based-repositories.html
• _hcuq 5y ago
  If you are starting with a new product, micro services are are a premature optimization. They have their place later.
  • dinvlad 5y ago
    Came here to say this. I think most of us suffer from this symptom of wanting to make the system more easily modifiable later etc. by "decoupling" various components, but as a result turn it into an unnecessarily complex blob that ironically makes our lives harder not easier down the road, in many cases. If anything, the overarching theme should be "make it simple, but not simpler" and try not to increase the number of components in the system without necessity, until and when the proper time comes. Doing things like proper testing and CI/CD from the start are much more important because that's what actually allows one to refactor the system later to introduce additional components, de-coupling etc. where needed. Otherwise, all of this is just shifting the complexity around.
• amelius 5y ago
  Yes, microservices are a bad idea. But modern OSes are built using them. E.g. Linux runs as a bunch of services.
• throwaway5752 5y ago
  Services, serverless, and monolith don't have to be exclusive and can be applied in different areas where they are good fits. You obviously can't have a pure monolith and everyone knows that because of geographical distribution, scaling, and availability, let along languages having niches. Monoliths are your friends. SOA is your friend. Serverless is your friend. You don't hang out with all your same friends and do the same things with them in real life, either.
• throwaway984393 5y ago
  In these discussions, people tend to forget the unsexy problem: coordinating work between humans. The reason an architecture is chosen is often purely a result of Conway's law. Just like the code organized on disk is often purely a result of how your language or build tool prefers you organize your code. Subconscious bias controls a lot of what we do, so designing systems partly requires an understanding of psychology and management techniques. If that sounds crazy, just ask W.E. Deming. The reason Toyota came up with TPS was not because they were geniuses, or the discovery of some "magical architecture". They just focused on how to always be improving quality and efficiency - which at first makes no sense at all, and sounds exactly like premature optimization. But the proof is in the pudding.
• nedsma 5y ago
  I've started doing microservices 5-6 years ago, and I don't want to go ever writing monoliths. I don't understand why these articles keep popping up.
• dorongrinstein 5y ago
  Your microservices pains are legitimate. That's why we built the Control Plane (https://controlplane.com https://controlplane.com) platform. Our customers deploy microservices in seconds and get unbreakable endpoints, even when AWS, GCP or Azure go completely down. They get free logging, metrics, secrets management, load balancing, auto-scaling, MTLS between services, service discovery, TLS, intelligent DNS routing to the nearest healthy cluster and much more. Multi region and multi cloud used to be hard. Now they are as natural as clicking a button. Before you write part two of your article, give the https://controlplane.com https://controlplane.com platform a try. One you've tried it - I'm 100% convinced you'll make a 180. I'm happy to personally demo it for you.
• kortex 5y ago
  This feels very FUDy. It gives a bunch of examples of ways in which microservices can go wrong, without empirically examining those claims. It also excludes the middle: you can have "milliservices" (really, just service-oriented architecture) which do more than route a single endpoint, but still give flexibility and scaling. We are a young startup in the ML-service space, with about a dozen engineers + data scientists. Our stack is based on all docker containerized python. We have 6 "micro"-services (not sure at which point they become micro) but each plays their own role, with ~4-30 REST endpoints each. It's been fantastic, and none of us are particularly experienced with microservices. We run on AWS east but you can spin most of the stack up locally with docker-compose. I don't even need k8s, if we wanted, we could probably deploy a local cluster with docker swarm. - Fault isolation I can't talk in depth but we were able to handle the recent east-1 outage with only parts of the stack degraded, others stayed functional. Also, rollout is most likely when something will fail. Rolling back a services is way easier than disrupting the whole stack. - Eliminating the technology lock The ML container is a massive beast with all the usual heavy ML dependencies. None of the other containers need any of that. - Easier understanding Yep, definitely true in my experience. The API surface area is much smaller than the code under the hood, so it's easier to reason about the data flow in/out. - Faster deployment We can easily patch one service and roll it out, rolling out hotfixes to prod with no disruption in the time to run through the CI pipeline, or roll back a task spec, which is near-instant. - Scalability Emphatically so. The difference in scale between our least and most used service is over 100x. We could probably get away with making the user-facing backend a monolith (and in fact it's the most monolithic, has the most endpoints) but for data pipelining, micro/"milliservices" has been a dream. I don't even know how it would work as a monolith. As with everything in this field, it all depends on use-case and tradeoffs. If your services each handle roughly the same load, the independent scaling argument weakens. If your business logic is complex, tightly coupled, and fits on a single box, you'll waste a ton of cycles just communicating.
• shrrrrrrooomms 5y ago
  On the point about technology lock I've thought that the move to microservices would mean allowing different programming languages, but whenever I've asked existing companies if they would be open to other languages it's usually a no. Part of it seems to be decent enough reasons but I usually think they could be overcome with a reasonable amount of work where the tradeoff may be worth it. I usually suspect it's more social reasons. My company also made the move to microservices and I was able to use another programming language but there was strong social pressure to conform.
• lgsilver 5y ago
  There’s also a product-related argument here as well. In order to start, most products require a lot of scaffolding—-modeling of business entities, general rw apis etc. These are well represented by the big “monolithic” frameworks like Rails or Django. There’s not a lot of value in developing a proprietary distributed paradigm for these. Having this core taken care of and flexible, then allows It’s devs to build more proprietary functionalities as distributed proprietary services. Building this core backbone for access to basic funtionalities, and then distributing the high-value technologies has been the recipe for many things I’ve built.
• bl4ckm0r3 5y ago
  I think starting with a decently written monolith is a great idea, the two things that I always saw that _make things bad_ (fsu) are auth, encapsulation (with no domain boundaries, typically 1 class with lots of responsibilities that are only useful in specific contexts but depend on common data and are hard to refactor, classic 3k lines of python code for the User class) and ORMs. Often these things (auth and orm) are pushed by frameworks and don't scale well because of the magic they use to make things work. I think today if i had to start from scratch would use lambdas as much as possible for all common external facing logic (auth etc) and GET routes (for scalability) and have a monolith (with very simple orm features) that implements business logic on top of a managed db (like a dynamodb or aurora). somewhere in the comment I have seen elixir being mentioned and I really like the approach elixir (and phoenix) have over organizing the domains in a monolith, together with a little reactive approach and of course optimize for deletion https://www.netlify.com/blog/2020/10/28/optimize-for-deletion-speed-up-development-without-adding-risk/ https://www.netlify.com/blog/2020/10/28/optimize-for-deletio...
• NicoJuicy 5y ago
  Almost no one is mentioning Domain Driven Design? https://matfrs2.github.io/RS2/predavanja/literatura/Avram%20A,%20Marinescu%20F.%20-%20Domain%20Driven%20Design%20Quickly.pdf https://matfrs2.github.io/RS2/predavanja/literatura/Avram%20... DDD Quickly is a good summary ( 66 pages) instead of the book of Eric Evans.
• coding123 5y ago
  The best start right now is to make two micro services: All your services in one executable (one docker image) Your UI (in another docker image) From there you're free to separate things out more and more over time if you so choose. Having those two separate makes it so that you are required to at least have some kind of ingress controller that maps requests one way and UI assets another, so expanding should come easy at that point.
• acd 5y ago
  Actually monoliths maybe faster than microservices. Consider monolith -> cpu l1 cache -> end user Microservice -> account servive -> foo service -> l1 cache -> end user Ie monolith goes directly to cou cache Microservice goes to network calls which are mich slower than cpu cache. Also with microservices you will need distributed application performance metric for call tracing. Distributed central logging. Container orchestration platform to run all the services.
• max002 5y ago
  Great art, pinning so many pain points.
• Tarucho 5y ago
  Microservices are just a way to implement a distributed system. The problem seems to be that quite a number of teams don't have any formation about system design (mono/distributed/mixed). Most teams go for microservices because of hype and because they see an spagheti monolith and believe the problem is the monolith and not the rotten badly modularized code.
• thrower123 5y ago
  I tend to build monoliths, because I've got a sub-two-pizza team to work with. If I could throw dozens of people at the problem, and moreover, needed to invent things to keep that many people busy, then I think microservices would be more interesting.
• darepublic 5y ago
  Don't start with doing everything faangs do, and hiring grand wizard architects who do nothing but evaluate what third party b2b software we can sign deals with
• akoumjian 5y ago
  I humbly offer my service scorecard as a tool to try to gauge whether a piece of functionality deserves an independent service: https://mulch.dev/service-scorecard/ https://mulch.dev/service-scorecard/
• yoyar 5y ago
  The point here for me is team dynamics, maturity, and skill level. If you have a team that can't competently write and maintain a monolith that is modular and built/tested via automation, then that team has no business trying to build and maintain microservices.
• trunnell 5y ago
  Former Netflix engineer and manager here. My advice: Start a greenfield project using what you know (unless your main goal is learning) keeping things as simple as possible. Microservices is more often an organization hack than a scaling hack. Refactor to separate microservices when either: 1) the team is growing and needs to split into multiple teams, or 2) high traffic forces you to scale horizontally. #1 is more likely to happen first. At 35-50 people a common limiting factor is coordination between engineers. A set of teams with each team developing 1 or more services is a great way to keep all teams unblocked because each team can deploy separately. You can also partition the business complexity into those separate teams to further reduce the coordination burden.
  • AtNightWeCode 5y ago
    What was the root cause of the dependency horror that Netflix created, now immortalized with all the scary data flow GIFs?
    • trunnell 5y ago
      I assume you're referring to the visualizations like the ones halfway down this post? https://netflixtechblog.com/vizceral-open-source-acc0c32113fe https://netflixtechblog.com/vizceral-open-source-acc0c32113f... It wasn't really a horror, and those charts are a little misleading. I'll try to explain. Plenty of others who were also there at the time might see it differently, but IMO this was a trade off to get higher productivity and higher resiliency at the cost of higher complexity. So it was a feature not a bug. When the cloud migration began in 2010, we had a straightforward architecture of a handful of Java monoliths and a giant Oracle database all running in a local data center. The DVD service made all the revenue but the future was the streaming service. It would turn out over the next 10 years we would need to grow engineering headcount over 10x to support the growing business complexity. Some of that complexity was foreseen and the intent was to address it with a culture analogous to a cellular ecosystem. There are many successful designs in nature that evolved to a complexity beyond our current understanding, like the human body or even the protein signalling pathways within individual cells. These systems tend to have excellent homeostasis and survivability in the face of novel stimuli. Notably, each cell is fairly independent: it can receive signals but it acts on its own, and its internal complexity can be hidden from its neighbors. We created a culture where teams were independent units. The sayings were, "loosely coupled and tightly aligned," and, "no red tape to ship." This is the opposite of an architect making top-down decisions. Instead we prioritized local decision making within teams which tends to be fast and effective, so this worked out well for productivity. But the side effect is that the overall system grew a bit beyond the limit of any one person to easily understand it. Thus the automated tooling to visualize the graph. But the dependency graph itself was rarely a problem. Any given developer was usually able to trace all the requests they were responsible for all the way down the dependency graph, and that's what really matters for development and debugging. Generally, no one needed to grok the zoomed out picture -- even during outages, problems were typically root caused to a particular service, and not related to the whole dependency graph. But the dependency graph makes for a compelling graphic, so it gets people's attention. The real story is, "productive organizational culture made of independent units."
• smrtinsert 5y ago
  What? No please force everyone to spend months creating projects that only copy the exact values over. It creates lots of jobs.
• lubesGordi 5y ago
  The problem with monoliths is that they're written fast and chock full of business logic that isn't reusable anywhere else. With microservices, if done correctly a la hasura, your business logic is abstracted to config, or to the highest level of abstraction your business allows.
  • sparker72678 5y ago
    I have never been in an environment where business logic could come even remotely close to being definable via config, even if config was some kind of fancy DSL. Every product I've worked on had deep interdependencies between major parts of the code _at least logically_, because _that was the product_. At some point you can't factor out the business logic anymore without factoring out the entire business, in my experience. This is a major reason software is so tricky. Still, I'm fascinated that this could exist somewhere. Have you seen it in the wild?
• maxdo 5y ago
  Someone please write an article, "Don't start with architecture some dude suggested because of their ego". There are cases when monolith is bad, and when microservice is the must. Take the healthy approach. The article is garbage with no real understanding how real microservices works: The deployment: Modern microservices are working using templates. You deploy it using that directly from you gitlab/github. You copy paste your artifact and it's there. The builds are taking 2 minutes to build, sometimes less, means you can quickly react on some issue as opposed to 30 minutes old school java monolith. Deployments are build in the same cluster you use for everything else. CI job runner is just another application in your cluster. So if your cluster is down, everything is down. The culture part: We use templates, where you have all the libraries , tracing in place. In fact when this request is coming we have some similar functionality written, so we reply to product, oh, this feature is very similar to feature X, we'll copy it, while we discuss some schedule thing our developer renamed similar project did commit and it's already deployed automatically to the dev cluster, the rest of the team joined to development. There is a bad pattern when you need to update your templates. This is tradeoff of approach, you don't libraries as a concept. Hence that you can have half services migrated, half services don't, that's a bonus. The cons is that you need scripts to push everything immediately. Better Fault Isolation: Yes, you might have settings down and core functionality working, means you have less SLA breaking events. Saves you money and customers. Same thing with error handling. If it's just tooling you copy paste a different set of tooling. If the error logging is not implemented in a proper way in the code... It's no different from monolith, it's just errors in code. But things like tracing are already part of the template so for basic evens handlers are traced from deploy #1.
  • danudey 5y ago
    This article sounds like someone who's never successfully implemented either solution. Things that are wrong so far: Monolithic apps need monitoring (e.g. Prometheus) just as much as microservices. Monolithic apps can have scaling issues if you only have one database instance (especially if you're write-heavy), so you may need to shard anyway. Monolithic apps will probably want a messaging system or queue to handle asynchronous tasks (e.g. sending e-mail, exporting data). Microservices do not require kubernetes. You can run them fine on other systems; at my last job, we just ran uwsgi processes on bare metal. Microservices do not require a realtime messaging system. You can just use API calls over HTTP, or gRPC, or whatever else. You'll probably want some kind of message queue as above, but not as an integral part of your architecture, meaning it can just be Redis instead of Kafka. Microservices do not require separate DB instances. If your microservices are all using separate schemas (which they should), you can migrate a service's schema to a new DB primary/replica set whenever you want. In fact, if you have one e.g. MySQL primary you can have multiple secondaries, each only replicating one schema, to handle read load from individual services (e.g. a primary write node and then separate read nodes for user data, product information, and everything else). When it's time to break out the user data into a separate database, just make the read replica the new primary for that DB and add a new read replica off that. This dude just straight up doesn't know what he's talking about, and it sounds like his experience with microservices is following a bad 'microservices with golang, kafka, cassandra, prometheus, and grafana on k8s' tutorial. Here's how you write baby's first microservices architecture (in whatever language you use): 1. Decide where the boundaries are in your given application; e.g. user data, product data, frontend rendering, payment systems 2. Write those services separately with HTTP/gRPC/whatever APIs as your interface. 3. For each API, also write a lightweight native interface library, e.g. user_interface, product_interface, payment_interface. Your services use this to call each other, and the method by which they communicate is an implementation detail left up to the interface library itself. 4. Each service gets its own database schema; e.g. user, product, payment, which all live on the same MySQL (or RDS or whatever) instance and read replica. 5. Everything has either its own port or its own hostname, so that your nginx instances can route requests correctly. There, now you have a working system which behaves like a monolith (working via what seems like internal APIs) but is actually a microservice architecture whose individual components can be scaled, refactored, or rewritten without any changes to the rest of the system. When you swap out your django protobuf-over-HTTP payment processing backend for a Rust process taking gRPC calls over Redis queues, you change your interface file accordingly and literally no one else has to know. It also means that your deployment times are faster, your unit testing is faster, your CI/CD is faster, and your application startup time is faster when you do have to do a service restart. I'm not sure why this is so hard for people to understand.
• btbuildem 5y ago
  > Service A could be written in Java, service B could be written in Go, service C could be written in Whitespace, if you’re brave enough. I've always found this to be such a huge strawman. I've yet to encounter an organization that uses a variety of technologies. Usually it's one of the top most popular, sometimes two, rarely three different languages. Devs migrate between teams, hiring is done to match the skills already onboard. Coding styles (even if they differ slightly between teams) usually follow corp "best practices" Even if it's a multitude of services, the culture of the codebase is usually very monolithic.
  • salt-thrower 5y ago
    Anecdotally, I've seen the strawman become real. Usually it's not more than two different languages. But at my current job, we've got a split between Typescript, vanilla Node.js, and Scala on the backend. All the results of various migrations and refactors spearheaded by different people at different times but not completed. The current vision is to have a unified Scala backend someday, but I'm not holding my breath.
• overgard 5y ago
  IMO, the big advantage of microservices over monoliths (if they're done right) is reducing iteration times. It's just a lot quicker to build/run/etc. I think monoliths are a fine starting point but once your iteration times get slow, that's when it's time to break it up.
  • salt-thrower 5y ago
    It's a big tradeoff for maintenance complexity and cognitive load though, and people often don't realize how big that tradeoff is. Chasing bugs and maintaining the spiderweb of network connections between all your services can quickly become a nightmare. A distributed ball of mud instead of a monolithic ball of mud, but a ball of mud nonetheless. Personally I lean towards building a monolith first, then breaking out features into separate services if you need it. But I've worked on teams that advocated for microservices needlessly, and it was 100% cargo cult behavior: "Netflix does it, so we should too." Another anecdote: my current company, a startup, could've launched its product a year earlier than it did, but our engineering lead insisted on pre-engineering a Rube Goldberg machine of a microservices backend before we even had any prospective customers. Took months of engineering time and headaches to grok all of it, when in reality, one monolith and a basic database could've done the job for years before we'd ever have to scale past that. But microservices architecture looks great on a resume, so /shrug
    • geekbird 5y ago
      "But I've worked on teams that advocated for microservices needlessly, and it was 100% cargo cult behavior: "Netflix does it, so we should too." I've seen this too, and in fact I got laid off because I pushed back against this silliness for what should have been a simple lift and shift.
      • salt-thrower 5y ago
        That's awful, and probably the most egregious example I've heard of a cargo cult gone wrong. The longer I'm in this field the more disappointed I am by the influence that trendy groupthink has. I know no field is immune to it, but it seems more pervasive in software.
• vlunkr 5y ago
  It seems to me that the ratio of hate-for-microservices/companies-actually-using-microservices is way out of wack. I know that there are some high-profile cases like Uber, but in nearly every conversation I see online or in person, we're all in agreement that going all in on microservices is hype-driven nonsense. Maybe I'm wrong though.
• anm89 5y ago
  I feel like I'm back in 2013 with all of these posts and I like it.
• MetaWhirledPeas 5y ago
  > If you’re going with a microservice: A Kubernetes cluster A load balancer Multiple compute instances for running the app and hosting the K8S cluster Try running a high-traffic high-functionality website without something equivalent to this. What's this magical single computer you'll be running it all on? You'll need a cluster of servers on a rack somewhere, managed the old fashioned way. You'll need equivalent tools to deploy to them and monitor them. I think what this article should be getting at is that low-traffic sites shouldn't start with microservices, and maybe that's true. But if you're trying to build a business that scales rapidly, you want to be ready to scale your website from day one.
  • lowbloodsugar 5y ago
    does stackoverflow count as high-traffic, high-functionality? pretty sure most people here would be very happy for their startup to have that level of traffic. it's no longer a single computer, sure, but, last time I read about it, it was monolithic.
    • MetaWhirledPeas 5y ago
      Stack Overflow is an example of a website with predictable traffic patterns. There's no Black Friday for Stack Overflow.
• drbojingle 5y ago
  Guy who hates micro services here (worked at a startup that tried to adopt them because the CTO's consulting friend who works in enterprise convinced him of how great it was). From what I can tell, micro services are primarily a solution to an organizational problem and not a technical one and I think people trip over this. If you have 600 developers working on the same back-end then you can benefit from micro services, because you can't possibly fit 600 developers into one standup. You'd never be able to coordinate. There are rare technical reasons to choose micro services and there is value to micro services when they're used correctly but if you don't have those precise problems then you don't need micro services. List would include situations like having a subsystem that utilizes far greater resources then any other sub system and would be more cost effective running on specialized hardware Most importantly tho for going 0 to 1 is context. Context is king and always will be. Start ups should not do enterprise services patterns because their not enterprises and neither is the guy coding alone in his bedroom. Your not Netflix. Your not Google. Those companies are going to be so large that they'll encounter every kind of architectural problem. All a start up needs to do is communicate, release, communicate, iterate, repeat. It's the equivalent of asking yourself what did NASA engineers do to send a rocket to the Moon when you're just a guy trying to start a car and get it down the road. Baby steps, for the love of god, baby steps.
  • cracell 5y ago
    Simple rule of thumb is one backend per team. Things like upgrading the language version should not require coordination between multiple dev teams. Of course there's 100s of permutations that work. Optimize for your situation. And if you have no clue what the right call is, go as simple as possible until it breaks on you.
  • dastbe 5y ago
    > There are rare technical reasons to choose micro services Is this just the difference between working in an infrastructure oriented space vs. product oriented? in infrastructure i find that it is often the case that most logical applications should be decomposed into multiple services given scaling and blast radius concerns where having everything in a single application would increase the impact of outages.
  • 5y ago
• dinvlad 5y ago
  Another point of confusion among many folks is monorepos. Some consider "monorepos = monoliths", which is more like comparing apples to oranges imo. Monorepos provide some of the benefits of monoliths in terms of 1) making it easier to refactor your entire codebase at once 2) sharing some common dependencies like framework versions etc., which makes it much easier to keep those up to date and more secure, as a result 3) sharing some common utilities like unit testing harnesses etc. 4) other things At the same time, monorepos don't force one into a monolith architecture at all, an in fact can provide most of the same benefits of microservices in terms of separate deployments etc. The most important lesson in my mind is, there's no "panacea" or "perfect structure" as a prescribed way to do things. Every system has its own demands (which also change over time), and the only "should" is to tailor things on a case-by-case basis, adjusting to a better structure when needed.
• ahallock 5y ago
  I failed to launch a side project because of this. Microservices were just becoming trendy and I went in head first. Ended up losing so much velocity worrying about how to set up the services and even going so far as to implement nano services as rock bottom lol. The project became more mental masturbation on distributed systems than solving any real human problem. So yeah, start with a monolith. And continue using the monolith. There might be a few services you need to factor out from your main system, but do so with caution.
• posharma 5y ago
  How many more articles do we need to drive this point home? First it was a fashion to develop using microservices. Now writing about not using them is in vogue :-).
• dimsuz 5y ago
  Every time I open the site and it pops up some weird "subscribe to this and that awesome content" in my face, I immediately close it. Each time I really hope that owner has some analytics set up and they will learn that having this thing is not a good thing to do to your readers.
  • XCSme 5y ago
    Same, I wonder why they keep doing it. Are they fine upsetting 50% of the users so that 5% subscribe? Or am I underestimating the sign-up rate?
• mastazi 5y ago
  Microservices doesn't necessarily mean K8S running on self-managed compute instances as in the example given in the article. The main mistake of the article is that the premise is "microservices" but then the examples are about infrastructure (K8S etc), but the 2 things are not tied, you can have that same architecture cited in the article running monolith instances for example, and it would be every bit as complex as managing the micorservices example, without any of the advantages. Fully managed serverless solutions like Lambda/Cloudflare Workers/etc, managed through SAM or Serverless Framework solves most of the problems cited in the article. The whole infra in our case is API Gateway + Lambda + DynamoDB, this infra is not more complex to manage than our old monolith which was on ALB + EC2 + RDS. Deployment is one "sam deploy" away (done in Github Actions), this is actually even simpler than our previous monolith.
  • tabtab 5y ago
    "Microservice" is inconsistently defined. One cannot accuse them of using a strawman definition if there is no realman.
    • mastazi 5y ago
      I disagree, microservices are an architectural concept related to the software, not to the infrastructure. Whether you are using containers or VPS or serverless or bare metal for your infrastructure, that's completely unrelated to the concept of microservices: you can deploy either a monolith or microservices in any of the above. As an example you can deploy a monolith on Lambda[1] or you can deploy microservices on bare metal using one of the several self managed serverless engines available[2]. [1] see e.g. https://claudiajs.com/tutorials/serverless-express.html https://claudiajs.com/tutorials/serverless-express.html or https://blog.logrocket.com/zappa-and-aws-lambda-for-serverless-django/ https://blog.logrocket.com/zappa-and-aws-lambda-for-serverle... [2] see e.g. https://fnproject.io/ https://fnproject.io/ and https://knative.dev/ https://knative.dev/
• yawaworht1978 5y ago
  I have worked in companies which had monolith software, but they have been large and established businesses. I will not name names, but I can say this... All but one had constant, repetitive and quite painful failures, not fixable, it seemed. One company was an exemption, with some failures but a clear culture of pushing issues while implementing new features. And one company I have been with from startup days till 150 employees had a microservice infrastructure, I have never seen so little downtime, such a smooth back office, front end, database, reporting system. The cto was owner and main developer, if something went awry, he would start working on the fix within minutes, no matter the day or time. The fastest issue response time ever. 2 lifetime downtimes of a handful minutes for the full service, and a couple components which didn't work for maybe an hour or sometimes overnight. I have to say though, when one microservice broke, it took down more tangential services than one would think, but other than that, hands down the best software I ever worked with.
• m12k 5y ago
  Here's my take on microservices: It's a form of modularization. Like all modularization it can be useful to uncouple larger parts of a system - to enforce an architecture, avoid unintended cross-dependencies, make explicit the dependencies that are intended, to allow teams to work more independently, and to allow the different parts of the system to be be developed, compiled, built, deployed (and sometimes scaled) independently. But all this comes at a cost - you have to know where the module boundaries are, because moving these is much harder. The flexibility that you've gained within each module comes at the cost of making it harder to move the border between modules. It's very easy to put down a module border in the right spot, and you make a refactor (needed for cleanup or performance improvement) go from tricky to impossible. E.g. that piece of info needed in this module now canonically lives in the other one. Or we accidentally add a couple N's to the time complexity of an algorithm that works on data in multiple modules. But getting the borders right on the first try is hard, unlikely even. Where those borders should be depends on a lot of things - the user domain, the performance characteristics, the development team(s) (Conway's law and all that) and the ways in which the business requirements change. For that reason, I think most successful modularizations are either done by breaking down an existing monolith (providing these insights) or by basing it on a known running system that is "close enough" in its needs and environment.
• winddude 5y ago
  wow, just wow, I don't know where to begin. I think something written by gpt-3 would have less errors on parts of a software stack.
• 2-718-281-828 5y ago
  The idea of microservices sometimes reminds me of visual programming looking at infrastructure diagrams. Like instead of writing the code and executing it. You implement variables (databases), conditions (lambda), loops (pubsub/sqs) etc as separate entities and then put them together.
• dastbe 5y ago
  I'm curious, has anyone leveraged bazel's package visibility rules to improve isolation within a monolith? one of the things i don't like about monoliths is that tight coupling is often silent rather than noisy, whereas if someone is editing package visibility rules to make library internals A visible to package B i know exactly what's going on.
  • jvolkman 5y ago
    Google uses visibility rules all the time (with Blaze, which is basically Bazel). Mixed with the repository's OWNERS system which uses a hierarchical tree of permissions files, you can't take a dependency on someone else's private packages without their permission.
• tabtab 5y ago
  You have to sprinkle some fads in, or else nobody will touch because it doesn't have enough resume-able buzzwords.
• indymike 5y ago
  Managing complexity is hard, no matter the approach to it. Microservices define boundaries around component inputs and output and try to reduce complexity by black boxing functionality. Monoliths try to reduce complexity by managing code (languages, libraries, databases, etc). I'm not sure there really is a good answer between the two because over time: 1. Vendor (and open source) blackboxes get introduced to monoliths, and you end up with a monolith built around a bunch of microservices. 2. Common tooling has a huge benefit, and copy-pasta code gets the job done faster than everything being custom every time. So you end up with microservices that every task ends up importing some giant framework and uses common libraries - so the monolith gets imported to the microservice. Software gets complex, faster than we all like to believe... It seems like software has gravity, attracts complexity, and ends up being a big ball of mud in the end, almost every time.
• johnnymonster 5y ago
  Avoid any advice that touts itself as gospel! Do your own DD for the product or services you’re building. Maybe you’re never going to hit more than 100 users in total or maybe you’re building a static website. Take some time and evaluate the pros and cons of your architecture and seek advice from those who have come before you!
• dmux 5y ago
  One problem I've never seen mentioned regarding microservices is what happens when the organization that produced them has moved from growing to stagnating and finally into decline. If microservices ship the org-chart, what happens when that organization fails to attract engineers? I worked for a company that microserviced themselves into a pit. We had a huge layoff which completely killed the morale of the remaining engineering staff. Over the next 3 years, more and more engineers left and the company refused to replace them. What started out as teams (~5 people) responsible for ~3 microservices ended up as teams of ~3 people responsible for ~6 microservices. It was kind of cool to be responsible for more architecture and see how it all fit together, but the sad reality was that too many of the microservices that had been stood up were stitching together disparate data from other microservices to then perform what a single SQL query against a RDBMS was doing.
• deleted 5y ago
  [deleted]
• ezekiel68 5y ago
  I've been a professional programmer since the late 1990s. What I observe is that many people flocked to microservices because they had only known monoliths and they were sick of the limitations inherent to them. Now we have a generation of engineers who have only known (or been taught) microservices and a backlash has developed because they are sick of the limitations inherent to them. This is my reading of the anti-OOP / anti-inheritance movement as well. To spice up Bjarne Stroustrup (inventor of c++), "There are only two kinds of programming languages: those that don't make it and those that people bitch about."
• ineedasername 5y ago
  My impression, which seems to be supported by this article? Is that when you're small, you can actually get up & running with an MVP with a non-serverless monolithic approach and scale for a bit before you hit a wall. And only at that point: 1) Scaling becomes much more complex and 2) Monolithic infrastructure prevents you from easily implementing best-of-breed solutions within segments of your functionality to optimize various functionality. And, from a cloud services $$ POV, it's cheaper and perhaps require less dev time, though I'm guessing that will depend on the project This seems reasonable? At least at the early & early-mid stages. If you make it that far and see things like scaling issue in your future, it seems like you should also be at a stage of growth where you'll be getting reasonable funding offers and can invest the resources into migrating away from monolithic. Disclaimer: My opinion here is formed mostly from following a not-completely-dissimilar process even when working with things more on a monolithic side of things: I'll use a high-powered workstation to spin up a vm's on the same host, and then if I need to I can migrate individual vm's to their own better-resourced instances on other hardware to scale things. I did this some years ago with a Hadoop cluster and the process worked out nicely. Although as it turned out, that example didn't last long: Hadoop was overkill because I overestimated the bigness of my data, which turned out to only be on the bigger side of small. Or smaller side of medium. When I had a rethink on it, I wrote some python code against a the primary sql-based data source & used Keras to do what I needed instead: Iterating each pieceon a nicely-spec'ed workstation took an hour or so, and a full end-to-end run maybe 3-4 hours. But this is kind of my point: Starting out, it's easy to thing "Oh I need to plan for ever possible eventuality & level of scale." No, you don't. And a final caveat to this: YMMV since circumstances differ from project to project. But these are things to consider before you automatically go for slicing each piece of functionality into grains of sand with their own microservice.
• emodendroket 5y ago
  Of course this advice doesn't always make sense, but it makes sense more often than people want to admit. Not that this is an original claim, if anybody remembers the "majestic monolith." Simply put, the microservice path makes a lot more sense when your organization is so big that you don't really know what other teams are doing all the time and need a clear delineation of areas of responsibility, or maybe if you have very large volumes you're dealing with. That doesn't describe most orgs, but if it describes you consider microservices.
  • abraxas 5y ago
    Oftentimes however with microservices it's the tail wagging the dog. Microservices architectures become such a burden that they strain the capacity of the existing team which leads to more hiring which thanks to Conway's law leads to more microservices being built which leads to more operational and architectural overhead which leads to more hiring...
    • emodendroket 5y ago
      That can definitely happen and be painful. I now work at a very large organization, though, and the benefits of microservice design are obvious (as were the pains of monolithic ones when I was working on an old legacy monolith in the same place).
• ChicagoDave 5y ago
  As is always the case, "it depends". Are monoliths are good in some cases? yes Are micro-services good in some cases? yes Is a hybrid solution good in some cases? yes Figuring out which way to go is why we wear the architect hat.
• gadflyinyoureye 5y ago
  My understanding from the HTML Template days is that a monolith contained both the business and presentation layer together. I made plenty of those with Struts 1.x and Spring MVC. Micro services were pitch as a means to separate the front end and back end. I'm a bit confused on microservices vs monolith in the modern SPA context. If I have an application that's front end is React and back end is Go and the two communicate over REST/HTTP+RPC, do I have microservices or a monolith?
• pulse7 5y ago
  I like monoliths... which are modular inside... no need for microservices, easy deployment even without Docker and Kubernetes... just a single binary...
• baalimago 5y ago
  Seems, to me, that the author is poor at designing microservices. Using his example: the login, session and user services should be only one service (something like Keycloak), there's no advantage to splitting this up, so why would you? Analytics service should never be a dependency of another serivce, but rely on service discovery and a preset telemetry/analytics/rpc endpoint which each of the consumer-facing services implements. Has anyone claimed that microservices will fend of poor design? There's never a silver bullet.
• DeathArrow 5y ago
  For me it highly depends on the size of software, the time to market, the time the software is supposed to work without major rewrites. If I am doing a blog application or an website for one time event, I would pick a monolith. If I start on ERP, a checkout solution I would pick microservices. Also if the man power is low but I expect growth in the future, I might go for a monolith broken in separate projects with minimal dependencies between modules so it wouldn't be terribly difficult to break it into microservices when the need and man power arrives.
• TeeWEE 5y ago
  I agree to not start with microservices.. But its better to not wait too long after the project is growing. Regarding his points: - Infrastructure requirements: You don't need all that stuff! You can have multiple services run on PaaS services / Cloud Run, and you dont need to deal with all the kubernetes stuff. Even if you prefer K8S, then you still dont need a service mesh from the start. Datadog and Gitlab brings you very far with hardly any work on your side. - Faster Deployments My point: 80 microservices? Crazy .. Why? Just have a service per business domain, and try unifying the CI/CD stack. We had 1 big Monolith which would deploy 5 times per day, buy every deploy took around 1 hour. Having 5 to 10 services, that all deploy within 5 minutes is so much nicer to work with. - The Supporting Culture This is important: Architecture follows company organization, and vice versa. Every team often owns 1 or 2 services. Teams should be organized by domain. Business boundaries should be agreed upon in a higher level. Sitting in your dev corner, building services without talking and aligning with the Product owners & MT is a recipe for distaster imho. The services should solve a problem that PO's understand. You should have alignment. - Better Fault Isolation We never said it was going to be easy... It requires a different way of building your system. You need to think distributed systems.
• daitangio 5y ago
  When the autor says > If you’re going with a microservice: > A Kubernetes cluster > A load balancer > Multiple compute instances[...] > Jaeger/Zipkin for distributed tracing To be fair, using K8s + helm I was able to install logging, grafana, prometheus very easily. If you leverage on Helm3 and Bitnami [1] helm charts, you can go fast. Also, you can use pipeline (like github/bitbucket pipelines) to deploy and remove jenkins completly: I have done it and it is a viable solution (although with some lock-in). So the complexity is a bit less if you study enough well your setup, but you must take time to plan your solution. After three years of K8s study, in my humble option K8s is far better compared to docker swarm, even for tiny projects, with k8s as a cloud managed solution (even small provider had it nowadays). [1]: https://bitnami.com/stack/postgresql/helm https://bitnami.com/stack/postgresql/helm
• philderbeast 5y ago
  I didnt't even get a quater of the way down the page before I stopped reading. As soon as the author started listing things like k8s as needed for microservices it shows they havent stopped to think out side the box. there is no reason you can't run your set of microservices as 3-4 docker containers on the same host, no load balancers, no k8s, no log aggrigation, etc etc etc. If your application makes sence as microservices you don't need to start with all of that, so including it all in the cost of startup makes no sense at all, as your application starts to scale out and need them, add them at that time, your going to need most of it for a monolith application as well, and some of them you may NEVER need (k8s for example, there is no reason you can't run your application on just plain old compute infrastructure, you don't even need to look at the "cloud" that old box in the corner of your office might be all you need for the project) if you stop and remember that "microservices" just means small single function services, not things like k8s you will probably find that you can actully do a lot less work if you go down that road by letting other exsisting projects so a whole bunch of the work for you and save you re-inventing the wheel to get your project finished and out the door.
• dr-detroit 5y ago
  Why is the author bringing this trash to me??? Maybe if you CS undergrad prof didn't teach how "how to be fast" but taught you dependency injection you would be competent.
• MaxMoney 5y ago
  Microservices are a plague on the industry. It's just as bad when OOP was introduced. I wish they would go away.
• pyuser583 5y ago
  Microservices requires lots of forethought, design, and highly qualified engineers. You spent the same amount of forethought, design, and talent on monoliths - you’d might not need microservices. The real issue is scale. A well designed micro service mesh will scale. A well designed monolith might scale.
• bobobob420 5y ago
  The previous button does not work on mobile to read the Java interview article
• blippage 5y ago
  There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. -- Fred Brooks Sussman summed up the problem nicely: "We really don't know how to compute!" So we latch onto whatever semi-plausible idea some consultant cooks up, like flowcharts, structured programming, agile, object-oriented programming, test-driven development, microservices, and countless other things. Microservices impose a transport layer over whatever it is you were doing before. So that's one extra point of failure that you've got to contend with. Complex problems require complex solutions. Sure, there are better and worse ways of doing things, but there are no miracles.
• anonymous_dev 5y ago
  My CTO is all about micro services in node (the agency is full of php and ruby devs). Now he is moving to aws lambdas, every should be a lambda… a lambdas hell, with no documentation. I think I’ll quit as soon as I find a good alternative job.
• hakfoo 5y ago
  I feel like a lot of microservice advocates fail to price in the overhead introduced when you split stuff up into multiple independent communicating units. Example: Replacing a simple database query (effectively instant) and relaying the data as a local variable, with poking a seperately hosted microservice which ends up adding 20ms of overhead doing a HTTPS request, encoding and de-encoding the result in JSON, etc.
• ngc248 5y ago
  Like the answer to most complex questions ... it depends.
• alex-2k1 5y ago
  Product Owner: Hey guys, I came up with this really great feature. Our competitors are already doing it so we gotta do it quickly. Is it possible to do it in 2 weeks? Team: No, we need 10 weeks because scale * Product Owner jumps out of the window (obviously realizing product is doomed and company never get another client without this feature) Is this real life?