What should the SDLC environments (and budgeting) look like if we're developing azure components (eg, azure functions)? RRS feed

  • Question

  • I work in an enterprise environment. For some time now (~6 to 12 months) there has been some pressure from the leadership team and architecture team to move to azure based developemnt - ie, developing solutions which make use of azure components like azure functions, logic apps, and so on.

    But despite how long this "idea" to move to azure has been floating around, it has yet to happen. And as far as I can see, the principal reason for this is because nobody knows what the SDLC is meant to look like in terms of environments, and particularly with respect to azure costs.

    I just overheard infrastructure staff telling a developer that they were not allowed to build a new function app in the development phase of the SDLC unless they got budget approval from infrastructure. I also heard them say that they could work under their personal subscription for free without approval, but the developer replied that this would be problematic since only they could see components developed on their personal subscription, which is less than ideal when the developer is acting as a member of a team creating components which are meant to interact with each other.

    I can understand that infrastructure does not want to pay for things they don't expect, where budget has not been approved. But the developer's point is also obviously valid.

    For those of you developing azure components in enterprise environments, I wonder if you could tell me what the "correct" approach is, here. I can hardly believe it's as difficult a problem as our infrastructure team seem to suggest it is, and yet they are in constant communication with Microsoft regarding our "migration" to azure platforms and components, so I should be able to trust their word on this.

    What's the story here?

    This question is really about Azure development in general, but I was unable to identify a forum better than "Pricing and Billing", since the other Azure forums seem to be broken down to single technologies. If there's a better one please let me know.

    Tuesday, September 24, 2019 5:01 AM

All replies

  • Azure offers different types of subscriptions based on business/customer requirement. Depending upon your need you can select the most appropriate one from the list here. If you opt for Pay-As-You-Go, you pay for what you use. Before, you move to Azure, I suggest you run Azure migrate tool that provides you assessment of your on-premise apps and workloads post which you can use Azure Calculator to estimate the cost for your migration to Azure. 

    After migration to Azure, your infrastructure team can use cost management to effectively plan and control cost involved in your business also leverage budgets in cost management to drive organizational accountability. This will help you inform others about their spending to proactively manage costs and to monitor how spending progresses over time.

    FYR: and 


    Tuesday, September 24, 2019 11:59 AM
  • Thanks, but I'm not asking for links to generic azure cost documentation or information on how to migrate an enterprise production environment. I'm sure that's all been looked at by the infra team already.

    I'm asking for actual enterprise developers to share the whys and hows of their decisions. I mean people and teams who are transitioning for normal on prem style development (.net web applications, MVC, winforms, windows services, etc), who are used to developing on their local machine and deploying to a regular on-prem dev or QA environment. 

    For example, right now a developer might build a web application on their local machine, run it hosted locally, play with it a bit, commit to source control and have it CI'd and CD'd to a shared location visible to QA or end users. 

    Under azure.... what? I think the closest analog would be enterprise dev/test. But infrastructure seems to be claiming that development is causing azure cost blowouts, and so all azure development now requires budget approval on a  *per module* basis. What used to be a simple dll, shared csproj library or nuget package, or even just a single class, now has to be microbudgeted. This grinds development speed down to almost nothing, and I can't believe it's the right way to do things.

    Tuesday, September 24, 2019 12:53 PM
  • Apologies the previous response was unsatisfacotry. I know you don't need more links but if you havent already, I recommend downloading and reviewing the Developer's Guide to Azure as it calls out common use-case scenarios that may help inform your decision.

    Also, wouldnt hurt to post your question on GitHub Developer community to target our developer community who can share their own experiences.

    Hope this helps but if not don't hesitate to respond. we will do our best to get you the answers you need.



    Saturday, September 28, 2019 3:35 AM