Share →
Buffer

As DevOps continues to grow in everyday practice, companies are faced with a number of new and old constraints that slow down the development cycle.

Some of these constraints are operational reaction time, “safe to fail” development platforms, standardized automation, manual error-prone workflows and operational costs which closely match demand and true capacity.

Working with Azure, I have discovered that it is more than a cloud service infrastructure. It addresses the constraints mentioned above and improves upon the development cycle.

As you might know from my other blog posts, I’m a big fan of automation and the reduction of manual processes. With Azure, I have found a fantastic platform for standardizing my methods of automating everything as well as creating a “configuration as code” type of practice for both the development and operation teams.

Using PowerShell, Azure cmdlet and DSC, I can now standardize the environment configuration. Why is this a big deal? Well, for me, I like a workflow that is understandable and simple. If I am trying to use other scripting languages and practices (batch file, python, ruby etc…) the workflow becomes muddled and complex. Although there are times when you may need to use other tools and languages, Azure’s standardized set of tools helps reduce complexity and confusion which can translate into reduced cost.

I also discovered how easy it is to create an application and then deploy it to Azure as a Proof of Concept (POC).  This ability flows into the Agile and Lean best practices approach of “safe-to-fail” experiments, resulting in fast feedback loops, data gathering and analysis, a period of learning, and then the opportunity to move forward with new information.

Proof of Concept flow:

POC

I have heard from many customers that they have to wait several days, or even weeks, to get a POC Virtual machine request processed – often with no guarantees that the server will have all the application components needed.  That type of delay doesn’t contribute to fast feedback!

Using my MSDN Azure credits (which all MSDN subscribers have) I can easily provision and host my POC site for a Friday show-and-tell. I can use the Azure automation features and create a reusable DSC script to install the core application components. Once I have that basic script, I can reuse it on other POC environments that have the same basic requirements. I can even use it to build out other environments once the POC has been approved.

This flexibility provides me with a “safe-to-fail” approach. I did not have to make a big investment or engage other team members for my POC site, which might not even get approved. It also allows me to highlight my demo in a real environment, which can give the POC a better chance of success.

As I dove deeper into Azure, I also discovered the infrastructure and cost benefits.  In my time within operations, cost and scalability were key to success. The challenge of keeping the infrastructure updated, secured and available was a huge effort and costly undertaking. Once you begin to account for the other environments like Staging, UAT, QA, Dev and Disaster Recovery the effort and cost dramatically increased.

Azure reduces the cost and effort by empowering the team to manage their own requirements and infrastructure.  Do I really care if the development team blows up the server?  In the old world, yes, because I would have to rebuild it and go back and forth with the team to determine what was the last set of configurations and applications the team put on the machine and environment.

In the new world of Azure, I would use the scripts that the development team had updated to re-create the current machine and environment.

In-addition, within Azure, the development team can perform the actions on their own, reducing the cost to the service-desk.

Another side-benefit is that a quick-to-provisioned environment allows the development team to quickly self-adjust when their applications and solutions blow up their environments.  Teams can handle the problem early on the in the development process before moving to more costly environments.

Finally, I have discovered the value of Azure when it comes to managing variable server capacity needs and stress loads for an application.  For example, if your application is a seasonal application, then it only makes sense to utilize what you need. Why pay for servers that only get used during seasonal peak time?

In todays software market, customer demands and faster delivery cycle are always increasing. Your infrastructure and capacity to adjust quickly to the evolving needs of your customers will define your business success.

For the companies that are stuck in the old ways of operating, there will be squandered opportunities and lost time related to the inability to obtain fast feedback, delays inherent in “command and control” procedures where teams must wait for environments to be provisioned and the lack of automated processes.

Companies, which can move to a self-service and automated model, will find themselves more easily able to adapt to the changing business climate, able to provide greater value to their customers and see a cost return in team efficiency.

This is why I believe Azure is more than just infrastructure.

Print Friendly
Tagged with →