This year we had the pleasure of enjoying Microsoft Ignite’s plethora of release already in March, only six months after the previous event in September 2020. For me the best part of these Microsoft conferences is always getting my hands on the book of news and going through it, looking for new upcoming things that excite me personally. Here I’ve collected my top three things revealed in Ignite 2021, and some analysis and possibly even speculation as to why they matter.
If you haven’t heard of Percept yet, it’s a platform for developing IoT solutions that use AI based on camera or microphone input on the edge. In other words, Percept is expected to allow you to easily develop smart camera or microphone devices that can perform analysis without a steady internet connection. The core concept here is neither new nor novel, in fact, when I first read about Percept I was immediately brought back to my first ever trip to USA to attend Build 2017: During the keynote, they played a video demonstrating just the kind of functionality that Percept is going to allow us to develop. And now, four years later, they are releasing a platform for accelerating the creation of these kinds of solutions into preview.
But what is Percept really, then? It incorporates a number of different things together under one product name. First of all, Percept has its own family of IoT devices sold by Microsoft as a devkit: Cameras, microphones and a hub device. Microsoft is also working with other device manufacturers to get their camera and microphone devices certified for Percept, so that they’ll be compatible with the underlying framework. The Percept framework itself comprises of Azure’s IoT, AI and machine learning services to make device management, deployment, and AI development more seamless. Microsoft is also providing a few sample AI models to get started with, and more solutions can be developed either without coding using Azure Cognitive Services’ Custom Vision, or via machine learning in Azure Machine Learning.
As I mentioned before, there is nothing really new about Percept. So why am I excited about it, except for the fact that it brought back memories from four years ago? Because it’s expected to make development of complicated things less complicated. It’s still a preview product, and it’s currently impossible to make any claims about how well Percept performs, but I am hoping to get my hands on a development kit at some point so that I could play around with it. Because let’s be real, if Microsoft manages to keep the value proposition of being an easy-to-use platform for developing edge AI solutions, that would make these capabilities available to a very wide customer base. And that would be pretty cool.
The Percept development kit can be ordered via Microsoft online store, and it will be available to countries where Percept has been certified. At least Finland wasn’t on the list of “soon to be certified” countries yet, so I’ll have to wait a little. Hopefully, you can get yours sooner!
Power BI Premium per User is coming to GA
I admit, it feels weird to be excited about Power BI when it’s a product that I personally don’t use at all. But some of my colleagues do use it, and we work together in the same projects where it’s my responsibility as the developer and data engineer to make sure that they have the data available for them in Power BI. If you are coming from a developer or data engineer background as well and are unfamiliar with Power BI, here’s the quick rundown as to what’s going on: Previously, Power BI has had two licensing models. You could either get Pro licenses which are associated with specific users, or you could get an organization-wide Premium license. Pro costs $9.99 per user/month while the cheapest Premium service tier costs $4,995 per month – and the latter contains a lot of useful extra features that Pro users are missing out on, such as AI and machine learning features, big data dataflows on Data lake, paginated reporting, access to report export APIs and up to 48 scheduled daily data refreshes. The list of Premium features definitely has at least something interesting for nearly every company using Power BI Pro – but capacity-based the price tag is just too expensive for many: Even if you had 100 Pro-licensed users (totaling at $999 / month in Power BI license expenses), getting a Premium capacity to replace those licenses would cost five times as much.
Which is where Premium per User comes in: Back in September 2020, in the previous Ignite event, Microsoft announced that this feature would be coming into preview, and now in Ignite 2021 they finally revealed the price tag and the GA date: April 2nd 2021. Premium per User is going to allow you to purchase user-based licenses that include nearly all features of the capacity-based Power BI Premium service. Features not included in Premium per User are on-premises reporting with Power BI Report Server, multi-geo deployment management, bring your own key -encryption and service autoscaling. Features which, while interesting, still don’t affect the kind of reporting you can do on the Power BI cloud service, so for the end users we can safely say that Premium per User is identical with the capacity-based model.
How about the price tag, then? Premium per User is going to cost $20 per user/month. So, looking back at the hypothetical example of 100 licensed Pro-users, getting Premium licenses for them would double the licensing costs, which would still be a lot cheaper than going with the capacity-based model. This leads nicely into why exactly I am excited about Premium per User: Similar to how Percept is promising to make previously expensive and difficult-to-develop capabilities available to a wider audience, Premium per User brings these premium features available to smaller and medium-sized businesses at an affordable price point. And as a developer and data engineer it’s important to remember: Even though we work with data all day long, the value our customers get from the data we wrangle comes from the insights they are able to get from that data. With Power BI Premium, their capabilities of getting these insights are improved, which in turn makes our jobs more meaningful and important as well.
Cosmos DB is getting role-based access control (RBAC) for data operations
My third favourite pick from Ignite isn’t something as sexy as a new product reveal, but a feature that actually sounds kind of boring, but which is still quite important: Cosmos DB now has RBAC capabilities in preview for data operations done on the SQL API. RBAC allows you to assign roles to Azure AD principals (that is, users, groups or service identities), so that you can authenticate against the service using that same principal and act within its own context. Previously Cosmos has had RBAC only for control plane operations, meaning that you have been able to restrict the management operations and access to Cosmos via Azure Portal, CLI or PowerShell for specific principals. For data plane operations, such as reading or writing data from applications or integration components, you have had to use either Cosmos’ primary keys or resource tokens, both of which have their own downsides:
- Primary keys are vulnerable, and they give you full permissions to all data and administrative resources within a Cosmos database account. They are long character strings that are used to authenticate against Cosmos DB, and while they are convenient in that using a primary key is very easy, they also give malicious users full access to your database should they somehow get their hands on your primary keys. It’s possible to recycle your primary keys in case they get compromised, and you can also either store them in a Key Vault which makes using primary keys safer, but they are still a potential strong attack vector against Cosmos DB.
- Resource tokens are technically time-based permissions for a Cosmos DB user to access data or perform operations in the database. In order to use resource tokens, you first need to create a user entity in Cosmos DB, give it access permissions to the data it needs and then request tokens. If you are creating an application that works using a service account then this scenario is fairly straightforward, since you only need to have one user entity. But if you want to provide your users with delegated permissions to Cosmos, you actually need to perform user creation, management and mapping to Azure AD principals on the fly in your APIs. That’s a lot of extra hassle.
How does RBAC for data operations simplify all this? First of all, there will no longer be any real reason to go for the easy way out of using primary keys because you can just as well use Azure AD’s managed identities with RBAC to access the database. And for delegated scenarios, you can simply provide your end users with access to Cosmos DB data with RBAC and then they can access the service using their own Azure AD accounts. There’ll be no need to perform any extra user management on your part anymore. Smarter, easier and most of all: More secure. That’s all the reasons I need to be excited about RBAC in Cosmos DB.
That’s my top three picks from Ignite and why they got onto the list! Do you agree or disagree about some of these? Does your list look different? Do let me know!