When Is IaaS Right for a Government Agency?
Traditionally, IaaS has been heavily used for shifting operations — taking an existing application running on-premises or in a colocation center and moving it to IaaS. For IT teams, IaaS can have a steep learning curve; treat IaaS as if it’s a replacement for an existing data center, and there’s a danger of unpredictable costs and unsatisfactory performance. IaaS providers charge for resources consumed, which means inefficient applications or processes that operate wastefully suddenly become problems for both budget and performance.
IT teams may be able to get out of the systems and data center business, but they replace that task with a close attention to performance and system management that wasn’t really an issue with government-owned hardware. Unlike SaaS, IaaS requires swapping job titles. Someone must be responsible for:
- Tight control on provisioning
- Data storage and tier management
- System performance management
- Watching costs
- Delivering training on IaaS management
It also requires understanding how old habits in security and application deployment can have huge and disproportionate effects in an IaaS environment.
The payoff from shifting to IaaS is huge, but getting maximum performance and budget benefits requires careful and continuous management on the agency side. Failing to take account of these new skills and continuing management costs is the single biggest factor that causes IaaS projects to collapse or fail to meet their goals.
DISCOVER: 3 factors to consider when optimizing a multicloud environment.
What Is PaaS?
Platform as a Service started out halfway between SaaS and IaaS. It has since morphed into an exciting area for application developers to use its various offerings as force multipliers to speed development and deployment. Along the way, the acronym lost its original meaning: PaaS can mean any type of platform and virtually any kind of service delivered by cloud-based providers. Amazon, Microsoft and Google each offer more than 100 different services that are arguably PaaS: databases, Big Data storage, email, SMS delivery and forwarding, queueing services, and artificial intelligence learning tools.
Generally, these new PaaS or extended infrastructure services are most relevant when paired with traditional IaaS offerings and a government agency’s application development and deployment.
In some cases, such as with cloud-based SQL or NoSQL databases, the “lift-and-shift” of an existing application from an agency data center to the cloud is simplified and even performance-enhanced by replacing government-owned database servers with a cloud provider’s database service. This can be a nearly painless operation, especially in IT shops that already treat databases as a service offered by the IT team to their own developers and application owners. Other easily isolated services, such as SMTP mail queueing or DNS service, are also ideal places to explore replacing on-premises or colocation-based servers with cloud-based services.
When Is PaaS Right for a Government Agency?
For most agencies, using other types of PaaS services is most appropriate when developing an agency’s own applications. When applications are redeveloped to take advantage of these new services, they gain better scalability and performance from a cloud-focused architecture. A second win comes from the modern design and huge support resources of cloud infrastructure providers. With a menu of dozens of cloud services to use in the development process, project teams often discover large chunks of traditional projects can be replaced by services that cost virtually nothing to run and, more important, make it easy to take advantage of the dynamic scale-up and scale-down built into cloud environments.
Of course, there is a cost for using PaaS, both literal and figurative. These high-end services, like their IaaS siblings, are charged based on usage. Sometimes, costs will go down with the shift from on-premises to cloud; a database, DNS or email service may be cheaper to use than provisioning servers, paying license fees and managing the underlying software.
The other important cost is in vendor lock-in. For very abstracted services, this may be minimal, but when an application depends on a specific toolset delivered by a particular cloud vendor, this makes shifting the application to a different cloud service expensive and time-consuming. It’s not same argument as Unix versus Windows: There’s a big difference between something sitting in a government-owned data center that may be unsupported and a cloud service provider going out of business, offering degraded services or delivering a huge price hike. That’s not a reason to avoid these in-between services, but it is something that each IT team should consider as part of its own risk analysis.
