Continuing my previous post on Application Modernization, here I talk about some approaches that work, and some that don’t.
tl;dr: Take your time moving to the cloud, and take the time to split the migration into stages – so that you can start taking advantage of the cloud using fairly simple architecture, then, as you become more comfortable with the platform, start introducing more PaaS and SaaS components
What you shouldn’t do
Basically – lift and shift without understanding:
- what the performance characteristics are in the current environment – and if they’re satisfactory
- what the target environment’s performance is like
- what your current architecture’s points of failure are
Some sales material would have you select the available VM size that Azure offers that most-closely-resembles the VMs on premises, upload your virtual hard disk, and – BAM! – you’re cloudified. Let’s say you have an application that requires a few components – a web site, with SQL behind it, and some executable code that runs on one of those servers. Let’s assume that the application requires a single web server and single application server. If you take this architecture to a public cloud, you won’t get an SLA – neither Amazon nor Azure offer single-instance SLAs. If that’s not enough to scare you off, the performance you get in Azure is significantly different than the performance in a datacenter. Whether it’s the network, disk, CPU, or something else – if you don’t test it, you’ll likely be unpleasantly surprised when the load hits.
What you should do
Modernize your application! Gartner describes Application Modernization as the following:
Application modernization services address the migration of legacy to new applications or platforms, including the integration of new functionality to provide the latest functions to the business. Modernization options include re-platforming, re-hosting, recoding, rearchitecting, re-engineering, interoperability, replacement and retirement, as well as changes to the application architecture to clarify which option should be selected.
I see application readiness as falling into three stages. This may be viewed as oversimplification, but I think it covers things at a broad level. If there’s better terminology, feel free to mention it in the comments.
- Not cloud-ready – the application can probably run in the cloud, but it’s not going to run well, or it may not be covered by your cloud provider’s SLA.
- Cloud Ready – the application runs well in the cloud, and and meets your SLA . It probably makes use of PaaS or SaaS in some components, and there is a roadmap to being cloud-native.
- Cloud Native – the application runs entirely in PaaS and SaaS. It is highly available and runs well.
Take your time moving to the cloud, and take the time to split the migration into stages – so that you can start taking advantage of the cloud using fairly simple architecture, then, as you become more comfortable with the platform, start introducing more PaaS and SaaS components.
When planning a move to Azure, look carefully at your application architecture. It’s easy enough to count CPUs, RAM, and storage consumed, but the less-easily-measured components are vital. Observe the network, storage, and compute utilization; look for spikes, and make sure that the infrastructure in your public cloud is comparable – your CPU may be older, and less performant, and you can eliminate a set of cores and save on licensing. Look out for storage bottlenecks in particular – Azure’s standard storage maxes out at 500 IOPS per disk, so you may need to stripe multiple disks together using Storage Spaces, or consider premium storage.
Next, identify what platform-native tooling there is that can run your application. As I mentioned earlier, this is the most cost-effective way to run your application in the cloud. In Azure, for example, Azure SQL or Azure Web Apps are simple to use and are often a quick migration target with minimal effort involved. Look at each component of your application and find out how much effort it will take to move it to a native service – not everything needs to move at once, of course, but it might be easier than you think.
Following that, identify where you have single points of failure, if you subtract the underlying infrastructure (hosts, network, power, etc). Find a way to eliminate these single points of failure, using the platform tools to the greatest extent possible – find a HA solution for SQL, load-balance your VMs, and use platform storage to provide a queue – Azure Storage is a great tool to provide a reliable quorum for multiple worker applications. This may require some refactoring.
Once you have an design that you think works – consisting of resilient IaaS, some PaaS or Saas, and appropriate resourcing, test your application. Azure has a good load testing toolkit, but you can use whatever tooling you’re comfortable with. Load testing is vital to assessing whether your application is going to run well in the cloud. If you’ve done a good job assessing your application’s resource needs, you will find that it passes with flying colours. Other times, you may find unexpected bottlenecks that need to be addressed. Making the load test as close to production traffic is really important to make sure that it’s going to do what you expect under load. I’ve seen this occur too many times – it worked in theory, with 50 users on the site, but when the Internet saw it and there were 50,000 sessions, it fell over.
Plan a backup – this is easy to overlook as you’re getting excited about getting your stuff running in the cloud. By now, you’ve got a pretty good understanding of your application’s architecture. Plan for disaster recovery, as well as data backup – you’re in the cloud, but natural disasters still occur, and it’s quite possible that you’re going to be attacked in some way, so data flexibility.
Before cutting over, have a fall-back plan. It’s not too hard to plan the fail-back of an application without a lot writes (like a website or reporting service) but it can be more challenging to fall-back if there’s live data writing somewhere (think an API backend to your mobile application). In these events, however, you can usually use a very similar process to fall back as you did to move forward.
Finally, pay attention to new features that are released on your cloud platform of choice, and make plans to further integrate your application with the offerings. You may have an application that runs quite well in Azure VMs, but over time, you may be able to save costs by moving more of it to various PaaS and SaaS solutions – your email server can be shut down and the functionality moved to a SaaS provider; a file server could be moved to Azure Files, Blob, or Queue storage (as appropriate), and your databases could be migrated to a PaaS offering. find ways to automate and streamline the deployment of the application, and find ways to make it scale out more effectively, more quickly, and fail gracefully. Monitor your resource consumption and resize components as needed – you can always start small and grow, or start big and shrink!
In Conclusion
My goal with this post is to communicate that when you’re planning a migration to a new platform, there’s certain planning that needs to go into migrating applications. I hope it was helpful to you.
There’s a lot of good cloud architecture reading out there, and I’m not going to repeat it all here – this blog post is already too long. Understanding why ChaosMonkey exists is key to designing for the cloud. Fundamentally, “assume failure”. Your application needs to be super-resilient, support high availability, and handle fault tolerance gracefully. The software doesn’t just need a good high availability story either – it should be something that’s supported by the platform you’re running on, and preferably supported by the vendor. This immediately excludes applications that rely on, for example, components of Server 2003 that are now deprecated.
Beyond “assume failure” at the infrastructure level, a DevOps culture is really important to succeeding in today’s IT environment. I highly recommend the following material for further reading:
Additionally, the MSDN Cloud Design Patterns site is excellent.
I also want to stress the fact that the field of information technology is a constantly-changing field. The application architecture that works in Azure generally works in your datacenter – and probably will work in your datacenter much more efficiently than a 10-year-old architecture. Whether or not you’re planning a move to the cloud, using modern tooling and design practices will save you time and money in the long term.