5 ms·

OS seems a little presumptuous. As does the majority of the "how it works" page. Making wildly ridiculous claims that amount to "microservice are silly" (my par

OS seems a little presumptuous. As does the majority of the "how it works" page. Making wildly ridiculous claims that amount to "microservice are silly" (my paraphrase) when really they've only managed to successfully sandbox applications. Much like Android with its "a user for every app by default." > Sandstorm takes a wildly different approach [than containerized services]: It containerizes objects, where an object is primarily defined by data Or... You've containerized the data access service and enforced a per-application sandbox. Plenty of precedent there. > Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them. Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system. > In the Sandstorm model, all of the components (from web server to database) needed to handle a particular grain run on the same machine. So your container scheduler can optimize for I/O. Again not that far from existing cloud schedulers. I'm not saying this isn't a powerful model or platform. I am saying that I'm very disinclined to want to work on such a platform, purely because I'm worried its developers buy into the "everybody else is way off base" attitude, when really they're only doing what many many successful architectures have done before them.

kentonv 10y ago
Hi! I'm the founder / tech lead of Sandstorm. I wrote that "How it Works" page (https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works) and designed the architecture it is describing. Before Sandstorm, I worked at Google on infrastructure for eight years. As you may know, Google has been doing containers and microservices for over a decade. What I describe on the page is largely based on that experience. > Plenty of precedent there. I've personally never observed a production (non-research) server architecture which containerizes and sandboxes application servers on a per-document level. That is, say, with Etherpad on Sandstorm, every document you create is in a separate container isolated from the others. I would love it if you could name some specific examples that work this way, as I'd very might like to see what others have done.
- solipsism 10y ago
  I get the grain-per-document thing. Sounds interesting for at least a subset of applications, and disagree with the grandparent that it's common practice. First question that comes to mind is how the data source is sharded like that. You say in another post that you don't mandate a tech stack. So let's say I want to store my data in MySQL. Are you saying each document literally has its own private database instance? I have many more questions, but they will depend on your answer to that question. :)
  - kentonv 10y ago
    > Are you saying each document literally has its own private database instance? Yes. Each "grain" (our catch-all term; could mean "an Etherpad document" or "a Gitlab repo" or "a Wekan board", etc.) gets a slice of filesystem to do whatever it wants with. Of course, MySQL is totally overkill for this task. We generally encourage people to use sqlite instead. But there are a couple apps that do actually run MySQL in the container, mostly because switching to sqlite would have been too much work. There are also several apps that use Mongo, but it turns out Mongo 3's WiredTiger engine is reasonably efficient for small data sets, so it works out. The model definitely is friendlier to some kinds of apps than others. Productivity apps with clear data boundaries -- Etherpad (document editor), Wekan (Trello clone), Rocket.Chat (Slack clone), Gitlab, etc. -- work very well, and are our main focus. "Big data processing" apps are not well-suited to this model. We're happy to cede those, as there are tons of people doing great work in that domain.
    - simplehuman 10y ago
      In the case of Rocket.Chat, is each channel a grain or is the entire chat a grain? It appears to me it should be a grain but I am not sure.
      - kentonv 10y ago
        Currently, the whole Rocket.Chat instance is a grain. However, it would be "more Sandstorm-y" if each channel were a separate grain. For that to work well, though, we need some UI features to emulate what Rocket.Chat already does internally: * The ability for grains to highlight themselves in the sidebar when there is activity or when you've been mentioned, so that you know to check them. This API actually just launched last week! So now the apps are being updated to use it. * Some way to create "private message" grains between two people. We haven't done this yet but we have some ideas. Soon, I hope to see Rocket.Chat add a "single-channel grain" mode where its own sidebar is removed and it relies on Sandstorm's sidebar. This would provide better security for channels which should only be accessible to a subset of people. Probably, the multi-channel mode will stick around too, for cases where you want the same people to have access to many channels.
saynsedit 10y ago
Yeah, the iPhone was also a dangerous fad that everyone bought into. There was precedent with Newton and palm pilot.
- andrewstuart2 10y ago
  I don't have a problem with the tech at all. It's the presumptuous attitude as if it's novel that bothers me.
tdaltonc 10y ago
>> Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them. > Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system. This just seems like a restatement of Conway's Law. Nothing outrageous or egregious about it. It's just how people are.
nl 10y ago
>> Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them. > Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system. Of course it is. It isn't even a terrible way to do it - making a team responsible for their own data end to end does decouple their development velocity from other teams. It does have problems too of course!
- andrewstuart2 10y ago
  Good microservices architectures are about data congruity and not team boundaries. Yes, they're hopefully small enough for a single team and may warrant further slicing if they're not, but I definitely would argue strongly against partitioning teams and services into 1:1 relationships. 1:N or 2:N maybe (they should be small enough to quickly learn), but never 1:1.
  - nl 10y ago
    Great! What about inter-company services? Inter-division? I think your "team:service = 1:N" model above is exactly what happens in many places, and exactly what you seemed to react so strongly to. It isn't exactly uncommon for a data ownership to be aligned with team structure. There are trade-off with all approaches, but I think your initial ("Good Lord, I sure hope that's not true.") comment is an overreaction.
naasking 10y ago
> Making wildly ridiculous claims that amount to "microservice are silly" (my paraphrase) when really they've only managed to successfully sandbox applications No, you don't understand the Sandstorm infrastructure. Sandstorm abstracts the data from the application via the Cap'N Proto protocol, so the user, not the application, is in full control of the application data. The common data format makes all sorts of interesting isolation policies possible, like containerizing internal application state. There is very little precedent for this sort of feature.
- api 10y ago
  I find this aspect of their docs totally confusing. Cap'N Proto is mentioned everywhere but without context. I went looking for more info on it and it looks like a serialization format like Google Protocol Buffers, but in the Sandstorm docs it's peppered everywhere in a way that makes it sound like magic pixie dust. How does a serialization format solve all these problems? Not saying it doesn't, just that this needs to be explained conceptually. In reading the docs I can never seem to grasp what the key invention is. How is this different from a Docker host with a gateway? The repeated invocation of Cap'N Proto also gives the impression that I would have to rewrite my entire app for this, but the number of familiar apps obviously means this isn't the case.
  - kentonv 10y ago
    Cap'n Proto isn't really the magic that makes everything work, it's just a communications layer that is designed to facilitate Sandstorm's security model -- namely, Capability-Based Security. Here's some relevant links: https://sandstorm.io/how-it-works#capabilities https://sandstorm.io/how-it-works#capabilities https://sandstorm.io/news/2014-12-15-capnproto-0.5 https://sandstorm.io/news/2014-12-15-capnproto-0.5 Note that Sandstorm does not require that apps store their data in Cap'n Proto format. Rather, the app communicates to the outside world via Cap'n Proto. Also note that many other protocols -- especially HTTP -- can be layered on top of Cap'n Proto, allowing apps that don't know anything about Cap'n Proto to operate. Here's how HTTP-over-Cap'n-Proto is defined, BTW: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/web-session.capnp https://github.com/sandstorm-io/sandstorm/blob/master/src/sa... The key advantage of using Cap'n Proto is that it allows Sandstorm to be aware of all of the connections that exist between apps, so that it can tell the user which apps are talking to which other apps and how those apps discovered each other, and give them the opportunity to revoke those connections.

kentonv 10y ago

Hi! I'm the founder / tech lead of Sandstorm. I wrote that "How it Works" page (https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works) and designed the architecture it is describing. Before Sandstorm, I worked at Google on infrastructure for eight years. As you may know, Google has been doing containers and microservices for over a decade. What I describe on the page is largely based on that experience. > Plenty of precedent there. I've personally never observed a production (non-research) server architecture which containerizes and sandboxes application servers on a per-document level. That is, say, with Etherpad on Sandstorm, every document you create is in a separate container isolated from the others. I would love it if you could name some specific examples that work this way, as I'd very might like to see what others have done.

solipsism 10y ago
I get the grain-per-document thing. Sounds interesting for at least a subset of applications, and disagree with the grandparent that it's common practice. First question that comes to mind is how the data source is sharded like that. You say in another post that you don't mandate a tech stack. So let's say I want to store my data in MySQL. Are you saying each document literally has its own private database instance? I have many more questions, but they will depend on your answer to that question. :)
- kentonv 10y ago
  > Are you saying each document literally has its own private database instance? Yes. Each "grain" (our catch-all term; could mean "an Etherpad document" or "a Gitlab repo" or "a Wekan board", etc.) gets a slice of filesystem to do whatever it wants with. Of course, MySQL is totally overkill for this task. We generally encourage people to use sqlite instead. But there are a couple apps that do actually run MySQL in the container, mostly because switching to sqlite would have been too much work. There are also several apps that use Mongo, but it turns out Mongo 3's WiredTiger engine is reasonably efficient for small data sets, so it works out. The model definitely is friendlier to some kinds of apps than others. Productivity apps with clear data boundaries -- Etherpad (document editor), Wekan (Trello clone), Rocket.Chat (Slack clone), Gitlab, etc. -- work very well, and are our main focus. "Big data processing" apps are not well-suited to this model. We're happy to cede those, as there are tons of people doing great work in that domain.
  - simplehuman 10y ago
    In the case of Rocket.Chat, is each channel a grain or is the entire chat a grain? It appears to me it should be a grain but I am not sure.
    - kentonv 10y ago
      Currently, the whole Rocket.Chat instance is a grain. However, it would be "more Sandstorm-y" if each channel were a separate grain. For that to work well, though, we need some UI features to emulate what Rocket.Chat already does internally: * The ability for grains to highlight themselves in the sidebar when there is activity or when you've been mentioned, so that you know to check them. This API actually just launched last week! So now the apps are being updated to use it. * Some way to create "private message" grains between two people. We haven't done this yet but we have some ideas. Soon, I hope to see Rocket.Chat add a "single-channel grain" mode where its own sidebar is removed and it relies on Sandstorm's sidebar. This would provide better security for channels which should only be accessible to a subset of people. Probably, the multi-channel mode will stick around too, for cases where you want the same people to have access to many channels.

saynsedit 10y ago

Yeah, the iPhone was also a dangerous fad that everyone bought into. There was precedent with Newton and palm pilot.

andrewstuart2 10y ago
I don't have a problem with the tech at all. It's the presumptuous attitude as if it's novel that bothers me.

tdaltonc 10y ago

>> Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them. > Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system. This just seems like a restatement of Conway's Law. Nothing outrageous or egregious about it. It's just how people are.

nl 10y ago

>> Microservices are seemingly designed to match the developer’s mental model of their system. Often, services are literally divided by the team who maintains them. > Good Lord, I sure hope that's not true. Maybe if the non-technical manager designed the system. Of course it is. It isn't even a terrible way to do it - making a team responsible for their own data end to end does decouple their development velocity from other teams. It does have problems too of course!

andrewstuart2 10y ago
Good microservices architectures are about data congruity and not team boundaries. Yes, they're hopefully small enough for a single team and may warrant further slicing if they're not, but I definitely would argue strongly against partitioning teams and services into 1:1 relationships. 1:N or 2:N maybe (they should be small enough to quickly learn), but never 1:1.
- nl 10y ago
  Great! What about inter-company services? Inter-division? I think your "team:service = 1:N" model above is exactly what happens in many places, and exactly what you seemed to react so strongly to. It isn't exactly uncommon for a data ownership to be aligned with team structure. There are trade-off with all approaches, but I think your initial ("Good Lord, I sure hope that's not true.") comment is an overreaction.

naasking 10y ago

> Making wildly ridiculous claims that amount to "microservice are silly" (my paraphrase) when really they've only managed to successfully sandbox applications No, you don't understand the Sandstorm infrastructure. Sandstorm abstracts the data from the application via the Cap'N Proto protocol, so the user, not the application, is in full control of the application data. The common data format makes all sorts of interesting isolation policies possible, like containerizing internal application state. There is very little precedent for this sort of feature.

api 10y ago
I find this aspect of their docs totally confusing. Cap'N Proto is mentioned everywhere but without context. I went looking for more info on it and it looks like a serialization format like Google Protocol Buffers, but in the Sandstorm docs it's peppered everywhere in a way that makes it sound like magic pixie dust. How does a serialization format solve all these problems? Not saying it doesn't, just that this needs to be explained conceptually. In reading the docs I can never seem to grasp what the key invention is. How is this different from a Docker host with a gateway? The repeated invocation of Cap'N Proto also gives the impression that I would have to rewrite my entire app for this, but the number of familiar apps obviously means this isn't the case.
- kentonv 10y ago
  Cap'n Proto isn't really the magic that makes everything work, it's just a communications layer that is designed to facilitate Sandstorm's security model -- namely, Capability-Based Security. Here's some relevant links: https://sandstorm.io/how-it-works#capabilities https://sandstorm.io/how-it-works#capabilities https://sandstorm.io/news/2014-12-15-capnproto-0.5 https://sandstorm.io/news/2014-12-15-capnproto-0.5 Note that Sandstorm does not require that apps store their data in Cap'n Proto format. Rather, the app communicates to the outside world via Cap'n Proto. Also note that many other protocols -- especially HTTP -- can be layered on top of Cap'n Proto, allowing apps that don't know anything about Cap'n Proto to operate. Here's how HTTP-over-Cap'n-Proto is defined, BTW: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/web-session.capnp https://github.com/sandstorm-io/sandstorm/blob/master/src/sa... The key advantage of using Cap'n Proto is that it allows Sandstorm to be aware of all of the connections that exist between apps, so that it can tell the user which apps are talking to which other apps and how those apps discovered each other, and give them the opportunity to revoke those connections.