Scott Hanselman

Announcing Visual Studio and Kubernetes – Visual Studio Connected Environment

November 15, '17 Comments [14] Posted in
Sponsored By

I've been having all kinds of fun lately with Kubernetes, exploring building my own Kubernetes Cluster on the metal, as well as using a managed Kubernetes cluster in Azure with AKS.

Today at the Connect() conference in NYC I was happy to announce Visual Studio Connected Environment. How would one take the best of Visual Studio and the best of managed Kubernetes and create something useful for development teams?

Ecosystem momentum behind containers is amazing right now with support for containers across clouds, operating systems, and development platforms. Additionally, while microservices as an architectural pattern has been around for years, more and more developers are discovering the advantages every day.

You can check out videos of the Connect() conference at https://www.microsoft.com/connectevent, but you should check out my practice video where I show a live demo of Kubernetes in Visual Studio:

The buzzword "cloud native" is thrown around a lot. It's a meaningful term, though, as it means "architecture with the cloud in mind." Applications that are cloud-native should consider these challenges:

  • Connecting to and leveraging cloud services
    • Use the right cloud services for your app, don't roll your own DB, Auth, Discovery, etc.
  • Dealing with complexity and staying cognizant of changes
    • Stubbing out copies of services can increase complexity and hide issues when your chain of invocations grows. K.I.S.S.
  • Setting up and managing infrastructure and dealing with changing pre-requisites
    • Even though you may have moved to containers for production, is your dev environment as representative of prod as possible?
  • Establishing consistent, common environments
    • Setting up private environments can be challenging, and it gets messier when you need to manage your local env, your team dev, staging, and ultimately prod.
  • Adopting best practices such as service discovery and secrets management
    • Keep secrets out of code, this is a solved problem. Service discovery and lookup should be straightforward and reliable in all environments.

A lot of this reminds us to use established and mature best practices, and avoid re-inventing the wheel when one already exists.

The announcements at Connect() are pretty cool because they're extending both VS and the Azure cloud to work like devs work AND like devops works. They're extending the developers’ IDE/editor experience into the cloud with services built on top of the container orchestration capabilities of Kubernetes on Azure. Visual Studio, VS Code and Visual Studio for Mac AND and through a CLI (command line interface) - they'll initially support .NET Core, node.js and Java on Linux. As Azure adds more support for Windows containers in Kubernetes, they'll enable .NET Full Framework applications. Given the state of Windows containers support in the platform, the initial focus is on green field development scenarios but lift-shift and modernize will come later.

It took me a moment to get my head around it (be sure to watch the video!) but it's pretty amazing. Your team has a shared development environments with your containers living in, and managed by Kubernetes. However, you also have your local development machine which then can reserve its own spaces for those services and containers that you're working on. You won't break the team with the work you're doing, but you'll be able to see how your services work and interact in an environment that is close to how it will look in production.

PLUS, you can F5 debug from Visual Studio or Visual Studio Code and debug, live in the cloud, in Kubernetes, as fast as you could locally.

Shared Development Environment

This positions Kubernetes as the underlayment for your containers, with the backplane managed by Azure/AKS, and the development experience behaving the way it always has. You use Visual Studio, or Visual Studio code, or the command line, and you use the languages and platforms that you prefer. In the demo I switch between .NET Core/C# and Node, VS and VSCode, no problem.

I, for one, look forward to our containerized future, and I hope you check it out as well!

You can sign up for the preview at http://aka.ms/signup-vsce


Sponsor: Why miss out on version controlling your database? It’s easier than you think because SQL Source Control connects your database to the same version control tools you use for applications. Find out how.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Wednesday, 15 November 2017 16:34:12 UTC
This is just awesome Scott. So much technology and moving forward from MS that it is so hard for small companies like mine to follow your trail.

Currently considering porting an asp.net (full .net) complex app (including wcf services in the backend) to CORE, and containers & orchestrators are part of the plot. Guess we'll be there by your video about Kubernetes 11.0 :-p
Pablo Alcoriza
Wednesday, 15 November 2017 17:23:56 UTC
Are there plans to open this up for Kubernetes in general? Lots of places have in-house Kubernetes farms or run them on AWS and Google too.

I assume this is using kube API and/or kubectl underneath the covers?
Henning Kilset
Wednesday, 15 November 2017 18:27:14 UTC
Thanks for the interest, Henning. I'm on the product team.

Right now we are focused on getting this capability to developers on Azure by streamlining the experience all the way from the tools to Kubernetes on Azure. For example, quickly creating a Kubernetes development environment right from Visual Studio or VS Code, being able to hit F5 right away, with Kubernetes pre-configured to enable isolated development that Scott talks about in his demo. Developers can continue leveraging the underlying Kubernetes orchestrator with kubectl, helm, and other APIs.
John Stallo (Microsoft)
Wednesday, 15 November 2017 19:24:48 UTC
What is the ETA on proper Windows support with Kubernetes? We currently have to invest in a very expensive Docker4Azure Enterprise to get a mixed node cluster going (we have linux and windows services in swarm mode). Docker Swarm seem to be the only production ready orchastrator with Windows support, but very expensive for development...
Francois Nel
Wednesday, 15 November 2017 20:14:29 UTC
Hey Francois,
What does "proper support" mean to you? We currently support Kubernetes + Windows on Azure Container Service, there are some feature gaps in Windows vs Linux, but most of those features aren't in Swarm anyway...

--brendan
Brendan Burns
Wednesday, 15 November 2017 20:28:18 UTC
You’re making the choice between a really simple and just-works App Service deployment, and a bit more complex, but with much more possibilities AKS deployment much harder with features like this. Currently still using App Service but AKS seems so tempting...
Nick
Wednesday, 15 November 2017 20:36:12 UTC
Additionally: the only thing holding us back from AKS is that we don't really want to manage the VM our containers run on. But we might just have to live with that drawback...
Nick
Thursday, 16 November 2017 07:50:10 UTC
Brendan,

Correct me if I'm wrong, but according to https://kubernetes.io/docs/getting-started-guides/windows/ Windows support is still in Alpha, there is no ConfigMaps and there is issues with Secrets, which does not seem to be a problem for us in Docker Swarm 17.09 (assuming ConfigMaps is equivalent to Docker Swarm's "Configs"). Inter node comms also seems to be a an issue (which I must admit, is a tricky thing in Docker Swarm as well). I do however see that the article is based on Kubernetes 1.5, where as I see 1.8 is the current version. We'll have another look at ACS and see if things have improved since we last looked at it in the begging of 2017. Containers seems to be a (very fast) moving target...
Francois Nel
Thursday, 16 November 2017 12:45:34 UTC
What is the recommended way to create a Kubernetes Cluster with Windows agents in AKS?

I have previously used "az acs create" with the "--windows" option, but that option is not available for "az aks create".






Karl Moberg
Thursday, 16 November 2017 14:31:43 UTC
Does this support AKS only? Can this be extended to support any k8s instance? like minikube?
Maciej Misztal
Sunday, 19 November 2017 21:01:25 UTC
Hi Scott,
Great announcements, as usual.
However, I'm concerned about what Mr. Henning Kilset mentioned.
Are there going to be support for Visual Studio + kubernetes development on On-Premise too ?

This is very important. The user should be able to "configure" the target location: Azure, Amazon, google, or on-premise.

I hope you consider this.

Many Thanks,
Jalal Shaer
Monday, 20 November 2017 02:30:16 UTC
I don't want to be too negative or harsh, but I am finding this blog to be less and less relevant to my daily work. And this was not the case when I first started reading it about 8 years ago. It used to be a helpful blog which I actually used. Now I look at the content and think tl;dr - move on.

The reason this is disappointing is because there's never been a bigger need for ASP.NET blogs than right now. Things move so fast that if I open up an old solution, it just blows up and I have to spend 2 days figuring out how to get my code to compile. And the modern tool-chain has become a nightmare. I never thought I'd say this, but I yearn for the old pre-Javascript-infatuation days. Life as a developer was ... simpler.

Now it is -> Learn Grunt. No scratch that. Learn Gulp. No scratch that. Learn Webpack. I must be getting old, grumpy and fatigued. But oh yes, Kubernetes Cluster. Do continue. Carry on...
Dave
Tuesday, 21 November 2017 13:48:55 UTC
Hi Scott,

Great feature and will save a lot of time. I have spent sleepless nights in setting up the environment manually for this kind of scenario for hobby projects.

I work for a big enterprise in Banking and Financial Domain and whenever I put forward the idea to them, even though they like it, the first thing they will object is that they can't expose their various environments in a third party infrastructure.

So, how can we make the enterprises feel secure about it?
Thursday, 23 November 2017 01:45:27 UTC
@Amal, good questions! Organizations who cannot commit to "everything in the cloud" still have a number of open options with Azure.

A common, first step for many organizations looking at cloud adoption is to place their dev/test environments in the cloud, even if their production environment with sensitive production data still needs to remain on-premise. This allows the development team to start tapping into cloud benefits like provisioning speed, elasticity, and reduced cost. Fully managed cloud services, like AKS, can significantly reduce the infrastructure that needs to be maintained and patched.

Organizations can also adopt a hybrid approach, where some of an organization's components run in the cloud, and connect to on-premise components that the organization deems must remain in its own datacenter. ExpressRoute and Virtual Networks are used in this hybrid pattern to provide secure communication between on-premise and cloud assets.

I hope you give VSCE a try: https://aka.ms/signup-vsce
John Stallo (Microsoft)
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.