Getting Started with Azure App Service and Platform as a Service
These Azure-based options can drive profits and productivity when leveraged properly.
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.
- Create a Web App
- Zip up your PHP project
- SFTP into Web App
- 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.
