[HN Gopher] Some thoughts on microservices
___________________________________________________________________
Some thoughts on microservices
Author : filipn
Score : 136 points
Date : 2021-11-29 13:59 UTC (2 days ago)
(HTM) web link (filipnikolovski.com)
(TXT) w3m dump (filipnikolovski.com)
| daxfohl wrote:
| For me it's the repetition in horizontal tasks. Need to update
| TLS version? Need to move to a new region? Need to add i18n? You
| have to do these things 20 times instead of one.
| maxdo wrote:
| Yet another "based on my experience" opinion. Based on my
| experience our service would fail due to performance because
| we'll , nodejs is still single thread. Given this we should
| either duplicate deployment of big service by roles that gives
| you same level of orchestrating complexity or rewrite in
| different languages, means hello microservices again :) ps our
| product was initially written by non tech cofounders that used
| heroku and microservices from day one. They used a swarm of small
| services to stay on free tier. So microservices in this use case
| are cheaper. And yes, it's simpler for non experience developer
| to get up to speed with your backend if it's a simple service.
| SomeCallMeTim wrote:
| Node can run multi-process with the Cluster module. Node being
| written as a monolith but running it in 100 instances is also
| an option. Roles can be implemented in software. There's much
| less "orchestrating complexity" when you're deploying a single
| service.
|
| So Node being single-threaded is not itself a reason to use
| microservices.
|
| I tend toward writing a monolith for the core API of a service,
| but then break out microservices for tasks that need to scale
| independently (or that need to run on high-memory/high-
| performance instances, for example). So I'm not totally against
| using microservices. But we should choose to use them when
| they're to our advantage to use them, not just "because they're
| already written that way."
| acjohnson55 wrote:
| Microservices are not a solution, they're a capability. It's
| powerful for a team to be able to deploy a tiny service with the
| absolute minimum amount of explicit plumbing to meet operational
| requirements. Whether they _should_ break their system up this
| way is a case by case judgment.
|
| Every place I've been, the costs of microservices get overlooked
| in favor of the illusion of decoupling. Microservices will
| absolutely make simple features fully contained within a service
| easier, but as soon as a feature spans services or even impacts
| the contract of a service, you're in for more pain than in a
| monolithic architecture. Microservices sieze local simplicity at
| the cost of integration complexity.
|
| Microservices, as a philosophy, is encoding your org design at
| the networking layer. I hope you get it the factoring right the
| first time, because it's going to be painful to change.
|
| I'm all for small services where they make sense. But just like
| the advice that "all functions should be small" microservices has
| been myopically adopted as a design principle, rather than a
| debatable decision.
| satyrnein wrote:
| At a previous company. I had a team that chose to rebuild a
| feature from the monolith as a microservice to "contain" the
| complexity. They built the service off to the side, had
| automated tests validating its inputs and outputs, and they
| were quite proud of it. Then came integration, and it became
| clear they had not put any thought into how to migrate the
| data, what would happen if the service was unavailable when the
| monolith called it, how to generate reports across the monolith
| and microservice, etc etc.
|
| In this case, using microservices was like getting drunk: a way
| to briefly push all your problems out of your mind and just
| focus on what's in front of you. But your problems didn't
| really go away, and in fact you just made them worse.
| bsder wrote:
| > Microservices, as a philosophy, is encoding your org design
| at the networking layer.
|
| Not always. One of the things where I desperately wish people
| _would_ adopt the "microservices philosophy" is in
| applications which provide a scripting language.
|
| For example, if I want to "script" OpenOffice, I am stuck with
| the _exact_ incarnation of Python shipped with OpenOffice.
| Nothing newer; nothing older; _exactly_ binary compatible. This
| is a really irritating limitation.
|
| If, however, they simply provided a "microservice interface"
| that anyone could talk to rather than just the anointed Python,
| then you could run your own Python or script using a completely
| different language.
|
| I'm picking on OpenOffice here, but this is not specific to
| them. Nobody who has a "scripting extension language" as part
| of their application has demonstrated anything better.
| geodel wrote:
| Indeed. I did simple calculation for myself. We kind of split a
| service in 5 microservices. Now if I look at e.g 5% integration
| related issues between 2 services, which would obviously not
| exist in monolith, we are actually looking > 20% chances of
| error in an end-to-end transaction.
|
| To me this is pretty high chance of error on day to day basis.
| And in our case some errors are convoluted, so possibly getting
| missed and causing slow data corruption.
| vineyardmike wrote:
| > Microservices, as a philosophy, is encoding your org design
| at the networking layer
|
| Def the best/worst reason to use it, but it does - practically
| - make sense. Anyone who has had cross-team-monoliths will
| welcome this.
| amelius wrote:
| Your first question in a job interview should be: "do you use
| microservices?" If the answer is yes, you can save yourself a
| lot of time.
| mumblemumble wrote:
| I know microservices have passed the excitement phase of the
| hype cycle, but they're not useless. One of the most
| enjoyable systems I've worked on was a microservice
| architecture.
|
| That said, I'm going make some wild inferences about what you
| were getting at in ordet to say that I agree that a
| microservice architecture is probably a solution in search of
| a problem in most cases. And, even in the cases where it is a
| good option, I can see all sorts of ways to mess up the
| implementation. The article is right; the trickiest things to
| get right about microservices are actually organizational
| issues, not technical ones. My hot take is that dev teams who
| are considering adopting microservices should take a serious
| look at how much ability they have to influence the org chart
| and inter-team and inter-departmental communication. If
| management is strictly something that happens to them, I
| would not give them stellar odds of achieving sustainable
| success with microservices. Perhaps some other form of SOA,
| but not actual microservices.
| momirlan wrote:
| If you bill by the hour, it could be a long, fruitful
| contract.
| taeric wrote:
| I'd be more worried with, "do you just have shared
| infrastructure for all data?"
|
| Hearing some places just have one giant database where all
| teams can add and remove columns is... Kind of scary to me.
| pooper wrote:
| > Hearing some places just have one giant database where
| all teams can add and remove columns is... Kind of scary to
| me.
|
| Are you talking about Bank of America? My impression from
| the interview was that it is not a free for all but rather
| all teams are equal but some teams are more "equal" than
| others (compliance). I still don't get why they need
| write/execute access. I would be OK with other teams having
| read access to my database.
|
| There was a discussion the other day about using views as
| an external interface to a "service" so basically we
| maintain rest, gRPC, or whatever but if other teams just
| need read only access to our data, we can expose a view to
| them
|
| https://news.ycombinator.com/item?id=29357874 https://web.a
| rchive.org/web/20211201192151/https://news.ycom...
| taeric wrote:
| Facebook is the one I've heard of.
| satyrnein wrote:
| Assuming people will need reports that cut across
| team/microservice boundaries, all that data has to end up
| in one common place, possibly a data warehouse. At which
| point, other teams can still add and remove columns and
| break your reports.
|
| Is there another way to do things?
| taeric wrote:
| Well, a data warehouse is one thing. I have heard of them
| just having a single live database that everyone hits.
| For all uses.
|
| Edit: in contrast, I don't want anything about a user,
| except their id in a table for most features. Hearing of
| free for all's on data makes me question how they protect
| payment or just general private data.
| orefalo wrote:
| Conways law is not about structuring... it's about domain
| knowledge.
|
| ie. if you work alone on a problem, you can only solve for the
| issues you know.
| roberthahn wrote:
| I find people's reactions to microservices to be fascinating. I
| have always looked at them with the same framing as Unix userland
| tools - many small, focused apps that do something really well,
| coupled with a super generic IPC mechanism - in Unix's case,
| using pipes or message queues.
|
| But Unix isn't all small tools. We have servers for the heavy
| work- like databases.
|
| The challenge then becomes; how do you design that IPC mechanism?
| Maybe it exists! I don't know the answer yet. But it's something
| I think about a lot and I haven't seen compelling evidence for
| "microservices are always bad, no exceptions"
| cjfd wrote:
| Well, pipes are very nice and useful for small processing
| tasks. "I want to know how often the word 'Parameter' occurs in
| the source files inside this repository." That is great! pipes
| are your friend. They are the fastest way known to mankind to
| solve this problem. But they are also fragile. You may not have
| thought about the fact that the word NoParameter also occurs in
| the code base and you did not want to count that. Now, when
| writing something big and complicated pipes simply cannot keep
| up. Nobody wants a browser that is actually 100 small
| executables that communicate over pipes. It will be horrible.
| The IPC mechanism that you are looking for and that can
| actually handle what is needed for a browser is called
| 'function call' and it was already quite popular when C was
| introduced....
|
| The interaction mechanisms between services, e.g. REST calls,
| is somewhere in between pipes and function calls. They are a
| bit more reliable than pipes and less reliable than function
| calls. They can be used for more complicated task than what
| pipes are used for but should not be used for task that are so
| complicated that they need function calls.
| samwillis wrote:
| "The longer I'm in tech, the more I'm convinced microservices
| were a technical solution to an organizational problem."
|
| @carnage4life on Twitter
|
| https://mobile.twitter.com/carnage4life/status/1311702322024...
|
| Now, I've not had the pleasure of working in an organisation
| using Microservices and so I'm only informed anecdotally. But I
| always assumed they where best used as an API boundary between
| teams, rather than adding more complexity to a teams work.
| bestcoder69 wrote:
| Imagine if all of AWS was a single executable file, but had to
| handle all the same scale, complexity, and release velocity.
| The S3 team would have to patiently coordinate with the...
| like... SageMaker team to figure out how big of servers they
| need, along with every other single possible shared concern.
|
| I picked a ridiculous example there. But just trying to show
| that if you need services, it should be easy to argue for them
| on the merits, because it's gonna be the least bad option.
| [deleted]
| recursivedoubts wrote:
| Microservices means just that: tiny, single purpose services that
| deploy and scale on their own.
|
| I often see appeals to Conway's Law when discussing
| microservices, but teams don't organize themselves this way.
| Instead, teams work on a _macro_ services: the email delivery
| team, or the monitoring team, or whatever. In most cases these
| macroservices would be best implemented and deployed as a
| monolith, and then presented to the outside world over a
| reasonable API.
| throwaway984393 wrote:
| ^ This. Microservices are introduced because it seems like
| they'll be able to decouple and scale well, and then they make
| mistakes that make everything even harder than if it'd stayed a
| monolith.
|
| Usually they don't plan for how they'll coordinate their work,
| and that leaves gaps in the design, and puts more risk on the
| business. Team A: |
| Email product: __|_____________ |
| Service C <---------- / How do we \ |
| Service D <-- \ | work together |
| --------------------- \ ------\-------------- | on
| overall | | How do we manage | | | How do we
| | | system design? | | stakeholder risk? | | |
| coordinate changes? | \_______________/
| --------------------- | \--------/----------- /
| | | | |
| | | \ |
| Team B: | | |
| "Data" team: | /
| Service A <---|-------
| Service B <--/
|
| On top of that, they don't even make a true microservice. They
| start directly calling into each others' data rather than
| interface at an API layer, they make assumptions about how each
| other works, they don't do load testing or set limits or
| quotas... and because none of them understand the rest of the
| system, they don't see that their mutual lack of understanding
| is the cause of their problems.
|
| Even with multiple teams, if they're forced to work inside a
| monolith, there's a much better chance they will _by accident_
| come to understand the rest of the system.
| mLuby wrote:
| Total tangent: very nice ASCII diagram, especially for a
| throwaway account. It's so _unusually_ nice that it 'd
| probably help identify the author if they ever made ASCII
| diagrams on their non-throwaway account (and who could
| resist?).
| orefalo wrote:
| I do not agree with many of your points.
|
| I also agree with some of them.
| daxfohl wrote:
| I was going to say that one nice aspect is that rollbacks are
| less frequent because the size of each deployment is smaller. But
| I've worked on million line code bases that still do weekly CICD
| pretty well, so I don't know if that advantage really holds
| water.
| [deleted]
| bob1029 wrote:
| Start with a monolith and only break it up if you are actually
| forced to by the computer (i.e. the process won't fit in ram
| anymore or eats all the CPU/IO). The second you break up your
| monolith, you lose its most powerful feature - The direct method
| invocation. The amount of time I see developers spending on JSON
| wire protocols, CORS problems, API endpoint designs, et. al.
| really is starting to concern me. I sometimes wonder if anyone
| wants to do any actual work or if this is just a big game to some
| people.
|
| I did the full trip on this microservices rollercoaster. Monolith
| => uServices => Monolith.
|
| I used to vehemently advocate for using microservices because of
| _how easy_ it would be to segment all the concerns into happy
| little buckets individuals could own. We used to sell our product
| to our customers as having a "microservices oriented
| architecture" as if that was magically going to solve all of our
| problems or was otherwise some inherent feature that our
| customers would be expected to care about. All this stuff really
| did for us is cause all of our current customers to walk away and
| force a re-evaluation of our desire to do business in this
| market. All the fun/shiny technology conversations and ideas
| instantly evaporated into a cloud of reality.
|
| We are back on the right track. Hardcore monorepo/monolith design
| zealotry has recovered our ship. We are focused on the business
| and customers again. The sense of relief as we deprecated our
| final service-to-service JSON API/controllers was immense. No
| more checking 10 different piles of logs or pulling out wireshark
| to figure out what the fuck is happening in-between 2 different
| code piles at arbitrary versions.
| jspash wrote:
| Here! here!
|
| I'm within spitting distance of the end of a project of
| collapsing a service-oriented system back into a Majestic
| Monolith. Every step of the way has reduced the lines of code,
| fixed bugs, saved money, saved time. It's been such a joy that
| I'm considering doing only this as a side hustle. "Saving"
| companies who were sold an over-complicated dream.
| bob1029 wrote:
| > It's been such a joy that I'm considering doing only this
| as a side hustle. "Saving" companies who were sold an over-
| complicated dream.
|
| This has crossed my mind a lot lately. I think we are looking
| directly at one of the largest emerging markets in
| technology. What do we think the TAM is going to be for
| undoing webscale monstrosities by 2025? Not every business
| will fail due to their poor technology choices and will be
| able to pay some serious consulting fees...
|
| I've practically got a system for doing this now. It mostly
| starts with domain modeling in excel and all the business
| stakeholders being in the loop at the same time until
| everyone agrees. I find if you get this part right it doesn't
| really matter if you use C# vs python, or AWS vs on-prem to
| build the actual product. Hard to get opinionated and locked
| in when your deploy to prod involves a 100 meg zip file and 3
| lines of powershell ran against a single box.
| alexchamberlain wrote:
| An interesting list, but is this specific to Microservices, or
| just Service Oriented Architecture in general?
|
| For me, other than the obvious size difference, the difference
| between microservices and "large" (?) services is that a single
| team breaks down their domain into sensible layers, abstractions
| etc.
| scottious wrote:
| A single team can break down their domain into sensible layers
| and abstractions within a monolith.
|
| Similarly, A microservices/SOA architecture can fail to break
| down their domain into good boundaries and abstractions. I've
| seen this happen a lot.
|
| It's a lot harder to fix bad microservices than to fix a bad
| monolith
| alexchamberlain wrote:
| It's very hard to isolate load from different use cases, use
| a mixture of different technologies or combine batch, event
| driven and request/response paradigms within a monolith
| though.
|
| I think certain things are easier to change in a monolith,
| where as other things are easier to change in a service based
| design. Depends what mistakes you've made along the way or
| how the spec/environment changes.
| tomrod wrote:
| Hey! I enjoyed this post a lot. I agree with almost all your
| points raised except for single-team == no microservices. Your
| prose makes your points easy to understand.
|
| I have a couple layout comments:
|
| First, I love that you have a high contract text-to-background.
| That is really helpful for me. There was/is a trend to have light
| gray on white backgrounds for blogs; this is absolutely a
| terrible pattern. I appreciate that you did not go this route.
|
| Second: serif fonts are difficult to read when the font size is
| relatively small. Something like Jura or similar could maintain
| the "terminal" feel without getting bogged down in serifs.
|
| Third: I have a really hard time reading content when it uses
| smaller fonts and uses a minor fraction of the screen. This is
| what I see: https://imgur.com/a/NPCBkHJ -- I am getting older,
| and reading smaller fonts is increasingly difficult for me. I
| tend to keep my zoom at 150%, something about this page forced it
| back to 100%. I am not well versed in responsive design, so I
| don't know the technical details for it, but having zoom maintain
| or using a larger font would save some cognitive cost to older
| users like myself needing to zoom in.
|
| Thanks for your thoughts on microservices!
| KronisLV wrote:
| > Never start with a microservice architecture if you have a
| single team.
|
| This is probably a good point, however isn't the entirety of the
| story.
|
| Personally, i agree that most teams shouldn't start out with
| microservices, monoliths can be entirely sufficient and are
| easier to run and reason about. Otherwise you might end up with
| so much operational complexity that you don't have much capacity
| left to actually develop the software and make sure that it's
| actually good.
|
| However, you also need to think about the coupling within your
| monolith, so that if the need arises, it can be broken up easily.
| I actually wrote more about this in my blog, in an article called
| "Moduliths: because we need to scale, but we also cannot afford
| microservices": https://blog.kronis.dev/articles/modulith-
| because-we-need-to...
|
| Where this goes wrong, is that no one actually thinks about this
| because their code works at that point in time, so they make
| their PDF report generation logic be tightly coupled to the rest
| of the codebase, same as with their file upload and handling
| logic, same with serving the static assets etc., so when suddenly
| you need to separate the front end from the back end, or extract
| one of the components because it's blocking updating to newer
| tech (for example, Java 8 to Java 11, everything else works, that
| one component breaks, so it would be more logical to keep it on
| the old/stable version for a bit, instead for it to block
| everything else), you just can't.
|
| Sooner or later, containers also have to be brought up, since
| they can be a way to do a multitude of applications in a
| manageable way, but at the same time it's easy to do them wrong,
| perhaps due to not understanding the tech or some of the
| potential concerns.
|
| Many out there think that "doing containers" involves taking
| their legacy monolith, putting it inside of a container and
| calling it a day. It isn't so, and you'll still have plenty of
| operational challenges if you do that. To do containers
| "properly", you'd need to actually look into how the application
| is configured, how it handles logging, external services, and how
| it handles persistent data. And it's not the "No true Scotsman"
| fallacy either, there are attempts to collect some of the more
| useful suggestions in actionable steps, for example:
| https://12factor.net/
|
| (though those suggestions aren't related directly to containers
| alone, they can work wonderfully on their own, outside of
| container deployments)
|
| Lastly, i've also seen Kubernetes be used as almost something
| synonymous to containers - in some environments, you can't have a
| conversation about containers without it being mentioned. I've
| also seen projects essentially fail because people chose it due
| to its popularity and couldn't cope with the complexity it
| introduced ("Oh hey, now we also need Istio, Kiali, Helm, oh and
| a Nexus instance to store Helm charts in, and we'll need to write
| them all, and then also have a service mesh and some key value
| store for the services"), when something simpler, like Docker
| Swarm or Hashicorp Nomad would have sufficed. I actually have yet
| another blog topic on the subject, "Docker Swarm over
| Kubernetes": https://blog.kronis.dev/articles/docker-swarm-over-
| kubernete...
|
| (honestly, this also applies outside of the context of
| containers, for example, picking something like Apache Kafka over
| RabbitMQ, and then being stuck dealing with its complexity)
|
| In conclusion, lots of consideration should be given when
| choosing both the architecture for any piece of software, as well
| as the tech to use to get it right. In some ways, this is slower
| and more cumbersome than just pushing some files to an FTP server
| that has PHP running there, but it can also be safer and more
| productive in the long term (configuration drift and environment
| rot). Sadly, if the wrong choices are made early, the bad design
| decisions will compound with time.
| koblas wrote:
| There is a huge amount of truth to this. I've been thinking of
| these as Microliths large monolithic codebases surrounded by
| service workers (lambda style or queue style).
|
| The biggest problem I've seen is that early applications are
| not built in a modular fashion. More as a maze of twisty little
| functions calling each other, where you quickly end up with
| circular dependancies and other "challenges". If your base
| monolithic architecture mimics the world of microservices,
| modular single purpose functions and event busses to pass
| around information.
|
| Good design is good design.
| FinanceAnon wrote:
| Fundamentally, I don't really see much difference between
| monoliths and microservices.
|
| In a monolith, you just call another function/class, but in
| microservices that function is a http call. I guess the benefit
| of microservices is the ability to independently scale different
| microservices, being able to choose different languages for
| different microservices and less conflicts in the repo as more
| people work on it, but you still have to deal with backwards
| compatibility and versioning of endpoints.
|
| I think lambdas are interesting when you look at it this way. A
| microservice is essentially a set of functions which is
| constantly deployed as one unit. But with Lambdas, each function
| is a single unit that can scale independently.
| ajuc wrote:
| > Fundamentally, I don't really see much difference between
| monoliths and microservices. In a monolith, you just call
| another function/class, but in microservices that function is a
| http call.
|
| In J2EE that difference is a configurable technical detail. You
| have 1 service that calls another, and the protocol they use
| can be a normal function call, RMI, SOAP (or I think REST
| nowadays) depending on dynamic configuration.
| spmurrayzzz wrote:
| Scale independently, and as a result can fail independently in
| an unfathomably opaque cascade of failure modes.
|
| I'm a big SOA fan, but my experience with any non-trivial
| lambda architectures has soured me on the FaaS concept writ
| large.
| goodpoint wrote:
| > you just call another function/class, but in microservices
| that function is a http call
|
| The difference is enormous.
| geoduck14 wrote:
| To be fair, you CAN build a monolith in a way that is very
| similar to microservice architecture.
|
| You can have a single function that handles all data base
| writes. A single function that monitors for failures. A single
| function that sends outbound notifications... etc
|
| If these functions are call in a way that: allows for A/B
| testing, SUPER high latency (or no response), failure
| notifications sent to the code owner, automatic retries of
| failures, independent code deploys
|
| Then, congratulations, you have a monolith made up of
| microservices!
| KronisLV wrote:
| > Fundamentally, I don't really see much difference between
| monoliths and microservices.
|
| > but in microservices that function is a http call
|
| I think that maybe you're understating the complexity that
| distributed systems may involve.
|
| For example, see all of the following: - https:
| //en.wikipedia.org/wiki/Fallacies_of_distributed_computing
| - https://blog.erratasec.com/2012/06/falsehoods-programmers-
| believe-about.html -
| https://medium.com/@kenbantoft/falsehoods-programmers-believe-
| about-networks-30a328c25c50
|
| Plus, in the current day and age, we still don't have that many
| convenient ways to make two systems interact over a network.
| REST and things like GraphQL don't map well to actions, whereas
| RPC solutions like gRPC also involve a certain amount of
| boilerplate code and you still need to think about how the
| concerns above.
| mikro2nd wrote:
| And not forgetting "A Note On Distributed Computing" https://
| www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/...
| papito wrote:
| The new generation of devs really develops systems as if HTTP
| were a zero-latency concept.
|
| This is just like those people who consider all DB calls to be
| "free". Not that this went away either, it's just way more
| egregious now.
| trixie_ wrote:
| There's a huge difference between http and function calls. When
| I call a function there is no chance it fails because the
| function 'cannot be reached'. With services there are endless
| reasons why one service is unable to communicate with another.
| It's a huge amount of overhead to build a system to handle
| inter-service communication and failure that doesn't exist when
| only calling a function in the same binary.
| FinanceAnon wrote:
| I agree, but perhaps I didn't word it the right way in my
| original comment. With microservices there is a big overhead
| in development and managing failures, but functionally it
| doesn't offer much more than a function call within a
| monolith.
| helge9210 wrote:
| > When I call a function there is no chance it fails
|
| I like to print statements like this one and put them in a
| frame on the wall.
| trixie_ wrote:
| Fails because the function is unreachable. The second half
| of the sentence you quoted says exactly that, why did you
| cut it out?
| helge9210 wrote:
| If execution of your binary is stopped some time between
| the call and return (with following restart), dealing
| with it is no simpler than dealing with network
| partitioning.
| valenterry wrote:
| It is. Because then you know that the caller also must
| have failed. Whereas with an http call, you might want to
| retry, log the error, fall back to a cache, etc. etc.
| zo1 wrote:
| It most certainly is easier to deal with the in-process
| version. I'm specifically referring to database
| transactions, which are much harder to have available in
| a distributed context. That failed network call
| complicates your life _so much_.
| [deleted]
| mellinoe wrote:
| This is ignoring the fundamentally-different issue that
| was raised, which is that the service boundary introduces
| a new failure point that doesn't exist in a function
| call. What you're describing could just as easily happen
| in a service call, IN ADDITION to the service just not
| being reachable.
| biglost wrote:
| And, you add latency issues and overhead. With a function
| call you pass two int and get a string of length 120 (how
| much memory is this? little, very little), with microservices
| you make an api call using http with it headers and get a
| json, and maybe you could need 2 api calls. For me it's easy,
| just create a monolith, when you become facebook or netflix,
| split symfony services into microservices (just an example).
| Oh, and don't forget the developers who translate a specific
| function into an endpoint, you need a change in the caller
| and you must change the api!
| com2kid wrote:
| > When I call a function there is no chance it fails because
| the function 'cannot be reached'.
|
| Run time DI configured from XML.
|
| With enough Java anything is possible!
| jayd16 wrote:
| There's flexibility in the ops/deployment side that you don't
| get with simple library calls. You can take down a specific
| service cluster and keep your app running with slightly
| degraded functionality.
|
| The blast radius on deployments can be smaller.
|
| You've already done the work to build up IPC/networked
| communication so you can make big decisions in a service (like
| using a better suited language for some feature) without
| worrying about integrating it with every other feature in your
| monolith.
|
| You can tailor the instance type to the service. Say you need
| some kind of video ingestion (or something) that is low use but
| needs a high memory ceiling. Would you rather pay for that
| memory across all your monolith instances or just run a few
| instances of a high memory service?
|
| There's a lot of differences you're not thinking about.
| papito wrote:
| First of all, we called these "distributed systems". We reserved
| those for rare cases where scale was THE requirement, and you
| jumped into it fully expecting to have no life.
|
| The world did not finally "crack" distributed systems. Most
| companies created multiple microservices, putting their small dev
| team underwater because "this is the way at the FAANG".
|
| All of your DRY principles are out the window, and now you have
| to debug in production - the new word for _that_ is
| OBSERVABILITY.
|
| Not to mention that the actual reason for distributed systems is
| to scale multiple parts of the system independently, but you need
| to KNOW what has to scale individually before you do it. What I
| see is that the topology really reflects the company structure,
| of course. It's not "what has to scale separately", it's "team Y
| is working on X, and team Y does not want to talk to team Z, so
| they will create a service to make sure they don't have to talk
| to people".
|
| Except that this is a giant self-own. We all still have to talk
| to each other, like, a LOT, because things just keep breaking all
| the time and no one knows why.
|
| Dropbox, Instagram, StackOverflow - these companies are largely
| monoliths to this day. You thinking that your small outfit needs
| to be like Google is highly arrogant.
|
| And don't get me started on the amount of money, people, CPU
| cycles, and CO2 emissions wasted on this solving of the problem
| most people don't have.
| Sohcahtoa82 wrote:
| My thoughts on microservices...
|
| They're fine. But what's NOT fine are _nano_ services. I did
| security on a project once where it seemed that every function
| was its own microservice. User registration, user login, and
| password resetting were each a separate microservice. It was an
| utter nightmare.
| coding123 wrote:
| Did they do this?
|
| user-registration.api.dev.my-company.com
|
| user-login.api.dev.my-company.com
|
| password-reset.api.dev.my-company.com
|
| or paths by some huge k8s nginx ingress?
| Sohcahtoa82 wrote:
| They started with the latter, but started shifting towards
| the former.
| zkldi wrote:
| Reminds me of this classic:
| https://www.youtube.com/watch?v=y8OnoxKotPQ
| Sohcahtoa82 wrote:
| How have I not seen this channel before?
|
| I'm realizing that the YouTube algorithm has no idea I'm a
| software/security engineer. It thinks I'm only into gaming,
| face plants, and dash cam videos.
| jeffbee wrote:
| Shoot, that's practically a monolith compared to the nightmare
| from which I resigned earlier this year. No way would they have
| allowed the entire password reset to reside in a single
| service. It would have been in the password-db-reader service,
| the password-db-mutator service, and the password-checker-
| service, among others. Absolutely terrifying and unmanageable.
| spmurrayzzz wrote:
| This is the flavor of reductio ad absurdum example I always
| give when people hype up the "micro" part of microservices.
| Only meant to be illustrative-- I had no idea that any org
| was _actually doing_ that sort of nonsense, yikes.
| BoumTAC wrote:
| I watch the other day, the Lex Fridman podcast with Kevin
| Systrom, founder of Instagram.
|
| He talks about the scaling issue; they were using Django at that
| time and scale up to 50 millions users with a small team of
| developers.
|
| I do not think a majority of companies have more than 50 millions
| users and absolutely need to go full microservices.
|
| https://www.youtube.com/watch?v=3pvpNKUPbIY
| zarkov99 wrote:
| Micro-services are meant to scale the number of developers not
| the number of users. As the article points out they are meant
| to address organizational issues and they do - at a significant
| technical cost.
| BoumTAC wrote:
| As I point out, they were a small team of developers before
| being bought by Facebook. And they still scale up to 50
| million users.
| zarkov99 wrote:
| Sorry, I misinterpreted what you originally wrote.
| hbn wrote:
| I don't think the number of users nor number of developers is
| really the deciding factor. Instagram, pre-Facebook
| acquisition, was a VERY simple application. It was literally
| just a chronological feed of (strictly square) photos with
| captions, you followed your friends, could explore hashtags,
| and not much more. Videos wouldn't even come for a few more
| years, let alone all the crazy stuff Facebook has hamfisted in
| there since.
|
| For the scope of that app, it would have been absurd to use
| microservices. And I think most people who are in favor of
| microservices would say the same thing. To me, what
| microservices help with is when you're building an entire
| platform, rather than a single product. Not even necessarily on
| the scope of Facebook or Google, but I've worked at companies
| where one team might work on an app for managing social media
| accounts, and another app helps you optimize the SEO of your
| website. Neither of those things really want to own the concept
| of a user they both share, or deal with account creation and
| whatnot. So that's handled by a dedicated microservice.
|
| Now, when you get to a size where you're building a platform,
| you're likely going to have lots of developers and users, but I
| don't think whether you use microservices is a function of
| either of those numbers, and they're just a side effect of the
| thing you've built.
| papito wrote:
| But they COULD have been. Insta was 12 people when it got
| acquired. If they tried to be "cool" and did distributed
| systems, the team would have ballooned to _at least_ 10x.
| cjfd wrote:
| One should probably not even think of microservices if one
| employs fewer than 100 programmers. In many cases microservices
| are introduced because of fashion and/or resume driven design not
| because it actually makes sense. I prefer refactoring a poorly
| structured monolith to refactoring poorly structured
| microservices in every case.
| codyb wrote:
| A coworker at a previous four person startup was always
| advocating microservices.
|
| Having to push back on that over and over was frustrating.
|
| We didn't even have a real devops guy, or a vpc with properly
| partitioned CIDR blocks to segregate our databases from the
| public web and we're going to start adding the complexity of a
| microservice architecture?
|
| For what! We didn't even have _users_ yet.
|
| But try to get folk to dogfood our application since we had no
| actual users besides the founder and it was like pulling teeth.
|
| Totally backwards to me.
| BoorishBears wrote:
| To me microservices should not be an architecture.
|
| You can have pieces of functionality in a monolith that make
| sense to scale independently, and those should not be micro,
| they should be meaningful pieces of functionality that justify
| the overhead of spinning them out.
|
| In a way your comment reflects this, a lot of the places that
| justified microservices were at a scale where their
| "microservice" was serving more requests than the average
| company's entire codebase.
|
| It's "big data" with 10 GBs of logs all over again.
| afarrell wrote:
| It is worth thinking about them before you need them because by
| the time you gain the skill and infra needed to support them,
| you'll have scaled so large that your ability to coordinate and
| communicate will be overwhelmed.
| papito wrote:
| How many startups out there have run into the problem of "oh
| no, we got too big too fast"?
| afarrell wrote:
| A fraction of the ones that are successful.
|
| I suppose what I really mean is: If your leadership
| subordinates (especially new joiners) are starting to
| struggle to coordinate, consider the possibility that you
| might already be at that point yet emotionally attached to
| the notion of staying small as you double or quadruple in
| population.
| m0llusk wrote:
| This doesn't match my experience at all. In particular, in the
| case where a small team is working on a series of small
| projects it can make a lot of sense to split up the components
| so that any one of the small projects can be built with one or
| two existing generalized components along with some custom
| machinery and some glue code to bring it all together. That way
| development of all of the small products can contribute to some
| well honed components that get shared by multiple products and
| development cycles.
|
| It seems like this is not coming up because the most common
| context of application is one or more teams working on a single
| large project probably forced to grow as fast as possible
| because of the funding structure involved. Increasingly,
| though, there are companies doing software development without
| the need for focus and scale that is so common to venture
| capital powered groups.
| mason55 wrote:
| The major difference is whether the small projects are
| independent applications that use some shared libraries (what
| I think you mean by "existing generalized components") or
| whether the small projects all talk to each other to create a
| single large application.
|
| If it's the former then you're just talking about refactoring
| functionality into a shared library, but at the end of the
| day you're still just building little monoliths. You don't
| have to worry about most of the problems that come up with
| microservices.
| belter wrote:
| The whole problem starts with calling them microservices. Just
| call it a service oriented architecture please. The whole micro
| thing is already an indication of the kind of trouble you are
| getting yourself into. More respect to the monolith please.
| syngrog66 wrote:
| I couldnt tell if you were serious or joking, or a mix of
| both. I think in part because I had the same reaction when I
| heard about microservices. I thought:
|
| "Uh... we had that back in the early 2000s at least, they
| called it SOA back then."
|
| And yes we learned back then how painful and complex that
| kind of architecture was to reason about and support,
| compared to a simple monolith.
|
| Monolith is truly king unless obviously you're at FAANG
| scales. 99%+ of shops are many orders of magnitude below that
| scale.
| UglyToad wrote:
| I'm going to build a lucrative personal brand / consulting
| business by hyping mesoservices, neither micro nor macro,
| just right.
| belter wrote:
| Reality and Fiction mingle together...
|
| "Mesoservices: Architecture for optimal trade-off between
| engineering and operations efficiency"
|
| https://www.codemotion.com/talks/mesoservices-
| architecture-f...
| hallway_monitor wrote:
| This is key. Recently I've become a bit obsessed with naming,
| and not just because naming needs to be consistent and
| coherent - how you name something in software dictates how
| you will think about it, what concepts you will relate to it,
| etc. The name of one component can affect your entire
| architecture. I'm not sure how to validate it, but I believe
| that naming choices are almost as important as application
| architecture because of their effects on your thought
| process.
| snarfy wrote:
| Another phrase I like to use is 'vertically integrated
| service'. You need to be vertically integrated to scale
| horizontally. That is the whole point of microservices after
| all.
| cjfd wrote:
| Well, a service-oriented architecture is a more general
| category then microservices and has been around much longer.
| In many cases it is much more justifiable on technical
| grounds. Just to give one example. You have an API that is
| not the most stable thing in the world and when it misbehaves
| you do not want it to take the whole application down with
| it. So you put it in a separate service that can easily be
| restarted. That is a good technical reason for a separation
| of executables. Problems arise when people introduce these
| separations for no good reason. Then one gets all of the
| problems of RPC and none of the benefits. I.e., one is making
| things more complicated for no good reason.
| jjoonathan wrote:
| > and has been around much longer
|
| There's your problem. People understood the tradeoffs, so
| it needed a rebranding before it could go through another
| hype cycle.
| solmag wrote:
| I like them for modularity, message queues and asynchronous
| events. But you are correct, esp. last one.
| cjfd wrote:
| Things like message queues and asynchronous events are
| available for your favorite programming language for in-
| executable use. You can then do things like running them on a
| thread pool that has the same number of threads as your
| machine has cores.
| jayd16 wrote:
| So you're not only suggesting monolith, but single
| instance? In process and non-shared queues only? No load
| balancing across monoliths?
| imwillofficial wrote:
| I didn't read any of that. I read it as more tools in the
| toolbox.
| jayd16 wrote:
| Without single instance, an in process queue doesn't
| provide the same kind of functionality that a shared
| queue does and would probably introduce split brain kind
| of problems, no?
| imwillofficial wrote:
| Right, you're taking it as a suggestion, as in a positive
| nudge to single instance monolithism. However, I read it
| as merely making GP aware of other options that are on
| the table.
| cjfd wrote:
| Not necessarily. That one can have these tools in-
| application doesn't mean one cannot combine this with
| some form of RPC as well. Especially whether one needs
| load balancing or not seem to be a completely orthogonal
| issue.
|
| On the other hand, why not a monolith and single
| instance? If one uses a performant language one would be
| amazed how much can run on a single machine. If one
| expects growth one should have some plan to scale, sure,
| but if one does not go for shenanigans like running
| queues and the like between applications using some form
| of RCP one might get amazed how much your single monolith
| can actually do. All this extra networks stuff and so on
| is not exactly free.
| jayd16 wrote:
| >On the other hand, why not a monolith and single
| instance?
|
| Single points of failure are bad. I agree its orthogonal,
| which is why I inquired further about the, imo, odd
| suggestion.
| ratww wrote:
| Running a single instance doesn't mean not having a
| backup.
| wongarsu wrote:
| Plenty of languages offer modularity, message queues and
| asynchronous events within a monolith. They are quite
| idiomatic in go, rust and elixir
| foobarian wrote:
| Splitting a system into microservices can help individual
| teams be better stewards of their part of the system. They
| can release on their own schedule, they can use their own
| linting rules, heck even a different language, and they can
| have better control of incoming code changes. With a
| monolith any random developer can go and flip some private
| method to public, import it way across the modules, and
| presto you are now building a ball of mud. Need an out of
| cycle release? Hopefully you have CI/CD or now you have to
| beg the SRE in charge to do it for you.
| Sebb767 wrote:
| > Splitting a system into microservices can help
| individual teams be better stewards of their part of the
| system.
|
| _Team_ being the keyword here. If you have 3-5
| developers per microservice, you 're absolutely okay. If
| you have 3-5 microservices per developer, that's when it
| gets ugly.
| WJW wrote:
| If you don't even have CI/CD yet I'll argue that your
| team has not reached the operational sophistication
| required for microservices yet. There are many ways in
| which microservices
|
| Also if individual devs can reach out across the codebase
| and turn private methods public, it is the pull request
| review procedure that you need to improve, not the
| architecture.
| ratww wrote:
| _> With a monolith any random developer can go and flip
| some private method to public, import it way across the
| modules, and presto you are now building a ball of mud._
|
| If "any developer" can do it, then the problem is not
| with monoliths, but rather with your pull request reviews
| process and lack of code ownership. This can even be
| helped by Github and other platforms with a _CODEOWNERS_
| file.
|
| Microservices by themselves doesn't solve this problem.
| If anyone has commit access to all micro services, then
| they can make an even bigger mess, the same way.
| foobarian wrote:
| I haven't had experience with well isolated modules in a
| monolith so I'm likely not giving monolith enough credit
| here. It's possible a microservice organization may still
| have an advantage by having more of this isolation by
| default, instead of an uphill battle to get things set up
| properly.
| [deleted]
| ratww wrote:
| If you are already doing code reviews, it is trivial to
| setup.
|
| If you're using microservices + monorepo, you need
| exactly the same thing, otherwise people will just commit
| in your service.
|
| If you're relying on multiple repositories, you can just
| split things within libraries and have the exact same
| effect. You can even have separate deployments with this
| arrangement.
|
| Not to mention it is also an "uphill battle to get things
| set up properly" with microservices, so there's really no
| advantage in using them for enforcing encapsulation.
|
| But most important: a team unable to enforce
| encapsulation and code ownership is not ready for
| microservices _at all_.
| drunkpotato wrote:
| Yes, that is the marketing brochure pitch for
| microservices.
|
| In the real world, poorly designed microservices make the
| ball of mud problem much, much worse, and whatever pain
| you had in deployments in a monolith are now magnified
| ten-fold. I have not been fortunate enough to see well-
| designed microservices, so I suspect the ball of mud is
| the default. Can this be rectified through discipline?
| Probably, but I haven't seen it.
|
| Asynchronous? Doesn't save you, when an upstream service
| changes event definitions and emits events with
| unexpected structure, and a downstream service starts
| failing. Can this be rectified through Async OpenAPI and
| rigorous contract testing? Probably, but I haven't seen
| this happen in a way that helps.
|
| I have seen large companies survive perfectly well on a
| monolithic ball of mud, and small companies get lost in a
| mud pit of microservices.
|
| My point is not that microservices are bad, they're not,
| they're just a tool, but they are a tool that is a poor
| fit for most companies, in my opinion. I can't speak to
| the few giant companies that need them and use them
| effectively; there is a good reason the tool exists.
| foobarian wrote:
| > In the real world, poorly designed microservices make
| the ball of mud problem much, much worse
|
| I can see that. I am trying to reflect on why I have such
| negative experience with a monolith and positive with
| microservices. It's possible that in the monolith setups
| I had, poor design was easy by default. No linting, no
| cross-module ownership interlocks, very slow and costly
| production deploys. Likewise the microservice setups
| tended to make poor design harder since code is isolated
| by default both at compile and runtime.
|
| Can you make a monolith with all the good benefits of
| modularity but without the complications of network RPC
| etc.? Maybe, but I haven't seen it yet. (Excluding
| trivial single-team apps; talking about at least 3 teams
| and 50+ headcount orgs).
|
| > Asynchronous? Doesn't save you, when an upstream
| service changes event definitions and emits events with
| unexpected structure, and a downstream service starts
| failing
|
| Sure, shit happens. Again my experience may be colored,
| but when costly mistakes happen in monoliths, it tended
| to take longer to roll back because of how deploys are
| structured both technically and on an organizational
| level. I think I would still prefer smaller units in this
| case.
| yakshaving_jgt wrote:
| Given your negative characterisation of the "ball of
| mud", I'm guessing you haven't actually read the original
| paper.
|
| > heck even a different language
|
| There's nothing about writing software in different
| languages that necessitates separating functionality with
| HTTP calls.
| foobarian wrote:
| > There's nothing about writing software in different
| languages that necessitates separating functionality with
| HTTP calls
|
| I mean it's only computers and the only limit to what we
| can make them do is our imagination.
|
| In this case though for the sake of argument what options
| would I have if I, say, needed to let a remote team add
| some functionality to my, say, Spring backend but they
| really prefer to write C# and have their own CI/CD
| system. I'm not sure how I would accomplish this in a
| monolith.
| ratww wrote:
| _> I 'm not sure how I would accomplish this in a
| monolith._
|
| With a library.
|
| Depending on what you're doing (process ran a few times a
| day?), maybe even spawning a process is enough.
|
| _> what options would I have if I, say, needed to let a
| remote team add some functionality to my, say, Spring
| backend but they really prefer to write C# and have their
| own CI /CD system._
|
| That sounds like you need at most two different services,
| not microservices.
| foobarian wrote:
| > With a library.
|
| I don't know what that library is right now. Meanwhile I
| could set up the separate repos/microservices by the end
| of the day.
|
| > That sounds like you need at most two different
| services, not microservices
|
| It is unfortunate that the "micro" in "microservice" is
| often misunderstood to expect that these are very small
| and granular components. In practice by and large it ends
| up being separate services with separate repo, code
| review, ownership, deploy or CI/CD etc. pipelines. It
| doesn't have to mean they are actually very small. I know
| people like to joke about npm components and the leftpad
| thing but in my experience microservices have not turned
| out like that.
| ratww wrote:
| _> I don 't know what that library is right now_
|
| Are you serious? In which language do you program that
| you don't have to use multiple libraries daily? You just
| talked about NPM.
|
| In your example, the C# could output DLLs that have
| functions that can be called by the Java code. This can
| give the same encapsulation you get with your multiple
| services example, including separate deployments,
| different repo, different language, etc.
|
| You could also use different processes. Please tell me
| you know what an executable is...
|
| _> Meanwhile I could set up the separate repos
| /microservices by the end of the day_
|
| That's because someone set it up for you, not because
| it's faster.
|
| In your hypothetical scenario of _" I needed to let a
| remote team add some functionality to my, say, Spring
| backend but they really prefer to write C# and have their
| own CI/CD system"_ you didn't mention that _" ...but we
| already have a fast way of setting up micro services".
|
| _> It is unfortunate that the "micro" in "microservice"
| is often misunderstood*
|
| It's not, you're using the term loosely. "Two services"
| do not make a micro service architecture.
|
| Sorry to be blunt, but I'm getting the feeling you're not
| talking out of experience, but rather repeating popular
| talking points.
| foobarian wrote:
| > Are you serious? In which language do you program that
| you don't have to use multiple libraries daily?
|
| I said I don't know which library would let me make C#
| method calls from a Java Spring runtime, presumably in
| the same process. Do you? Feel free to share a link.
|
| > That's because someone set it up for you, not because
| it's faster.
|
| Yes, the whole point was to come up with a concrete
| example for the sake of argument, and see how we can
| accomplish it in practice. We're not writing academic
| papers here, the fact that this functionality is widely
| available is a good thing.
|
| > It's not, you're using the term loosely
|
| Yes, me and 95% of the industry. Again, it's unfortunate
| but here we are.
| ratww wrote:
| _> I said I don 't know which library would let me make
| C# method calls from a Java Spring runtime, presumably in
| the same process. Do you? Feel free to share a link._
|
| You don't need a library for that, it's is part of the
| language. Java can call code from native libraries, C#
| can export native functions. It can also be another
| process.
|
| _> Yes, the whole point was to come up with a concrete
| example for the sake of argument, and see how we can
| accomplish it in practice. We 're not writing academic
| papers here, the fact that this functionality is widely
| available is a good thing._
|
| The problem is that you moved the goalposts. "I need to
| interoperate with C# code" is very different from "I need
| to interoperate with C# code and my company uses
| microservices and that's the only thing I know".
|
| You can't claim something is automatically worse just
| because you're ignorant about it.
|
| _> Yes, me and 95% of the industry. Again, it 's
| unfortunate but here we are._
|
| Nope. There are exactly zero companies claiming to use
| microservices when they have exact two services. And it's
| not about size, by the way, it's about different
| architectural patterns.
| foobarian wrote:
| > You don't need a library for that, it's is part of the
| language. Java can call code from native libraries, C#
| can export native functions. It can also be another
| process.
|
| Having never done this, I believe you. I am still
| skeptical of how quickly/effectively you could set up a
| CI/CD system and the module repos to deploy to a
| monolith. I wonder how the type interop works there
| (equivalent of OpenAPI-based code generation).
|
| > The problem is that you moved the goalposts. "I need to
| interoperate with C# code" is very different from "I need
| to interoperate with C# code and my company uses
| microservices and that's the only thing I know".
|
| That's maybe a bit unfair. There are a lot of
| microservice shops, but I haven't heard many who do this
| Franken-monolith thing. Remember that infamous
| microservice dependency graph from Uber? I guess Facebook
| was famous for doing a monolith but I don't know if it
| was purely PHP or not.
|
| > You can't claim something is automatically worse just
| because you're ignorant about it.
|
| I can if the metric is availability/familiarity in the
| industry, but OK.
|
| > Nope. There are exactly zero companies claiming to use
| microservices when they have exact two services. And it's
| not about size, by the way, it's about different
| architectural patterns.
|
| I don't know, my experience is people like to say they
| use microservices but they just have a service-oriented
| architecture. Meanwhile I never ran across an
| organization that does something like npm modules and
| goes way crazy with granular services. I don't know,
| maybe they are out there.
| jayd16 wrote:
| In process queues don't offer the same capacity smoothing
| as a shared queue. I don't think most of those queues offer
| persistence either. They're really not equivalent, are
| they?
| choeger wrote:
| If I was CTO of a company, microservices would give me
| nightmares. How do you do due diligence on used free software
| (licenses and security updates)? How do you plan the resource
| usage of your whole setup if every developer can add a new
| autoscaling service? Who is actually keeping track on deployments
| so we don't accidentally overload the system? How do you refactor
| a cross-service feature consistently? And the worst part: Who
| keeps track of the n*n contracts between the services?
|
| I mean yes, I know that each of these problems can be solved,
| sometimes in a relatively straightforward manner. But who really
| has all these aspects covered and doesn't run some services that
| started to smell weirdly a couple of months ago?
| clintonb wrote:
| > How do you do due diligence on used free software (licenses
| and security updates)?
|
| Use the same process you would use if you had a monolith.
|
| The rest of your issues can be solved by planning out your
| services, rather than giving everyone free reign to make a new
| service. Switching to services doesn't magically mean your
| teams stop talking and designing together.
| bluGill wrote:
| I'm looking at micro services for a different reasons: security.
| I have given up on the idea that our code will ever be completely
| secure. However micro services means if someone breaks into one
| service they can't see data belonging to a different service.
| (that is run each service as a different user, and so OS
| protections means file commands cannot open such data)
|
| This only protects against some threats related to insecure code,
| but layers of protection is the key to threats and it is useful
| for the parts it does help.
| daxfohl wrote:
| I could maybe see that for some specialized case, but for the
| general case it seems like the more independent, distributed
| things you're juggling, the more likely you are to end up with
| security holes in the first place. The time you have to spend
| on security would have to be spread too broad and thin.
| bluGill wrote:
| The cost varies. Some of the code I work with is safety
| critical - people can die if it isn't working. If someone
| breaks into our system and gets private data that "only"
| costs us a lot of money, but if they break into our system
| and take over the safety critical parts people die.
| Nextgrid wrote:
| I'd still be concerned about kernel-level exploits in this
| case. I'd run every service in its own VM.
| bluGill wrote:
| There have been examples of people breaking out of VMs. My
| ultimate wish is to run everything on separate CPUs.
| wayoutthere wrote:
| I have found one other use case: limiting the blast radius of ops
| and deployment issues. As an example, I once was working with a
| large telecom client who had their AAA web service (yes, don't
| roll your own auth, but this client was big enough and had the
| right expertise on staff to do so) in the same monolith as their
| account management web service. The account management service
| saw active, frequent development to support new functionality
| while the AAA code only got updated a couple times a year.
|
| Why touch a critical web service relied upon by literally every
| product you have when you don't have to? Your business still
| functions if account management is offline; but not when
| authentication is offline. Even short outages to auth were
| unacceptable (millions of customers) and any updates had to be
| performed in constrained windows due to the criticality of the
| service.
|
| So we cleaved off the mission-critical parts, stuck them in their
| own repos to be versioned independently, which let us move faster
| on the account management work since we could confidently deploy
| code that wasn't 100% working because we didn't need to wait for
| a maintenance window.
| nunez wrote:
| OP makes a really good point in that dev teams also need to own
| their infrastructure when everything is a microservice. Asking
| "DevOps" to change an infra component prior to a release just
| shifts the monolith under the rug while also completely defeating
| the point of DevOps.
|
| Lots of devs don't know infrastructure that well, though this is
| changing with the adoption of Kubernetes. Additionally, most devs
| don't want to go on-call when their app crashes unexpectedly.
___________________________________________________________________
(page generated 2021-12-01 23:02 UTC)