4 ms·

Very detailed blog with lots of wise words used, but very little actual experience shared. For a startup - all this may feel OK like you're cheating the system

Very detailed blog with lots of wise words used, but very little actual experience shared. For a startup - all this may feel OK like you're cheating the system and beating others to the punch - but damn, if you actually make it - good luck scaling that up. Personally, I don't see faas a competitive market advantage. It's a tool and i'd be a hell of a lot more selective in how I used it.

scarface74 8y ago
For a startup - all this may feel OK like you're cheating the system and beating others to the punch - but damn, if you actually make it - good luck scaling that up. Why is that a problem? I am speaking in C# terms... Phase 1 Monolith: all of your code is one solution, with separate domain specific projects (assemblies) with separate namespaces with a logical use of access modifiers exposed as an interface. All of the other code uses interfaces as dependencies defined with a DI framework. Phase 2: We need scale now. Bring up a lot more VMs at the click of a button behind a load balancer and you get scale quickly. Phase 3: Take your project that you need to scale independently out of the monolithic solution, expose it as API, put that one API behind a load balancer. Then have a proxy class in your client and use your DI to map your interface to your proxy. If you integrate something like Swagger into your API, it can create the proxy class for you. If you can deal with eventual consistency, use a queueing mechanism. Rinse and repeat and keep taking projects out of the monolith as needed. There will be some shared code you don’t want to run out of process. For that, create Nugget packages and you won’t have to change your client code at all.
- holtalanm 8y ago
  I was thinking something along these lines, as well. I recently learned of the IDesign Method, which seems to try to do something like this, with a standard architecture for handling scaling in a future-proof kind of way. Forgive me if my understanding of that architecture is wrong. I only have read parts of the book so far.
  - scarface74 8y ago
    It's basically Domain Driven Design combined with SOLID principals. If you have a Customer domain and an Order domain, as tempting as it is to join the two related tables in code, avoid it. Have another service (not http service/domain service) aggregate information from both domains. It's then mechanically trivial to split the Customer module and the Orders module both the code and the data store.
- merb 8y ago
  > There will be some shared code you don’t want to run out of process. For that, create Nugget packages and you won’t have to change your client code at all. actually you can keep your solution and just have many projects in one solution (monorepo)
  - scarface74 8y ago
    having one large solution causes a ton of issues. Even if you have multiple solutions in one repo, that means everytime you deploy, you have to deploy the whole thing. Rolling back becomes more difficult and one team can break the build and it effects other teams.
    - merb 8y ago
      > Even if you have multiple solutions in one repo, that means everytime you deploy, you have to deploy the whole thing. Why? Just because the code sit's in one repo, doesn't mean that everything needs to be deployed the same time.
      - scarface74 8y ago
        How do you do independently automatic partial builds and deployments to an integration environment with a monorepo? If I just changed one solution, pushed it, and the build process is automated, how does it know not rebuild and deploy all of the solutions?
ris 8y ago
> but damn, if you actually make it - good luck scaling that up It's foolish to think that the initial version you make of any system is going to be the same thing that you end up scaling to a million users and it's foolish to think that you're going to understand where your actual pinch points are going to be before that system is under any sort of pressure. Let alone before you really know what your product is really going to be (which is the situation most startups find themselves in). The slices you decide to make with the knife early on more often than not look stupid and burdensome once you're actually under pressure. Most people also underestimate how far it's possible to push monoliths. My favourite example is the OpenStreetMap infrastructure, which has to support thousands of concurrent users editing a global map that is ~105G when compressed. It's largely monolithic. And that doesn't really seem to be a problem. Works well. I suspect most people have never actually seen the sort of "heavy load" they talk about so much running on a sensibly designed monolith to the point that it's not coping due to its architecture. There's a lot of conceit around how big a load people really deal with.
pbreit 8y ago
Scaling is infinitely easier than making it.
- supernovae 8y ago
  nah, making stuff is easy, keeping it running and scaling it is hard. Most people just delay the hard stuff perpetually or abandon it all together in looking for something else.

scarface74 8y ago

For a startup - all this may feel OK like you're cheating the system and beating others to the punch - but damn, if you actually make it - good luck scaling that up. Why is that a problem? I am speaking in C# terms... Phase 1 Monolith: all of your code is one solution, with separate domain specific projects (assemblies) with separate namespaces with a logical use of access modifiers exposed as an interface. All of the other code uses interfaces as dependencies defined with a DI framework. Phase 2: We need scale now. Bring up a lot more VMs at the click of a button behind a load balancer and you get scale quickly. Phase 3: Take your project that you need to scale independently out of the monolithic solution, expose it as API, put that one API behind a load balancer. Then have a proxy class in your client and use your DI to map your interface to your proxy. If you integrate something like Swagger into your API, it can create the proxy class for you. If you can deal with eventual consistency, use a queueing mechanism. Rinse and repeat and keep taking projects out of the monolith as needed. There will be some shared code you don’t want to run out of process. For that, create Nugget packages and you won’t have to change your client code at all.

holtalanm 8y ago
I was thinking something along these lines, as well. I recently learned of the IDesign Method, which seems to try to do something like this, with a standard architecture for handling scaling in a future-proof kind of way. Forgive me if my understanding of that architecture is wrong. I only have read parts of the book so far.
- scarface74 8y ago
  It's basically Domain Driven Design combined with SOLID principals. If you have a Customer domain and an Order domain, as tempting as it is to join the two related tables in code, avoid it. Have another service (not http service/domain service) aggregate information from both domains. It's then mechanically trivial to split the Customer module and the Orders module both the code and the data store.
merb 8y ago
> There will be some shared code you don’t want to run out of process. For that, create Nugget packages and you won’t have to change your client code at all. actually you can keep your solution and just have many projects in one solution (monorepo)
- scarface74 8y ago
  having one large solution causes a ton of issues. Even if you have multiple solutions in one repo, that means everytime you deploy, you have to deploy the whole thing. Rolling back becomes more difficult and one team can break the build and it effects other teams.
  - merb 8y ago
    > Even if you have multiple solutions in one repo, that means everytime you deploy, you have to deploy the whole thing. Why? Just because the code sit's in one repo, doesn't mean that everything needs to be deployed the same time.
    - scarface74 8y ago
      How do you do independently automatic partial builds and deployments to an integration environment with a monorepo? If I just changed one solution, pushed it, and the build process is automated, how does it know not rebuild and deploy all of the solutions?

ris 8y ago

> but damn, if you actually make it - good luck scaling that up It's foolish to think that the initial version you make of any system is going to be the same thing that you end up scaling to a million users and it's foolish to think that you're going to understand where your actual pinch points are going to be before that system is under any sort of pressure. Let alone before you really know what your product is really going to be (which is the situation most startups find themselves in). The slices you decide to make with the knife early on more often than not look stupid and burdensome once you're actually under pressure. Most people also underestimate how far it's possible to push monoliths. My favourite example is the OpenStreetMap infrastructure, which has to support thousands of concurrent users editing a global map that is ~105G when compressed. It's largely monolithic. And that doesn't really seem to be a problem. Works well. I suspect most people have never actually seen the sort of "heavy load" they talk about so much running on a sensibly designed monolith to the point that it's not coping due to its architecture. There's a lot of conceit around how big a load people really deal with.

pbreit 8y ago

Scaling is infinitely easier than making it.

supernovae 8y ago
nah, making stuff is easy, keeping it running and scaling it is hard. Most people just delay the hard stuff perpetually or abandon it all together in looking for something else.