16 ms·

I don't think I blame the author at all. I'm not sure why you would start with microservices, unless you wanted to show that you could build a microservices app

I don't think I blame the author at all. I'm not sure why you would start with microservices, unless you wanted to show that you could build a microservices application. Monoliths are quicker and easier to setup when you're talking about a small service in the first place. It's when an organization grows and the software grows and the monolith starts to get unwieldy that it makes sense to go to microservices. It's then that the advantage of microservices both at the engineering and organizational level really helps. A team of three engineers orchestrating 25 microservices sounds insane to me. A team of of thirty turning one monolith into 10 microservices and splitting into 10 teams of three, each responsible for maintaining one service, is the scenario you want for microservices.

stcredzero 8y ago
Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. A team of three engineers orchestrating 25 microservices sounds insane to me. A team of of thirty turning one monolith into 10 microservices and splitting into 10 teams of three, each responsible for maintaining one service, is the scenario you want for microservices. A team size of 10 should be able to move fast and do amazing things. This has been the common wisdom for decades. Get larger, then you spend too much time communicating. There's a reason why Conway's Law exists. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- nicoburns 8y ago
  Agreed. And there's no reason why your monolith need become 10 microservices. It could be split into say just 3 if that makes more sense.
  - kenhwang 8y ago
    We have a running joke that we run macroservices, which is really just a 4 way split of our monolith once the team grew large enough.
    - jacquesm 8y ago
      That's a pretty good way of doing it, decouple what you have to but no more than that.
- pytester 8y ago
  I don't think Martin Fowler realized when he wrote the first microservices article that he'd stumbled upon a technical solution to a political problem. He just saw it work and wanted to share.
  - stcredzero 8y ago
    I don't think Martin Fowler realized when he wrote the first microservices article that he'd stumbled upon a technical solution to a political problem. He just saw it work and wanted to share. The generation of programmers that Martin Fowler is from, are exactly the people from whom I got my ideas around how organization politics effect software and vice versa. There was plenty of cynicism around organization politics back then.
    - jacquesm 8y ago
      And it's not as if Martin Fowler came up with the idea as an original either, QnX, Erlang and many other systems used those basic ideas much earlier (sometimes decades earlier). But this is the web, where the old is new again.
      - icebraining 8y ago
        He says so himself: > We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix.
      - projektfu 8y ago
        It’s safe to say that Fowler rarely claims to originate things. He’s more of a taxonomist.
    - User23 8y ago
      It's interesting how few executives understand this come reorganization time.
  - mcguire 8y ago
    The architecture of software comes to resemble the organization writing the software. Use that fact or it will use you.
- igouy 8y ago
  > Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. What reasons do you have for making that link? What are you refering to? It's possible to load some code and snapshot as a Smalltalk image; then load some different code and snapshot as a different Smalltalk image.
  - stcredzero 8y ago
    What reasons do you have for making that link? What are you refering to? It's possible to load some code and snapshot as a Smalltalk image; then load some different code and snapshot as a different Smalltalk image. It's a different story when you're working on a team, and a different story when there are two or more teams using the same repository. Sure, you still have the image. The debate had to do with how the Smalltalk image affected the community's relationship to the rest of the world of software ecosystems, and how the image affected software architecture in the small. That "geography" tended to produce an insular Smalltalk community and tightly bound architecture within individual projects.
    - protomyth 8y ago
      Did anyone ever build a multi-image Smalltalk? For a lot of stuff it wouldn't make sense, but having the ability to separate the image.
      - stcredzero 8y ago
        Did anyone ever build a multi-image Smalltalk? People at least played around with that as a research project. There's one that showed up at the Camp Smalltalks I went to, with a weird-but-sensible sounding name. (Weird enough I can't remember the name.) There would have been great utility in such a thing. For one thing, the debugger in Smalltalk is just another Smalltalk application. So what happens when you want to debug the debugger? Make a copy of the debugger's code and modify the debugger hooks so that when debugging the debugger, it's the debugger-copy that's debugging the debugger. With multi-image Smalltalk, you could just have one Smalltalk image run the debugger-copy without doing a bunch of copy/renaming. (Which, I just remembered, you can make mistakes at, with hilarious results.) If you do the hacky shortcut of implementing one Smalltalk inside another Smalltalk (Call this St2), then the subset of objects that are the St2 objects can act a bit like a separate image. In that case, the host Smalltalk debugger can debug the St2 debugger.
- tabtab 8y ago
  Indeed! Conway's the man. Unless your "service" corresponds to an actual existing team who has the time and authority to focus on it, you are asking for trouble and/or wasteful busywork. I curse misapplied microservices. By the way, for a relatively small service to be shared by multiple applications, try RDBMS stored procedures first.
- jrochkind1 8y ago
  > Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. Was there a consensus resolution?
  - stcredzero 8y ago
    Was there a consensus resolution? Smalltalk is awesome. Everyone else is doing it wrong, those dirty unwashed! https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ...
    - mcguire 8y ago
      Images are hard to version control.
      - pjmlp 8y ago
        Not when using a Smalltalk aware version control.
bunderbunder 8y ago
It might depend a bit on how you scope it, too. I once worked at a company where a team of 3 produced way more than 25 microservices. But the trick was, they were all running off the same binary, just with slightly different configurations. Doing it that way gave the ops team the ability to isolate different business processes that relied on that functionality, in order to limit the scale of outages. Canary releases, too. It's 3 developers in charge of 25 different services all talking to each other over REST that sounds awful to me. What's that even getting you? Maybe if you're the kind of person who thinks that double-checking HTTP status codes and validating JSON is actually fun...
- twic 8y ago
  I've done that a couple of times. It's a good pattern! I worked on an e-commerce site a decade ago where the process types were: 1. Customer-facing web app 2. CMS for merchandising staff 3. Scheduled jobs worker 4. Feed handler for inventory updates 5. Distributed lock manager 6. Distributed cache manager We had two binary artifacts - one for the CMS, one for everything else - and they were all built from a single codebase. The CMS was different because we compiled in masses of third-party framework code for the CMS. Each process type ran with different config which enabled and configured the relevant subsystems on as needed. I'm not sure to what extent we even really needed to do that: the scheduled jobs and inventory feed workers could safely have run the customer app as well, as long as the front-end proxies never routed traffic to them.
  - NicoJuicy 8y ago
    Looks like a service oriented architecture to me
- dtech 8y ago
  I work on an application like that. Not 3:25 but not that far off either. I'm quite content with the situation. The apps all handle a bespoke data connection, converting it into a standard model which they submit to our message broker. From then on our services are much larger and smaller in number. It's very write-once-run-forever, some of these have not been touched since their inception years ago, resulting in a decreased complexity and maintenance cost. The trick is not having REST calls all over yours services. You're just building a distributed monolith at that point.
kakwa_ 8y ago
Microservices are interesting. Not Technically, as they increase complexity. But they enable something really powerful: continuity of means, continuity of responsibility, that way a small team has full hand of developing AND operating a piece of a solution. Basically, organization tends to be quite efficient when dealing with small teams (about dozen people, pizza rule and everything), that way information flows easily, with point to point communication without the need of a coordinator. However, with such architecture, greater emphasis should be put on interfaces (aka APIs). A detailed contract must be written (or even set as a policy): * how long the API while remain stable? * how will it be deprecated? with a Vn and Vn-1 scheme? * how is it documented? * what are the limitations? (performance, call rates, etc)? If you don't believe me, just read "Military-Standard-498". We can say anything about military standards, but military organizations, as people specifying, ordering and operating complex systems for decades, they know a thing or two about managing complex systems. And interfaces have a good place in their documentation corpus with the IRS (Interface Requirements Specification) and IDD (Interface Design Description) documents. Keep in mind this MIL-STD is from 1994.
- 0db532a0 8y ago
  According to Wikipedia, Military Standard 498 has been replaced with ISO/IEC/IEEE 12207. Do you have any experience with that? Do you have experience with any other modern standards for software development?
  - kakwa_ 8y ago
    Not really, it's something I was confronted to when I was working on military contracts a few years ago. From what I recall, it's very waterfall minded in term of specification workflow, it's also quite document heavy, and the terminology and acronyms can take a while to get used to. I found it was a bit lacking regarding how to put together all the pieces into a big system, aka the Integration step. IMHO It's a bit too software oriented, lacking on the system side of thing (http://www.abelia.com/498pdf/498GBOT.PDF http://www.abelia.com/498pdf/498GBOT.PDF page 60).
    - 8y ago
mirkules 8y ago
We’ve done exactly this - turned a team of 15 engineers from managing one giant monolith to two teams managing about 10 or so microservices (docker + kubernetes, OpenAPI + light4j framework). Even though we are in the early stages of redesign, I’m already seeing some drawbacks and challenges that just didn’t exist before: - Performance. Each of the services talks to the other service via well-defined JSON interface (OpenAPI/Swagger yaml definitions). This sounds good in theory, but parsing JSON and then serializing it N times has a real performance cost. In a giant “monolith” (in the Java world) EJB talked to each other, which despite being java-only (in practice), was relatively fast, and could work across web app containers. In hindsight, it was probably a bad decision to JSON-ize all the things (maybe another protocol?) - Management of 10-ish repositories and build jobs. We have Jenkins for our semi-automatic CI. We also have our microservices in a hierarchy, all depending on a common parent microservice. So naturally, branching, building and testing across all these different microservices is difficult. Imagine having to roll back a commit, then having to find the equivalent commit in the two other parent services, then rolling back the horizontal services to the equivalent commit, some with different commit hooks tied to different JIRA boards. Not fun. - Authentication/Authorization also becomes challenging since every microservice needs to be auth-aware. As I said we are still early in this, so it is hard to say if we reduced our footprint/increased productivity in a measurable way, but at least I can identify the pitfalls at this point.
- merb 8y ago
  > So naturally, branching, building and testing across all these different microservices is difficult. Imagine having to roll back a commit, then having to find the equivalent commit in the two other parent services, then rolling back the horizontal services to the equivalent commit that should not happen. if it does you don't have a microservice architecture, you have a spaghetti service architecture.
  - tabtab 8y ago
    How does one know if X is the wrong solution or if X is the right solution but the shop is "doing X wrong"? This also applies to monoliths: maybe they can scale, but one is doing them wrong. Changing from doing monoliths wrong to doing microservices wrong is obviously not progress. The same issue appeared when OOP was fairly new: people started using it heavily and ended up making messes. They were then told that they were "doing it wrong". OOP was initially sold as magic reusable Lego blocks that automatically create nice modularity. There was even an OOP magazine cover showing just that: a coder using magic Legos that farted kaleidoscopic glitter. Microservices is making similar promises. It took a while to learn where and how to use OOP and also when not to: it sucks at some things.
cortesoft 8y ago
I really hate the term 'microservice', because it carries the implication that each service should be really small. In reality, I think the best approach is to choose good boundaries for your services, regardless of the size. People forget the original 'microservice': the database. No one thinks about it as adding the complexity of other 'services' because the boundaries of the service are so well defined and functional.
- Rapzid 8y ago
  I really like this example. A lot of databases have very good module separation internally. However, you don't often see people splitting out query planning, storage, caching, and etc into separately hosted services forced to communicate over the network; even in modern distributed databases.
  - mlthoughts2018 8y ago
    Meanwhile, you also don’t see a lot of people claiming you should have one single repository that stores the source code, configs, CI tooling, deployment tooling, etc., for Postgres and Mathematica and the Linux kernel and the Unity engine, or that operating any one of these kinds of systems should have anything to do with running any other system apart from declared interfaces through which they might choose to optionally communicate or rely on each other as black box resources.
pbreit 8y ago
I’ve worked at 2 companies with monoliths that had great products and tremendous business success. And 3 companies with micro service infrastructures that had lousy products and little business success. Can’t totally blame microservices but I recall a distinctly slower and more complicated dev cycle. These were mostly newer companies where micro services make even less sense and improving product and gaining users is king.
darkerside 8y ago
And then you pray to whatever God you believe in that you happened to get those 10 abstractions just right!
ragona 8y ago
The definition of “micro” appears to be hugely variable! If you’d asked me I’d say that sure, my last team definitely built microservices. A team of around 10 engineers built and maintained something like 3 services for a product launch, each with a very different purpose, and over time we added a couple more. Three people maintaining 25 services sounds absolutely bonkers to me.
tylerl 8y ago
Well, THERE'S your problem! If you are doing http/json between microservices then you are definitely holding it wrong. Do yourself a favor and use protobuf/grpc. It exists specifically for this purpose, specifically because what you're doing is bad for your own health. Or Avro, or Thrift, or whatever. Same thing. Since Google took forever to open source grpc, every time their engineers left to modernize some other tech company, Facebook or Twitter or whatever, they'd reimplement proto/stubby at their new gig. Because it's literally the only way to solve this problem. So use whatever incarnation you like.. you have options. But json/http isn't one of them. The problem goes way deeper than serialization efficiency. (edit: d'oh! Replied to the wrong comment. Aw well, the advice is still sound.)
boomlinde 8y ago
While there are cases where I think microservices make it easier to scale an application across multiple hosts, I don't understand the organizational benefits compared to just using modules/packages within a monolith. IMO a team that makes an organizational mess of a monolith and makes it grow unwieldy will likely repeat that mistake with a microservice oriented design.
pjmlp 8y ago
Even then, that is what libraries are for.
Cthulhu_ 8y ago
10 teams of 3 each owning their own little slice of the pie sounds like an organizational nightmare; mostly, you can't keep each team fully occupied with just that one service, that's not how it works. And any task that touches more than one microservice will involve a lot of overhead with teams coordinating. While I do feel like one team should hold ownership of a service, they should also be working on others and be open to contributions - like the open source model. Finally, going from a monolith to 10 services sounds like a bad. I'd get some metrics first, see what component of the monolith would benefit the most (in the overall application performance) from being extracted and (for example) rewritten in a more specialized language. If you can't prove with numbers that you need to migrate to a microservices architecture (or: split up your application), then don't do it. If it's not about performance, you've got an organizational problem, and trying to solve it with a technical solution is not fixing the problem, only adding more. IMO, etc.
- walrus1066 8y ago
  "10 teams of 3 each owning their own little slice of the pie sounds like an organizational nightmare; mostly, you can't keep each team fully occupied with just that one service, that's not how it works. And any task that touches more than one microservice will involve a lot of overhead with teams coordinating." I guess that's where the critical challenge lies. You'd better be damn sure you know your business domain better than the business itself! So you can lay down the right boundaries, contracts & responsibilities for your services. Once your service boundaries are laid down, they're very hard to change It takes just one cross-cutting requirement change to tank your architecture and turn it into a distributed ball of mud!
  - s_kilk 8y ago
    Which has to stand as a damning indictment of the one-service-per-team model, surely? Something so inflexible can't survive contact with reality (for very long). At work we run 20-something microservices with a team of 14 engineers, and there's no siloing. If we need to add a feature that touches three services then the devs just touch the three services and orchestrate the deployments correctly. Devs wander between services depending on the needs of the project/product, not based on an arbitrary division.
skohan 8y ago
I also think designing in the microservices mindset (i.e. loose coupling, separable, dependency free architecture) is something which can be done on a continuum, and there's not a strict dichotomy between The Monolith and Microservices(tm). Even if you're working on an early prototype which fits into a handful of source files, it can be useful to organize your application in terms of parallel, independent pieces long before it becomes necessary to enforce that separation on an infrastructure/dev-ops level.
kabes 8y ago
If your monolith goes unwieldy you have a problem with your code structure which microservices won't solve. As we all know, you need well isolated, modular code with well defined boundaries. You can achieve this just as well in a monolith (and you can also achieve totally spaghetti code between microservices). Microservices is a deployment choice. It's the choice to talk between the isolated parts with RPC's instead of local function calls. So are there no reasons to have multiple services? No there are reasons, but since it's about deployments, the reasons are related to deployment factors. E.g. if you have a subsystem that needs to run in a different environment, or a subsystem that has different performance/scalability requirements etc.
ataturk 8y ago
Every place I have worked that had a monolith sucked. It has only been in the last two years as microservices have been rolling out with containerized platforms like OSE and Kubernetes that my life has gotten better. I was in the same boat about a dozen years ago when I was doing a lot of UI work in Javascript and hating it and then jQuery came out and saved my career. Nobody thinks much of jQuery today, but back then it was such a breath of fresh air. I feel that way about Kubernetes right now--my hands are so tied by "operations" people gatekeeping and now that I've been mostly a back-end developer for many years, I felt like I was between a rock and hard place until DevOps finally broke loose.
linkmotif 8y ago
You start with microservices when you realize that including the Elasticsearch API in your jar causes dependency conflicts that are not easy to resolve.
dunk010 8y ago
That's just "services", though, and it's been the way that people have been building software for a very long time. I can attest to have done this in 2007 at a large website, which was at least 7 years before the "microservices" hype picked up (https://trends.google.com/trends/explore?date=all&q=microservices https://trends.google.com/trends/explore?date=all&q=microser...). When people say "microservices" they're referring to the model of many more services than what you describe, and the associated infrastructure to manage them.

stcredzero 8y ago

Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. A team of three engineers orchestrating 25 microservices sounds insane to me. A team of of thirty turning one monolith into 10 microservices and splitting into 10 teams of three, each responsible for maintaining one service, is the scenario you want for microservices. A team size of 10 should be able to move fast and do amazing things. This has been the common wisdom for decades. Get larger, then you spend too much time communicating. There's a reason why Conway's Law exists. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

nicoburns 8y ago
Agreed. And there's no reason why your monolith need become 10 microservices. It could be split into say just 3 if that makes more sense.
- kenhwang 8y ago
  We have a running joke that we run macroservices, which is really just a 4 way split of our monolith once the team grew large enough.
  - jacquesm 8y ago
    That's a pretty good way of doing it, decouple what you have to but no more than that.
pytester 8y ago
I don't think Martin Fowler realized when he wrote the first microservices article that he'd stumbled upon a technical solution to a political problem. He just saw it work and wanted to share.
- stcredzero 8y ago
  I don't think Martin Fowler realized when he wrote the first microservices article that he'd stumbled upon a technical solution to a political problem. He just saw it work and wanted to share. The generation of programmers that Martin Fowler is from, are exactly the people from whom I got my ideas around how organization politics effect software and vice versa. There was plenty of cynicism around organization politics back then.
  - jacquesm 8y ago
    And it's not as if Martin Fowler came up with the idea as an original either, QnX, Erlang and many other systems used those basic ideas much earlier (sometimes decades earlier). But this is the web, where the old is new again.
    - icebraining 8y ago
      He says so himself: > We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix.
    - projektfu 8y ago
      It’s safe to say that Fowler rarely claims to originate things. He’s more of a taxonomist.
  - User23 8y ago
    It's interesting how few executives understand this come reorganization time.
- mcguire 8y ago
  The architecture of software comes to resemble the organization writing the software. Use that fact or it will use you.
igouy 8y ago
> Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. What reasons do you have for making that link? What are you refering to? It's possible to load some code and snapshot as a Smalltalk image; then load some different code and snapshot as a different Smalltalk image.
- stcredzero 8y ago
  What reasons do you have for making that link? What are you refering to? It's possible to load some code and snapshot as a Smalltalk image; then load some different code and snapshot as a different Smalltalk image. It's a different story when you're working on a team, and a different story when there are two or more teams using the same repository. Sure, you still have the image. The debate had to do with how the Smalltalk image affected the community's relationship to the rest of the world of software ecosystems, and how the image affected software architecture in the small. That "geography" tended to produce an insular Smalltalk community and tightly bound architecture within individual projects.
  - protomyth 8y ago
    Did anyone ever build a multi-image Smalltalk? For a lot of stuff it wouldn't make sense, but having the ability to separate the image.
    - stcredzero 8y ago
      Did anyone ever build a multi-image Smalltalk? People at least played around with that as a research project. There's one that showed up at the Camp Smalltalks I went to, with a weird-but-sensible sounding name. (Weird enough I can't remember the name.) There would have been great utility in such a thing. For one thing, the debugger in Smalltalk is just another Smalltalk application. So what happens when you want to debug the debugger? Make a copy of the debugger's code and modify the debugger hooks so that when debugging the debugger, it's the debugger-copy that's debugging the debugger. With multi-image Smalltalk, you could just have one Smalltalk image run the debugger-copy without doing a bunch of copy/renaming. (Which, I just remembered, you can make mistakes at, with hilarious results.) If you do the hacky shortcut of implementing one Smalltalk inside another Smalltalk (Call this St2), then the subset of objects that are the St2 objects can act a bit like a separate image. In that case, the host Smalltalk debugger can debug the St2 debugger.
tabtab 8y ago
Indeed! Conway's the man. Unless your "service" corresponds to an actual existing team who has the time and authority to focus on it, you are asking for trouble and/or wasteful busywork. I curse misapplied microservices. By the way, for a relatively small service to be shared by multiple applications, try RDBMS stored procedures first.
jrochkind1 8y ago
> Funny, but we saw a debate around monolithic codebases and the monolithic image in Smalltalk. Was there a consensus resolution?
- stcredzero 8y ago
  Was there a consensus resolution? Smalltalk is awesome. Everyone else is doing it wrong, those dirty unwashed! https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporativ...
  - mcguire 8y ago
    Images are hard to version control.
    - pjmlp 8y ago
      Not when using a Smalltalk aware version control.

bunderbunder 8y ago

It might depend a bit on how you scope it, too. I once worked at a company where a team of 3 produced way more than 25 microservices. But the trick was, they were all running off the same binary, just with slightly different configurations. Doing it that way gave the ops team the ability to isolate different business processes that relied on that functionality, in order to limit the scale of outages. Canary releases, too. It's 3 developers in charge of 25 different services all talking to each other over REST that sounds awful to me. What's that even getting you? Maybe if you're the kind of person who thinks that double-checking HTTP status codes and validating JSON is actually fun...

twic 8y ago
I've done that a couple of times. It's a good pattern! I worked on an e-commerce site a decade ago where the process types were: 1. Customer-facing web app 2. CMS for merchandising staff 3. Scheduled jobs worker 4. Feed handler for inventory updates 5. Distributed lock manager 6. Distributed cache manager We had two binary artifacts - one for the CMS, one for everything else - and they were all built from a single codebase. The CMS was different because we compiled in masses of third-party framework code for the CMS. Each process type ran with different config which enabled and configured the relevant subsystems on as needed. I'm not sure to what extent we even really needed to do that: the scheduled jobs and inventory feed workers could safely have run the customer app as well, as long as the front-end proxies never routed traffic to them.
- NicoJuicy 8y ago
  Looks like a service oriented architecture to me
dtech 8y ago
I work on an application like that. Not 3:25 but not that far off either. I'm quite content with the situation. The apps all handle a bespoke data connection, converting it into a standard model which they submit to our message broker. From then on our services are much larger and smaller in number. It's very write-once-run-forever, some of these have not been touched since their inception years ago, resulting in a decreased complexity and maintenance cost. The trick is not having REST calls all over yours services. You're just building a distributed monolith at that point.

kakwa_ 8y ago

Microservices are interesting. Not Technically, as they increase complexity. But they enable something really powerful: continuity of means, continuity of responsibility, that way a small team has full hand of developing AND operating a piece of a solution. Basically, organization tends to be quite efficient when dealing with small teams (about dozen people, pizza rule and everything), that way information flows easily, with point to point communication without the need of a coordinator. However, with such architecture, greater emphasis should be put on interfaces (aka APIs). A detailed contract must be written (or even set as a policy): * how long the API while remain stable? * how will it be deprecated? with a Vn and Vn-1 scheme? * how is it documented? * what are the limitations? (performance, call rates, etc)? If you don't believe me, just read "Military-Standard-498". We can say anything about military standards, but military organizations, as people specifying, ordering and operating complex systems for decades, they know a thing or two about managing complex systems. And interfaces have a good place in their documentation corpus with the IRS (Interface Requirements Specification) and IDD (Interface Design Description) documents. Keep in mind this MIL-STD is from 1994.

0db532a0 8y ago
According to Wikipedia, Military Standard 498 has been replaced with ISO/IEC/IEEE 12207. Do you have any experience with that? Do you have experience with any other modern standards for software development?
- kakwa_ 8y ago
  Not really, it's something I was confronted to when I was working on military contracts a few years ago. From what I recall, it's very waterfall minded in term of specification workflow, it's also quite document heavy, and the terminology and acronyms can take a while to get used to. I found it was a bit lacking regarding how to put together all the pieces into a big system, aka the Integration step. IMHO It's a bit too software oriented, lacking on the system side of thing (http://www.abelia.com/498pdf/498GBOT.PDF http://www.abelia.com/498pdf/498GBOT.PDF page 60).
  - 8y ago

mirkules 8y ago

We’ve done exactly this - turned a team of 15 engineers from managing one giant monolith to two teams managing about 10 or so microservices (docker + kubernetes, OpenAPI + light4j framework). Even though we are in the early stages of redesign, I’m already seeing some drawbacks and challenges that just didn’t exist before: - Performance. Each of the services talks to the other service via well-defined JSON interface (OpenAPI/Swagger yaml definitions). This sounds good in theory, but parsing JSON and then serializing it N times has a real performance cost. In a giant “monolith” (in the Java world) EJB talked to each other, which despite being java-only (in practice), was relatively fast, and could work across web app containers. In hindsight, it was probably a bad decision to JSON-ize all the things (maybe another protocol?) - Management of 10-ish repositories and build jobs. We have Jenkins for our semi-automatic CI. We also have our microservices in a hierarchy, all depending on a common parent microservice. So naturally, branching, building and testing across all these different microservices is difficult. Imagine having to roll back a commit, then having to find the equivalent commit in the two other parent services, then rolling back the horizontal services to the equivalent commit, some with different commit hooks tied to different JIRA boards. Not fun. - Authentication/Authorization also becomes challenging since every microservice needs to be auth-aware. As I said we are still early in this, so it is hard to say if we reduced our footprint/increased productivity in a measurable way, but at least I can identify the pitfalls at this point.

merb 8y ago
> So naturally, branching, building and testing across all these different microservices is difficult. Imagine having to roll back a commit, then having to find the equivalent commit in the two other parent services, then rolling back the horizontal services to the equivalent commit that should not happen. if it does you don't have a microservice architecture, you have a spaghetti service architecture.
- tabtab 8y ago
  How does one know if X is the wrong solution or if X is the right solution but the shop is "doing X wrong"? This also applies to monoliths: maybe they can scale, but one is doing them wrong. Changing from doing monoliths wrong to doing microservices wrong is obviously not progress. The same issue appeared when OOP was fairly new: people started using it heavily and ended up making messes. They were then told that they were "doing it wrong". OOP was initially sold as magic reusable Lego blocks that automatically create nice modularity. There was even an OOP magazine cover showing just that: a coder using magic Legos that farted kaleidoscopic glitter. Microservices is making similar promises. It took a while to learn where and how to use OOP and also when not to: it sucks at some things.

cortesoft 8y ago

I really hate the term 'microservice', because it carries the implication that each service should be really small. In reality, I think the best approach is to choose good boundaries for your services, regardless of the size. People forget the original 'microservice': the database. No one thinks about it as adding the complexity of other 'services' because the boundaries of the service are so well defined and functional.

Rapzid 8y ago
I really like this example. A lot of databases have very good module separation internally. However, you don't often see people splitting out query planning, storage, caching, and etc into separately hosted services forced to communicate over the network; even in modern distributed databases.
- mlthoughts2018 8y ago
  Meanwhile, you also don’t see a lot of people claiming you should have one single repository that stores the source code, configs, CI tooling, deployment tooling, etc., for Postgres and Mathematica and the Linux kernel and the Unity engine, or that operating any one of these kinds of systems should have anything to do with running any other system apart from declared interfaces through which they might choose to optionally communicate or rely on each other as black box resources.

pbreit 8y ago

I’ve worked at 2 companies with monoliths that had great products and tremendous business success. And 3 companies with micro service infrastructures that had lousy products and little business success. Can’t totally blame microservices but I recall a distinctly slower and more complicated dev cycle. These were mostly newer companies where micro services make even less sense and improving product and gaining users is king.

darkerside 8y ago

And then you pray to whatever God you believe in that you happened to get those 10 abstractions just right!

ragona 8y ago

The definition of “micro” appears to be hugely variable! If you’d asked me I’d say that sure, my last team definitely built microservices. A team of around 10 engineers built and maintained something like 3 services for a product launch, each with a very different purpose, and over time we added a couple more. Three people maintaining 25 services sounds absolutely bonkers to me.

tylerl 8y ago

Well, THERE'S your problem! If you are doing http/json between microservices then you are definitely holding it wrong. Do yourself a favor and use protobuf/grpc. It exists specifically for this purpose, specifically because what you're doing is bad for your own health. Or Avro, or Thrift, or whatever. Same thing. Since Google took forever to open source grpc, every time their engineers left to modernize some other tech company, Facebook or Twitter or whatever, they'd reimplement proto/stubby at their new gig. Because it's literally the only way to solve this problem. So use whatever incarnation you like.. you have options. But json/http isn't one of them. The problem goes way deeper than serialization efficiency. (edit: d'oh! Replied to the wrong comment. Aw well, the advice is still sound.)

boomlinde 8y ago

While there are cases where I think microservices make it easier to scale an application across multiple hosts, I don't understand the organizational benefits compared to just using modules/packages within a monolith. IMO a team that makes an organizational mess of a monolith and makes it grow unwieldy will likely repeat that mistake with a microservice oriented design.

pjmlp 8y ago

Even then, that is what libraries are for.

Cthulhu_ 8y ago

10 teams of 3 each owning their own little slice of the pie sounds like an organizational nightmare; mostly, you can't keep each team fully occupied with just that one service, that's not how it works. And any task that touches more than one microservice will involve a lot of overhead with teams coordinating. While I do feel like one team should hold ownership of a service, they should also be working on others and be open to contributions - like the open source model. Finally, going from a monolith to 10 services sounds like a bad. I'd get some metrics first, see what component of the monolith would benefit the most (in the overall application performance) from being extracted and (for example) rewritten in a more specialized language. If you can't prove with numbers that you need to migrate to a microservices architecture (or: split up your application), then don't do it. If it's not about performance, you've got an organizational problem, and trying to solve it with a technical solution is not fixing the problem, only adding more. IMO, etc.

walrus1066 8y ago
"10 teams of 3 each owning their own little slice of the pie sounds like an organizational nightmare; mostly, you can't keep each team fully occupied with just that one service, that's not how it works. And any task that touches more than one microservice will involve a lot of overhead with teams coordinating." I guess that's where the critical challenge lies. You'd better be damn sure you know your business domain better than the business itself! So you can lay down the right boundaries, contracts & responsibilities for your services. Once your service boundaries are laid down, they're very hard to change It takes just one cross-cutting requirement change to tank your architecture and turn it into a distributed ball of mud!
- s_kilk 8y ago
  Which has to stand as a damning indictment of the one-service-per-team model, surely? Something so inflexible can't survive contact with reality (for very long). At work we run 20-something microservices with a team of 14 engineers, and there's no siloing. If we need to add a feature that touches three services then the devs just touch the three services and orchestrate the deployments correctly. Devs wander between services depending on the needs of the project/product, not based on an arbitrary division.

skohan 8y ago

I also think designing in the microservices mindset (i.e. loose coupling, separable, dependency free architecture) is something which can be done on a continuum, and there's not a strict dichotomy between The Monolith and Microservices(tm). Even if you're working on an early prototype which fits into a handful of source files, it can be useful to organize your application in terms of parallel, independent pieces long before it becomes necessary to enforce that separation on an infrastructure/dev-ops level.

kabes 8y ago

If your monolith goes unwieldy you have a problem with your code structure which microservices won't solve. As we all know, you need well isolated, modular code with well defined boundaries. You can achieve this just as well in a monolith (and you can also achieve totally spaghetti code between microservices). Microservices is a deployment choice. It's the choice to talk between the isolated parts with RPC's instead of local function calls. So are there no reasons to have multiple services? No there are reasons, but since it's about deployments, the reasons are related to deployment factors. E.g. if you have a subsystem that needs to run in a different environment, or a subsystem that has different performance/scalability requirements etc.

ataturk 8y ago

Every place I have worked that had a monolith sucked. It has only been in the last two years as microservices have been rolling out with containerized platforms like OSE and Kubernetes that my life has gotten better. I was in the same boat about a dozen years ago when I was doing a lot of UI work in Javascript and hating it and then jQuery came out and saved my career. Nobody thinks much of jQuery today, but back then it was such a breath of fresh air. I feel that way about Kubernetes right now--my hands are so tied by "operations" people gatekeeping and now that I've been mostly a back-end developer for many years, I felt like I was between a rock and hard place until DevOps finally broke loose.

linkmotif 8y ago

You start with microservices when you realize that including the Elasticsearch API in your jar causes dependency conflicts that are not easy to resolve.

dunk010 8y ago

That's just "services", though, and it's been the way that people have been building software for a very long time. I can attest to have done this in 2007 at a large website, which was at least 7 years before the "microservices" hype picked up (https://trends.google.com/trends/explore?date=all&q=microservices https://trends.google.com/trends/explore?date=all&q=microser...). When people say "microservices" they're referring to the model of many more services than what you describe, and the associated infrastructure to manage them.