Announcing Visual Studio and Kubernetes – Visual Studio Connected Environment
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.
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.
About Newsletter
I assume this is using kube API and/or kubectl underneath the covers?
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.
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
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...
I have previously used "az acs create" with the "--windows" option, but that option is not available for "az aks create".
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,
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...
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?
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
Comments are closed.
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