8 ms·

Honest Microservices

93 points by tate 6y ago

ForHackernews 6y ago
I have a theory that microservices evolved because developers don't know how to write libraries that they publish to or install from private package repositories.
- varispeed 6y ago
  There are also pushy managers who would insist on slapping another function onto an existing microservice and then cut time spent on writing tests, just so that he can meet his targets and get a bonus. Then the app with time will start to perform worse and worse but when it happens, the manager will be long into a new gig and the developers will get the whipping. Then they'll get new developers to fix the mess and once it gets stable, a new manager will start to insist on adding that function to an existing microservice... and the cycle repeats...
- thrower123 6y ago
  I always thought microservices were an organizational solution to the problem of bloated headcount on teams meeting the hard reality that if you put more than two cooks in the kitchen, diminishing and counterproductive results are the norm.
  - linkdd 6y ago
    Team oriented architecture? I worked in some companies where each team were managing multiple micro services. Micro services answer a very specific problematic: they are small to allow the least technical debt per "business features". The less technical debt there is, the more robust your system is against changing specs.
    - candiddevmike 6y ago
      What is your definition of technical debt here? Just because something has a small LOC, doesn't mean it lacks tech debt. It's just harder to find and quantify. In fact, I would posit they're littered with tech debt, especially from an infrastructure and shared services standpoint.
      - linkdd 6y ago
        Services should be independent of each others (as much as possible). IMHO, technical debt is found in coupling (modules, services, ...), the number of dependencies (not only code dependencies, since making an HTTP request also introduces a soft dependency), and the amount of knowledge required to understand the code. If your service is unaware of its infrastructure (understand: i don't care if i run in docker/k8s/baremetal/...), the infrastructure's technical debt does not leak to the code.
varispeed 6y ago
The author gets it. I hope every developer dealing with microservices will read this.
robin21 6y ago
This really needs a tl;dr summary. And I think especially so given that they want to make things “simple”.
- gegtik 6y ago
  my takeaway: start formally treating microservices like libraries, and think about how we traditionally link libraries to get work done
- gijoeyguerra 6y ago
  tl;dr "The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist, modular software development. It is based on the experience of leading developers of the Unix operating system. Early Unix developers were important in bringing the concepts of modularity and reusability into software engineering practice, spawning a "software tools" movement. Over time, the leading developers of Unix (and programs that ran on it) established a set of cultural norms for developing software; these norms became as important and influential as the technology of Unix itself; this has been termed the "Unix philosophy."
WolfOliver 6y ago
I think its going more like this: Cycle 1 1. Have you seen this new thing called X? It's like Y only with more coolness. 2. X is pretty good! 3. X is great! 4. All the X! 5. Problems I've had with X 6. You know, X is pretty bad Cycle 2 1. Have you seen this new thing called Y'? It's like X only with more coolness. 2. Y' is pretty good! 3. Y' is great! 4. All the Y'! 5. Problems I've had with Y' 6. You know, Y' is pretty bad Cycle 3 1. Have you seen this new thing called X'? It's like Y' only with more coolness. 2. X' is pretty good! 3. X' is great! 4. All the X'! 5. Problems I've had with X' 6. You know, Y' is pretty bad Where X and Y are concepts which get slightly better in each cycle.
- foobiekr 6y ago
  I see no evidence they get better. Software in 2020 is in a terrible state.
mrkeen 6y ago
> Deployment decisions have nothing to with microservices. Weird. My mental model of where to divide things is precisely this. If two things can change (and be deployed) independently, they can go in different services.
- Aqueous 6y ago
  I think that's probably a good heuristic but it's actually just a proxy for the underlying domain separation, which is actually why two things should go into different services.
linkdd 6y ago
Microservices brings a lot of complexity. Yeah you're not analyzing a stack trace, instead you put correlation IDs in your requests and you analyze a network call stack. And you'll need a centralized logging mechanism to not have to log to hundreds of servers (or pods if running on kubernetes) to get that sweet failing request with its correlation ID. It's far more easier to do Service Oriented Architecture when you don't need the performance/flexibility/scaling of microservices. I would not recommend any startup to go through the microservice route until they have the resources *and the need* to do so.
- 100011_100001 6y ago
  Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. Of course it might turn out that the errors are coming from bad inbound REST calls, but regardless it helps to narrow things down. I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.
  - candiddevmike 6y ago
    Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.
    - coding123 6y ago
      Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.
dyeje 6y ago
These sound like just more platitudes without some example implementations.
- DanielBMarkham 6y ago
  Here you go: https://danielbmarkham.com/outlines-of-a-supercompiler-in-f/ https://danielbmarkham.com/outlines-of-a-supercompiler-in-f/ Example implementations are also available for deeper inspection on GitHub. See link in article.
sorokod 6y ago
"Anything involving a large framework. What part of "micro" are folks missing? What on earth is a "large" framework? What does the size of a framework (by whatever metric) has to do with the "micro" which refers to a slice of the domain the service is taking care of.
- linkdd 6y ago
  The author seems to think that a microservice should have as few dependencies as possible. If your business logic is contained in another framework and your microservice just call a subset of those functions, is it really a microservice ?
- 100011_100001 6y ago
  You'll be surprised. A group I work with opted for a microservices approach, a few years later they have 47 tightly coupled "microservices" that have to be deployed all together or they break.
  - ryanbrunner 6y ago
    That's unrelated to the framework used to power those things though. You can have perfectly decoupled services running some bloated Java framework or using Go with minimal libraries or whatever. You might prefer one or the other, but it has little do with how much those services fit into the definition of 'microservices'.
  - scottious 6y ago
    ah, the dreaded distributed monolith. I hope this is looked at as a terrible anti-pattern someday. "But we can deploy services independently" they say, "we can scale these services independently too!", "We can finally scale our development team!" Years later: no services are scaled independently. Deployments are a mess. Most deploys end up having to be lock-stop deploys. Issues are incredibly hard to track down because of complex network interactions. For some reason 7 of them are written in Rust and only 1 guy knows Rust. Stack traces become almost worthless. You find yourself having to piece together log files across tons of services to track down issues. You have hundreds of Jenkins jobs for deploying services.
rakoo 6y ago
> Honest Microservices Defined > An app that cannot crash. It has a way to fail gracefully but that doesn't involve some downstream coder poking through your call stack. > An app that does one and only one useful business function. What's that? See IST. > An app that is composable with other apps from the command line. > An app that uses dynamic, free-form, late-bound text streams to talk to other apps. > An app that can be reasoned about, modified, or completely replaced by a maintenance programmer many years from now with little or no preparation. > The app must have tests. > The app must do what the tests say it does. > The app cannot do anything that the tests do not cover. > These tests exist in a compilation unit separate from the app itself and are in no way coupled to it. > When in doubt, think of your compiled app as a pure function running inside a program. That program is a plain, vanilla, default operating system. A good chunk of it sounds _a lot_ like the UNIX philosophy, and it is more obvious when looking at the author's article on IST. In that view the services supervisor, like sysvinit, runit or systemd becomes the supercompiler in charge of starting the different services, watching them and restarting them when they fail. Evidently if we haven't gone this direction and came up with different tools then something must be wrong in this architecture but I don't have enough experience to understand what exactly, unfortunately
- marcosdumay 6y ago
  > A good chunk of it sounds _a lot_ like the UNIX philosophy Yes, it does _sound_ this way, doesn't it? That's because the UNIX philosophy is misrepresented. Having small self contained pieces of code serves you nothing if they can't be called on many different tasks with different arguments. In theory, you could make generic microservices that behave like UNIX tools. On practice if you try that, your CRUD application will reside 90% in a single service, and you'll have some extra tools for a few more complex parts. (What isn't a bad architecture, by the way, but it's not what people describe as "microservices".)
  - rakoo 6y ago
    It all depends how your app is split. Maybe you have pagination, and pagination could be extracted. Maybe you have logs, and they are handled outside. For pieces to be truly independent and exchangeable it seems to me it has to happen on more technical jointures rather than functional ones.
sdevonoes 6y ago
I agree, but I think the author is missing one big point: - microservices is not a tech concept, it's a management concept We (devs) like to think that microservices is all about tech, but in reality it's a disguised tech concept used by management to: - grow the team. We are going to need more devs to build more microservices! - have more things to manage. Like, do you really think managers want to say "yeah, I manage the delivery of... a library". At the end of the quarter they want to say: "yeah, I manage the delivery of a service that..." - get salary raises. See previous point That's it. The tech industry is shifting (has shifted already?) from a "tech people know better. Let them drive the big decisions" perspective to a "lean managers drive tech decisions because they know Agile and Agile is good" one. Microservices is all about management/organizational topics, not about tech.
- ryanbrunner 6y ago
  In my experience, engineers will be pushing for microservices as often if not more than tech management. The reasons are sometimes different - a lot of times it reduces down to "our existing services are all written with old, unsexy technology and I want to do something greenfields with new tech that looks good on my resume", but they're definitely not fighting against the tide of management insisting on microservices.
  - sdevonoes 6y ago
    I see that as well, but only if microservices have been already "approved" in your organization (usually by upper tech management).
  - devonkim 6y ago
    Another reason I’ve seen is “this project will be around for a while and we should skip past the growing pains to go into microservices.” If it’s a rewrite of an existing system, then it’s more justifiable because it’s about eliminating technical debt and is not a greenfield project. But for new efforts where an organization has never seen customer demand in X, Y, Z services being created it’s pure conjecture and premature optimization to essential refactor across service boundaries before a monolith with some usage metrics even exists
vergessenmir 6y ago
The article does not address any of the problems related to microservices and provides approaches that seem deceptively language agnostic which are in fact heavily dependent and influence your microservices design. It's interesting that this is not compared to the 12 Factor App or similar methodologies. Points 5 (maintainability),6 (testability) and 8 (test coverage) are added like they are trivial things to achieve. Points 3 (composability),10 (single responsibility) - gloss over the fact that even if you do achieve this, deployment of services with detailed dependency graphs is still a big problem for complex environments. Deployments are a problem with microservices and it isn't clear how they address this. I like the idea of the supercompiler at the end. It's a lofty ideal and don't think anything remotely near it will exist in a long time (or ever) where you compile to a cloud environment (unless it is purely immutable and versioned). Also consider that cloud services change. Can't imagine how a compiler will evolve with that, we have a hard enough time with changing ABIs.
- xwdv 6y ago
  I’ve seen supercompilers in their infancy, I’m certain they will exist someday as fully envisioned.
- deleted 6y ago
  [deleted]
0xbadcafebee 6y ago
If you try to label X, it will fall into hype bullshit territory. Humans are largely stupid animals. We hear something is good and we parrot it, until we hear it is bad and we parrot it, and we use our very limited experience to reinforce our narrative. Stop labeling X. Show the metrics for each way of working to empirically prove outcomes. Use what can be proven works better. Where there isn't one conclusive better way, do a meta-analysis and define the edge cases. Only use the case that has the best outcomes for your needs. Move on with life. Or we could keep navel-gazing and admit that we actually just do what we like, not what works best.
mumblemumble 6y ago
Hot take: If simply arguing about definitions of terms could break the hype cycle, technology hype cycles would have died out in the 1990s.
benreesman 6y ago
Why do none of these articles about the appropriate way to organize RPCs in your service talk about technological reasons for doing an RPC? If I have a computation that has a very CPU-intensive part and a very memory intensive part, maybe I want more than one SKU/instance type involved. That’s a technical reason to do an RPC. I have a computation that doesn’t fit on any of my SKUs, gonna need some RPCs. If I have unsafe/unmanaged code for the performance sensitive part but managed code for the watchdog part, that could go either way, maybe I do IPC or maybe I use an FFI. RPC boundaries have costs and benefits. They are a tool, not an ideal to aspire to.
- cmdkeen 6y ago
  It's in the early days but this is exactly what Architecture the Hard Parts[0] is working on: finding for each system the right balance between pulling things apart and putting them back together again. [0]: http://architecturethehardparts.com/ http://architecturethehardparts.com/ - book on the way, the training course is excellent
deleted 6y ago
[deleted]
coding123 6y ago
I wrote a React electron app that starts all our companies microservices on a single laptop and docker images for databases (which has our canned test data). It runs like 15 things and you have the entire application running in about 12 seconds. (most of the waiting time is mysql/mongo/memcached/rabbit starting up slowly in docker). You can also grab the PID of one of the services it displays and throw it in VSCode for debugging (since it's all node). It also makes a bunch of recommendations like - git pull, change branch (if there are changes), open vscode, open Azure Devop's PR page. All of the crazy microtasks our team has shackled ourselves to into are handled by this app. It's fine now, but I would never ever ever ever in a million years recommend microservices to a team of 6 developers.
conor_f 6y ago
Agree wholeheartedly with the concept of this but the content is dangerously close to the style of discussion the author doesn't like about tech!
Kinrany 6y ago
Unison has that supercompiler: https://www.unisonweb.org/ https://www.unisonweb.org/
jayd16 6y ago
Like the SOLID post I feel like I somewhat agree with the sentiment but disagree with a lot of the specific points. This seems like a pretty opinionated prescriptive. For example, in my mind microservices is just SOA with no lower bound on service size ...and no upper bound for that matter. IE we're not wasting time arguing services need to be split or merged just because of their "size." (units aren't even specified) OP seems to think we should be worrying about what frameworks are used... This post seems to really beat the programmer with "just try harder with tests and you'll get it!", or "your app cannot crash". Oh sure. No crashes. Why didn't I think of that? Then it pines for magical tools that don't exist. I really don't understand what learning there is to get out of this article. It doesn't even touch on the biggest problems of "how do you separate services into logical units with minimal cross talk" and "When you do have cross service communication, how can you deal with that distributed computation." "Just write tests" isn't helpful.
- DanielBMarkham 6y ago
  Nope. Types can completely replace tests. The tests described in the article are ATDD tests, not TDD or unit tests. They're the result of a specific business workflow that has a goal of making sure you're building things that are useful. If you don't have that workflow, you can just use types to do the same work. And nope, no magic tool required. Sure, tooling and automation would be really cool, much the same as having a C compiler beats the heck out of writing assembly, but it's not directly relevant to the points in the essay.
nine_zeros 6y ago
Todays microservices (with containers and kubernetes) are so complicated that entire fleets of engineers are required to keep them from just falling apart. They make tools to automate a bit, that tool fails. So now, more tooling is needed to detect and failover this in-house tool. Now we're dependent on many other services simply to maintain another in-house tool. Then a new hire comes along and brings more tools. The analogy is civil engineers have started building a structure with new and shiny tools/materials. With new materials, the buildings collapse in many new ways so they build tools to stop them from collapsing. Only now, these new tools need constant management and handholding by thousands more civil engineers. If one of these tools fails, the structure collapses. While I'm not opposed to tooling and automation, the constant patchwork over patchwork makes enterprise Java look more robust and humane.

93 points by tate 6y ago

I have a theory that microservices evolved because developers don't know how to write libraries that they publish to or install from private package repositories.

varispeed 6y ago
There are also pushy managers who would insist on slapping another function onto an existing microservice and then cut time spent on writing tests, just so that he can meet his targets and get a bonus. Then the app with time will start to perform worse and worse but when it happens, the manager will be long into a new gig and the developers will get the whipping. Then they'll get new developers to fix the mess and once it gets stable, a new manager will start to insist on adding that function to an existing microservice... and the cycle repeats...
thrower123 6y ago
I always thought microservices were an organizational solution to the problem of bloated headcount on teams meeting the hard reality that if you put more than two cooks in the kitchen, diminishing and counterproductive results are the norm.
- linkdd 6y ago
  Team oriented architecture? I worked in some companies where each team were managing multiple micro services. Micro services answer a very specific problematic: they are small to allow the least technical debt per "business features". The less technical debt there is, the more robust your system is against changing specs.
  - candiddevmike 6y ago
    What is your definition of technical debt here? Just because something has a small LOC, doesn't mean it lacks tech debt. It's just harder to find and quantify. In fact, I would posit they're littered with tech debt, especially from an infrastructure and shared services standpoint.
    - linkdd 6y ago
      Services should be independent of each others (as much as possible). IMHO, technical debt is found in coupling (modules, services, ...), the number of dependencies (not only code dependencies, since making an HTTP request also introduces a soft dependency), and the amount of knowledge required to understand the code. If your service is unaware of its infrastructure (understand: i don't care if i run in docker/k8s/baremetal/...), the infrastructure's technical debt does not leak to the code.

varispeed 6y ago

The author gets it. I hope every developer dealing with microservices will read this.

robin21 6y ago

This really needs a tl;dr summary. And I think especially so given that they want to make things “simple”.

gegtik 6y ago
my takeaway: start formally treating microservices like libraries, and think about how we traditionally link libraries to get work done
gijoeyguerra 6y ago
tl;dr "The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist, modular software development. It is based on the experience of leading developers of the Unix operating system. Early Unix developers were important in bringing the concepts of modularity and reusability into software engineering practice, spawning a "software tools" movement. Over time, the leading developers of Unix (and programs that ran on it) established a set of cultural norms for developing software; these norms became as important and influential as the technology of Unix itself; this has been termed the "Unix philosophy."

WolfOliver 6y ago

I think its going more like this: Cycle 1 1. Have you seen this new thing called X? It's like Y only with more coolness. 2. X is pretty good! 3. X is great! 4. All the X! 5. Problems I've had with X 6. You know, X is pretty bad Cycle 2 1. Have you seen this new thing called Y'? It's like X only with more coolness. 2. Y' is pretty good! 3. Y' is great! 4. All the Y'! 5. Problems I've had with Y' 6. You know, Y' is pretty bad Cycle 3 1. Have you seen this new thing called X'? It's like Y' only with more coolness. 2. X' is pretty good! 3. X' is great! 4. All the X'! 5. Problems I've had with X' 6. You know, Y' is pretty bad Where X and Y are concepts which get slightly better in each cycle.

foobiekr 6y ago
I see no evidence they get better. Software in 2020 is in a terrible state.

mrkeen 6y ago

> Deployment decisions have nothing to with microservices. Weird. My mental model of where to divide things is precisely this. If two things can change (and be deployed) independently, they can go in different services.

Aqueous 6y ago
I think that's probably a good heuristic but it's actually just a proxy for the underlying domain separation, which is actually why two things should go into different services.

linkdd 6y ago

Microservices brings a lot of complexity. Yeah you're not analyzing a stack trace, instead you put correlation IDs in your requests and you analyze a network call stack. And you'll need a centralized logging mechanism to not have to log to hundreds of servers (or pods if running on kubernetes) to get that sweet failing request with its correlation ID. It's far more easier to do Service Oriented Architecture when you don't need the performance/flexibility/scaling of microservices. I would not recommend any startup to go through the microservice route until they have the resources *and the need* to do so.

100011_100001 6y ago
Microservices done right help isolate issues though. If you have an ecosystem of 100 microservices, but blue-widget-microservice is throwing errors you know which codebase you need to look at. Of course it might turn out that the errors are coming from bad inbound REST calls, but regardless it helps to narrow things down. I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.
- candiddevmike 6y ago
  Does it though? If you're triaging an issue, in a microservice environment, errors become limitless red herrings. Reproducibility becomes an enormous undertaking, especially when you can't (quickly) recreate the entire stack ("won't fit on my laptop"). A monolith can be quite scalable and portable.
  - coding123 6y ago
    Not only can a monolithic code base be scaleable but you can make it into microservices by adjusting it's startup parameters: monolith --start-batch-jobs monolith --start-claim-processor monolith --start-graphql And they would be interconnected probably via some clustering protocol with libraries that hide the complexity and runs a bus available in a litany of languages. Need scale? k8s replica count on the above pods.

dyeje 6y ago

These sound like just more platitudes without some example implementations.

DanielBMarkham 6y ago
Here you go: https://danielbmarkham.com/outlines-of-a-supercompiler-in-f/ https://danielbmarkham.com/outlines-of-a-supercompiler-in-f/ Example implementations are also available for deeper inspection on GitHub. See link in article.

sorokod 6y ago

"Anything involving a large framework. What part of "micro" are folks missing? What on earth is a "large" framework? What does the size of a framework (by whatever metric) has to do with the "micro" which refers to a slice of the domain the service is taking care of.

linkdd 6y ago
The author seems to think that a microservice should have as few dependencies as possible. If your business logic is contained in another framework and your microservice just call a subset of those functions, is it really a microservice ?
100011_100001 6y ago
You'll be surprised. A group I work with opted for a microservices approach, a few years later they have 47 tightly coupled "microservices" that have to be deployed all together or they break.
- ryanbrunner 6y ago
  That's unrelated to the framework used to power those things though. You can have perfectly decoupled services running some bloated Java framework or using Go with minimal libraries or whatever. You might prefer one or the other, but it has little do with how much those services fit into the definition of 'microservices'.
- scottious 6y ago
  ah, the dreaded distributed monolith. I hope this is looked at as a terrible anti-pattern someday. "But we can deploy services independently" they say, "we can scale these services independently too!", "We can finally scale our development team!" Years later: no services are scaled independently. Deployments are a mess. Most deploys end up having to be lock-stop deploys. Issues are incredibly hard to track down because of complex network interactions. For some reason 7 of them are written in Rust and only 1 guy knows Rust. Stack traces become almost worthless. You find yourself having to piece together log files across tons of services to track down issues. You have hundreds of Jenkins jobs for deploying services.

rakoo 6y ago

> Honest Microservices Defined > An app that cannot crash. It has a way to fail gracefully but that doesn't involve some downstream coder poking through your call stack. > An app that does one and only one useful business function. What's that? See IST. > An app that is composable with other apps from the command line. > An app that uses dynamic, free-form, late-bound text streams to talk to other apps. > An app that can be reasoned about, modified, or completely replaced by a maintenance programmer many years from now with little or no preparation. > The app must have tests. > The app must do what the tests say it does. > The app cannot do anything that the tests do not cover. > These tests exist in a compilation unit separate from the app itself and are in no way coupled to it. > When in doubt, think of your compiled app as a pure function running inside a program. That program is a plain, vanilla, default operating system. A good chunk of it sounds _a lot_ like the UNIX philosophy, and it is more obvious when looking at the author's article on IST. In that view the services supervisor, like sysvinit, runit or systemd becomes the supercompiler in charge of starting the different services, watching them and restarting them when they fail. Evidently if we haven't gone this direction and came up with different tools then something must be wrong in this architecture but I don't have enough experience to understand what exactly, unfortunately

marcosdumay 6y ago
> A good chunk of it sounds _a lot_ like the UNIX philosophy Yes, it does _sound_ this way, doesn't it? That's because the UNIX philosophy is misrepresented. Having small self contained pieces of code serves you nothing if they can't be called on many different tasks with different arguments. In theory, you could make generic microservices that behave like UNIX tools. On practice if you try that, your CRUD application will reside 90% in a single service, and you'll have some extra tools for a few more complex parts. (What isn't a bad architecture, by the way, but it's not what people describe as "microservices".)
- rakoo 6y ago
  It all depends how your app is split. Maybe you have pagination, and pagination could be extracted. Maybe you have logs, and they are handled outside. For pieces to be truly independent and exchangeable it seems to me it has to happen on more technical jointures rather than functional ones.

sdevonoes 6y ago

I agree, but I think the author is missing one big point: - microservices is not a tech concept, it's a management concept We (devs) like to think that microservices is all about tech, but in reality it's a disguised tech concept used by management to: - grow the team. We are going to need more devs to build more microservices! - have more things to manage. Like, do you really think managers want to say "yeah, I manage the delivery of... a library". At the end of the quarter they want to say: "yeah, I manage the delivery of a service that..." - get salary raises. See previous point That's it. The tech industry is shifting (has shifted already?) from a "tech people know better. Let them drive the big decisions" perspective to a "lean managers drive tech decisions because they know Agile and Agile is good" one. Microservices is all about management/organizational topics, not about tech.

ryanbrunner 6y ago
In my experience, engineers will be pushing for microservices as often if not more than tech management. The reasons are sometimes different - a lot of times it reduces down to "our existing services are all written with old, unsexy technology and I want to do something greenfields with new tech that looks good on my resume", but they're definitely not fighting against the tide of management insisting on microservices.
- sdevonoes 6y ago
  I see that as well, but only if microservices have been already "approved" in your organization (usually by upper tech management).
- devonkim 6y ago
  Another reason I’ve seen is “this project will be around for a while and we should skip past the growing pains to go into microservices.” If it’s a rewrite of an existing system, then it’s more justifiable because it’s about eliminating technical debt and is not a greenfield project. But for new efforts where an organization has never seen customer demand in X, Y, Z services being created it’s pure conjecture and premature optimization to essential refactor across service boundaries before a monolith with some usage metrics even exists

vergessenmir 6y ago

The article does not address any of the problems related to microservices and provides approaches that seem deceptively language agnostic which are in fact heavily dependent and influence your microservices design. It's interesting that this is not compared to the 12 Factor App or similar methodologies. Points 5 (maintainability),6 (testability) and 8 (test coverage) are added like they are trivial things to achieve. Points 3 (composability),10 (single responsibility) - gloss over the fact that even if you do achieve this, deployment of services with detailed dependency graphs is still a big problem for complex environments. Deployments are a problem with microservices and it isn't clear how they address this. I like the idea of the supercompiler at the end. It's a lofty ideal and don't think anything remotely near it will exist in a long time (or ever) where you compile to a cloud environment (unless it is purely immutable and versioned). Also consider that cloud services change. Can't imagine how a compiler will evolve with that, we have a hard enough time with changing ABIs.

xwdv 6y ago
I’ve seen supercompilers in their infancy, I’m certain they will exist someday as fully envisioned.
deleted 6y ago
[deleted]

0xbadcafebee 6y ago

If you try to label X, it will fall into hype bullshit territory. Humans are largely stupid animals. We hear something is good and we parrot it, until we hear it is bad and we parrot it, and we use our very limited experience to reinforce our narrative. Stop labeling X. Show the metrics for each way of working to empirically prove outcomes. Use what can be proven works better. Where there isn't one conclusive better way, do a meta-analysis and define the edge cases. Only use the case that has the best outcomes for your needs. Move on with life. Or we could keep navel-gazing and admit that we actually just do what we like, not what works best.

mumblemumble 6y ago

Hot take: If simply arguing about definitions of terms could break the hype cycle, technology hype cycles would have died out in the 1990s.

benreesman 6y ago

Why do none of these articles about the appropriate way to organize RPCs in your service talk about technological reasons for doing an RPC? If I have a computation that has a very CPU-intensive part and a very memory intensive part, maybe I want more than one SKU/instance type involved. That’s a technical reason to do an RPC. I have a computation that doesn’t fit on any of my SKUs, gonna need some RPCs. If I have unsafe/unmanaged code for the performance sensitive part but managed code for the watchdog part, that could go either way, maybe I do IPC or maybe I use an FFI. RPC boundaries have costs and benefits. They are a tool, not an ideal to aspire to.

cmdkeen 6y ago
It's in the early days but this is exactly what Architecture the Hard Parts[0] is working on: finding for each system the right balance between pulling things apart and putting them back together again. [0]: http://architecturethehardparts.com/ http://architecturethehardparts.com/ - book on the way, the training course is excellent

deleted 6y ago

[deleted]

coding123 6y ago

I wrote a React electron app that starts all our companies microservices on a single laptop and docker images for databases (which has our canned test data). It runs like 15 things and you have the entire application running in about 12 seconds. (most of the waiting time is mysql/mongo/memcached/rabbit starting up slowly in docker). You can also grab the PID of one of the services it displays and throw it in VSCode for debugging (since it's all node). It also makes a bunch of recommendations like - git pull, change branch (if there are changes), open vscode, open Azure Devop's PR page. All of the crazy microtasks our team has shackled ourselves to into are handled by this app. It's fine now, but I would never ever ever ever in a million years recommend microservices to a team of 6 developers.

conor_f 6y ago

Agree wholeheartedly with the concept of this but the content is dangerously close to the style of discussion the author doesn't like about tech!

Kinrany 6y ago

Unison has that supercompiler: https://www.unisonweb.org/ https://www.unisonweb.org/

jayd16 6y ago

Like the SOLID post I feel like I somewhat agree with the sentiment but disagree with a lot of the specific points. This seems like a pretty opinionated prescriptive. For example, in my mind microservices is just SOA with no lower bound on service size ...and no upper bound for that matter. IE we're not wasting time arguing services need to be split or merged just because of their "size." (units aren't even specified) OP seems to think we should be worrying about what frameworks are used... This post seems to really beat the programmer with "just try harder with tests and you'll get it!", or "your app cannot crash". Oh sure. No crashes. Why didn't I think of that? Then it pines for magical tools that don't exist. I really don't understand what learning there is to get out of this article. It doesn't even touch on the biggest problems of "how do you separate services into logical units with minimal cross talk" and "When you do have cross service communication, how can you deal with that distributed computation." "Just write tests" isn't helpful.

DanielBMarkham 6y ago
Nope. Types can completely replace tests. The tests described in the article are ATDD tests, not TDD or unit tests. They're the result of a specific business workflow that has a goal of making sure you're building things that are useful. If you don't have that workflow, you can just use types to do the same work. And nope, no magic tool required. Sure, tooling and automation would be really cool, much the same as having a C compiler beats the heck out of writing assembly, but it's not directly relevant to the points in the essay.

nine_zeros 6y ago

Todays microservices (with containers and kubernetes) are so complicated that entire fleets of engineers are required to keep them from just falling apart. They make tools to automate a bit, that tool fails. So now, more tooling is needed to detect and failover this in-house tool. Now we're dependent on many other services simply to maintain another in-house tool. Then a new hire comes along and brings more tools. The analogy is civil engineers have started building a structure with new and shiny tools/materials. With new materials, the buildings collapse in many new ways so they build tools to stop them from collapsing. Only now, these new tools need constant management and handholding by thousands more civil engineers. If one of these tools fails, the structure collapses. While I'm not opposed to tooling and automation, the constant patchwork over patchwork makes enterprise Java look more robust and humane.