Hey node developers, switch to .NET Core – now!

Several years ago I started building a bigger project as a Software as a Service application. Beside all the different technical requirements, being able to work directly on my MacBook Pro without starting virtual machines, was a big wish. At this time a tool chain based on Node.js, Express, NPM and WebStorm was available. Over the years building backend services with Node.js, and this means with JavaScript, felt like rapid prototyping. Getting started is very fast and lightweight but when the project grows compile time features like a strong type system are missing. Year over year I did reviews how to get esp. the beauty of C# and the powerful compiler infrastructure of .NET back.

intelligentservice

In the last month Microsoft released Visual Studio for Mac and with it the investments into .NET Core increased. Building backend services in Visual Studio for Mac based on .NET Core and ASP.NET Core including the out of the box support in Azure App Services is definitely what I was looking for.

Because of that I decided to give it a spin. After a couple weeks working with the framework I can say it was the right decision because of the following key reasons:

  • Full managed and type safe environment based on the powerful C# compiler
  • Broad ecosystem for components similar to NPM via NuGet
  • Ability to convert runtime errors in compile time errors 
  • Hosting the results on Linux, Docker Containers or just Azure App Services
  • ASP.NET Core comes with out of the box easy to use Dependency Injection system
  • ASP.NET Core learned and steeled the best things from the node + express chain
  • C# Attribute and Extension-Classes are unbeatable to beatify your code 

And last but not least everything works well on my MacBook Pro without the need of a single virtual machines – Thanks Microsoft for letting me keep the platform I love!

Azure Costs: Public Preview CSP Support

Today we’re very excited to announce the start of the public preview for Cloud Solution Providers.  After several weeks and months of continous improvements in the azure costs platform, we now start the public preview phase of the CSP support.  

b3e5c00e-e4e6-4ecd-b764-746bcbb2de1c

The great new CSP portal gives you access to the spendings your customers are generating. There are a couple of use cases we would like to point out:  

Enroll into the CSP program:
When visiting our new CSP portal the system will require enrolling into the CSP program. You can do this with an existing Azure Costs account or in case you would like to differentiate between internal spendings and customer spendings, just use an additional account!

 59ee1668-64eb-4bfb-b135-f68f3ff3975c
Register Accounts:
Microsoft requires every CSP to sign into the CSP program for every geographical region separately. As an internal reseller you will have accounts for USD, EUR or AUD and several more. Azure Costs allows you to register every single CSP account, to track costs in different currencies and countries separately.
7b12c995-0c67-4b6c-b20c-a2c19cae071e
Activate Customers:
During the registration process Azure Costs imports all existing customers. This does not mean Azure Costs tracks spendings. If you would like to track spendings for a specific customer, activate this customer in the “New/Not-Activated Customers” widget. The spending information of every activated customer will be imported automatically.
2e47b12a-fbbc-4cad-bcab-3cd2b70fb138

Interested in the new feature?
Getting started with Azure Costs for CSPs is very easy, just visit our new portal for Cloud Solution providers and enroll into the CSP program as described above. To become part of the public preview of the CSP support an existing enterprise plan is required.

Any questions, wishes or ideas? Try our feedback portal or drop a mail to help@azure-costs.com.

 

Git Deployment – Shallow Clone Support in Azure App Services – The missing piece

Azure App Services and the open source project KuduSync behind this great Azure Service is a huge time saver for agile teams. Especially DevOps teams will like the continuous deployment features.  Personally I focus a lot on the Git based deployment which enables you to roll back and forward in seconds whenever it is required. Beside that, it is possible to work with standard tools available on market to implement continuous deployment or integration.

Deployments - Microsoft Azure 2017-07-18 06-48-11

When I started working with Azure App Services building Node.js apps, I wrote a little node package called Azure Deploy. It allowed me to push changes as part of a build process directly into the Azure App Service. Originally, CodeShip was the service of choice for the build process but since I need to support Git Repositories beside GitHub, BitBucket and GitLabs, I migrated to Visual Studio Team Services (VSTS) and the integrated build platform.

vso-build-tasks

After several months and hundreds of deploys, which means hundreds of commits to the local git repository, it became a fairly complex and fat thing. This is normally not a problem but my Azure Deploy package clones the local git repository from Azure App Service to a temp directory and copies the build output over it. Last but not least it commits and pushes the changes back to Azure. The big repository took more than 4 minutes to clone so I was wondering if I can use Shallow Clone to get only the latest state of the repository.

This idea works well on Unix based git servers, on GitHub or even in Visual Studio Team Services as well. But when you try to clone a local Git Repository of Azure App Services via Shallow Clone option

git clone --depth 1 https://github.com/jquery/jquery.git jquery

it ends up with an error. The error and its background is also documented in the GitHub project of KuduSync here. So what to do now?

Another nice option of Azure App Services is the option to pull changes from a Git Repository instantly after a commit. This works well in VSTS, based on GitHooks but also with GitHub and a couple other platforms. It’s also possible to clone via shallow clone flag from these repositories which closes the loop. The final solution is to commit into a VSTS or GitHub hosted publishing repository which triggers a pull deployment in Azure App Services.

At the end this change reduced the whole deployment time from 5 up to 9 minutes, down to approx. 90 seconds. You can find the updated Azure Deploy component in the NPM registry here.

Feature Announcement: Smart Compare

We’re very excited today, to announce the release of a game-changing new feature for azure costs: Smart Compare.

Smart Compare allows our customers to conveniently compare their monthly cloud costs with the costs of any previous month. By simply choosing the relevant months, azure costs now highlights cost spikes and deflections, so that our customers can focus on the costs they are really interested in – and ignore those they’re not.

compare-final.png
These results can then be sorted and powerful filters allow our customers to limit what they see, to only what they’re interested in.

filter-demo.png

We are sure that this great feature will help our costumers to identify the real cost drivers and make informed decisions on cost optimization strategies.

How to get started?
Comparing cloud costs is this simple: The Smart Compare and sorting functionality can be used right now as part of our Preview UI. Just select multiple months as shown above, to identify cost drivers, spikes and deflections.

Interested in the SmartCompare feature?
Try the new feature today by simply logging into your azure costs portal. Smart Compare is part of every paid plan, starting with the Professional subscription.

Any questions, wishes or ideas? Try our feedback portal or drop a mail to help@azure-costs.com.

Review: GitHub vs. Visual Studio Team Services (VSTS) – Should you switch?

Disclaimer: This article is about Visual Studio Team Services (VSTS) and GitHub. The author has a very positive opinion about both services and does not get any offers from Microsoft or GitHub writing this article. The whole article is written IMHO.

Over the last years GitHub has become a success factor for projects related to git repositories for me personally. I also tested several other solutions but mainly I struggeled with the performance or the usability. About 2 years ago I started using Visual Studio Team Services (VSTS) with a work related project. The service looked promising but had a lot of early release issues, so in the last 24 months it was interesting to see how a promising solution became adult. Last week I decided to move away from GitHub for all my closed source projects and rely on Visual Studio Team Service (VSTS). This article gives a deeper look on the main reasons of why I did the move and may help deciders to get detailed information before implementing:

Git-Repository sprawl
Nowadays thanks to bower, npm, bundler or NuGet the amount of Git repositories are growing steadily. When you are focused on component based software development Git is a great helper but the amount of repositories is sprawling because very often every component has its own live in a separated Git repository, which means you have a separate release cycle and a different versioning compared to your main project.

vsts-git

I guess this is the secret source of component managers which are working closely together with git repositories. Of course VSTS and GitHub are supporting multiple git repositories but GitHub lets you pay on a package on git repositories, VSTS lets you pay for users. Especially for small teams paying for users is the better deal, compared to paying for repositories. At the end Microsoft offers a smaller groups of 5 everything for free. This fact stopped my permanent GitHub problem: Having too less private repository space.

GitHub:
O – Allows to have as many GitHub repositories as needed
+ – Generates releases out of tags automatically (good semver integration)
– – Charging base is the count of private git repositories

VSTS:
O – Allows to have as many GitHub repositories as needed
+ – Comes with unlimited git repositories, plans are user based
– – Repository management is not that intuitive as it is in other solutions

Pull Requests and Forks
Forks and pull requests are the most important features GitHub introduced very early to support community driven development. I would say in the open source world Github is the platform when it comes to forks and pull requests. Currently I would never think about moving open source repositories away from GitHub because of this great feature.

pull-request.png

When it comes to closed source projects, forking and pull requests are becoming only important in bigger teams with different products or product lines. We are using this feature strongly in our teams at my company. Smaller startups or teams will not use these workflows often but nevertheless it is a road blocker for me to do the 100% switch to VSTS. I guess it took Microsoft around 12 month to deliver it in a more simple way GitHub is doing this.

GitHub
+ – Cross repository forking
+ – Pull requests incl. discussion thread and a lot of community features

VSTS:
O – Supports pull request on repository level

Agile Process support with EPiCs, features and backlogs
When it comes to bigger teams or more structure, people are having the option that to implement a process is the key. This brings me to the biggest enterprise blocker I see in GitHub, the Issue-Tracking system. Companies who migrated to an agile framework like SCRUM or KANBAN need to have the option to work with features, backlogs or bugs. Microsoft delivers with VSTS a highly customizable and adaptable work item management system. The SCRUM and KANBAN template makes perfect sense for agile teams but also the traditional waterfall model can be implemented (even if I don’t understand why someone should do this.)

backlog.png

GitHub
– – It’s just an Issue Tracker
+ – Has good integration into many cloud services

VSTS:
+ – Offers customisable work item management
+ – Comes with templates for agile team structures

Handle your Test-Cases
Even if your projects comes with a great code coverage and good unit tests, the requirements to execute manual tests or just to orchestrate automated integration tests exists. VSTS implements based on the work item management a test case management which has the option to integrate it with automation bots via WinRM and other protocols.

bot

The ability to document test cases and write specific step by step guides how to verify a feature is a big plus esp. in small teams where no dedicated QA resources are hired.

GitHub
O – Ability to integrate with external QA services
– – No integrated test case management

VSTS:
O – Ability to integrate with external QA services
+ – Test Case management is part of the work item management

Centralised Source Code management as migration path
For a couple month Microsoft offers virtual TFS collection, which allows companies that want to go pave the road for git based repositories to stay with the existing centralised source code management besides new git repositories. In the early day VSTS just supported a TFS collection per project space but now maintaining TFS collection is that easy as it is creating new git repositories. This will become very important features for existing TFS customers.

new-repo.png

Revised Build-System incl. Linux Support
I guess Microsoft learned very fast that the XAML file based build system was very inflexible and complicated for a SaaS service like VSTS. Because of that a couple month ago a new step based build system was introduced which will orchestrate the build agent out of VSTS

build-task.png

Since Microsoft supports Windows, Linux and Mac build agents there are no road blockers anymore, besides that the hosted build services for VSTS are very rare. There is a build server Microsoft offers out of the box but from my experience you will get more problems customizing that. When you are focused on Azure check also what the Azure App Services can do for you because KuduSync offers out of the box build for your .NET application during deployment.

 GitHub
+ – Many different build services available with GitHub integration (CodeShip, T..)
– – Build definitions are not part of the code project
– – No release management to aggregate several projects 

VSTS:
– – Hosted build services for VSTS rare
+ – Build definitions are part of the code project
+ – Release Management allows to aggregate several sub projects

Other services and options:
There are also other options and products on the market and I guess one of the most popular one is Assembla which is pretty comparable to Visual Studio Team Services. Also the products from Atlassian (Jira, BitBucket) are great options supporting your development cycle. This article had the intention to support companies who are dealing with GitHub and / or On Premise TFS and now are thinking about combining the positive of both.

I personally think GitHub could become a great option for enterprises as well, when the Issue-Tracker problem is solved which was mainly the reason why I searched for an alternative!