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.
It’s 2017 and it’s official: Government agencies want to move to the cloud. But they are often unprepared for the transition, or stuck in the middle of a confusing process. So this week, AIS and Microsoft kicked off the new year with a terrific AzureGov Meetup full of valuable information, training resources and demos on exactly where and how to start a successful government cloud journey.
With the explosion of new sensors and service offerings producing geospatial telemetry, there’s an ever-increasing need for tools to gain business insights from this data. One of the premier tools for this in the geospatial domain is GeoServer.
Fully open-source and free to use, GeoServer provides Open Geospatial Consortium (OGC) web service interfaces to rendering images or complete metadata in most common geospatial interchange formats. In a consulting capacity, Applied Information Sciences has leveraged Geoserver with great success, allowing us to deploy a complete software stack in minutes instead days or weeks. In this post I’ll give an overview of the DevOps practices we’ve applied to enable this capability, as well as a brief overview of the supporting technologies. Read More…