Going from traditional web-apps to a micro services architecture is giving us a challenge with the Octopus license model.
Before the change we were quite happily using a professional license to deploy all our needed systems. Splitting the codebase into separate solutions and deploying them as Azure WebApps gives us a headache since we now have to go from a 700USD to a 5000USD license for the same amount of business functionality
Pressure is already on to use Visual Studio Release Management as this is covered by existing licenses. I don’t really want to go that route.
Are anyone else having the same problems as Micro Service architectures are getting more popular? Or have suggestions on how to legally deploy micro services from a professional license, please let me know!
Where are you hitting your license limit (machines or projects or both)?
Can you give us some more information about what you environments, projects and deployment processes look like to give us a better understanding of your setup?
One solution we have had other customers use to deploy their micro services is to have a single project with a step for each of their individual services.
If you’re on 3.0 and are using Azure web app targets, initially when we released 3.0 we were counting each Azure web app target towards the machine limit on your license, but we changed this in 3.0.7 so that they do not count towards the machine limit.
Hi,
Oh… looks like we have been happily deploying with 2.6 (!). So time to upgrade.
With 2.6 we hit our limit on projects, not machines. We run on-premises backends (IIS, MSSQLServer, .NET) with integration endpoints in Azure (WepApps). We have about 5 backends and 10 Azure Web apps in production, but will get approx. 10 more the next month.
Our Octopus setup is that we run one Visual studio solution pr. backend. It gets packaged as Nuget package using TeamCity. Then we run deploy from Octopus of the package. Both backends and Azure WebApps are packaged separately in their own Nuget package as they need to be deployed independently.
Is it possible to deploy different Nuget packages from a step? We are using steps a couple of places to differentiate between needed behaviour in different environments, but have never tried to do deploy different packages that way.
Yes, you can deploy different packages from a step, you can bind the PackageId field to a variable which you can then scope to environments/machines/roles with different variables.
Or, you could have one NuGet step per package in you project to deploy your backend services and Azure web apps. This way you could deploy individual steps if you do a deployment but not all services has changed.
