| Pro Database Migration to Azure |
Page 1 of 3 Author: Kevin Kline et al This book aims to give you a holistic approach to migrating on-premise databases to Azure, how does it fare?
The authors are experienced industry veterans, aiming to pass on their hard-won wisdom and experience, including their successes and failures. The book is aimed at IT leadership, IT decision makers, project owners, managers, enterprise, and application architects. It should also prove useful for enterprise DBAs and consultants. Below is a chapter-by-chapter exploration of the topics covered. Chapter 1: The Azure SQL Data Platform Although running applications in the cloud is becoming standard, it can still be a problem, especially for people familiar with just on-premise systems. The book opens with a look at the core Azure services and concepts, including: compute, network, storage, accounts, subscriptions, resource groups, tags, regions, and availability zones. These are all background features that you’ll use frequently in cloud work. Some advantages of migrating to the cloud are discussed (e.g. heightened security), before looking at cloud architecture, covering IaaS, PaaS, SaaS, Stack, and landing zone. Next, five disciplines of cloud governance are explained, there are based on Microsoft’s Cloud Adoption Framework, being: cost management, security baseline, resource consistency, identity baseline, and deployment acceleration – there are chapter links for each item. There’s an interesting section on some of the bigger mistakes that have been made during cloud migration, with the aim of not repeating them. These include:
In each case, the problem is discussed, and some solutions proposed. Next, the benefits of cloud computing are discussed, these include:
There’s an interesting insight in a recent report, that said in the last 2 years, 80% of respondents had failed migrations, with systems were moved back to on-premise. Various causes and solutions were discussed, including: costs, controls (devs with sa permission in the cloud can start expensive services), performance (often an afterthought!), and security (tools exist, but need implementing). Next, the importance of pilot projects is discussed. Ideally, this would be a balance of risks versus improvements. The project should not be a critical one, involve 4-6 staff, be well-defined, a few months of duration for learning, and have a champion to support it. Lastly, the authors stress the importance of including an enterprise architect with cloud experience in team. You wouldn’t build a skyscraper without an architect, and similarly, an architecture can see the overall bigger picture of the components, discovery, access, implementation etc. Overall, much of this is chapter is background material that the rest of the book builds upon. Sometimes, terms are introduced without adequate definitions (these are often given later), this may be ok, since the book assumes some experience (but doesn’t really say how much). Generally, the book is conversational in nature, again this may be ok, since it seems people learn from stories. Cliches abound, which is perhaps to be expected with older IT people. The book contains helpful discussions, diagrams, links, summary, and plenty of incidental tips and advice. These traits apply to the whole book.
Chapter 2: Planning Considerations and Analysis Planning can help identify and reduce risks. There are various planning frameworks, but all should cover: scope, assets, testing, validation, migration, postmigration, and postmortem. The chapter opens with a look at planning frameworks, the authors suggest Waterfall and Kanban often combine well together, and for larger projects Waterfall and Scrum. Here, Waterfall is used to control the phases rather than order the work. Various phases of planning are discussed, including:
Next, the importance of adopting a cloud mindset is highlighted. Typically, on-premise systems are overprovisioned, to cater for future growth. This is not needed on a cloud system, where resources can quickly and easily be increased and decreased. On-premiss servers often have CPU usage levels of around 30%, whereas you’d expect nearer 80% for cloud servers. There’s a helpful section on analysing workloads, involving recording performance metrics, and correctness of results. Where possible, automation should be used. High Availability (HA) and Disaster Recovery (DR) are of paramount importance to businesses. Various Azure offerings are discussed. Azure PaaS offers in-built HA/DR capabilities, here you give up controls and trust the failover to Microsoft. With IaaS, typically you set up HA/DR yourself. The chapter ends with a discussion on the importance of a migration dry run. There’s a very useful diagram of the alternatives when migrating from on-premise to Azure, covering backup/restore, Azure Site Recovery, transaction replication, DMS, DMA, BACPAC, etc. Strangely, it didn’t mention the easiest option I’ve seen, a menu option in SSMS (ok, it uses BACPAC behind the scenes). The chapter contains lots of useful information, with some very helpful diagrams and a valuable ‘outputs’ section. In some areas, it feels like plenty of words are being used, but little is being said (e.g. planning section). Maybe it’s because I prefer key points/lists etc rather than a chatty/story style. If you already understand the basics underlying Azure, and the different Azure database options, you can understand the technical info, but it feels muddled, fragmented (talking about Managed Instance in one place and serverless in another). It will feel worse if you’re trying to learn these technologies from this book. Additionally, some important information is given in passing, rather than stressing its importance. Chapter 3: Budgeting for an Azure Migration One of the main reasons given to moving systems to the cloud is the perceived cost savings. This may be possible, but everyone should be aware of the ease at which costs can accumulate. This chapter look at managing your cloud costs, while the next chapter looks at the importance of sticking to a budget. The chapter opens with a look at why costs are important. High costs can block a potential migration project, additionally it’s known that a large number of migrated systems are moved from the cloud back to on-premise (cloud repatriation) when the cost savings do not materialise. Some systems are cheaper to run on-premise. Costs should be evaluated throughout the project, and it’s noted that most architectural decisions have a cost associated with them. Generally, costings are not an interesting subject for technical staff, but it should be remembered, costings affect the project’s viability, and your salary! There’s a brief section examining if the cloud will save you money, and it can, but not always. Next, the importance of building a budget is examined, and while there are tools that can help, everyone’s project is slightly different and it’s easy to get overwhelmed with all the potential resources/options. Third parties and Microsoft can help give advice and direction – the authors state this can be costly, but is typically money well spent while getting your team up to speed. Next, there’s a look at the authors’ methodology for building a budget, called FLAT:
Costing tools allow you to make a reasonable guess at costs, tools discussed include:
The cost of Egress is noted (ingress is free, but egress will cost). Various factors that impact it are discussed, including: regions, amounts of data, use of ExpressRoute. Similarly, networking costs are highlighted, vnets are free but many network components have a cost. There’s a very useful section on ways to reduce your costs, which can have a significant impact on a project’s success. Savings discussed include:
The chapter ends with a look at building evidence to support your Return on Investment (ROI). Migrating from on-premise to the cloud moves costs from CapEx to OpEx, this is often good for reducing the tax bill since OpEx is fully deductible in the current year - a major selling point. System changes are often much quicker in the cloud (e.g. adding more CPUs can be done in a few minutes). The cloud often gives more functionality, with more cutting-edge technology, allowing better solutions. Other ROI selling points include: security, scalability, easier admin, and better HA/DR. This chapter made an interesting read. Lots of useful idea for estimating costs and reducing costs. Chapter 4: Azure Cost Management The previous chapter was mostly concerned about costs, which leads naturally to looking at how costs can be managed throughout the cloud journey. The major tool for this is the Azure Cost Management and Billing in the Azure Portal, this allows you to monitor your spending using reports, alerts, and automatic actions. Here you can pay bills, manage access to costs, analyse costs, create budgets and alerts, etc. The rest of the chapter explores this functionality in more detail, including:
Again, there’s a useful section on how to reduce costs, overlapping with the previous chapter. Additionally, there’s a look at underused resources that could use a lower resource tier, proactive performance tuning, looking for and removing waste, look for unknown charges, create governance policies, create useful alerts, and looking for anomalies This was another useful chapter, lots of helpful advice on how to reduce your costs, from industry veterans that have seen it all before. Chapter 5: Service and Systems Monitoring Here we examine some best practices for monitoring Microsoft data platforms. The chapter opens with a look at the purpose of monitoring tools i.e. provide a view of the health and availability of systems. This includes incidents, event notifications, responses, capacity planning, and alerting. There’s a useful section on what to collect (metrics, logs, traces). Different weightings can be given to different conditions, allowing you to proactively respond to thresholds. The importance of baselines is noted, this allow you to determine if the current conditions are ‘normal’. Azure Application Insights can build smart baselines based on historical data. The use of dynamic thresholds and smart alerts is illustrated (e.g. if CPU usage is 20% above the baseline for 30 minutes, trigger an autoscale to add more CPUs). Since workload change with time, the baselines also need to be retaken. There’s a helpful section on using baselines to right-size your cloud platform – remember you can run on a lower spec server for normal work, and autoscale it when necessary. The last section looks at what Azure offers for data platform monitoring, including:
This was a very interesting chapter. If you support systems, you’re going to get problems, so it helps to know what features are available to help you. The importance of knowing your workload (e.g. to create a reasonably valid baseline), is again highlighted. I was a little surprised it didn’t mention the sqlassessment.exe tool to help determine the correct database size when migrating to Azure. 
|
||||
| Last Updated ( Wednesday, 23 November 2022 ) |
