Steve Michelotti and I presented a session on AzureGov last week at Microsoft Ignite 2017 in Orlando. It focused on demonstrating the innovative capabilities in AzureGov that are specifically designed to help government agencies with their mission. We dedicated about 80% of the session to live demos.
Steve started out with a brief description of AzureGov and how to get started…along with some recent news announcements, including API Management and Key Vault. Steve then quickly transitioned into demos related to Cognitive Services, Azure IOT and Power BI. I conducted two demos related to Cosmos DB Graph database and the CNTK deep learning algorithm on an N Series GPU machine.
Please watch the video below and let us know if you have any questions.
As part of AIS Managed Services, we provide proactive management and reactive support of infrastructure and applications at a predictable monthly cost. Recently, during a routine infrastructure health check, we noticed that Azure was failing to take backups for a particular virtual machine. Why?
The client is a medium-sized outdoor equipment vendor. For this enterprise customer, we have configured Azure Recovery Services to take a daily backup of all the virtual machines in the production environment. The environment is set up with four domain controllers. Two of them are hosted in Azure while the other two are hosted on-premises. All domain controllers are running Windows Server 2008 R2. Both domain controllers hosted in Azure have 120GB System Drives attached to them, with only Active Directory Domain Services and DNS Server roles present on the server. Read More…
Previously in another blog post, I laid out a quick summary of Continuous Integration (CI) and Continuous Delivery (CD) in Visual Studio Team Services (VSTS). Today we’re going to expand a bit on those DevOps processes to better suit your (or your clients’!) needs.
With CI and CD, a build agent is required—that is, a place where your code is sent to be compiled and then subsequently deployed. By default, VSTS gives you the option to use a hosted agent. This is an entirely a cloud solution; you can just choose one of the hosted agents to build and deploy your code and you’re all set. But there are a couple of drawbacks with this…
How do you get better uptime than the cloud? Two clouds!
AIS’ CTO Vishwas Lele stopped by the .NET Rocks podcast this week to talk about our experiences building ultra-reliable applications, both on-premises and in the cloud.
The discussion digs into the decisions around reliability – it’s easy to want it, but will you pay for it? It’s important to calculate the cost of downtime, as that helps set the budget for what it takes to stay up. And that leads to a conversation about how you build highly reliable software – it can’t just come from the infrastructure, there is code involved as well! And the next question is – how do you make your app work in two different clouds?
Another month, another great #AzureGovMeetup in Washington, D.C. Last week’s Meetup was all about the hybrid cloud (storing data both on-premises and in the cloud), a critical part of government IT transformation.
Keeping up with ever-changing IT environments is a challenge for most organizations, so we discussed how agencies can gain visibility and control across their hybrid cloud, along with choosing the right tools, management and recovery, and improving security and protection. The Meetup also featured updates on the latest technologies and upcoming plans from the recent Microsoft Build 2017 conference.
AIS’ CTO and Azure MVP Vishwas Lele and Cloud Architect Harin Sandhoo both gave great presentations, along with Microsoft Cloud Solution Architect, Brian Harrison. In case you missed it (or want to watch again), you can watch the entire Meetup right here: Read More…
After you’ve created your template, you can use PowerShell to kick off the deployment process. PowerShell is a great tool with a ton of features to help automate Azure processes. In order to deploy Azure ARM Templates with PowerShell, you will need to install the Azure PowerShell cmdlets. You can do this by simply running the command Install-Module AzureRM inside a PowerShell session.
Check out this link for more information on installing Azure PowerShell cmdlets. PowerShell works best on a Windows platform, although there is a version now out for Mac that you can check out here. You can also use Azure CLI to do the same thing. PowerShell and Azure CLI are quick and easy ways to create resources without using the Portal. I still stick with PowerShell, even though I primarily use a Mac computer for development work. (I’ll talk more about this in the next section.) Read More…
Early in my web development career, I always tried to avoid deployment work. It made me uneasy to watch other developers constantly bang their heads against their desks, frustrated with getting our app deployed to whatever cloud service we were using at the time. Deployment work became the “short straw” assignment because it was always a long, unpredictable and thankless task. It wasn’t until I advanced in my tech career that I realized why I felt this way.
My experience with deployment activities, up to this point, always involved a manual process. I thought that the time it took to set up an automated deployment mechanism was a lot of unnecessary overhead – I’d much rather spend my time developing the actual application and spend just a few hours every so often on a manual deployment process when I was ready. However, as I got to work with more and more experienced developers, I began to understand that a manual deployment process is slow, unreliable, unrepeatable, and rarely ever consistent across environments. A manual deployment process also requires detailed documentation that can be hard to follow and in constant need of updating.
As a result, the deployment process becomes this mysterious beast that only a few experts on your development team can tame. This will ultimately isolate the members of your development team, who could be spending more time working on features or fixing bugs related to your application or software. Although there is some initial overhead involved when creating a fully automated deployment pipeline, subsequent deployments of the same infrastructure can be done in a matter of seconds. And since validation is also baked into the automated process, your developers will only have to devote time to application deployment if something fails or goes wrong.
This three-part blog series will serve to provide a general set of instructions on how to build an automated deployment pipeline using Azure cloud services and Octopus Deploy, a user-friendly automation tool that integrates well with Azure. It might not detail out every step you need, but it will point you in the right direction, and show you the value of utilizing automated deployment mechanisms. Let’s get started. Read More…
The recent #AWS and #Azure outages over the past two weeks are a good reminder of how seemingly simple problems (failure of power source or incorrect script parameter) can have a wide impact on application availability.
Look, the cloud debate is largely over and customers (commercial, government agencies, and startups) are moving the majority of their systems to the cloud. These recent outages are not going to slow that momentum down.
That said, all the talk of 3-4-5 9s of availability and financial-backed SLAs has lulled many customers into expecting a utility-grade availability for their cloud-hosted applications out of the box. This expectation is unrealistic given the complexity of the ever-growing moving parts in a connected global infrastructure, dependence on third-party applications, multi-tenancy, commodity hardware, transient faults due to a shared infrastructure, and so on.
Unfortunately, we cannot eliminate such cloud failures. So what can we do to protect our apps from failures? The answer is to conduct a systematic analysis of the different failure modes, and have a recovery action for each failure type. This is exactly the technique (FMEA) that other engineering disciplines (like civil engineering) have used to deal with failure planning. FMEA is a systematic, proactive method for evaluating a process to identify where and how it might fail and to assess the relative impact of different failures, in order to identify the parts of the process that are most in need of change. Read More…
Lift & Shift is an approach to migrating a legacy business application hosted in an on-premises data center environment to one hosted in the cloud. The goal is to move the application “as-is,” with little to no changes to the business functions performed by the application. One common lift and shift scenario is the migration of applications that were not originally developed for distributed cloud environments, but once moved, can take advantage of some of the benefits of cloud computing, such as increased availability and/or reduced total cost of operations (TCO).
This blog details some important considerations and challenges associated with the lift and shift method, based on our real-world experiences moving both custom and packaged (commercial) legacy applications to Microsoft Azure. Read More…
Transient exception handling and retry logic are considered an important defensive programming practice, especially in the public cloud. But how good is your exception handling? Unfortunately, it’s not always easy to simulate transient exceptions.