By: Brian Hiatt
This is the second in a series of brief articles about migrating compute, storage, and network workload from hosted, or on premise hosted, to public cloud like Amazon Web Services or Microsoft Azure.
Many of the clients and prospective clients I engage with have heard varying strategies about migration of workload to cloud from multiple sources. During the initial conversations to qualify prospective clients, one of the early questions that I get asked very early in the discussion and almost every time is:
Can we take advantage of some cloud functions like PaaS or IaaS as part of the migration?
While the safest migration to cloud is as-is, there is almost always an opportunity to take advantage of some of these services to gain some immediate benefits of the cloud while still keeping risk as low as required (see my Article 1 – Article 1-Migration to Cloud – As is or Transform).
I usually start by getting and understanding of the client’s definition of PaaS and IaaS because sometimes the perception and understanding of these acronyms varies. According to Techopedia the definitions are:
PaaS – Platform as a service (PaaS) is a concept that describes a computing platform that is rented or delivered as an integrated solution, solution stack or service through an Internet connection.
IaaS – Infrastructure as a service (IaaS) is a service model that delivers computer infrastructure on an outsourced basis to support enterprise operations. Typically, IaaS provides hardware, storage, servers and data center space or network components; it may also include software. Infrastructure as a service (IaaS) is also known as hardware as a service (HaaS).
Aha, I now see another acronym HaaS for IaaS. The Information Technology world is great at making up acronyms for everything….. so these two can be used interchangeably.
These definitions seem reasonable to me so we can go with them. Back to the topic of this article a great example of utilizing PaaS in the cloud is the database layer. From my experience, migrating relational databases like SQL Server, Postgres, and MySQL from stand-alone instances into PaaS is a quick way to get some extra bang for the buck during migration. They provide a safe way to make a transformative change during migration while keeping risk low. As with all transformations a detailed analysis of the target service is required to make sure it will meet the requirements.
A great example is when I was architecting a SQL Server database migration, I looked at Azure SQL Server PaaS. It met all the requirements except one. The service (at the time) could only handle up to 100 databases per instance. This client had over 700 databases and used cross-database joins (more on that later), so Azure SQL PaaS was not an option. I then looked at Azure Managed SQL and it could hold more than 100 databases but did not support cross-database joins, so Azure Managed SQL was not a candidate.
Summary
My point is not about the exact example above, it is about understanding the source environment and the target environment and assessing applicability as part of the design. Sometimes this is not that easy as cloud services change quite a bit and there are times when you “don’t know what you don’t know”. One of my favorite sayings is; “If I had a nickel for every time I had to learn something once, I would be rich”. Surround you with the best team you can and do not be paralyzed. Pilot projects help, but sometimes you have to fall down to get back up.
About the Author
Brian Hiatt is an expert leader at safe and successful data center workload migration to private, virtual private, and public clouds. His experience includes large scale global data center migrations as well as small to medium size business workload migrations. He can be reached at or https://brianhiatt.com