Forum Discussion

ThomasDay's avatar
ThomasDay
Impactful Individual
8 years ago
Solved

Third party V2 Embedded application

Hello all,   Today we cut over to serve up our embedded reports via the Embedded V2 API  accessing a Third Party Workspace application using the Azure SKU. We've been using V1 embedded for over a y...
Need Help
  • ThomasDay's avatar
    ThomasDay
    8 years ago

    As I experiment with how to work around this dreadful situation, let me recap:

    1. Azure A1 level of "premium capacity" for third party embedding is insufficient to support one active user for more than 15 minutes before hitting the wall when the "premium capacity" slows down and the site fails.  Every visual is x'd out
    2. Our applications run perfectly on app.powerbi service and have for 24 months, and in V1 third party embedding for 18 months.  Nothing crazy about them, just slicers and nice visuals, buttons and bookmarks and tabs...what powerbi is made for. 
    3. No indication that this Premium capacity at (11K/year) would not support this 1 user level of resource like what is available on app.powerbi service.  That would seem to be a reasonable baseline.
    4. There are no metrics available either prior or now that show how capacity has been consumed.
    5. There is NO autoscaling feature to boost capacity when needed and idle back down when things are quiet.
    6. Oh, and did I mention we're really small and an A3 level of expense ($36K) is unsupportable by our current cost/revenue structure.  

    As we look to manage our site...and manually scale capacity when people log on (we know that A1 will last about 15 minutes...very draggy tho) what I find is that during the scale up or down--the capacity basically shuts down altogether for about 1-2 minutes during this process--and the site fails.

     

    Not sure what else to add.  It's really a seriously grevious situation will pull us under. 

     

    You could say we've been warned...since we had some time to get it working...and we got it working and waited until now to cutover.  What we never did was suspect that an A1 level was so anemic as to be unusable for a "made for powerbi" commercial application such as ours.  

     

    Like I've said before: don't believe me, let's share screens. The facts will reveal themselves quickly. 

     

    And as a rhetorical question, how can any commercial application bootstrap itself and have expenses grow with revenue when the smallest purchasable level of resource fails with one user on the site for more than 15 minutes?

     

    Tom

v-jiascu-msft's avatar
v-jiascu-msft
Microsoft Employee
8 years ago

Hi ThomasDay,

 

I'm afraid this isn't an issue that others could have.

1.  Did you need to migrate your contents? If so, did you do it properly? Please refer to migrate-from-powerbi-embedded.

2. Did you modify your application to use the Power BI REST API? Please refer to #rebuild-your-application.

 

If you can share the solution when you get it, I will appreciate it.

 

Best Regards,

Dale

  • ThomasDay's avatar
    ThomasDay
    Impactful Individual
    8 years ago

    v-jiascu-msft   thank you for your reply.  Here's what I've discovered.

     
    First as context, we have confirmed that we've created our workspace properly, configured the Azure SKU for Third Party embedding properly and migrated our content properly.  It all connects and works from that vantage point.  I will add that 3 days in, we've not yet had a phone conversation with a tech support person---we and they have however agreed on the scope of the question.
     
    Additionally, our powerbi applications run beautifully on app.powerbi service (24 months)and embedding V1 service (18 months).  They are fast and very effective.  Our application contains a lot of data on the entire healthcare system in the US and users use slicers to explore and develop insights about proiders.  A great and very unique powerbi application--it shines.  It sure seems like what the tool was made for...complex data distilled and accessible to those in the industry.
     
    While we were concerned about the embedding pricing model, I figured that the V2 pricing scheme would be expensive but we could fund V2 pricing tier growth as we grow
     
    And, naturally, I fully expected it to perform at a level that speaks to our entire powerbi experience for 2+ years.  Who wouldn't? 
     
    It turns out that the Azure A1 Level pricing tier (not cheap at $11k per year) is insufficient capacity to run/serve a single active user of our applications on a continuous basis.  Nothing crazy, just using the application to explore data relationships.  The failures were a result of running out of capacity and having the service slow down.  In fact the A2 level is also sluggish.  The A3 service tier ($35k) does the trick.  Not to mention there is no auto ramp up of capacity to meet demand....so that the meter slows down when usage slows down.  
     
    So here we are...$36k to replicate app.powerbi performance for a single user?  I would be glad to show anyone at microsoft what is going on.  These are easy to verify facts so if you don't believe them...let's have at it, share screens and you can see for yourself. 
     
    How could any powerbi developer anticipate such a situation and why would Microsoft price embedding capacity in this fashion?
     
    Tom
    • ThomasDay's avatar
      ThomasDay
      Impactful Individual
      8 years ago

      As I experiment with how to work around this dreadful situation, let me recap:

      1. Azure A1 level of "premium capacity" for third party embedding is insufficient to support one active user for more than 15 minutes before hitting the wall when the "premium capacity" slows down and the site fails.  Every visual is x'd out
      2. Our applications run perfectly on app.powerbi service and have for 24 months, and in V1 third party embedding for 18 months.  Nothing crazy about them, just slicers and nice visuals, buttons and bookmarks and tabs...what powerbi is made for. 
      3. No indication that this Premium capacity at (11K/year) would not support this 1 user level of resource like what is available on app.powerbi service.  That would seem to be a reasonable baseline.
      4. There are no metrics available either prior or now that show how capacity has been consumed.
      5. There is NO autoscaling feature to boost capacity when needed and idle back down when things are quiet.
      6. Oh, and did I mention we're really small and an A3 level of expense ($36K) is unsupportable by our current cost/revenue structure.  

      As we look to manage our site...and manually scale capacity when people log on (we know that A1 will last about 15 minutes...very draggy tho) what I find is that during the scale up or down--the capacity basically shuts down altogether for about 1-2 minutes during this process--and the site fails.

       

      Not sure what else to add.  It's really a seriously grevious situation will pull us under. 

       

      You could say we've been warned...since we had some time to get it working...and we got it working and waited until now to cutover.  What we never did was suspect that an A1 level was so anemic as to be unusable for a "made for powerbi" commercial application such as ours.  

       

      Like I've said before: don't believe me, let's share screens. The facts will reveal themselves quickly. 

       

      And as a rhetorical question, how can any commercial application bootstrap itself and have expenses grow with revenue when the smallest purchasable level of resource fails with one user on the site for more than 15 minutes?

       

      Tom