There’s a moment in building something where you have to decide who you’re optimizing for.
Early on, it’s just you. Then maybe a small set of ideas, sketches, or prototypes. Eventually, you reach a point where the work is real enough that keeping it completely private starts to hurt more than it helps.
I think I’m at that point now.
The Tension Between Polish and Learning
There’s a strong pull to wait until something feels “done” before letting anyone see it. Polished. Documented. Fully formed.
The problem is that polish often hides the most important feedback.
What I care about right now isn’t applause or adoption. It’s learning. I want to know where people pause, what they misunderstand, and which assumptions don’t survive first contact with reality.
That kind of insight doesn’t come from dashboards or signups. It comes from thoughtful eyes on unfinished work.
Choosing Who Gets to Look
I’m not interested in opening the floodgates yet. Early feedback shapes products, whether you want it to or not, and I’m being intentional about who helps shape this one.
Peers. Builders. People who understand tradeoffs. People who are comfortable saying, “This part feels off,” instead of just asking for features.
That’s who I want looking right now.
Comfortable, Not Rushed
Letting people see something before it’s ready isn’t about being early. It’s about being honest about where the work actually is.
I’m comfortable with people looking. I’m comfortable with it being incomplete. I’m comfortable saying, “This is close, but not finished.”
What I’m not interested in is rushing past that phase just to say it’s launched.
There will be a time to open the door wider. I’m not there yet.
But I’m close enough now that letting people see the shape of it feels like the right next step.
Over the years, there have been plenty of moments where a new technology showed up and people rushed to declare that everything was about to change. Sometimes they were right. Sometimes they were early. Sometimes they were just obnoxious and faded out with the fad.
More than once, I chose not to act.
Not because I couldn’t build something, but because it didn’t feel like the right moment. The pieces weren’t there yet. Or the problem was still being solved well enough by humans. Or the solution would have created as many issues as it fixed.
My dad was a video engineer by trade. He was one of, if not the first, people in Kansas City trained to run a slow-motion reel-to-reel machine. His experiences with new and emerging technologies helped shape how I think about when to get involved, and when to sit on the sidelines.
When Chyron video technology began emerging in the 1960s and 1970s, it was used sparingly. My dad wasn’t trained on Chyron yet, but he had an idea. He took a small video camera, mounted it on a tripod, and pointed it at the scoreboard during a baseball game.
Later, he did the same thing for football and other sports.
That simple workaround helped change what viewers came to expect from televised sports. In a nine-inning baseball game, it’s nice to know the inning, the score, and the time at any moment. Today, those elements are permanently embedded on your screen, so normal you don’t even notice them. They’re expected.
My dad saw a technology that wasn’t being used in the best way possible, and he acted at the right moment.
Experience has a way of teaching you when to move. He was right.
It seems like just yesterday
It seems like just yesterday, but I’ve lived through multiple waves of tooling shifts myself. Each one promised to simplify software development. Each one delivered real gains, along with new kinds of friction.
What never really went away was the same underlying problem: humans doing invisible coordination work between systems that don’t quite understand each other.
We learned to live with it. We staffed around it. We normalized it.
For a long time, that was the right call.
Why This Time Feels Different
What’s changed isn’t just the technology. It’s the combination of things finally lining up, and the growing awareness of the gaps that still need to be filled.
We now have systems that can reason just enough to participate in work, not just execute it. We have workflows that can adapt instead of forcing everything down a single happy path. And we’re finally talking openly about the cost of context switching, glue work, and human babysitting of software.
More importantly, we’ve learned what doesn’t work.
Blind automation doesn’t scale judgment. More tools don’t automatically create clarity. And faster output doesn’t guarantee better outcomes.
Those lessons matter.
Waiting Was Part of the Work
If I’m honest, part of being ready now comes from knowing what I don’t want to build.
I don’t want another system that just moves work faster without understanding it. I don’t want something that replaces human judgment instead of supporting it. And I don’t want to rush something into the world just because the timing feels exciting.
I waited until it felt necessary, not just possible.
Close, But Not Quite There Yet
I’m finally at a point where it feels okay to say that I’m building something. In truth, I have been for months.
I’ll be opening a beta soon. I can’t say exactly when yet. But I’m close enough now that the direction is clear and the product is taking its final shape.
For the first time in a long time, it feels like the right moment to act.
The stretch between Christmas and the New Year has always been a strange and useful pause.
The calendar hasn’t flipped yet, but the pressure eases just enough to think. Projects slow down. Meetings drop off. You get a little space to reflect without immediately turning that reflection into a plan.
This is usually when I take stock of what’s actually worth paying attention to.
Less Noise, More Signal
There’s no shortage of predictions right now. Every week brings another “AI will change everything” headline, another tool launch, another bold claim about the future of work.
Most of it is noise.
What I’m paying closer attention to is quieter:
Where teams are still struggling, even with better tools
Where automation helps, but also where it gets in the way
How often humans are still doing invisible glue work between systems
And which problems keep showing up no matter how advanced the tech gets
Those patterns matter more than any single product announcement.
The Gap That Keeps Showing Up
One thing I keep seeing is a growing gap between capability and clarity.
We have systems that can generate code, route work, summarize decisions, and automate entire workflows. But many teams are still unclear about why certain work exists, who should make which decisions, and when software should act versus pause.
More capability doesn’t automatically lead to better outcomes. In some cases, it just makes existing problems happen faster.
That’s the space I find most interesting right now.
What I’m Intentionally Not Rushing
There’s a strong pull at the start of a new year to rush toward answers.
I’m resisting that.
Some problems benefit from speed. Others benefit from sitting with them a little longer. Understanding how people actually work, where judgment shows up, and where things fall apart, takes time.
I’m okay with that.
Looking Ahead, Quietly
As we move into the new year, I’ll be sharing more of what I’m observing as these ideas take shape. Not polished conclusions, but real thinking in progress.
If you’re curious where that goes next, I’ve started talking out loud in a few places beyond this blog. You’ll find links on the site if you want to follow along.
No pressure. No sign-ups. Just conversation.
Sometimes the most useful thing at the start of a new year is simply paying attention.
This time of year has a way of slowing things down.
As winter settles in and we all spend a little more time with family and friends, there’s often a moment when the noise quiets just enough to think. For most people, I’m sure it’s about the magic of the holidays, time with family and friends, or maybe even a warm-weather vacation. For me, my head wanders to my work. Not the next sprint or the next feature, but what actually matters over the long haul.
This year, that reflection keeps coming back to a simple question:
What really makes a great engineer?
After decades in this industry, I’ve seen tools change, paradigms shift, and entire job descriptions come and go. But I’ve also watched one critical skill slowly fade into the background.
And right now, that skill matters more than ever.
It Isn’t Coding Speed or Tool Knowledge
The most valuable skill I’ve seen engineers lose isn’t typing speed, language fluency, or familiarity with the latest framework.
It’s not PR velocity or anything measured by DORA metrics. It’s definitely not who has the deepest front-end framework expertise.
All of those things are valuable. But something else is more important.
It’s the ability to reason through ambiguity.
When I was coming up, we didn’t have the luxury of abstraction layers everywhere. If something didn’t work, you traced it. You reasoned about it. You figured out why.
I’ve mentioned before that I used to test on algorithms in my hiring assessments. They mattered. Not because engineers would be implementing them every day, but because algorithms expose reasoning, tradeoffs, and comfort with uncertainty.
The final part of my assessment was a four-question story titled “One Bad Day.” In it, engineers were faced with real-world problems and incomplete information. There were no right or wrong answers. What mattered was how they handled uncertainty when confronted with it.
Those questions revealed how someone thinks when there isn’t a clear path forward.
As software evolved, we got very good at assembling systems. We got much less comfortable sitting with ambiguity.
Abstraction Is Powerful, But It Has a Cost
Modern tools are incredible. They let us build faster and bigger than ever before. But they also hide complexity, and when complexity is hidden long enough, people forget it exists.
That’s how we end up with engineers who are productive, but uneasy the moment something doesn’t behave as expected. When the happy path breaks, the thinking muscle hasn’t been exercised.
AI accelerates this trend if we’re not careful.
Why This Skill Matters More Now, Not Less
There’s a fear that AI will do the thinking for us.
I believe the opposite.
AI is very good at producing output. It’s much worse at knowing when that output is wrong, incomplete, or misaligned with intent. That gap is where human reasoning becomes invaluable.
The real present in this new era isn’t faster code generation. It’s the opportunity to refocus engineers on judgment, evaluation, and problem framing.
Those are learned skills. They compound over time. And they don’t disappear when tools change.
The Gift That Actually Lasts
As you head into the end of the year, maybe while you’re opening presents or just enjoying a quieter moment, this is the thing worth investing in.
The greatest gift you can give yourself as an engineer isn’t another tool or certification. It’s the willingness to slow down, sit with ambiguity, and reason your way through it.
When I first got into software, there were no libraries waiting for us. No package managers. No Stack Overflow. No copy-paste from GitHub.
If you wanted to build something, you built it. Top to bottom.
If I needed to talk to another system, I opened a socket. I connected via TCP. I handled the protocol. If something failed, I debugged it at the wire level. Applications were handcrafted end to end, and you were responsible for everything you shipped.
That experience shaped how I think about software to this day.
From Building Software to Assembling Software
As my career progressed and I started hiring engineers, I noticed something changing. We stopped teaching people how software works and started teaching them how to assemble it.
That’s not necessarily bad, but it does change the skill set.
When I built hiring assessments, one of the things I always tested was algorithms. Not because I expected everyone to be writing sorting routines every day, but because algorithms tell you how someone thinks. They reveal reasoning, tradeoffs, and how a person approaches a problem when there isn’t already a solution handed to them.
Over time, that kind of thinking became less emphasized. We got very good at wiring packages together. We got worse at understanding what was actually happening underneath.
That shift matters more than most people realize.
Automation Isn’t New, Context Is
Long before AI entered the conversation, I used to tell teams the same thing over and over. I can automate almost anything, but we need to start with people.
You let humans run the process first. You iron out the edge cases. You understand where things break. Then you automate the boring, repeatable parts and kick the exceptions back to humans.
That model has worked for me for decades.
What’s new now isn’t automation. What’s new is that software can finally understand a little bit of context. Not perfectly, but enough to participate instead of blindly executing instructions.
That distinction is everything.
The Real Cost of Babysitting Software
At one company, I had a peer who was incredibly good at keeping things running. Customers were happy. Issues were handled quickly. From the outside, everything looked fine.
When he eventually left, I dug into the system and realized how much time had been spent babysitting instead of fixing root problems. Not because he didn’t care, but because there simply weren’t enough hours in the day.
The company didn’t push for deeper fixes because the work was getting done. In reality, they were paying a premium for reactive support instead of investing in durable solutions.
That experience stuck with me.
Software that constantly needs human babysitting isn’t efficient. It’s expensive. And worse, it hides the real cost behind “everything is working.”
How My Thinking Has Changed
Today, I care less about features and more about intent.
Where does intent originate? How is it preserved as work moves through systems? What happens when that intent becomes unclear? And when should software act versus pause and ask for help?
These questions matter more to me now than which framework is trending.
Some principles I won’t compromise on anymore:
Tools should preserve intent, not just produce output.
Automation without context just accelerates the wrong outcomes.
Humans are not a failure mode, they are part of the design.
Software should adapt to people, not force people to adapt to it.
Why This Is Finally Possible
For most of my career, software was deterministic because it had to be. That made context preservation incredibly hard.
Now we have systems that can reason, summarize, adapt, and operate with uncertainty. We can design workflows that branch. That pause. That escalate. That involve humans when confidence drops.
This doesn’t replace judgment. It finally gives judgment a place to live inside the system.
A Quiet Tease
I’m working on something that reflects all of this.
It’s shaped by decades of building software the hard way, watching teams struggle with invisible friction, and seeing how often people end up doing work that tools should have handled better.
I’m not ready to talk about it publicly yet.
But if modern dev tools feel powerful and exhausting at the same time, we’re probably thinking about the same problem.
The first computer most people encounter today fits in their pocket. Mine filled most of a desk. Actually, a desk and a printer cabinet next to it.
My very first computer experiences were on our school’s Apple I machines, playing Oregon Trail on either black and white TVs or bright green monochrome monitors. Later at home, in the late 1980s, we got an Epson Equity I+ with a 10 MHz CPU, 640K of RAM, a 10 MB hard drive, a 5.25 inch floppy drive, and an EGA monitor that felt like stepping into full color after years of monochrome. If you lived through that transition, you remember how magical it felt. Not just more pixels, but more possibility.
Since then I have watched wave after wave of transformation reshape software and the world around it.
The CPU evolution, from the simplicity of that first 10 MHz machine to modern processing stacks capable of teraflops.
Gaming advances from Pac-Man at the arcade or on Atari at home, to Super Mario on Nintendo, from 8 bit to 16 bit, to 64 bit, and eventually to fully immersive 3D experiences.
The rise of the internet, starting with dial up BBS systems and rapidly becoming the global information network we rely on today.
Communication shifting from letters and postcards to electronic messaging, long before anyone imagined what smartphones would become.
Social platforms growing from AOL chatrooms and small forums to worldwide communities where billions share ideas.
The mobile phone evolving from a clunky brick attached to a briefcase to a pocket sized computer that dwarfs the power of my first PC.
Music and movies becoming instantly accessible. No more waiting for release days or storing shelves full of physical media.
Breakthroughs in biology that finally let us map DNA and understand life in new ways.
Automation taking form in 3D printing, robotics, and smart home technology.
Machine learning taking root, followed by modern generative AI that can now write, reason, and assist in ways we only imagined in science fiction.
And these are just the highlights. After 25 years in the industry and a lifetime of tinkering, the list is a long one.
What is interesting about right now, especially with 2026 on the horizon, is that it feels like another one of those rare pivot points. Except this time the shift is not about faster processors or prettier screens. It is about the relationship between humans and software fundamentally changing.
We are entering an era where tools are not just tools. They are partners. They help us think, reason, and build. They fill gaps. They accelerate ideas. They lift creativity instead of replacing it.
For the first time in my career, I am building something that sits directly in the center of that shift. Something that focuses on how to evolve the bigger picture rather than profit from it. Something designed with everyone in mind, not tied to advancing any particular agenda.
I will be announcing something big very soon for software development. At least, I think it is big. For now, I will simply say this:
Everything I have learned since that Epson Equity, from the GW-BASIC and MS-DOS 3.2 manuals, through distributed computing, microservices, and machine learning, all the way to modern AI, has been quietly converging into a project I have been shaping for a very long time. I just did not realize it until recently.
It is close now.
And once it is ready, I believe it will change how a lot of people think about building software, and possibly grow into something far larger than that.
I know it’s been a long time since I last posted, but I think it is relevant to discuss training and education, especially in software development. This has been a topic weighing on my mind a lot the past several years.
In the past 20 years since I made the leap into my career path, I have witnessed many changes in technology. The microprocessor and the internet have taken over nearly every facet of our daily lives. It is quite remarkable where we came from to where we are today, and to think it has only been that short of a time while I’ve been a professional.
When I first started writing software, we didn’t have the rich toolsets we have now. We had some very basic compiler suites, or command line compilation using a text editor to edit the source files. We also didn’t have the libraries available today. Most problems we had to solve from scratch. Finally, to top it off, we didn’t have Google to save the day when we needed that snippet of code to hybridize into our own solution. We had to know how to write algorithms to solve problems. The solutions weren’t handed to us, and we weren’t coddled to the answer via great tools that auto complete our lines of code, and format our code and give us instant feedback to errors or omissions without compilation and trial and error.
I may sound like an codgidy old man, and maybe I am, but I think having to solve problems from scratch taught my generation a lot about problem solving. I think this is the magic bullet that is missing from the college curriculum, work training programs, or coding bootcamps. I think all of those things are great, and there is some foundational stuff there, but these folks are missing out on algorithm design. This is the foundation for which all software works. You have to be able to solve problems. You can’t just rely on Google or great tools to solve them for you.
So, here I plead to anyone affiliated with these software development educational programs, spend some time on bubble sort or binary search. Teach your students about how to extract a subset of text from a string, or how to increment numbers exponentially. Spend some time on conditional logic, and order of operation. All of these things have value, and while pretty basic, they are the building blocks that we are skipping over to get to the cool IDE or the latest tool or JavaScript library.
So, you’re a Rockstar developer and you’ve constructed an app that is primed and ready to be the next big thing. All that stands between you and millions of users is deploying it to the cloud. While you’ve narrowed your choices to Microsoft Azure, Amazon Web Services (AWS), or Google Compute, you just aren’t sure about where to park your creation for the long haul. After all, you expect to be publishing new features and updates daily for quite some time. The future home of your masterpiece can’t slow you down on your quest to conquer the computing universe! You’ve done your pricing research and all three options are comparable, so really the decision comes down to first time configuration ease, first time deploy time, subsequent deploy times, and any other perks that might save you steps in the future as this juggernaut scales.
Well my friend, this guide was written for you!
Prerequisites
Since you probably aren’t going to hand over the source code to your ultimate creation, for purposes of demonstration, we will call upon our old reliable and trusty friend, “Hello World”, written in C#, ASP.NET Core, and utilizing Visual Studio 2015.
This guide assumes you have accounts setup at Azure, AWS and Google Compute. For Azure, you’ll want to install the latest Azure SDK for Visual Studio 2015. For .NET Core, make sure you have installed Visual Studio Update 3 or greater. It’s also a good idea to do all of your updates for Visual Studio under Extensions and Updates.
Azure
First, we will deploy our web app to Microsoft Azure. One nice thing about deploying to Microsoft’s cloud service when using Microsoft’s development studio is that the two are very nicely integrated. The first advantage that Azure has over any other platform is in configuration. When you open Visual Studio to build your web app, click “New Project…”:
Next, select Templates->Visual C#->.NET Core->ASP.NET Core Web Application (.NET Core). Uncheck “Add Application Insights to project” and give your project the name “HelloWorldAzure”:
On the next screen, select “Web Application” and you’ll see in the bottom right quadrant of the screen, “Host in the cloud” is checked. This is great, because this helps us configure our cloud deployment without having to bounce between interfaces.
After clicking “OK”, the following screen loads. You’ll notice everything will preselect and fill. A unique name will be generated for your Web App Name. You can change this to whatever you want it to be as long as it is unique. Your subscription will preselect from the list, however if you have multiple subscriptions you’ll need to select the correct one. If already you already have a Resource Group and App Service Plan created in the same region, they will preselect. If not, you can select the correct one(s) or create new ones by clicking “New…”. For this example, we’ll create a new resource group and app service plan.
After I click “New…” on Resource Group, it asks for me to give the Resource Group a new name. I’ll choose HelloWorldAzureResourceGroup. After I click “New…” on App Service Plan, I get the following dialogue prepopulated with all of the options I need, so I’ll click “OK”.
Now that you see these changes to the Create App Service dialogue:
I now click the Create button and get a familiar progress dialogue:
At the completion of the progress dialog, our project is now created. To make this a real “Hello World” web app, navigate to the Index.cshtml view under Home and replace the HTML in the view with the following and save.
<h1>Hello World!</h1>
Now, it’s time to get our project deployed to Azure. First, right click on the project and click “Publish…”.
You’ll notice right away that all of the setup work took and the project is ready to publish.
As long as you don’t need to reconfigure you are safe to click Publish. After waiting a minute or so, your environment will be created in Azure and your project will be deployed. You’ll see in the bottom left corner of your Visual Studio and a browser will open with your website in it deployed on an azurewebsites.net domain.
There are many more Azure features to explore, but that summarizes the basics of getting a project published to the cloud.
AWS and Google Compute
To get a “Hello World” project ready for AWS or Google Compute, we need to bypass all of the Microsoft Azure platform integration during project creation. First start by reading the beginning of the Azure guide above, but name the project HelloWorld instead of HelloWorldAzure and when prompted to “Host in the cloud” uncheck that box.
I now click the OK button and get a familiar progress dialogue:
At the completion of the progress dialog, our project is now created. Just like in our Azure setup, to make this a real “Hello World” web app, navigate to the Index.cshtml view under Home and replace the HTML in the view with the following and save.
<h1>Hello World!</h1>
At this point, our project is now ready to deploy, but the process is different for each platform, while the overall process is going to be the same. First, we need to create a compute instance on each platform. Next, we need to configure that instance to receive our web application. Then we configure our application for deploying to that instance. Finally, we deploy to the instance by using the Publish wizard like we did in the Azure example, but our new publish profile will target our compute instance and not Azure.
AWS
The way we are going to get our application to AWS is to build an AWS EC2 instance and configure it for Web Deploy. To do this, we need to sign into our AWS Console. From here, click Services->EC2.
Click the blue “Launch Instance” button:
Scroll about halfway down the list and select:
By default, the AWS EC2 wizard will select t2.micro. This is fine for our purposes, but you can pick whichever computing power you think you’ll need here. Remember that you are building a virtual machine to run as a web server, so it needs to be able to support your application. In the future, you can tear it down and replace it, but these are considerations you’ll want to think through.
Next, you’ll need to configure your webserver. Click “Next: Configure Instance Details”.
Here you can configure many details about your web application, including number of instances and other details. For our purposes, we will leave the defaults and click “Next: Add Storage”.
Again, the defaults here are fine for our purposes, but you might want more or less storage, more volumes, different speeds, etc.. These are all things to consider. Click “Next: Add Tags”.
On this screen you can assign Tags to your EC2 instance. Tags are the way in AWS to help you identify your resources and categorize them for different purposes. For our example, click “Next: Configure Security Group”.
Finally, a screen we need to affect to get our app working. Since we are building a web server, we need to allow HTTP traffic at minimum, but we’ll also add web deploy traffic too. If you are going to configure your application for SSL/TLS or other ports and traffic, you’ll have more work to do here.
First, you’ll notice RDP is added already. This rule allows you to be able to use Remote Desktop to remotely administer your server. Leave this in there, we’ll need that access later, but change the Source to Anywhere.
Next, click “Add Rule” to add our HTTP rule. Scroll to HTTP in the drop down and that is all we need. It automatically sets up port 80, which is the default HTTP port. Again, use Source Anywhere.
For web deploy, click “Add Rule” and leave it as Custom TCP Rule. For the Port Range, pick 8172, which is what web deploy listens on. You guessed it, set the Source to Anywhere as well.
At this point, your screen should look like:
Click the blue “Review and Launch” button. On the next screen you can review what you have configured. Once you are satisfied, you can click the blue “Launch” button.
You’ll now be prompted to “Select an existing key pair or create a new key pair”. Once you’ve created a key pair, you can select it, but since this is our first time running through, we’ll “Create a new key pair”. To do so, give the key pair a name and click “Download Key Pair” to download the PEM file. You need to do this, because you won’t be able to do it later. You’ll need this file to be able to access your instance after it is created.
Once you download your PEM file and store it in a safe place, click the blue “Launch Instances” button. It’ll take a few minutes, but your instance will be created. Click the blue “View Instances” button at the bottom of the screen.
Next you’ll see your instance “Initializing” on the next screen:
Once the Status changes from “Initializing” to “2/2 checks passed”, your instance is ready to connect to and finish the configuration.
At this point, we will RDP to the server. To do this, right click on the instance and click “Connect”.
Click “Download Remote Desktop File”. The file will save by default to your downloads on your computer. Next, click “Get Password”. Now the PEM file we downloaded comes into play. You can either copy and paste the contents of the file into the next dialog or browse to the file and upload it. Either way, once you have it in the text box on the screen, click “Decrypt Password”.
Now you can get your password to use for the Administrator account. Open the RDP file and connect using this information. You’ll be prompted to accept the security certificate. Click “Yes”.
Because both AWS and Google Compute are so similar once you connect to the server to configure it, I’ll explain how to build a Google Compute instance next. You can skip to the Configure IIS headling if this doesn’t interest you.
Google Compute
To create a Google Compute instance, log in to your Google Compute Console. Click “Create Project” from the drop down at the top. You will be prompted to give your project a name. We’ll call this project “Hello World”. Google Compute will assign a project ID that is unique to this project.
Click “CREATE” and after about a minute you’ll be taken to the dashboard for your project.
Click the hamburger menu () at the top left and click:
From the Cloud Launcher, scroll to OS and click:
Then on the next screen click the blue “Launch on Compute Engine” button.
You’ll now be prompted to select your billing account.
Select it from the list and click “SET ACCOUNT”. You are now in the Google Compute Engine and your server is initializing:
Wait about another minute or so and you’ll be prompted to complete the setup. From this screen, you can change any settings you want, but for this example, check Allow HTTP traffic. If you were configuring this server for SSL/TLS you’d want to also check Allow HTTPS traffic too.
Once you’ve done this, click the blue “Create” button.
After clicking, you’ll be taken back to the VM Instances page. Creating your new server takes a few minutes. You can watch and wait on this screen.
Your sever is configured when it gets the green checkmark:
Now that our server is created, we need to open up a port in the network to allow Web Deploy. Click on the server name to take you to the edit screen. Scroll down to the network section and click the “default” link.
Scroll down to your firewall rules and click “Add firewall rule”.
Fill out your rule just like this:
When you are finished, click the blue Create button. Then click the back arrow 2 times to get you back to the VM Instances screen.
At this point, we need to configure a Windows account, so click on the server name to take you to the edit screen. Click on “Create or reset Windows password” at the top of the page.
Click “SET” and on the next screen copy the password from the dialog and click “CLOSE”.
Now that you have a windows account, you need to download the RDP file to connect to the server. To do this, click the RDP dropdown on the VM instances edit screen for your server. Then click “Download the RDP file”.
You may be prompted to login to your Google account again, but afterwards the file will download to your Downloads folder. Move this file to another location and open it. Use the username and password you created in the previous steps. You’ll be prompted to accept the security certificate. Click “Yes”.
Configure IIS
Now that you have your compute instance created in either AWS or Google Compute and you have logged into your server, you need to configure your server to host your website. First, you need to go to Server Manager and click on Local Server. From the Manage menu, select “Add Roles and Features”. This opens the Add Roles and Features Wizard.
From here, click Next, then select Role-based or feature-based installation and click Next. On the next screen, select “Select a server from the server pool” and click Next.
From this screen you’ll need to select “Web Server” then click Add Features.
After that, click Next. On the next screen select ASP.NET 4.5 under .NET Framework 4.5 Features. We’ll install .NET Core on a different step.
Click Next. Then click Next on the following screen. Then you will have the Web Server installation tree. Click Next on this screen. Then click Install on the following screen.
Wait about one minute and the installation will finish. Click Close.
Follow the wizard to install. After the installation is complete, reboot your server.
Deploy to the Cloud
Regardless of if you chose AWS or Google Compute, now we need to configure our application to deploy to our compute instance.
In Visual Studio, right click on the project name and click Publish.
This opens the Publish wizard. Select Custom and then give your publish profile a name. I’ll use CloudDeploy as mine.
Click OK and for Publish method pick Web Deploy.
For Server, put in the IP address or host name of the compute instance. For “Site name” put in Default Web Site. For “User name” put in the user name (probably Administrator) and for Password put in the password. Check “Save password” and click “Validate Connection”.
At this point you will have to validate a certificate for Web Deploy. Be sure and check “Save this certificate for future sessions of Visual Studio”.
If everything went well so far, you’ll see:
Click Next. On this screen expand “File Publish Options” and check “Remove additional files at destination”. This will be useful when publishing updates to your application so you aren’t left with remnants of previous deployments.
Now click Publish. The publish will most likely error with an error code of ERROR_CERTIFICATE_VALIDATION_FAILED. This is expected because of the untrusted certificate issued by the compute instance. In your Solution Explorer, find your publish profile file with the .pubxml file extension. Open this, and add the following on a new line before the </PropertyGroup> tag.
Save the file, close it, right click on your project and click Publish again. Now when you click the Publish button the publish will succeed. Open your IP address or server host name in your browser and you should see your application:
Voila! You’re done! You have succeeded in building a web server on your platform of choice and deploying your application to the cloud.
Conclusion
Congratulations! You are now an expert on deploying your ASP.NET Core web application to Microsoft Azure, AWS, and Google Compute. As you can see, all three systems, with the proper configuration can accept your web application from Web Deploy and deploy and run with ease.
Comparing the different platforms, there is really not very much difference in configuration between AWS and Google Compute. They both are very powerful, and give you good wizards to walk through the setup on their websites. The only downside is having to RDP to the server to configure it, but these things can be scripted and probably should be scripted using a system like Chef or Jenkins to reduce user error.
Microsoft Azure seems to be the most direct way to deploy, but you’d expect that since you are using Microsoft Visual Studio to configure and deploy the application. Azure, from it’s tight integration, doesn’t give you the server level granular control right out of the box using an App Service, like we had on the other two platforms. Azure does have this capability using Web Roles or just building a VM and installing .NET Core and Web Deploy on the server like we did on the other platforms. Likewise, there are volumes of Chef recipes or different scripts online to build and tear down AWS or Google Compute servers.
Finally, your choice should come down to cost, preference and possibly geography, although all three of these platforms have great worldwide geographical coverage. You really can’t lose, so get out and take advantage of what ASP.NET Core and the cloud have to offer in rapid development, continuous integration and scale! Happy coding!
So much can be said about character. To me, it is the number one thing I look for in another person in any walk of life, not just professionally. Character is our moral fiber. It is what makes us who we are and it provides us what we need when we are at our whit’s end.
Mark Twain said, “It is curious that physical courage should be so common in the world and moral courage so rare.” I don’t know if it is so rare or it is just not advertised. Doing the right thing, being paitent and kind, being strong when the chips are on the line, these are things that just aren’t talked about. They are exactly the types of things I look for in those around me.
I am a huge football fan. My team I root for is the Kansas City Chiefs. In 1998, after a very good run in 1997 and a 13-3 regular season record and a disappointing loss to the division rival Denver Broncos in the divisional round of the playoffs, Marty Schottenheimer was going all-in to try and win a Super Bowl. He brought in several players of questionable character, but with above average talent. This move backfired and Marty experienced his first and only losing season in his coaching career, going 7-9. Marty went against his moral fiber and brought in players purely on talent. He never did this again in his other coaching stops. He only had one other losing season.
In my own career, I have spent much of the interview process talking with the candidate. I’ve been known to take a candidate to Starbucks and buy them a coffee and just try and get to know them. During nice weather, I might take them on a walk through the trails by our offices if their shoes are up for it. This approach tells me more about the person and I also get a feel for their qualifications. I can always coach them up or teach the person a skill, but I can’t teach them to be a person I trust with the operation and execution of my future and the futures of those I work with.
In short, when looking to who to surround yourself with, look to character before talent and you’ll do much better in the long run. I’ve mentioned George Washington as one historical person I’ve looked up to as a leader. He was quoted as saying, “It is better to be alone than in bad company.” There is so much truth in this short statement.
Everyone has heard the expression, “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime,” or some variation of this. In fact, it’s been quoted, paraphrased, blogged, memed and parodied so many times, it hardly seems blog post worthy anymore. The phrase itself is a fairly novel concept. The real reward in life is learning to be self sufficient and to not be dependent on others. This is truly where happiness comes from. A new penny loses it’s shine eventually and is just a penny, but if you know how to make that one penny into many pennies, the reward is so much greater. Blah, blah, blah, etcetera, etcetera, etcetera. We all know this, right?
When I got started in IT leadership, I was so obsessed with making sure things were handled to my standard that I hoarded much of the work. I would tell myself that I was protecting my employees from having to deal with such things, but in actuality I was hindering their development. There was the occasional employee I felt so comfortable with that I would hand one particular project to them and let them own it, but for the most part I felt like I had to have my hands on everything that was going on. I felt if I didn’t do this, we would fail. I felt such ownership over every piece of software, hardware, process, or procedure that I couldn’t let it go.
I can still remember having several conversations with my boss about delegation. We talked on the subject often, and I understood that it was something I needed to get better at, but I sure didn’t know how. How do you own something, and be responsible for it’s success and yet let other people do it? This concept was hard to grasp. It was hard to grasp for him too, but we both vowed to get better at it.
I remember seeing a program about George Washington once, and on the program they talked about his leadership style. George would gather those whose opinions he valued, hear them out and make a call. I visualize them in a circle around some old 1700’s wood table made from a tree trunk, standing of course, in full dress for the period. I picture them with their wigs and hats. George would address the group with the issue, and then he would back off and let them all talk about it. He would observe and in the end I picture him clearing his throat to a silence of the crowd and just telling them how it is. George took the opinions and ideas and formulated his own idea and then that is what happened. That is my image of a good leader. The thing was, George had those around him that he trusted to provide value. How did he get to that point? Sure you could say it was because he served in the trenches with them. You could say it was because George always had the absolute best around him at all times. The truth probably is that George did his best to teach them all to fish. He made them better, so in the end he was better at his job.
To come full circle, I think we can learn something from George Washington. For us to be the absolute best version of ourselves, it is our responsibility to teach everyone around us to fish. In business, now, I think I do a much better job of this. I give everyone who works for me the permission to fail. In fact, I encourage it. I want them to try to solve problems on their own. I tell them that my door is always open to talk through what they are working on, but in the end, they are the ones working on it. I will not do it for them, even at the expense of the project or a deadline. In my early days, I had no problem sitting down at my employee’s workstation and running through the solution to whatever problem they were working on and not thinking twice about it. Each time I did this, I was setting them back days, weeks, or months in their development and maturation as a technology professional. To be the best leader I can be, it is up to me to make those around me the absolute best they can be. If I do this, in the end, we will all reap the rewards of learning to fish.
in the bottom left corner of your Visual Studio and a browser will open with your website in it deployed on an azurewebsites.net domain.
) at the top left and click:
Jake Dubin 