Cloud service offerings can feel abstract and confusing. Parsing the differences between Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) can make all the difference in understanding the best fit for your situation. Where IaaS ends and PaaS starts is not always clear cut. In my experience, by focusing on the three P’s — people, process and platform — customers get a clear idea as to what best suits their needs.
How many people does it take to ready IaaS for developers, testers, quality assurance and production? There’s the procurement of hardware and software, submission of request for users, networking, storage, sizing of hardware (virtual machine), memory, disk, operating system, patching level… what did I miss? Oh yeah, the developer (usually a development team or manager) needs to provide the specifications and installation instructions, along with the configuration settings. Let’s get the team together aligning with hybrid cloud architecture:
- Project Management Office
- Quality Assurance/Quality Control
- Risk Management
- Strategic Planning
- End-User Support
- Network Team
- Storage Team
- Server Team
- Data Team
- Security Team
- Development Team
- Line of Business Team(s)
How many people does it take to ready PaaS for developers, testers, quality assurance and production? Hmm… PaaS is much lighter, so it does not require the control and overhead of infrastructure. Let’s go with the following team:
- Enterprise Architect
- Development Team
- Line of Business Team(s)
- Hybrid Cloud Operations Team
As with any solution, it’s important to map out the implementation strategy. Whether using IaaS or PaaS, the enterprise architect would be providing a “best practices” approach to the solution. Agree or disagree, a decoupled component design provides flexibility with scale, maintainability, support and empowering change.
OK. Is it really that easy? Not really — like with IaaS, PaaS requires planning. However, the plan can be much lighter with fewer team members.
Azure provides a platform to complete various workloads. Traditional workloads require power, metal and cooling to support various infrastructure servers. Infrastructure servers can be delivered using Azure IaaS. Common applications require various underlying requirements, which vary in utilization. For example, an application may require resources during a heavy sales day such as Black Friday, or an application may require zero resources during changeover between workloads.
This table provides various mappings from traditional workloads to modern workloads as they relate to capabilities in Azure.
|Azure IaaS Basics||Azure PaaS/Serverless Basics|
|VMware Hosts (Virtual Machines)||Managed by Microsoft|
|Windows Server 2016
Java Runtime Engine
|Internet Information Services||Web Services|
|Application Services||Web Jobs (on Trigger)
Web Jobs (Continuously)
|Scheduled Jobs (Script or Program)||Web Jobs (Scheduled)|
|SQL Server Database||Azure SQL Database|
|Application Session State
(if Application Is Stateful)
|Azure Redis Cache
(Ideally Create Stateless Applications)
Throughout my experience in various job roles — which have included business application manager, enterprise architect and build master — requesting infrastructure was always a challenge. I was asked to justify the capital investment; I had to submit a request to the infrastructure team, which used a form that was overwhelming. Overall, the time from minimal viable product to production took several months. Let’s look at the pros and cons of PaaS.
- Forces a user-centric mind-set, provides greater impact to organization objectives and goals
- Enables a developer-first mind-set (with more development teams than infrastructure teams, solutions delivery speeds up)
- The ability to allow shadow IT with controls (or citizen developer)
- Fully managed underlying infrastructure
- Dynamic scaling up and down based on traffic times (such as Black Friday, nights, weekends, weekdays)
- No virtual machine management (patching, sizing, current state, one-off configurations)
- Reduced total technical debt (predicable costs over time)
- Requires mind-set changes across the entire organization
- Less managed; sometimes leaves users unsure of process
- Implementation mapping decisions, trade-offs and considerations
- Greater shared responsibilities among cloud provider (Microsoft), development and monitoring/support
- Developer’s component implementation of smaller units of work (minimum viable product vs. requirements)
- Fixed capital expenditure ability to amortize or depreciate
As Azure’s ecosystem continues to grow market share, more and more organizations are seeking growth and potential savings. Understanding how to differentiate between situations that would benefit from Azure’s ecosystem of services is valuable to finding the right fit. Start with the three P’s, and reach out to your account manager to get connected with a hybrid solution architect for further guidance.