6 ms·

Microservices from a Startup Perspective

47 points by andima 8y ago

thinkingkong 8y ago
The original goal for moving from a monolith to a microservices architecture was loosely stated as “its hard for us to work on the app together and ship features”. Something that isnt addressed in the results or suggestions. How much did the team improve shipping features for customers? Is the app more reliable? Does the engineering team spend way more time on CI/CD and all the other “overhead”? Most teams will never need this type of solution, even though theyre tons of fun to build and operate. I just wish we had a better way of sharing the non-engineering results of these types of efforts.
- pc86 8y ago
  Any CI/CD overhead should not be unique to microservices though. I've worked on monoliths with fully automated CI/CD pipelines, tests, etc. I haven't noticed any difference in the amount of overhead/ALM work required between monoliths and microservices other than the number of tests, scale/time of deployment, etc.
- matwood 8y ago
  > Does the engineering team spend way more time on CI/CD and all the other “overhead”? CI/CD is required regardless of microservice or monolith. Once you have it working for one deployment, it should be trivial for 1+N.
  - thinkingkong 8y ago
    Id welcome a good discussion on triviality in this case. Wiring up jenkins or something to just deploy when you press the button can be easy. Wiring it up so distributed services being augmented, deployed, migrated, etc all without downtime - to me at least - is complex enough to not be trivial.
    - matwood 8y ago
      IMO, CI/CD already means zero downtime deploys. After a team has done the CI work on commits and zero downtime CD, it doesn't matter if it's for a monolith or microservices. The initial work is not trivial, but once it is done you just copy it for each service. Maybe you are thinking about how do you deploy inter-service dependencies? In that case, you don't. I'm not joking. When you move to microservices you have to treat other internal services like they are something you do not control. This means maintaining backwards compatibility, versioned APIs, etc... At first it seems like it is harder, but once you get in the mindset that this always must run and serve existing clients it is rather freeing. Plus, being able to treat each service on its own makes it easy to focus and do large changes - thus move faster. Compare this to friends who tell me about logging in at 11PM to deploy because they have to take the system down. Completely taking down the system to deploy should almost never happen today.
supernovae 8y ago
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
vorpalhex 8y ago
Microservices from a startup perspective: don't. Microservices are great. They are also complex, expensive and require much higher expertise. Start with a well groomed monolith that is well modularized then split it when scale (user scale, team scale) makes sense.
- staticassertion 8y ago
  > They are also complex I would say the complexity is largely in deployment. Otherwise, I find microservices much simpler to reason about. As an example, keeping a bunch of small, isolated microservices behind queues means that I can reason about them very locally. I know what data they own, I know their interfaces, and I don't really need to think 'outside' fo them - they just send other asynchronous messages out. I don't need to think about dependencies very much - if a downstream or upstream server fails it is irrelevant to the microservices, so long as the queueing system is up. It's a bit more annoying to get infrastructure and whatnot set up, but not a ton. > expensive Maybe? Shouldn't finger grained scaling be cheaper in some cases? > require much higher expertise I don't really agree. Again, by keeping things small and by maintaining the ability to reason about components locally, I think that it's easier to work with microservices than monoliths. > Due to the monolithic software architecture, it was difficult to add new features without affecting the entire system and it was quite complex to release new changes, since we had to rebuild and redeploy the entire product, even though we changed only a few lines of code. That resulted in high risk deployments which happened less frequently - new features got released slowly. From the article. For a startup the ability to add features quickly is pretty important - especially early on. I'm not advocating microservices first for every situation, but I've built systems microservice-first and it's been fine.
  - sk5t 8y ago
    Have you familiarized yourself with the canonical fallacies of distributed computing? https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
    - 8y ago
ris 8y ago
I'm already seeing the first generation of developers who've only ever worked in an environment that's trying to do microservices and think that the only way of encapsulating code is by making bits of it talk http to other bits.
- ummonk 8y ago
  This. Distributing your components over a network certainly forces encapsulation, but you can have encapsulation without all the complexities that come with running microservices in separate processes / machines.
- Will_Parker 8y ago
  Yeah, too many microservices I've seen are easily replaced by a function, and the practical tradeoffs are entirely benefits.
andy_ppp 8y ago
Why not just choose Akka or Elixir and then you App will be built with message passing from the start. This makes things trivial to break off onto different machines when you need to. If you choose Elixir you get OTP which does lots of excellent things to be able to scale out your app, the data passing is transparent between nodes (i.e. no protobuf or GRPC here). Excellent ways to monitor and deploy your app (and inspect messages as they are passed). I really need to write up the huge amount of work we’ve put into node and go microservices that are already part of the Erlang/Elixir ecosystem... For startups don’t bother, if you do it right it will literally kill your startup before you see the benefits.
- fnl 8y ago
  Good point, but for a Startup I think even that is too low level. I would suggest something like Istio or Lagom (which is built on top of Akka).

47 points by andima 8y ago

The original goal for moving from a monolith to a microservices architecture was loosely stated as “its hard for us to work on the app together and ship features”. Something that isnt addressed in the results or suggestions. How much did the team improve shipping features for customers? Is the app more reliable? Does the engineering team spend way more time on CI/CD and all the other “overhead”? Most teams will never need this type of solution, even though theyre tons of fun to build and operate. I just wish we had a better way of sharing the non-engineering results of these types of efforts.

pc86 8y ago
Any CI/CD overhead should not be unique to microservices though. I've worked on monoliths with fully automated CI/CD pipelines, tests, etc. I haven't noticed any difference in the amount of overhead/ALM work required between monoliths and microservices other than the number of tests, scale/time of deployment, etc.
matwood 8y ago
> Does the engineering team spend way more time on CI/CD and all the other “overhead”? CI/CD is required regardless of microservice or monolith. Once you have it working for one deployment, it should be trivial for 1+N.
- thinkingkong 8y ago
  Id welcome a good discussion on triviality in this case. Wiring up jenkins or something to just deploy when you press the button can be easy. Wiring it up so distributed services being augmented, deployed, migrated, etc all without downtime - to me at least - is complex enough to not be trivial.
  - matwood 8y ago
    IMO, CI/CD already means zero downtime deploys. After a team has done the CI work on commits and zero downtime CD, it doesn't matter if it's for a monolith or microservices. The initial work is not trivial, but once it is done you just copy it for each service. Maybe you are thinking about how do you deploy inter-service dependencies? In that case, you don't. I'm not joking. When you move to microservices you have to treat other internal services like they are something you do not control. This means maintaining backwards compatibility, versioned APIs, etc... At first it seems like it is harder, but once you get in the mindset that this always must run and serve existing clients it is rather freeing. Plus, being able to treat each service on its own makes it easy to focus and do large changes - thus move faster. Compare this to friends who tell me about logging in at 11PM to deploy because they have to take the system down. Completely taking down the system to deploy should almost never happen today.

supernovae 8y ago

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

vorpalhex 8y ago

Microservices from a startup perspective: don't. Microservices are great. They are also complex, expensive and require much higher expertise. Start with a well groomed monolith that is well modularized then split it when scale (user scale, team scale) makes sense.

staticassertion 8y ago
> They are also complex I would say the complexity is largely in deployment. Otherwise, I find microservices much simpler to reason about. As an example, keeping a bunch of small, isolated microservices behind queues means that I can reason about them very locally. I know what data they own, I know their interfaces, and I don't really need to think 'outside' fo them - they just send other asynchronous messages out. I don't need to think about dependencies very much - if a downstream or upstream server fails it is irrelevant to the microservices, so long as the queueing system is up. It's a bit more annoying to get infrastructure and whatnot set up, but not a ton. > expensive Maybe? Shouldn't finger grained scaling be cheaper in some cases? > require much higher expertise I don't really agree. Again, by keeping things small and by maintaining the ability to reason about components locally, I think that it's easier to work with microservices than monoliths. > Due to the monolithic software architecture, it was difficult to add new features without affecting the entire system and it was quite complex to release new changes, since we had to rebuild and redeploy the entire product, even though we changed only a few lines of code. That resulted in high risk deployments which happened less frequently - new features got released slowly. From the article. For a startup the ability to add features quickly is pretty important - especially early on. I'm not advocating microservices first for every situation, but I've built systems microservice-first and it's been fine.
- sk5t 8y ago
  Have you familiarized yourself with the canonical fallacies of distributed computing? https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
  - 8y ago

ris 8y ago

I'm already seeing the first generation of developers who've only ever worked in an environment that's trying to do microservices and think that the only way of encapsulating code is by making bits of it talk http to other bits.

ummonk 8y ago
This. Distributing your components over a network certainly forces encapsulation, but you can have encapsulation without all the complexities that come with running microservices in separate processes / machines.
Will_Parker 8y ago
Yeah, too many microservices I've seen are easily replaced by a function, and the practical tradeoffs are entirely benefits.

andy_ppp 8y ago

Why not just choose Akka or Elixir and then you App will be built with message passing from the start. This makes things trivial to break off onto different machines when you need to. If you choose Elixir you get OTP which does lots of excellent things to be able to scale out your app, the data passing is transparent between nodes (i.e. no protobuf or GRPC here). Excellent ways to monitor and deploy your app (and inspect messages as they are passed). I really need to write up the huge amount of work we’ve put into node and go microservices that are already part of the Erlang/Elixir ecosystem... For startups don’t bother, if you do it right it will literally kill your startup before you see the benefits.

fnl 8y ago
Good point, but for a Startup I think even that is too low level. I would suggest something like Istio or Lagom (which is built on top of Akka).