Starting with microservices
arnoldgalovics.com
arnoldgalovics.com
The most important thing I learned is that "microservices" in absolutely no way necessitates "bullshit spread across multiple cloud vendors and other scenarios involving more than 1 computer". What part of microservices says things must be separated by way of an arbitrary wire protocol?
We now have a "monolith" (process) that is comprised of many "microservices" (class files), each of which is responsible for its own database, business logic, types, etc. These services are able to communicate amongst themselves using the simple path of direct method invocation.
If you are looking to scale up your capacity or even make things more resilient, microservices vs monolith is really not the conversation you need to be having. If you are trying to better organize your codebase, you might be in the right place but you also need to be super careful with how you proceed.
We wasted a solid 3 years trying to make microservices solve all of our problems. Looking back, we spent more time worrying about trying to put Humpty Dumpty back together again with JSON APIs and other technological duct tape than what our customers were complaining about.
They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.
That's an understatement. It was soul destroying awfulness.
Microservices and monoliths are opposing extremes on a scale. There is a range somewhere in the middle which is entirely sensible.
I feel like I've found my greatest success with my service abstractions by separating things out based on resource and availability needs of the functionality.
I wish more languages/compilers/runtimes had a similar capability.
I think that what the OP is referring to is the fact that you can map URLs to PHP files pretty easily and therefore changing what an endpoint does can be as simple as just swapping out a single file for another one.
However, that tends to fall apart with most modern frameworks, like Symfony, Laravel, Lumen and Slim, where you will typically invoke a main application file which deals with all of the bootstrapping first (reading configuration, DB connections, logging etc.) and then will hand off control over to a router, which will usually map to a controller of some sort, which may have the actual business/view logic spread over other referenced files, the way as other similar technologies like (Ruby on Rails) do it.
Of course, that's not a bad thing, especially since it allows you to follow some of the RESTful conventions, like having path variables without doing rewrites at the web server level, such as /users/12345/photos versus /users/photos.php?id=12345
That said, the whole "mostly single file, maybe with a few common imports" approach can also work fine, as long as your endpoints are kept relatively small. I haven't seen it scale up to large projects that well, at least most of the time.
I think it's a variety of cookie-cutter scaling:
https://paulhammant.com/2011/11/29/cookie-cutter-scaling/
But there's nothing in that about using different entrypoints or routing.
FWIW, variations on the theme:
1. A single binary with a single entrypoint, which can play multiple roles simultaneously (UI, API, scheduled jobs), but where different kinds of request are routed to different pools of instances
2. A single binary with multiple embedded configurations, selecting via command line arguments etc, each for a single different role (UI, admin console, data ingestion)
3. A single (Java) binary with multiple entrypoints (main methods), each playing a different role (live calculations, batch calculations, data recording)
4. A single (C++) codebase building multiple binaries (via CMake add_executable), each playing a different role (calculating prices for potatoes, calculating prices for oranges)
5. A single repository with multiple completely separate applications, with some shared submodules, each built separately, playing a different role (receiving transactions, validating transactions, reporting transactions)
That last one is probably not an example of what you are talking about, but it's closer to the one before than to the first in the list. There is a sort of "ring species" [1] shape to this variation.
That's not a requirement, cf. Erlang/OTP.
But to qualify as a microservice, you need it decoupled enough that you can independently deploy and/or restart individual services. Pretty sure that's a minimum to call yourself microservice-based, and hard to do by just using classes in C++ or something.
Arguably you should also have quite a bit of control over dependencies and their versions. If your service isn't ready for python3, it can keep using python2, or whatever. Taking this to the extreme would generally mean a black box that serializes everything over a network, so that any service can be implemented on any stack. I'm not sure that's fundamental to the idea of microservices, though.
You don't get the convenience of a single datastore with simple transactions but it sounds like you prefer the flexibility of services owning their own data.
As it turns out there's no silver bullet. Do what works for you.
Imagine designing your entire architecture around your build system.
On the opposite extreme you're talking multiple PRs, languages, test suites and deploys for every new feature. I've watched startups do this and die before finding something people want to buy.
We applied this ideology to our software project. Our build/deploy toolchain is 100% in-house code. Turns out, there's actually not a lot of it required because you can build a monster .net project into a single exe distribution with 1 simple command line operation. This applies to most other ecosystems as well. Everything else is basic file operations and moving shit between computers. No reason to vendor either of these problems out.
The benefits of having bespoke CI tooling are difficult to overstate. We've got automated processes where a project manager can multiselect 20 different customers, select a commit hash, and schedule an email containing a link to a zip of the resulting build that will be delivered to each customer's configured IT contact upon completion - all with a single button press. This process also entails injection of customer-specific configuration that is pulled at runtime from another system into each customer's distribution. The email templates are configured on a per customer basis and email delivery is delayed based upon project parameters.
I can't imagine wiring something like this up in Jenkins or GH Actions.
How is the rest of the process not applicable to GH or Jenkins?
While we do Microservices at work ( distrubited team and Conway's law does make sense: https://ardalis.com/conways-law-ddd-and-microservices/ )
It doesn't make sense for me personally. So I applied all DDD logic and implemented it in my app.
In dotnet there is a useful feature where functionality from referenced projects is included in your main WebApp. Which makes everything pretty clean.
I use application logic over 2 "gateways". Where a gateway is a dummy solution that contains Swagger, global things for that project ( eg. auth verification) and uses the controllers/logic from the referenced projects.
- SPA - Angular that contains a Ocelot gateway on the same domain ( = no cors issues)
- ApiGateway - Contains all the backend api logic and custom integrations with partners.
- ShopGateway - Is included in the Frontend.
- Frontend - the shop itselve. Currently in the process of making this db-less ( everything over API / messages or using the gateway. The gateway is currently a referenced project ( see up), so everything is pretty fast)
In the meantime, i can make "reasonable" quick adjustments and the logic is really flexible.
Overview of the solution: https://ibb.co/k5wn07x
Note: Db migration from "1 project" to this is not complete yet :( . But it's one of the bigger shifts and i'm already 90% finished before i can start the actual shift to MartenDb from EF / Dapper )
If you want a quick summary on the logic behind, DDD would be the answer.
The basic problem is that before you know where the module boundary is, you cannot have a clear module boundary. So three popular approaches emerge:
(a) DDD "milliservices". Basically define the different sorts of users, come up with a clustering of the different sorts of people that you think will be using your app. People are considered to be in the same cluster if they use the same jargon to refer to things, or different clusters if they both use some word but they both mean subtly different things by it.
(b) Gut-feeling microservices that become feature microservices. I should probably have an "auth service," I don't know what it does but I'm going to be doing auth so that's probably a service. I need to import a git library to contact GitHub, probably there should be a "git service" that handles all communication to GitHub or other git repos. Each of these things exposes some swagger/openAPI docs, maybe we should have a docs service? -- that sort of thing. The danger is that the things that are easy to break off are usually not the core competency of the product, and so there emerges some sort of "core services," one or two big honkers that basically are monoliths. People are aware that they aren't supposed to keep adding to the core services and so new services emerge named after feature requests, hello "sharing service," hello "wallet service." Except the core usually is tightly coupled to these new feature services and they all kind of connect to each other. The idea of splitting the core services into other services to fit the newfound module boundaries becomes complicated by all these ties to nearby features, you are not actually loosely coupled because you do RPCs and you probably code in the expectation of success into these RPCs like method calls.
(c) Every noun becomes a "nanoservice". This is a service that watches just one or two tables (or NoSQL document types or what have you) and exposes a CRUD API for that noun, plus a couple auxiliary verbs to do actual business needs with those nouns. So if you were implementing Git there would be a file service, a tree service, a branch service, a commit service, probably a working tree service... But you just have to "know" that logs and rebases and cherrypicks live in CommitService while diffing for some reason lives in TreeService and adding a file to your working tree requires first creating it in FileService and then handing that link off to the WorkingTreeService which will make needed calls to TreeService, creating your own tree is exposed via TreeService's CRUD but the developers tell you that down that road There Be Dragons and you should not have been messing with that.
Any of these three can be successful but only insofar as you can create new module boundaries and move module boundaries and test to make sure that your users will not notice any performance regressions. Of them I would only recommend option (a), because it gives a really nice place for these tests to live and an intuition that each test should document a user journey for the system.
I'm in this comment and i don't like it.
My current team has this pattern. I think we've ended up with two core services, with a fairly thin channel between them, but a constellation of tightly-coupled peripheral services around each core.
To be honest, it works pretty well. It wasn't intentional, and it grew in exactly the haphazard way you describe. But it's not a disaster, or at least doesn't feel like one.
Maybe we should rebrand this as "natural microservices"?
Does it mean calling a method of a class?
I don't think I agree with this statement. "More and smaller" also means potentially more routing and communication paths, thus increased latency and complexity.
I'm watching a government customer take simple, cohesive systems developed by a small team (4-5 people) and split it up into tiny little pieces scattered across different hosting platforms and even clouds.
Why?
Because it's "fun" for the architects and pads out their resume.
Just now, I'm watching a "digital interactions" project that will have dozens of components across two clouds, including multiple ETL steps. In all seriousness, half of that could be replaced by a database index, and the other half with a trigger.
They're seriously going to deploy clusters of stuff on Kubernetes for 100 MB of data to make sure it "scales"... to 200 MB. Maybe. Eventually.
What kills me is that now that they've made the decision to over-engineer the thing, my consultancy firm can't bid on the tender because we don't have the appropriate experience building over-engineered monstrosities!
The simple and effective solutions to problems we've delivered in the past are disqualifying us from work.
You guessed it: my next project will be an architect's wet dream and will be over engineered just so that we can say on tender applications that "yes, we have the relevant experience".
Gotta play the game by the rules...
The seemingly-infinite VC money being thrown around around means you can create a startup, raise some money and provide a comfortable salary & industry experience for yourself and your friends for a few years, regardless of whether the company "makes it" in the end or whether the business problem is even solvable.
At this point solving the business problem is no longer the primary objective. The longer you can drag out the process of "solving" this problem the longer you & your employees can enjoy the salary and build "experience". So instead of a simple solution that needs a team of 5, you end up with an engineering playground that needs 50 people (and associated managers, scrum masters, etc) spread across many teams just to keep the lights on. The outcome becomes endless busywork, self-inflicted problems to brag about solving on your engineering blog (every startup has got to have one obviously) and next AWS conference to attract more employees looking for this kind of environment and make yourself look "serious" in the eyes of VCs that keep bankrolling the disaster.
The business problem, if it gets solved at all, is a secondary concern since the VCs happily keep throwing more money into the dumpster fire and some bigger idiot might even buy out the company regardless of its inefficiency.
Fingers crossed he doesn't discover k8s...
One definite disadvantage is testability (which drives stability and ease of refactoring). I can write an automated end-to-end test that will enter some text into a CMS on my site, hit submit, then verify that a post was published. If the CMS is google sheets, I'm going to violate some terms of service and possibly get a blacklisted IP if I do that. Instead I'm going to mock out a response according to the API contract sheets gives me. If they change the API in a subtle way, it may break.
An advantage is that google sheets is probably more robust than my CMS and I'll never be able to look at (or have to fix) their code.
Flexibility cuts both ways: I can't add features to sheets. So if there's a field I really need to validate on the client, I'm out of luck. But also nobody is going to ask for that feature because I obviously can't add it, so that may be good assuming there's a workaround.
Governments are generally driven by a set of requirements that most of us have no inkling of. Distributed deployments are often not just for performance or resilience, but also politics and/or playing the vendors off against each other. It seems daft to us mere minions but there's often N-level chess shenanigans going on near the top.
I think there is value in wiring a monolith together in such a way that each course grained subcomponent exposes a constrained interface into the rest of the system (payments, orders, shipping, customers etc) before needing to break it into distributed micro-services.
Note: I quite like Dependency Injection, I just think the 1 giant bag of dependencies can lead to complexity at scale.
I think the real main issue is lack of discipline when dividing the application into modules.
Spaghetti is basically defined as an application where real modularisation does not exist and everything talks to everything.
It is much easier to work with an application when you can abstract parts of it when you are solving your problem. You effectively work on much smaller part of the application.
Spaghetti == you effectively have to take into account possibility of the piece of code you look at interacting with any other piece of code in the application.
Well modularised application == you only need to take into account the contents of your current module and the interface of the other modules you are using.
One reason why microservices sort of work (when done well) is because they force people to think about APIs and how those services talk to each other.
In most cases you could just put these microservices as modules in a monolithic application and expend the effort on ensuring APIs and application structure.
I have successfully rolled back couple microservice initiatives by integrating services into monoliths. This usually results in the team getting back a lot of their time because their environment suddenly became much simpler. Less applications to manage, less network communication, less possible ways for things to break, less frameworks, less resources needed to run the application, less processes (like processes around deployment, release management, etc.), less boilerplate code, and so on. The list is very long.
Of course, when you work on a large monolith vs a lot of small microservices, it is now important to be able to structure your applications. But there is also an opportunity for improvement.
Sure, if you were ready to make an entire separate application for it it will not be worse when you turn it into one package of a monolith?
Also you can build nested structures with modules (like a larger module consisting of smaller submodules).
Divide and conquer. This is how abstraction works in a nutshell. You start with a large problem, divide it into smaller parts (modules), each part you treat as a separate problem dividing it into smaller modules, and so on.
There exists no need to have a flat application consisting of hundreds of sibling modules.
An application might consist of larger modules, then some of those might have smaller submodules (packages), then those might have even smaller ones (classes), then you have methods, then you have statements, then you have function calls, etc.
A large monolith does not have to succumb to spaghetti or ravioli-type structuring. A good developer should know how to structure an application of any size.
Then instead of having a IService with 15 methods with a construction with 20 dependencies listed (multiply it with say 50 IServices in your project - mmmm spagheti project), you end up with a IHandler with a single method and a constructor that only has say 3 injected dependencies, only what it needs. The trade off is, you now have 100's of small Handler files, some people don't like that BUT you now have a pleasant git commit history per file and most of the code of a Handler file fits on one screen and it is easy to digest. You can also let a handler trigger other handlers if it needs to (via the same mediator). It also fits with SRP.
Auto-wiring 95% of your dependencies still stays intact as the above plumbing will need it to work.
You can run a single copy of the resulting binary (eg. for testing) that spins up all sub-components, or copy it to multiple machines and start individual parts. The ones which happen to run together can use in-process communication as well, others will have to dial in via remoting.
Have worked at multiple companies that started out as a monolith and are still running the monolith in some form or the other while breaking it down into micro services.
I like to analogize it to assembly vs structured programming languages, or C vs Java- you can write the same programs in either, you can write bugs in either, but there are whole classes of pitfalls that get erased by moving from one language to another.
I have experienced this pain so many times and in so many different varieties. Often, you cannot meaningfully subdivide the problem space without ruining the logical semantics per the business (i.e. bowl of spaghetti).
An alternative is to embrace the reality that circular dependencies are actually inevitable and appropriate ways to model many things.
The example scenario I like to use is that of a typical banking customer. One customer likely has a checking and savings account. For each of those accounts, there are potentially multiple customers (joint ownership). Neither of these logical business types will ever "win" in the real world DI graph. Certainly you can start to invent bullshit like AccountCustomer and CustomerAccount, but that only gets you 1 layer deeper into an infinitely-recursive rabbit hole of pain and suffering. There also exists the relational path, but I have heavily advocated for that elsewhere and it is not always applicable when talking about code-time BL method implementation. Being able to model things just as they are in the real world is a big key to success in the more complicated problem domains.
Instead of trying to control what depends on what, I shifted my thinking to:
> What needs to start up and in what order?
Turns out, most things don't really care in practice. The only thing I have to explicitly initialize before everything else in my current code base is my domain model working set (recovery from snapshot/event logs) and settings. I decided to not use DI for any business services. Instead, all services become a static class with static members that can be invoked from anywhere. This also includes the domain model instance which is used as the in-memory working set. This type just contains an array of every subordinate domain type (Customers, Accounts, etc.). By having the working set available as a public static type, every service can directly access it without requiring method injection. If I was working with a different problem domain (or certain bounded context within this one), I might prefer method-level injection.
Yes - according to every book on programming style you ever read, this is an abominable practice. Unit testing this would be difficult/impossible. But you know what? It works. It's simple. I can teach a novice how to add a new service in an hour. A project manager stumbling into AccountService might actually walk away enlightened. You can circularly-reference things at runtime if you need to. I've got some call graphs that bounce back and forth between customer & account services 5+ times. And it totally makes sense to model it that way too as far as the business is concerned. Everyone is happy.
I used to get upset about this, but now I embrace it. If a business method requires certain things to operate, then modeling those things as arguments to the method is totally reasonable. Some business is complicated and messy so we would expect more arguments to be involved. Trying to sweep reality under the rug just makes things 10x harder elsewhere.
The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this.
There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an ergonomics change, not one of capability.
But even if the webserver is the problem, it feels unlikely that you'll end up saving much in infrastructure cost by scaling just the login service rather than just deploying more copies of your webserver.
Not saying it is impossible, but it's unlikely for that to be a good justification to adopt microservices. I'm not saying that there aren't good reasons to use microservices, but I agree that scalability is not a good selling point. I'd actually argue that it's harder to build scalable microservices than monoliths.
I would challenge that. Obviously a well written "monolith" with well insulated modules, separation of concerns etc can use different databases but I heard too many times when I ask "why can't we shard the database" the answer "the data model is one and it's way easier to develop on one single data model that on N models inside the monolith".
The real issue is in scaling the data store. Microservices typically work around that problem by each having their own separate database, but nothing prevents your monolith from also talking to different DBs.
And when you have alternatives, great. But for example game devs don't. Or operating system devs. Though of course these are all active areas of ongoing research (for decades!).
If the problem/subject were that easy we would have already solved it and it wouldn't be a hot topic.
And since it's likely a nonlinear problem it's hard to map the problem-solution space, hard to get a good mental model for it, so we use the next best thing: stories. We have success stories and parables on what not to do. (And whole conferences dedicated to telling them :))
For deploying they are nothing but a very large hindrance.
It's much easier to test them in separation also. Deployments are low risk, not much need for coordination with other teams, etc.
There are components that have a heavier load, so we run more of those. Not really a big difference compared to simply running a few more monoliths and configuring them to only handle certain requests... but that's already a given here.
I don't have strong opinions either way. Teams/companies should do what works for them, and they should spend some time on improving it so they can be more effective. (Because most people/teams/companies have a "good enough" complacency inertia/bias.) And most solutions work in both setups. (Eg. making builds fast requires a divide and conquer strategy anyway. Do you build modules/packages separately and link them in the end? Do you build containers separately? Same thing. Do whatever works.)
As long as your bug is well behaved and decided to keep itself into a single microservice... and you somehow know what microservice it is, then yes, it's much easier.
Let's take a typical monolith. You'll be serving endpoints that: - Are CPU intensive - Are memory intensive - Are I/O intensive
They are almost always heavy on some part, but not all. And definitely they are not uniformly all relying on the same amount of resources.
Now, you scale out horizontally, adding instances of the same size because each of these monolithic instances need to be capable of serving the entire domain without impacting tail latencies. Some part of your application becoming more resource intensive? You'll be bumping up the sizes of the entire monolith because you are essentially needing to do the equivalent of provisioning for peak load.
Contrast this with microservices (which I'm not arguing are a silver bullet), you can run your memory intensive part of memory optimized instances, and run your compute intensive parts on compute optimized instances.
That's the part about scalability.
Now, the more interesting part (for me, personally) is reliability. You are decreasing your blast radius of a bad component/thread/process taking down your entire monolith service, and instead compartmentalizing it into limited subparts of your entire API or application.
Finally, as you mentioned, microservices do help guide you towards better choices when it comes to structuring your data. You can do this with monoliths as well (and should), but it doesn't come naturally, and having a single data store is the main reason I see teams run into scalability issues :)
---
Addition: Some thing I don't see many people talk about is the ability to address tech-debt in Microservices. My experience has been that it is an enormous benefit to have made you domain smaller for when it comes to making changes that require sweeping across the whole codebase. Examples include upgrading language versions (e.g. Scala 2 -> 3, Haskell 8.10 -> 9.2), upgrading frameworks, introducing stricter compilation checks (e.g. TypeScript and strict: true).
These easily end up being either insurmountable or year-long projects in a monolith, where it's very hard to incrementally benefit from the work because they are often by nature all or nothing changes.
Plus being able to choose different tech for different types of work, and also being able to split between teams when your org gets more vast.
Though I guess this is more about using services than micro services, per-say.
Isn't that a bit of an empty argument. Literally anything Turing complete is an ergonomics change when compared to anything else Turing complete.
We are writing for the same computer. There's nothing different (fundamentally) about the kernel and my program.
What you have on your desk isn't equivalent to a Turing machine.
One of the good reasons to spend time with Erlang or Elixir is it'll force you to learn how to write your programs with a variety of actors. Actors are generally easy cut points for turning into microservices if necessary. As with many programming languages I appreciate not being forced to use that paradigm everywhere, but it's great to be forced to do it for a while to learn how, so you can more comfortably adapt the paradigm elsewhere. My Go code is not 100% split into actors everywhere, but it definitely has actors embedded into it where useful, and even on my small team I can cite multiple cases where "actors" got pulled out into microservices. It wasn't "trivial", but it was relatively easy.
In essence, creating a microservice with elixir is about the same amount of effort as adding a controller in rails.
This is my position as well. Strong interfaces, good logical separation of function under the covers, etc. should allow splitting off things at whatever level of micro you prefer.
This results in K8s-driven-development instead of microservices.
Kafka producers use a partition key of your choice, so the UserLoggedInEvent and UserActivityEvent that relate to the same userId will always be written to same partition. This is how horizontal scaling of Kafka consumers works, without ordering problems. Anyone that isn't aware of this has very limited experience with Kafka and event-driven microservices.
I respect the author's attempt to give some balance, but I think some parts aren't well informed.
It's important to understand the benefits of microservices AND the costs. Small focused projects have small, fast test suites, can be wholly owned and developed by a single team amongst many, can be released and deployed without fear of breaking unrelated features across a vast platform, can be retired easily when obsolete. They also introduce the complexity of communication across many systems to complete an end-to-end journey, and require incredibly careful design and carefully chosen boundaries and responsibilities if you want to allow each one to evolve independently. This takes time and experience, and many organisations get themselves into a big mess with no governance, consistency or cohesion across a confusing sea of services and teams.
There's no free lunch, but let's get beyond fashion-driven lurching from one extreme to another. This cycle of having a few years where the costs of an approach aren't acknowledged, to a few years where the benefits aren't acknowledged, is very lame.
Well said. I do sympathize with some of the criticisms but only insofar as people who didn't have experience with microservices get sold on a lot of hype, the tradeoffs aren't made clear, and they get burned. The cycle seems to be "This is the silver bullet for programming complexity!" for a few years, followed by a few years of "This isn't a silver bullet!" before the Next Big Thing (TM) comes along and the cycle starts over.
My search engine is a hybrid architecture, with some monoliths and some microservices.
* Index - 5+ minute start time and uses 60% of system RAM.;
* Search Server (query parser, etc.) - 30 second start time due to having to load a bunch of term frequency data, low resources, ephemeral state
* Assistant Server (dictionary lookups, spell checks, etc.) - fast start, medium resources, stateless
* Crawler - only runs sometimes, high resources, statefull
* Archive Server- fast start, low resources, ephemeral state
* Public API gateway - 5 second start time, low resources, ephemeral state
+ a few others
A lot of the ways it's divided is along the lines of minimizing disruption when deploying changes. I don't have the server resources to run secondary instances of any of these, so I'm working with what I've got. If I patch the crawler, I don't want the search function to go down. If I patch the search function, I don't want to have to wait 5 minutes to restart the index.
It would certainly be cleaner to say break apart the Index service in terms of design, as it does several disparate things, but those things have a resource synergy which means I can't, not without buying another server and running a small 100 GbE network between them. Seems silly for a living room operation.
That's an overstatement if I've ever heard one. Staring a greenfield project with microservices is a nightmare. In a greenfield monolith you can code and deploy your dependencies together. In greenfield microservices? Oh, right. Set them all up for deployment, figure out netwroking and access between them, any change requires the fix-test-deploy dance etc.
Most of the problems people are talking about seem to be around using microservices inappropriately, without sufficient preparation, or when an application is not complex enough to benefit from it.
Microservices are not a panacea any more than any other architecture. Properly implemented, they have significant strengths vs monoliths, but require experience to get right.
Properly implemented monoliths built by experienced developers are likely to strongly resemble microservices but without some of the advantages that I enjoy.
As others have said, it’s not all or nothing, one or the other, but I don’t get the hate for microservices here.
It's like functions: don't turn code into a function until you need it in three different places.
But then, I'm firmly in the old-skool "don't split the monolith until you absolutely have to" camp.
We haven't had a great track record defining the semantics of component boundaries, but http is both simple enough that it constricts code flow in a particular way leaving a lot of misunderstandings and bike shedding discussions off of the table, and is the ligua franca for external services owned by other orgs so your engineers can be universally expected to understand those semantics. There is a nice decoupling of letting teams make technology choices though. Letting that drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard.
Maybe I need to go on the talk giving, consultant circuit reselling a restricted view of DI as "hybrid service architecture! Write your code as microservices but DevOps can colocate your apps in the same process if that's more efficient!" Lolz
It's also quite a nerd trap as we developers love to separate components into as small of boxes as possible, but just like I've seen super deep object hierarchies that didn't gain you anything at the end of the day, it's easy to fall into the trap of spinning every tiny bit of code into its own service.
I'm creating my own backend arch right now from scratch, and really trying to look at each network traversal from a "what does drawing this boundary actually get me" perspective. And I'm only splitting that out because the third party protocol being implemented is inherently separate services in an interesting way.
Microservices are not the only way to modularize code.
Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.
> Letting [technology choices] drift on a per team basis is kind of nice to allow experimentation with different technologies without having to get the whole org onboard.
This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.
> Microservices are not the only way to modularize code.
Nobody said that it was the only way to modularize code.
However, but to be frank, most of those require greater discipline than most of the engineering teams going to microservices have. These teams don't do a great job at microservices, but probably would do a worse job with a monolith.
> Also, there is TONS of bike-shedding with regard to HTTP. Which HTTP method do you use? How do you structure your paths? What does the body of the request look like? How to we translate failures into the various HTTP error codes? Do you send a 200 or a 201 status for this particular request? I could go on and on... Even among well established HTTP APIs, there are differences.
You can bike shed anything, that's why it's called bikeshedding. Referring to nobody being able to contribute to the design review of a nuclear reactor so the committee just fights over the color of the bikeshed. That being said, the state space of an HTTP API is strictly smaller than a local library's API, and you can generally expect backend engineers to at least know what complete the state space of options looks like and what the tradeoffs are.
> This is very much a double edged sword. I've seen this happen and people just tend to avoid services in languages/frameworks that they don't know. And even if they don't avoid them, they are less productive in them. We have a critical services written in Rust and one guy at the company knows Rust. We have 2 services written in a particular Java reactive framework which only a few people know how to use. Any newcomers to these services have to spend a lot of time learning a new thing.
The other end I've seen is that having the whole org on one tech stack is a single organizational point of failure. It's not an issue for smaller orgs, but if you have more than say, 200 devs working on the same product, you want a little experimentation and a lower barrier to new technology. If something is abandoned you can simply replace it, since it's not your literal entire stack. And forcing your devs to be polylingual I've found makes them better in all of the language they use, even their primary language.
I would suggest that http not be the go-to mechanism for communicating between microservices. Each should be able to operate to some degree without hard dependencies. If you build using microservices with RPC over http or what-have-you replacing function calls, you've done it wrong. You can usually tell if your 'bounded context' is of the form noun-service or adjective-noun-service. Usually the context boundary should be a process (workflow kind) that serves a user type. Reliable one-way async datastreams are more useful for keeping microservices fed with the information it needs, and it can decide how to utilize that information in a way that makes sense for that service. If you have core 'source of truth' services used by many others, you have a distributed monolith.
I worked for a company that microserviced themselves into a pit. We had a huge layoff which completely killed the morale of the remaining engineering staff. Over the next 3 years, more and more engineers left and the company refused to replace them. What started out as teams (~5 people) responsible for ~3 microservices ended up as teams of ~3 people responsible for ~6 microservices.
It was kind of cool to be responsible for more architecture and see how it all fit together, but the sad reality was that too many of the microservices that had been stood up were stitching together disparate data from other microservices to then perform what a single SQL query against a RDBMS was doing.
Choosing architecture has to be conscious not based on trends or beliefs. Even small app can be easy to mantain and develop in miroservices manner if you know WHY you decided to split it up. Don't do (or don't stop doing this) because you read some comments on hacker news or reddit :)
In my project we do utilise microserve architecture through the serverless paradigm (i.e. bunch of lambdas) but those services are exposed directly to the client via API gateways (many of them). In essence there is very little service-to-service communication. Each service has its own data storage (s3, dynomo, etc), its own queues and topics and there is very little service inter-dependencies of any sort.
Each "micro Service" is kind of its own "micro API" if you like.
The reason I believe this is a good approach for pretty much any problem is because each component is 100% swapable, it builds on its own and frankly has little to do with the rest of the system and such erros do not have a cascading effect. These services can be moved and reused in other systems too. The responsability for using these services in some sort or orchestrated manner lies with the client and yes the client/s is heavy.
Now it is true that I cannot simply union select bunch of data. You need to except that each "micro service/API" is much like all other 3rd-party APIs and so you need to come up with your own way of pulling analytics, data consistency checks, etc. The fact that service-to-service comms are sort of banned have forced us to come up with interesting algorithms that rely heavily on solid computer science (math) principles.
Just saying
In reality, how often will a client actually want to perform a straight swap like this, though? And that's assuming there is such a thing as a straight swap, which there almost never is.
It's a nice idea in theory but in practice it's worth very, very little.
These ideas work for me in practice so I don't know.
Surely there are excesses in the realm of microservice architecture… “every library is a microservice…” is advice I’ve read in the past. Service discovery / routing isn’t easy. Naming things is hard.
Personally I prefer the term Service and try to make no prescriptions as to what size it will end up being.
People have different opinions on microservices because microservices is great when done right, but can easily screw things up if people don't split the bounded contexts carefully. It's also more expensive to correct these mistakes because there are APIs between them instead of just code, so many projects would live on with them painfully forever.