The power of Platform as a Service lies in its ability to bolster profitability and productivity. Microsoft Azure’s PaaS and App Service offerings, in particular, give organizations a wealth of options that can help make enterprise IT more competitive. In an earlier blog, I explained the three P’s of PaaS: people, process and platform. In this blog, I’ll focus on the people.

Operations vs. Development

There are typically a couple different viewpoints that have an impact on driving IT value in an organization, generally referred to as “operations” and “development.” The operations team is responsible for running the day-to-day activities — keeping the lights on. Operations works to review currently supported versions of processes, operating systems and applications. This includes identifying which hardware and software may be depreciated or decommissioned, and then disposing of the hardware.

Development creates or updates code for critical internal or external business applications. Application development teams generally receive a request from various revenue-generating and revenue-supporting departments (and yes, the IT department can be one of those departments). One of the unique experiences I witnessed frequently while working in IT for a retail company was that the department asking for the change had typically already justified the change.

Application development estimated the cost to complete the work and presented the data to the department’s management for them to share with their director. Unfortunately, there were interdependencies that affected multiple systems and applications; therefore, other departments needed to get involved.

Getting Started with App Service

There are several guidelines that organizations should follow prior to adopting any cloud app service. Azure App Service holds a lot of value if implemented for the right reasons by both operations and development. Some of the recommended guidelines include the following:

  • Seek “why” first. What problem are you trying to solve? This will help determine the right tools and platform to use.
  • Don’t develop a business case (the business case may cost more than failing fast). Allow for some experimentation in small increments to prove out concepts and gather customer feedback.
  • Crawl, walk, run and then sprint to get organized when setting priorities. Set attainable expectations that can be accomplished in short amounts of time.
  • Stage and use quality assurance measures (from simple to complex) to validate the why. Track accomplishments and act of feedback.

 

Table 1: App Services for Everyone


Click the table to view a larger version. (Source for CAPEX definition)

 

Why Consider Platform as a Service?

As the curtain is pulled back on application workloads, PaaS provides flexibility, recoverability and security essentially out of the box.

Service Options Available

  • VM
  • Container Instances
  • Batch
  • Cloud Services
  • Mobile App
  • Kubernetes Service (AKS)
  • Web App for Containers
  • Service Fabric
  • Web App
  • Function App (Functions)

Azure Web Apps provides a highly scalable, self-patching web hosting service.

  1. Create a Web App
  2. Zip up your PHP project
  3. SFTP into Web App
  4. Enable Autoscaling

 

Diagram 1: Application Workloads


SOURCE: Microsoft

 

Define Your Hybrid Cloud Approach

Hybrid cloud can support existing and new platform services, empowering the entire organization (e.g., application development and shadow IT). Enabling PaaS as an option, an application lifecycle strategy allows companies to quickly identify increased profitability and/or productivity or fail, learn and move forward to the next experiment. In the table below are some common clichés that come up when implementing new approaches to IT. It is well worth considering approaching the open-ended possibilities of Azure with a different mindset.

 

Table 2: Eliminate Clichés

Traditional (Infrastructure/Control) Hybrid Cloud (Business/Flexible)
The problem with that is

This is the way we have always done it

We know; it’s minimal risk

Batch processing window is shrinking; provision more hardware

Capacity planning meetings

Requirements for Monolithic

We cannot fail

Let’s try this

What if we did it this way

We don’t know everything; risk of failure is excepted

Triggered events can allow people, data and systems to communicate when/where required

Add this feature/capability tomorrow…scale as needed

decoupled (it can work; think PowerApps/Flow = Logic apps/functions)

It’s okay to fail; learn, move forward

Fail fast; build for resiliency

 

Make sure to check back — in my next blog post, I’ll cover the process to modernize applications.

Learn more about CDW’s partnership with Microsoft to deliver Azure’s benefits to your organization.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>