[HN Gopher] Why our team cancelled our move to microservices
___________________________________________________________________
Why our team cancelled our move to microservices
Author : start123
Score : 93 points
Date : 2022-01-25 21:01 UTC (1 hours ago)
(HTM) web link (steven-lemon182.medium.com)
(TXT) w3m dump (steven-lemon182.medium.com)
| andrewstuart wrote:
| Microservices shift complexity from code to operations -
| microservices don't remove complexity - they spread it wider,
| making the whole more complex.
| Kalium wrote:
| I agree that microservices shift complexity, but I'm not sure
| that this inherently results in an overall increase in
| complexity. For example, using highly automated ops tools like
| autoscaling and load balancing can enable smooth handling of
| problems that can be challenging to handle in code.
| FridgeSeal wrote:
| It's about trade offs I think.
|
| Monolith can Microservices are so often presented as "x is
| better than y", but it should be "which is more applicable for
| the team size, product and operational concerns".
|
| Monoliths are a great choice for certain team sizes and
| applications, want stricter isolation and blast-radius between
| different teams and products and need to scale different things
| differently? Micro services are probably a better choice.
| ironmagma wrote:
| Examining behavior in the limit (a la physics) is interesting.
| Imagine a system where every function call goes out to a
| separate process. Suddenly you have a lot of processes waiting
| around to be called. Debugging requires special tools.
| Profiling becomes a nightmare. Even determining if the system
| is fully running becomes difficult. What have you gained?
| edude03 wrote:
| Minor nit: functions as a service are almost exactly this -
| and they (from a technical perspective) don't wait to be
| called, they pop into existence just in time.
|
| Arguably though it's not special tools is just different
| tools. You usually can't run a debugger live in production
| but with tools like distributed tracing and service meshes
| you get really close
| whimsicalism wrote:
| > What have you gained?
|
| Separation of responsibilities? Easier to analyze because you
| only have so many inputs and outputs to a simpler system?
|
| Debugging something that touches a lot of paths in a monolith
| can be quite nightmarish as well.
| bcrosby95 wrote:
| Most comments about this assumes a poorly designed monolith
| and a well designed set of microservices. A microservices
| architecture can be a rats nest too.
|
| I guess what it means is that even if you can build a well
| modularized system, it will only stay well modularized if
| you use a network call to enforce it. Well, at least for
| most companies.
|
| Conceptually, there's nothing keeping you from designing
| your codebase to work as both microservices or direct
| calls. I've certainly done it before - each service defined
| a Java interface, and codegen could hook that up as either
| a direct call or to route over some kind of layer.
| whimsicalism wrote:
| Or something that can be spun up as a service or imported
| as a library
| ironmagma wrote:
| > you only have so many inputs and outputs to a simpler
| system?
|
| Doesn't a function only have so many inputs and outputs
| too? Scope capturing/global variables aside.
| whimsicalism wrote:
| > Doesn't a function only have so many inputs and outputs
| too? Scope capturing/global variables aside.
|
| Sure, and a microservices architecture to me implies a
| larger movement towards function-esque, idemopotency,
| analyzability and away from global state.
|
| To me, monolithic architecture implies global shared
| state that is difficult to reason about.
| [deleted]
| rydgel wrote:
| Why would you consider microservices if you are only 12
| developers?
| tored wrote:
| It can sometimes make sense even that small, like if team has
| different geographical locations and/or time zones.
|
| And that I think how you should approach micro services, to
| solve an organizational problem, not use it for solving a
| technical problem.
| bhuber wrote:
| Most of the conversation so far has focused on the development
| benefits of microservices (decoupling deployments, less
| coordination between teams, etc). Small teams don't really have
| this problem, but there are other benefits to microservices.
| One of the biggest is scaling heterogeneous compute resources.
|
| Suppose, for example, your webapp backend has to do some very
| expensive ML GPU processing for 1% of your incoming traffic. If
| you deploy your backend as a monolith, every single one of your
| backend nodes has to be an expensive GPU node, and as your
| normal traffic increases, you have to scale using GPU nodes
| regardless of whether you actually need more GPU compute power
| for your ML traffic.
|
| If you instead deploy the ML logic as a separate service, it
| can be hosted on GPU nodes, while the rest of your logic is
| hosted on much cheaper regular compute nodes, and both can be
| scaled separately.
|
| Availability is another good example. Suppose you have some API
| endpoints that are both far more compute intensive than the
| rest of your app, but also less essential. If you deploy these
| as a separate service, a traffic surge to the expensive
| endpoints will slow them down due to resource starvation (at
| least until autoscaling catches up), but the rest of your app
| will be unaffected.
| jeremyjh wrote:
| So sure, maybe make the ML model a separate service, but you
| don't really have the same driver for other services; state-
| less server processes tend to need the same type of resources
| only in different amounts, and you don't really gain anything
| by splitting your work load based on the words used in your
| domain description.
|
| Real-world monoliths often do have some supporting services
| or partner services that they interact with. That doesn't
| mean you need a "micro-service architecture" in order to
| scale your workload.
| FridgeSeal wrote:
| Because the team might already be comfortable working in that
| way? Because certain parts of the application might require
| specialised implementations and very natural lines of
| separation fall out?
|
| I'm in a team of 4 and the few API's we expose would be
| considered microservices. We did that because it was easiest
| and fastest for us to build and maintain and the features we
| provide were all quite distinct.
| kgeist wrote:
| Just last week I found an interesting and unexpected (for me)
| advantage of microservices. We have two monoliths written in
| different stacks/frameworks, and developed by different
| departments. Monolith #1 is being split into microservices, we
| already have around 20 microservices. Monolith #2 kind of lags
| behind, and there are certain problems that they encountered,
| which are already solved in one of the microservices split from
| monolith #1. The solution I came up with is to simply reuse the
| microservice from monolith #1 in monolith #2 (the service is
| isolated and self-contained so it doesn't care who uses it). I
| found it to be a rather elegant and simple solution for cases
| when you want to reuse an implementation but can't package it
| into a library because clients have different stacks.
| Ostrogodsky wrote:
| Medium? Nah
| fdgsdfogijq wrote:
| It took me a while to accept that microservices are better. Not
| in every case, but in a surprising number of cases. They really
| shine when combined with serverless computing. Clear seperation
| of code by a networking call is the next logical step in the
| encapsulation principle of object oriented programming. We hide
| the implementation details and only expose an interface, which
| creates seperation and forces us to stop sphagetti logic.
| Microservices are the enxt step in that design pattern, and only
| with the improvement in container technology and cloud computing
| has this become achievable (in the sense of there not being so
| much operations and complexity overhead).
| winternett wrote:
| A size 20 shoe is better for a large foot... But not better for
| a size 15 or size 10 foot.
|
| Saying Microservices are better is the same as me saying "a
| size 20 shoe is better than any other shoe"... for everyone.
|
| It's not a viable statement in any use case, except for people
| with size 20 feet.
|
| The business need is what determines the solution necessary.
| fdgsdfogijq wrote:
| I know its not a catch all. But more often than I would like
| to admit they bring simplicity and reduce complexity. The
| more I develop software, the less I can stomach monoliths
| running on some big server. The other day I was considering
| deploying an MVP I have written on Django, and instead just
| ripped it apart and pushed the pieces into their own seperate
| lambdas. Deploying some monolith API like that was nerve
| wrecking, updates are, the blast radius is higher, and the
| composability of components is easier with smaller
| microservices.
| shuntress wrote:
| I think the catch is that "Services" are typically the scope at
| which encapsulation should stop.
|
| They don't need to be "Micro".
| pc86 wrote:
| This is just arguing over the service boundary definition and
| not the architecture. There are multiple comments here trying
| to differentiate between a "service" and a "microservice"
| which seems like a fools errand to me.
| jokethrowaway wrote:
| I hope you're trolling.
|
| If not, enjoy implementing joins across services.
| pc86 wrote:
| Doesn't this just mean you picked a bad service boundary? You
| shouldn't have to join across services, ever.
|
| Seems like a straw man.
| dagss wrote:
| "just picked a bad service boundary" -- well that's the
| thing isn't it. If you always pick the right boundary up
| front, something that is perfect both now and also
| anticipates any kind of future crazy feature request -- if
| you can pull that off I'd say _any_ architecture will work
| well.
|
| But most people get boundaries wrong some times. Sometimes
| very badly wrong. Sometimes the boundaries are historical,
| set by product owners without technical input, set by
| junior developer, set by superficial attributes, and
| sometimes even the most experienced developer-architect
| just does a mistake.
|
| And the whole point of not doing microservices is you don't
| have a huge investment in your boundaries, it's more
| feasible to change them once you inevitably now and then
| realize you got them wrong.
| tored wrote:
| It will eventually happen even if you manage to create the
| perfect boundaries, e.g for report & statistics.
| rodorgas wrote:
| You shouldn't be doing report and statistics on live
| data, but in a data warehouse.
| dragonwriter wrote:
| Reports and statistics, especially on material that
| crosses service boundaries (but even on single-service
| information, to keep services single-responsibility) are
| their own logical services, which operate on copies of
| data received from (often multiple) upstream services.
| (In many real world cases, you'll want this functionality
| in a data warehouse, but there are some cases where some
| of it may be in something that looks like normal
| services, whose data that can change other than by push
| from other services deals with reporting and report-
| delivery configuration, not the business data on which
| reporting is done.)
| quickthrower2 wrote:
| > Clear seperation of code by a networking call is the next
| logical step in the encapsulation principle of object oriented
| programming.
|
| You can have clear separation at the import/library level
| though. No need to add that extra latency to every call.
| winternett wrote:
| The term "Monolith" was devised by people who wanted to brand
| microservices as newer and superior.
|
| It's almost as if in order to succeed these days you need to
| discredit and disparage your competition rather than simply
| having a better product, and that's why I don't buy into buzz
| words at all.
|
| If it's not broken, don't fix it... Microservices are relatively
| new and unproven. The way the world has rushed to dive into
| microservice infrastructure only highlights reckless spending and
| waste that is characteristic of overpriced goods and high taxes
| that are constantly in turn thrust upon us, as consumers.
|
| Microservice architecture is also inherently designed to lock a
| customer into very specific tools that make future migration to
| any other platform a very costly decision in most cases...
| Thereby locking a customer into platform-specific dependency.
| Microservices architecture also introduces the ability for
| providers to charge for each specific service as a utility...
| Instead of being charged for one single server annually, on
| microservices you can be charged for many individual components
| that run your app independently, and when usage skyrockets, it's
| a sticker shock that you can only stop by going offline.
|
| We have also seen enough failures and pain points within
| microservice and even cloud architectures over the past two years
| alone to raise questions about whether or not it it indeed a
| better solution.
|
| We need to stop disparaging traditional (non-cloud) hosting and
| solutions that aren't obsolete at all in this manner, and focus
| on what works, what is secure, and what is cost effective in
| order to stay sustainable into the future.
|
| The more we allow marketing minds to take control of our IT
| decisions over reasonable technical minds, the more costly it
| will be to us all over time, no matter what salary we make. Bog
| tech firms will hate me for saying this, but any human in the
| chain can tell that reckless drive for weak/vulnerable/costly/and
| over-complex IT solutions cannot be sustained as a viable long-
| term business sales strategy anyway.
| duxup wrote:
| I don't even know what anyone means by monolith or micro
| services.
|
| I'm somewhat sure everyone is somewhere in between depending on
| who you ask.
| staticassertion wrote:
| ISBN-13: 978-1491950357 ISBN-10: 1491950358
|
| Here you go, you can read this book and it explains.
| duxup wrote:
| I know what the terms means, but I think in common language
| people mean different things when you find out what they
| are doing.
| staticassertion wrote:
| Oh, sure. People are wrong a lot.
| ryan_j_naughton wrote:
| > Microservice architecture is also inherently designed to lock
| a customer into very specific tools that make future migration
| to any other platform a very costly decision in most cases...
| Thereby locking a customer into platform-specific dependency
|
| Can you elaborate on this? Examples? Thanks!!
| glintik wrote:
| > Microservices are relatively new and unproven.
|
| They are so old, buddy, actually. Splitting monolith into
| services(not always been micro) is a natural evolution for any
| software.
| winternett wrote:
| Agreed in essence... The ideology is indeed old, but the
| practice of putting flashy wrappers and catchy names around
| the services are new.. Like "Dynamo DB" and "Route 53". Those
| names appeal to non technical product owners that then force
| adoption onto development teams... Pure fluff at it's best.
|
| That's the think about the marketing first model we're
| dealing with now... No real innovation, just branding/name
| changes and highly tailored customization to lock a customer
| into a specific platform.
| Clubber wrote:
| It was SOA (Service Oriented Architecture) where you would
| split them up, that predates Microservices by quite a bit. I
| remember doing that in the early 2000s.
|
| What I think he is saying is that Microservices people pitch
| their service against monolith as better, but monolith hasn't
| been in vogue for 20 years. I saw the same tactic with scrum
| people pitching against waterfall which hadn't been in vogue
| for quite a while either.
| hdjjhhvvhga wrote:
| Well, SOA is such a broad term. If you include CORBA, you
| could say it's terrible. On the other hand, gRPC is a
| pleasure to work with if you need to deal with different
| environments.
| jbverschoor wrote:
| Although clunky to implement, EJB had really well thought
| out concepts, architecture and roles
| [deleted]
| [deleted]
| ozim wrote:
| I don't think it was "splitting monolith" it was more like
| connecting separate applications.
|
| Like you had a payroll in your enterprise of 1000 employees
| and you needed that same data in 5 applications in 3
| different departments. So you would wrap payroll into a
| service and have that data accessible in multiple places.
|
| I think that is still a valid approach to build monolith app
| and use multiple services if they are internal apps.
|
| For customer facing and quickly changing stuff you might want
| to add microservices to be able to build new features quickly
| when ideally microservice should have its own database with
| what it needs to operate.
| da_chicken wrote:
| > Splitting monolith into services(not always been micro) is
| a natural evolution for any software.
|
| No less natural than "joining the innumerable incompatible
| and bug-ridden fragments into a single unified solution."
|
| Linux is a bazar. Except distros and package repositories are
| cathedrals.
|
| Windows is a cathedral. Except software distribution is a
| bazar.
| rzz3 wrote:
| Yeah, it used to be called "Service Oriented Architecture",
| and is nothing new.
| Graffur wrote:
| > The term "Monolith" was devised by people who wanted to brand
| microservices as newer and superior.
|
| I am interested in hearing more history on this
| [deleted]
| staticassertion wrote:
| > It's almost as if in order to succeed these days you need to
| discredit and disparage your competition rather than simply
| having a better product, and that's why I don't buy into buzz
| words at all.
|
| Meh. In order to sound smart on HN it's easiest to point at
| something and call it "hype".
|
| > Microservices are relatively new and unproven
|
| SOA is old as fuck. Microservices are also fairly old, but
| especially when you consider they're really just SOA + dogma.
|
| > Microservice architecture is also inherently designed to lock
| a customer into very specific tools that make future migration
| to any other platform a very costly decision in most cases...
|
| No? Not at all.
|
| > Instead of being charged for one single server annually, on
| microservices you can be charged for many individual components
| that run your app independently, and when usage skyrockets,
| it's a sticker shock that you can only stop by going offline.
|
| Alternatively phrased: If you only use one service you only pay
| for it, not for the whole suite of features you don't need or
| want.
|
| > We have also seen enough failures and pain points within
| microservice and even cloud architectures over the past two
| years alone to raise questions about whether or not it it
| indeed a better solution.
|
| And plenty of success stories.
|
| > We need to stop disparaging traditional (non-cloud) hosting
| and solutions that aren't obsolete at all in this manner, and
| focus on what works, what is secure, and what is cost effective
| in order to stay sustainable into the future.
|
| Microservices work, are secure, and are cost effective.
|
| Honestly your post contains no useful information and is
| satirically close to a "return to traditional family values!"
| speech.
| ozim wrote:
| That is how you get to it.
|
| If you are noname rapper you start dissing bigger guys so they
| diss you back and you get notoriety because someone noticed
| you.
|
| As a politician you have to say others are the worst and broke
| everything but you have plan to fix everything that is broken
| now.
|
| In the end all the swearing is posturing and all "great plans"
| turn out not possible in reality.
|
| While yes you can do nice stuff with microservices, it is not a
| silver bullet.
| serial_dev wrote:
| Microservices make sense in some scenarios.
|
| I work at a large retail company with who knows how many
| developers. We have different teams for payment, promotions,
| product search, account, shipping and more. All of them working
| on a single codebase with coordinated deployments would be a
| nightmare.
|
| Previously, I joined a startup (previous coworkers of mine), a
| developer and a business guy. The developer "drank the
| microservices kool-aid", and came up with (in theory) super
| scalable solutions and like a dozen of microservices. It was
| difficult to keep things in mind, the tech stack was way too
| complicated for two developers. It was also less performant and
| more costly. The added complexity was totally unnecessary,
| especially because we never got neither tons of users, nor more
| developers. The business guy trusted the developer, so the
| company never worked enough on their product and USP. I guess
| the developer just didn't want to accept that the fancy tech
| solutions won't bring success.
|
| Yet another time, we were a small team (5-ish devs, product
| owner, and a designer). We started with a monolith and we paid
| attention to software design and moved quickly.
|
| Also, for some reason it's often overlooked, that you can make
| your monolith modular and design it so that when the day comes,
| you can split it up into smaller services. You don't need to
| start with microservices, you can start with a monolith and
| figure out later how to split it up (if necessary).
|
| Microservices and "monoliths" have their place, you just need
| to know when to use which.
| rodorgas wrote:
| Is there any way to read without login?
| f0xtrot wrote:
| edit: nvm; its not the full article.
|
| Found it on outline[.]com
|
| https://outline.com/Leznmz
| rodorgas wrote:
| Isn't it cropped on the first paragraph for you?
| quickthrower2 wrote:
| https://pastebin.com/BcA7r18x
| jpalomaki wrote:
| Some perspective from Netflix. Around 10k employees [1] (could
| not find how many are working with software), more that 1000
| microservices [2].
|
| The second article also provides some insight to the services.
| Those make sense for me - they truly sound like independent,
| relatively large pieces of software. Not like "LoginService" type
| of things you sometimes see.
|
| Few examples: 1)Create a main menu list of movies 2)Determine
| your subscription status to provide content relevant to that
| subscription tier 3)Use your watch history to recommend videos
| you may like
|
| [1]
| https://www.macrotrends.net/stocks/charts/NFLX/netflix/numbe...
| [2] https://www.cloudzero.com/blog/netflix-aws?hs_amp=true
| glintik wrote:
| "Microservices had been sold to us as the ideal architectural for
| perhaps a year now." When he learn that there is no ideal
| architectural in software? )
| luhego wrote:
| I think that moving a monolith to a microservices architecture is
| only justified if the organization size is large enough, so there
| are different business teams/departments. In that scenario, each
| team/department will own a microservice and this will speed up
| the development on each team. Still, every time there is a change
| in any microservice API, that will require coordination. For a
| small company(12 developers), I can't see the benefit.
| tored wrote:
| I wish more languages had an abstraction layer above namespaces,
| classes & interfaces, something like Java modules, to help
| organize a large monolith.
|
| Instead of creating isolation over an network interface we add an
| abstraction to achieve it.
| kirse wrote:
| I always start with a monolith while keeping microservices in
| mind. Have clear communication boundaries, avoid shared state as
| much as possible, consider asynchronous and parallel processing
| needs, etc.
|
| Actor systems are a natural fit for this eventual de-coupling.
| What starts as a simple actor w/ a mailbox can eventually grow to
| a standalone REST service with minimal headache in architectural
| refactoring.
| f0xtrot wrote:
| Article is from 2019.
| contextfree wrote:
| I'm not speaking from experience here, but it seems like rather
| than "moving to a microservices architecture" it would perhaps be
| better to think more in terms of "splitting out specific
| functionality X into an independently deployable and hostable
| service, which should alleviate the specific problem Y that we've
| been experiencing due to their being too closely coupled" and if
| there are no obvious X and Y then maybe the "monolith" is fine?
| wpietri wrote:
| For sure. Find a problem first, then look at solutions. Try one
| out, see if it helps. If not, try a different solution.
|
| Man-with-a-hammer syndrome is dangerous.
| shroompasta wrote:
| Their architecture didn't provide any clear boundaries to be
| sufficient for microservices, however that isn't the case for
| many medium to larger sized projects.
|
| (By the way, just because there's still quite a bit of coupling
| between services, doesn't mean there aren't clear boundaries -
| Microservices can communicate with one another all the time and
| still be justified in being decoupled)
|
| There isn't an absolute answer to monolith vs microservices - It
| depends case by case.
|
| Instagram was built using Django and I'm unsure of ig's
| architecture today, but it remained monolithic for a very long
| time (at least till late 2019), and if that architecture sufficed
| for Instagram, I'm sure it would suffice for many other projects.
|
| However, still, it's not a this or that as many of the comments
| here would seemingly imply - Again, it's HEAVILY dependent on the
| case.
| GrumpyNl wrote:
| There is a big misconception that a monolith has to be fully
| deployed every time. A well designed monolith can be partially
| deployed.
| Softcadbury wrote:
| Can you say more about that ? I'm a DotNet developer and I
| don't see how this could be possible without having several
| applications
| henryfjordan wrote:
| If a monolith has routes /a and /b, you can deploy the whole
| service to 2 servers with a proxy where all of the requests
| for /a goes to server 1 and all the requests for /b go to
| server 2. Server 1 has all the code to respond to /b but will
| never see that request.
| atwebb wrote:
| Feature flagging comes to mind, just don't expose the pieces
| that don't work or are in-progress? or .exclude or something.
| pc86 wrote:
| How?
| lemmsjid wrote:
| The 'monolith' (which I find a silly term but I'll use it
| here) can expose different parts of itself as services. As
| long as those services can be versioned and are backwards
| compatible, you can deploy the monolith using any schedule or
| notification mechanism you like.
|
| If the monolith is composed of modules with a DAG-like
| dependency structure (e.g. maven projects), then pieces of
| the monolith can be deployed alongside the dependencies they
| need.
| Graffur wrote:
| I think the problem is there's no popular framework that
| makes this easy (or is there?)
| pythux wrote:
| > Recently our development team had a small break in our feature
| delivery schedule. Technical leadership decided that this time
| would be best spent splitting our monolithic architecture into
| microservices.
|
| Maybe redesigning the architecture of the product just because
| there is time vs. there have a pain point/problem that needs
| solving is already a red flag. In this context it feels like
| "micro services" was a hammer looking for a nail, and they had no
| such nail.
| LASR wrote:
| Exactly.
|
| Microservices can solve for some problems, eg: scaling
| infrastructure in a non-uniform manner or scaling development
| velocity non-uniformly across many teams.
|
| But there are also tons of other ways to solve these problems.
| The mistake is in assuming that you need microservices to do x,
| without really critically thinking about what is actually
| stoping you from having x right now.
|
| The move to microservices (or any similar kind of rewrite
| efforts) should be undertaken only when it's painfully obvious
| that it's needed.
| vmception wrote:
| I think many microservice implementations are more complex than
| necessary but I also am extremely skeptical of someone's
| competence if the database is on the same compute instance as
| everything else
| cyberge99 wrote:
| I'm skeptical because they're on IIS in 2022.
| feoren wrote:
| Rephrasing: "this person, who is probably solving a very
| different problem with different design constraints than me, is
| doing things differently than the handful of ways I have ever
| seen in my limited career, and is therefore stupid."
| foxyv wrote:
| Going from a monolith to a micro-service setup is essentially my
| idea of a Christian hell. Swirling depths of pain and uncertainty
| interspersed with screaming and urgency. There is no rest. No one
| knows when it will end.
|
| I think this is because our monoliths are so complicated they
| hide away our technical debt like monstrous Jack-In-The-Boxes.
| When you start breaking it into chunks all of these issues come
| exploding out of them. Suddenly huge bugs that no one noticed or
| cared about are showing up in testing. Old libraries that sat
| dormant wake from their crypts to harass and torture junior
| developers. Forgotten binaries whose source code was lost with
| the changeover from ancient source control software to GIT starts
| showing up security issues in VeraCode.
|
| Really, a well coded monolith is just a bunch of micro-services
| on the same server communicating through memory. In reality it's
| more of a Lich who's eyes shine with the light of the tortured
| souls of fallen QA testers and developers.
| dasil003 wrote:
| Agreed, however I've experienced something worse: trying to
| refactor domain models across an SOA that was poorly factored
| to begin with, and then layered 10k eng-years of incremental
| feature development driven by a fractured product team with
| short average tenures.
| misterbwong wrote:
| The real problem in monolithic codebases isn't that it's large
| and needs to be separated- it's that the pieces are logically
| coupled. Microservices force you into separation but do not force
| decoupling.
| mykowebhn wrote:
| > It is useful to bear Conway's law in mind when considering the
| shape of your architecture. It states that your software's
| architecture grows in a way that mimics how your organization and
| teams are structured.
|
| I had always assumed that it was the other way around. Good to be
| made aware of the alternative.
| nurettin wrote:
| > A benefit of microservices is that each team can be responsible
| for releasing their services independently and without
| coordination with other teams.
|
| Sounds almost sarcastic. How do you deliver API changes without
| alerting other teams?
| willcipriano wrote:
| I'd guess that 90-95% of tickets do not alter a existing API in
| a non-backwards compatible way
| linuxdude314 wrote:
| Do you not version APIs you design?
|
| When engineering an API meant for consumption by disparate
| services it's imperative to provide back words compatibility.
|
| This is pretty basic stuff anyone designing a serious API
| should be taking into account.
| dzhiurgis wrote:
| Sure we do, it's been /v1.0/ for the last 2 years!
| tombert wrote:
| Generally speaking if you're adding another field to a JSON or
| something, that doesn't really break the parser [1] or affect
| downstream. While you should still probably let the downstream
| teams know, it's not necessarily going to break anyone's code.
|
| [1] I'm aware that that's not always true (e.g. adding a field
| that's ridiculously large choking up the parser).
| darrylb42 wrote:
| or you have a customer that has strict validation on and
| adding a field breaks their ability to deserialize.
| wging wrote:
| Not all changes result in a change to the way your service is
| called, and even those changes can (with some effort and care)
| be made backwards-compatible. Performance-level changes are one
| obvious one - for example, I wouldn't expect to have to keep my
| caller in the loop if I decrease my API's latency by 50ms, even
| though it might be a good idea.
|
| But other behavior changes are also not necessarily something
| that _requires_ a team to be alerted. A good design provides an
| abstraction where the caller shouldn 't have to care about the
| underlying implementation or details of how a request is
| fulfilled.
| bilalq wrote:
| This is how things were done at Amazon quite successfully. The
| golden rule is to never break API backwards compatibility. If
| you must, create a new version of the API and leave the old
| version functional. If you need to shut down old functionality,
| it becomes a campaign you have to drive to move your dependents
| off of it. One little thing that people often overlooked but
| was very important was to have API operations for describing
| your enums rather than just putting them in the docs. This
| allowed for easier adoption of them by API consumers and forced
| them to consider what to do in the case of an unrecognized
| value being encountered.
| kgeist wrote:
| >The golden rule is to never break API backwards
| compatibility. If you must, create a new version of the API
| and leave the old version functional
|
| It also helps with zero-downtime deployments:
|
| 1) spawn a new instance of the service with the new API, side
| by side with the old one
|
| 2) now incoming traffic (which still expects the old API) is
| routed to the new instance with the new API, and it's OK,
| because it's backward-compatible
|
| 3) shut down the old instance
|
| 4) eventually some time later all clients are switched to the
| new API, we can delete the old code
| noogle wrote:
| How can accumulation of versions be prevented? Now the same
| team has to maintain two products, and the underlying
| mechanism is still limited by the older version.
|
| Anecdotally, a robust backward-compatibility has been seen
| as a hinderance to e.g. Java's progress (so much that a
| newer language, Kotlin, was created to break free from that
| burden).
| trinovantes wrote:
| One way is to rewrite version N endpoints to use version
| N+1 endpoints. You just need to ensure clients can handle
| null/empty data so that when some requested data is
| depreciated, you don't break old apps. The increased
| latency from N conversion calls also encourage the oldest
| clients to migrate without breaking backwards
| comparability.
| ARandumGuy wrote:
| There isn't really a solution to version bloat aside from
| good processes and general diligence. There's no easy way
| to handle that sort of thing, unfortunately.
|
| However, I do think it can be easier to deal with for
| internal services then for something like Java. When the
| number of users is in the dozens rather then the
| millions, it's a lot easier to make sure everyone gets
| moved over to the new version.
| kgeist wrote:
| Well we usually coordinate between the teams. I.e. we
| don't force other teams to make changes as soon as
| possible (they have their own plans) but we agree to add
| relevant changes to their backlog, so that it was fixable
| in a 1-2 month window.
| zoover2020 wrote:
| And still done! Fully agree.
| jeffbee wrote:
| Don't ever change APIs. It's pretty simple. I don't know why
| the monolith people believe this is such a gotcha.
|
| If you really need to change the API, give the new API another
| name. You may choose to think of this as "versioned APIs", if
| you want, but "versioned" and "renamed" are the same thing.
| shuntress wrote:
| > Sounds almost sarcastic. How do you deliver API changes
| without alerting other teams?
|
| Sounds almost sarcastic. To deliver API changes without
| alerting other teams you, of course, simply deploy the changes
| without sending a message to the other teams.
|
| The non-sarcastic answer is that sometimes you want to make
| changes that will not affect an APIs users in any significant
| way. Of course you would still document these changes in a
| change log that the consumers of the API may or may not check.
| Or you may want to hype/market these changes for clout reasons.
|
| Maybe it's an API that services multiple sets of users with
| different partially-overlapping requirements and they don't all
| need to know about the new change.
|
| Maybe it's a soft launch for a surprise feature that's going to
| be announced later.
|
| Maybe the other team is on vacation and you just want to get
| changes out the door before some holiday.
| jacobsenscott wrote:
| Also, this (independent deployability) is simply not a feature
| of microservices. It is a feature of any _well architected_
| code base.
|
| I've always worked on monoliths, and I've almost never needed
| to coordinate a release with anyone. I just merge my branch and
| deploy. Github and shopify talk about merging and deploying
| monoliths hundreds of times per day without coordination.
|
| The case where you would need to coordinate a release in a
| monolith is exactly the same case where you would need to
| coordinate a release in microservice app. That's the case where
| your change depends on someone else releasing their change
| first. It doesn't matter if their change is in a different
| service, or just in a different module or set of modules in the
| same application.
|
| Now, most application are _not_ well architected -
| micorservices or monoliths. In the case of a poorly architected
| app deploying a monolith is much easier anyway. Just merge all
| that spaghetti and push one button, vs trying to coordinate the
| releases of 15 tangled microservices in the proper order.
| root_axis wrote:
| Never break the API. If you need a new API contract use API
| versioning so that consumers can upgrade when it's convenient.
| Additionally, use contract testing.
| jokethrowaway wrote:
| That's why finding the right boundaries between services (yes,
| services, microservices is a harmful buzzword) is important, so
| that you minimise having to communicate and coordinate with
| other teams.
| volkk wrote:
| 100%. Boundaries are extremely important, and if you're a
| service onto which 7 other teams rely on, there's an issue
| with your teams and the way you've setup your services.
| Bounded contexts!
| no_wizard wrote:
| Proper deprecation procedures. you can document how you
| uniformly deprecate and remove APIs. This is a strength of
| using something like OpenAPI for documentation, or GraphQL, for
| instance. It is then the responsibility of a consumer to deal
| with these deprecation(s). On the most basic level you could
| also do versioning, though its not _my_ recommendation
|
| Document and set expectations accordingly. I've done this move
| before breaking apart a monolith into separate micro services
| and this is key. Spending more time on good documentation is
| generally a good idea regardless.
|
| I'm assuming we're not talking about public facing APIs. That's
| a situation where versioning might make a lot more sense.
| FpUser wrote:
| Something like Microsoft does with the their interfaces
|
| They have multiple versions of calls. The older one function as
| before and never change. Want different behavior - here is
| your_interface_v1(), your_interface_v2(), etc.
|
| You still alert team about new functionality but they're free
| to consume it at their own pace. This of course involves a
| boatload of design and planning.
|
| I am in general against microservices and consider those as the
| last resort when nothing else works. To me a microservice is
| mostly my monolith interacting with another monolith.
|
| When monolith becomes big enough that it needs 2 teams I
| usually handle it by each team releasing their part as a
| library that still gets linked into the same monolith. That is
| my version of "microservice" when the only reason for it to
| exist is to have two or more "independent" teams.
| giaour wrote:
| > Microservices allow your team to have control over the full
| stack they require to deliver a feature.
|
| This is honestly pretty rare, at least in my experience. What I
| have seen is that organizations will buy in to the microservices
| hype, then dictate to their teams what stacks, deployment
| paradigms, etc. (sometimes even down to the sprint cadence) are
| acceptable.
| beebmam wrote:
| My experience is the opposite of yours. Teams I've worked with
| get massive freedom to implement their services with any
| (reasonable) language + framework: Rust, Python, Java, Go, C++,
| C#, and so on.
|
| Seems like an organizational decision
| jedberg wrote:
| > We have approximately 12 developers spread across 2 feature
| teams and a support team.
|
| If I were consulting for this company, I would have told them to
| stop right there, microservices are probably not for them. Unless
| you build from the start for microservices on something like AWS
| lambda, doing with such a small team would be really hard.
|
| And as they eventually discovered, a lot of unnecessary overhead
| for such a small team.
| wpietri wrote:
| One of the questions I like asking developer pals is what ratio
| their company has between engineers and services/deployable
| units. Anybody reading this care to share?
|
| For me, that number says a lot more about the day-to-day life
| of devs than the microservices vs monolith label does.
| jedberg wrote:
| I don't remember the hard numbers, but on average each
| service was maintained by about 4 people but there were
| outliers in both directions. Sometimes there were four or
| five services maintained by one person, and sometimes there
| was one service backed by a team of 25+.
|
| The other important number was that about 25% of engineering
| was dedicated to building the tools to manage the
| microservices. We didn't work on customer facing software --
| the other engineers were our customers. And I found that
| number to be pretty consistent amongst any company that was
| fully invested into microservices.
| jeremyjh wrote:
| Yeah, honestly this should be the entire content of the
| article. Not only do they only have two small teams but they
| all overlap completely anyway. There is no reason even a
| significantly larger org - say 40+ people in 8-10 teams cannot
| work effectively in a single repository and monolith
| architecture. Beyond that there are certain growing pains and
| if you don't effectively manage those then I could see how you
| end up going with micro-services.
|
| Beyond scaling a large development org the primary benefits of
| micro-services accrue to consultants who bill by the hour.
| dvt wrote:
| A few points I'd like to make:
|
| 1. You can't "migrate" to microservices from a monolith. This is
| an architectural decision that is made early on. What "migrating"
| means here is re-building. Interestingly, migrating from
| microservices to a monolith is actually much more viable, and
| often times just means stick everything on one box and talk
| through function calls or IPC or something instead of HTTP. Don't
| believe me? See this quote:
|
| > The only ways we could break down our monolith meant that
| implementing a standard 'feature' would involve updating multiple
| microservices at the same time. Having each feature requiring
| different combinations of microservices prevented any
| microservice from being owned by a single team.
|
| Once something is built as "one thing," you can't really easily
| take it apart into "many things."
|
| 2. Microservices does _not_ mean Kubernetes. The idea that to
| properly implement microservices, you need to set up a k8s
| cluster and hire 5 devops guys that keep it running is just flat-
| out wrong.
|
| 3. Microservices are "antifragile," to use a Talebian term. So I
| think that this paragraph is actually incorrect:
|
| > This uncertainty made creating microservices more fraught, as
| we couldn't predict what new links would pop up, even in the
| short term.
|
| A microservice is way easier to change (again, if designed
| properly), than a huge app that shares state all over the place.
|
| 4. What's the point here? It seems like the decision was hasty
| and predictably a waste of time. Any CTO/architect/tech lead
| worth his or her salt would've said this is a bad idea to begin
| with.
| edude03 wrote:
| > Microservices does not mean Kubernetes. The idea that to
| properly implement microservices, you need to set up a k8s
| cluster and hire 5 devops guys that keep it running is just
| flat-out wrong.
|
| You don't need to use kubernetes but I strongly believe it's
| the best choice if you're not using FaaS. If you pick nomad or
| bare vms you'll spend a lot of your time building a framework
| to deploy/monitor/network/configure etc your services whereas
| kubernetes has "sane" defaults for all of these
|
| That said - you should use managed kubernetes and not deploy it
| from scratch
| notyourday wrote:
| Do you have an auth service that does not do API? Does your API
| ask the auth rather than reaching into the auth table to see who
| is authorized? When you send an email, do you do it inline or do
| you trigger a push to a queue with separate worker(s)? Does your
| externally accessible API talk to internal services using a
| predefined protocol rather than reaching directly into a
| database?
|
| Congratulations, you have micro services!
|
| As someone who have driven the migration from a monolith (just
| set environment variables and magically the same codebase becomes
| auth, notifications, workers, web and API and the same codebase
| reaches into every single database and talks to every single
| service) into micro services because a simple features were
| taking months to implement, I can confidently say that even
| today, in 2022, an average organization does not have the tooling
| or the team to do a monolith. Monolith is a cargo cult. Break
| stuff into an digestable chunks, externalize your own internal
| libraries if they are shared, version the interfaces and stop
| worrying about microservice complexities.
| joatmon-snoo wrote:
| Monolith vs microservice is not a dichotomy, it's a spectrum (as
| it is with so many other things). Individual microservices can
| still become monolith-y and become responsible for doing a Lot of
| Things (TM).
|
| That being said, the biggest hurdle in a re-architecture project
| like this is usually in the "n=1 -> n=2" stage, and "n=2 -> n=5"
| is a lot easier: once you add service #2, you learn how to set up
| telemetry, permissions, billing/chargeback, alerting, etc. The
| next few are just repeating the same process.
| jedberg wrote:
| I always say n=2 -> n=3 is the hardest step, then n=1 -> n=2.
| With 1 to 2, you can take a lot of shortcuts with the n's
| communicating directly. With 3, you have to start formalizing
| message transmission either through a message bus or a cache or
| whatever. But once you have n=3, n=3+ is pretty easy as it's
| mostly edge cases to solve for or geometric scaling problems.
___________________________________________________________________
(page generated 2022-01-25 23:00 UTC)