4 ms·

> In fact, you may discover that you already have a dozen of microservices deployed at your organization. Very true, robotics/avionics/etc. have been using "mi

> In fact, you may discover that you already have a dozen of microservices deployed at your organization. Very true, robotics/avionics/etc. have been using "microservices" for a long time, nothing new here. Robot Operating System (ROS), Data Distribution Service (DDS), Lightweight Communications and Marshalling (LCM), and others all encourage that architecture.

justinsaccount 8y ago
Yep... any enterprise is likely full of them: ldap: authentication microservice syslog: logging microservice smtp: messaging microservice smb/nfs: file storage microservice They haven't been called that for the past 40 years, but that's what they are.
- stingraycharles 8y ago
  Back in the day it was called Service Oriented Architecture. Then CORBA happened and that became a curse word, and guess we will repeat this when HTTP/4.0 will feature RPC?
  - ealexhudson 8y ago
    CORBA is a bit different: that's more about making remote code appear as if it were local, and having the network disappear. SOA isn't necessarily RPC: it could be message passing, for example. Async invocation like that in RPC is much tougher. I do think the distinction between "services" and "microservices" is a bit overblown. Clearly something like IMAP is not a microservice - it contains auth, storage, search and a few other pieces. Calling LDAP a microservice is potentially a stretch for similar reasons. But fundamentally, the concerns and architecture of both are extremely similar.
    - euske 8y ago
      > I do think the distinction between "services" and "microservices" is a bit overblown. I just realized that adding micro- or nano- or -oriented is a great way to create a buzzword in the current climate. Say, microsecurity, nanolearning, or anger-oriented user interface.
- Thaxll 8y ago
  Except that they don't really talk to each other and if they do it's using custom protocols. Also I wouldn't call those "micro".
  - justinsaccount 8y ago
    They don't talk to each other? So you've never seen an smtp server store its spool on an nfs mount, authenticate against ldap, and log to a remote syslog server?
  - sbov 8y ago
    A microservice doesn't have to be micro! They are oftentimes a single bounded context in domain driven design, which can be huge.
    - newaccoutnas 8y ago
      So, a service, then?
- entity345 8y ago
  Don't confuse applications and protocols with microservices. Microservices are services within an application.
  - cestith 8y ago
    There's every chance your MX MTA authenticates people against LDAP, uses LDAP again to figure out where to forward the mail to another system for final account storage, then the MDA stores the message on a clustered file system or an object store, then tells the logging system to log the delivery. The LDAP systems for authentication and for where the user's mail lives might be separate instances. Then the MUA connects to an IMAP proxy which talks to LDAP to authenticate and to determine where the messages for this user are stored (again, possibly different LDAP instances), then connects to an IMAP backend that retrieves the data from a clustered file system or object store. The IMAP proxy, IMAP backend, and MDA are separate systems. The object store is, likewise, a separate system. Meanwhile some of your users are using a webmail client as their MUA. That talks to an outbound-only MTA and the IMAP proxy, but it may talk directly to LDAP for authentication rather than authenticating to the mail servers first. It can pull user preferences from LDAP. It pulls their contact book from LDAP. These might be three different LDAP instances. I has a calendar app in the same page in another tab, but that talks instead to a separate CalDav server. The folder pane which updates with the number of unread messages in each folder updates through a different backend process on a different web server from the listing of mail in your current folder, which is a separate web server from the one that just fetched the content of the highlighted message into your preview pane. Meanwhile. half of these systems actually forward through another MTA which makes no final delivery decision itself but scans for spam scoring. Those messages that make it through the filtering get forwarded to another service which only scans for malware. Then those messages which pass go to the system that forwards the mail for final delivery to the user or to the remote party's mx server. All of these systems need their timestamps correct, so they all talk to an NTP service running alone on a VM or container that does nothing else. All of these systems send their logs to a central logging cluster via a defined protocol. The logging servers do nothing else. Just because your mail server might run qmail, Courier, Amavis, SpamAssassin, procmail, and mutt on one box with local storage and local logging doesn't mean that's how mail is done at scale. It's pretty clear to me how if you think of "email" as the application that it is composed of microservices.
mikepurvis 8y ago
I'm a ROS user (~7 years) and occasional contributor. One interesting wart you find in the ROS community is that there are two main supported ways of testing your ROS code: - Unit test the individual functions and classes using gtest or nose (this is built into catkin, this buildsystem). - Integration test your ROS APIs bringing up an actual ROS multi-process system and having a designated test node which exits to deliver the pass/fail verdict (this is managed by the "rostest" package). The much-touted advantage of microservices is supposed to be that you have these obvious service interface boundaries at which to test, but the reality in ROS land is that it's a lot of work to test there. It's work to generate the binaries or playback data, failures are harder to understand, and because you're at the mercy of RPC timing, nothing is deterministic, so your tests end up full of fudge factors and tolerances. And on top of that, the tests themselves execute way slower, since there's so much more set up and teardown. Is that a failure in the framework? Not sure, but the end result of it is that you only test at the RPC boundary that functionality which can only be tested there; everything else is stuffed into library functions that can be verified with gtest.

justinsaccount 8y ago

Yep... any enterprise is likely full of them: ldap: authentication microservice syslog: logging microservice smtp: messaging microservice smb/nfs: file storage microservice They haven't been called that for the past 40 years, but that's what they are.

stingraycharles 8y ago
Back in the day it was called Service Oriented Architecture. Then CORBA happened and that became a curse word, and guess we will repeat this when HTTP/4.0 will feature RPC?
- ealexhudson 8y ago
  CORBA is a bit different: that's more about making remote code appear as if it were local, and having the network disappear. SOA isn't necessarily RPC: it could be message passing, for example. Async invocation like that in RPC is much tougher. I do think the distinction between "services" and "microservices" is a bit overblown. Clearly something like IMAP is not a microservice - it contains auth, storage, search and a few other pieces. Calling LDAP a microservice is potentially a stretch for similar reasons. But fundamentally, the concerns and architecture of both are extremely similar.
  - euske 8y ago
    > I do think the distinction between "services" and "microservices" is a bit overblown. I just realized that adding micro- or nano- or -oriented is a great way to create a buzzword in the current climate. Say, microsecurity, nanolearning, or anger-oriented user interface.
Thaxll 8y ago
Except that they don't really talk to each other and if they do it's using custom protocols. Also I wouldn't call those "micro".
- justinsaccount 8y ago
  They don't talk to each other? So you've never seen an smtp server store its spool on an nfs mount, authenticate against ldap, and log to a remote syslog server?
- sbov 8y ago
  A microservice doesn't have to be micro! They are oftentimes a single bounded context in domain driven design, which can be huge.
  - newaccoutnas 8y ago
    So, a service, then?
entity345 8y ago
Don't confuse applications and protocols with microservices. Microservices are services within an application.
- cestith 8y ago
  There's every chance your MX MTA authenticates people against LDAP, uses LDAP again to figure out where to forward the mail to another system for final account storage, then the MDA stores the message on a clustered file system or an object store, then tells the logging system to log the delivery. The LDAP systems for authentication and for where the user's mail lives might be separate instances. Then the MUA connects to an IMAP proxy which talks to LDAP to authenticate and to determine where the messages for this user are stored (again, possibly different LDAP instances), then connects to an IMAP backend that retrieves the data from a clustered file system or object store. The IMAP proxy, IMAP backend, and MDA are separate systems. The object store is, likewise, a separate system. Meanwhile some of your users are using a webmail client as their MUA. That talks to an outbound-only MTA and the IMAP proxy, but it may talk directly to LDAP for authentication rather than authenticating to the mail servers first. It can pull user preferences from LDAP. It pulls their contact book from LDAP. These might be three different LDAP instances. I has a calendar app in the same page in another tab, but that talks instead to a separate CalDav server. The folder pane which updates with the number of unread messages in each folder updates through a different backend process on a different web server from the listing of mail in your current folder, which is a separate web server from the one that just fetched the content of the highlighted message into your preview pane. Meanwhile. half of these systems actually forward through another MTA which makes no final delivery decision itself but scans for spam scoring. Those messages that make it through the filtering get forwarded to another service which only scans for malware. Then those messages which pass go to the system that forwards the mail for final delivery to the user or to the remote party's mx server. All of these systems need their timestamps correct, so they all talk to an NTP service running alone on a VM or container that does nothing else. All of these systems send their logs to a central logging cluster via a defined protocol. The logging servers do nothing else. Just because your mail server might run qmail, Courier, Amavis, SpamAssassin, procmail, and mutt on one box with local storage and local logging doesn't mean that's how mail is done at scale. It's pretty clear to me how if you think of "email" as the application that it is composed of microservices.

mikepurvis 8y ago

I'm a ROS user (~7 years) and occasional contributor. One interesting wart you find in the ROS community is that there are two main supported ways of testing your ROS code: - Unit test the individual functions and classes using gtest or nose (this is built into catkin, this buildsystem). - Integration test your ROS APIs bringing up an actual ROS multi-process system and having a designated test node which exits to deliver the pass/fail verdict (this is managed by the "rostest" package). The much-touted advantage of microservices is supposed to be that you have these obvious service interface boundaries at which to test, but the reality in ROS land is that it's a lot of work to test there. It's work to generate the binaries or playback data, failures are harder to understand, and because you're at the mercy of RPC timing, nothing is deterministic, so your tests end up full of fudge factors and tolerances. And on top of that, the tests themselves execute way slower, since there's so much more set up and teardown. Is that a failure in the framework? Not sure, but the end result of it is that you only test at the RPC boundary that functionality which can only be tested there; everything else is stuffed into library functions that can be verified with gtest.