Protecting a web-app with AzureAD

Deploying a web application on azure is incredibly easy these days. You can handle everything, including creating a whole new web app and app service directly from Visual Studio. A lot of times we deploy these small web apps as internal tools for our team or company but we must not forget about securing those behind a log-in so that they are not accessible to anyone trying out domains at azurewebsites.net

Read More

Share Comments

Azure CosmosDB Graph Explorer

Azure CosmosDB Graph Explorer is a great opensource tool that allows you to easily and quickly visualize the data you have in your Azure CosmosDB Graph (yes, just graph at the moment).

Read More

Share Comments

ServiceFabric RemotingTransport settings in ASPNET Core project

When wirting a Service Fabric Service that uses the Remoting Transport layer, you sometimes need to update the default settings to allow for a greater message size or operation timeout.

According to the documentation, this is achieved by overriding the default settings in the Assembly manifest file that you find under Properties/AssemblyInfo.cs

1
2
3
using Microsoft.ServiceFabric.Services.Remoting.FabricTransport;
// Allow messages up to 100 MB, operation timeout to 10m
[assembly: FabricTransportServiceRemotingProvider(MaxMessageSize = 100000000, OperationTimeoutInSeconds = 6000)]

However, you might notice that if you created an ASPNET Core service (to use as a gateway perhaps), the new project type does not have the AssemblyInfo.cs file anymore. Even more, if you create it yourself, it will be ignored.

This is happening because in the new ASPNET CORE project type, the AssemblyInfo file is auto-generated during build. Since there’s no other way (as far as I could find) to update our remoting settings, we need to get rid of the auto-generated file and write our own.

First, create your own AssemblyInfo.cs file under the Properties folder.
Next, find the auto-generated file in the obj folder. Copy its contents over into your newly created file.
Lastly, we need to instruct the build system to not generate the file automatically any more.
We do this by updating the project file:

1
2
3
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

That’s it, with these changes, you now have the new remoting settings available for your ASPNET CORE project.

Share Comments

CosmosDB graph formats

When working with CosmosDB GraphAPI it helps to understand how the engine stores or manipulates the inputs, so I will try to explain the data formats.

Read More

Share Comments

Mixing Gremlin with DocDB API in CosmosDB

One of the best things about CosomosDB is the ability to mix and match APIs and models based on what makes sense for your use case.

Sometimes it just makes sense that your database is built as a graph, and in that case you can use the (familiar) Gremlin language to write your queries. However, for some things it might be easier or more optimal to use familiar DocDB APIs.

Read More

Share Comments

CosmosDB Graph Read optimization with ReadDocument

One of the interesting things that caught my eye in the newly released 0.3.0-preview SDK was the .limit() step optimization.
Like we saw in one of my older posts, limit() was executed client side, so you’d get the entire result set from the server and the client side sdk would filter and return it back to caller.

Read More

Share Comments

CosmosDB Graph gremlin tips

After fiddling with the requests for inserting data using Gremlin, I decided to check on some other common calls and I was not super impressed with the results.

Read More

Share Comments

CosmosDB Graph Read optimization with ReadDocument

Like we saw before, you can use the DocDB API or Gremlin interchangeably for inserting data, and you can also do the same for reads. Complex queries or traversals will still need Gremlin, but for simple reads you could (and probably should) use the DocDB API - and by simple reads, I mean reads where you know the ParititonKey and the Id of the node you need to retrieve.

Read More

Share Comments

Imagine a database system...

Imagine a database system…
… where you don’t need to define a schema ahead of time. Which means you don’t need to worry about schema migrations or syncing your data models.

Imagine a database system…
… that is globally available by design and you can enable it in a matter of minutes with a few clicks.

Imagine a database system…
… that is elastically scalable by design and in near real-time. You pay for what you need, when you need it without spinning VMs up and down.

Imagine a database system…
… that is fully managed, on the best cloud out there, so you don’t ever need to worry about infrastructure and everything that comes with managing that infrastructure

Imagine a database system…
… that supports multiple data models (relational, table, graph, document) so you don’t ever have to compromise on one type, or have to use multiple databases for your needs.

Imagine a database system…
… that supports multiple APIs for manipulating your data. You can choose from a number of Apis like the familiar SQL, DocumentDB or MongoDB, Gremlin, Table API or even Cassandra.

Imagine a database system…
… that has 5 consistency levels that are easy to understand and define. Break away from just Eventual or Strong consistency of the other distributed database offerings out there.

Imagine a database system…
… that has single digit millisecond latency performance and availability guarantees backed by an SLA at the 99 percentile

If you got excited imagining… imagine no more, CosmosDB is here and it’s everything you’ve ever wanted from a database! Check it out today!

Share Comments

Getting a list of VM SKUs with Powershell

I was working on an ARM template the other day for deploying an ElasticSearch cluster on Azure. One of the things I needed to decide on was the SKUs of the VMs in the cluster. I knew I wanted a Linux machine but I wasn’t familiar with the SKU Names that I had to enter.

Read More

Share Comments