I’m considering using Octopus for deploying application I’m working on. Problem that I see is that licensing model seems to be not very friendly for micro-services architecture. I’ve been playing with free version on localhost for a while and I see few issues depending on approach I take.
Approach 1 - Project deploy all services
I have one project that deploy all my micro services. Every micro service is created by team city as separate package and published to Octopus’ repository. Since it’s possible to “Skip any package step that is already installed” and have Child steps, Octopus will not mess up with services which didn’t get any update.
PROBLEM
This approach is licensing friendly as you don’t need to have separate project for each micro service. Problem is with Triggers. I want Octopus to create release when any of packages changed. There is “Automatic Release Creation” option but it allows me to specify only one package.
Approach 2 - Project per Micro service
This solves PROBLEM in Approach 1, but licensing model is not very friendly for such approach. Having many micro-services requires going very high on licensing plan - vastly increasing costs for even small projects.
Question
Am I missing something here or Octopus’ licensing model is indeed not very micro-service friendly?
Hi Mateusz,
Thanks for getting in touch! If Automatic Release Creation is the only reason that you believe is holding you back from using a single project, my advice would be to create a release after build when the package is pushed via octo.exe.
ARC is and always will be the minimum to create a new release, and was designed for older TFS systems where you could only push a package and could not add steps to create releases. It is unlikely it will be extended.
For micro services the channels feature of a project really is the best option for single project micro service maintenance. You can create channels per service that an be scoped to specific steps, you can also create channels that will allow you to release multiple services at once. It would give you the freedom you want without the cost of additional licensing.
When you want more control of individual projects regardless of micro services or projects, then this will extended licensing limits. As with all things convenient it can come with an increase in cost. But as explained above you do have options to not have to increase your licensing.
Using automation at build level instead of ARC is the first step 
Please let me know if I can explain any of this further.
Vanessa
Thanks Vanessa!
Creating release via build server (team city in my case) is something I didn’t think about. I’m gonna also take a look at using channels in context of micro-services.
Hi Mateusz,
Happy to help. Let me know if you run into any problems
Vanessa