Co m pl im of Steve Francis ts Steps to Success en Preparing for Your Migration to the Cloud Preparing for Your Migration to the Cloud Steps to Success Steve Francis Beijing Boston Farnham Sebastopol Tokyo Preparing for Your Migration to the Cloud by Steve Francis Copyright © 2018 O’Reilly Media All rights reserved Printed in the United States of America Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://oreilly.com/safari) For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com Acquisition Editor, Editor: Nicole Tache Production Editor: Nan Barber Copyeditor: Octal Publishing, Inc July 2018: Interior Designer: David Futato Cover Designer: Karen Montgomery Illustrator: Rebecca Demarest First Edition Revision History for the First Edition 2018-07-23: First Release The O’Reilly logo is a registered trademark of O’Reilly Media, Inc Preparing for Your Migration to the Cloud, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc The views expressed in this work are those of the authors, and not represent the publisher’s views While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work Use of the information and instructions contained in this work is at your own risk If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights This work is part of a collaboration between O’Reilly and LogicMonitor See our statement of editorial independence 978-1-492-03880-1 [LSI] Table of Contents Preface v Preparing for Your Migration to the Cloud Introduction What’s the Attraction of the Cloud? Cloud Constraints and Challenges Plan Your Approach The Seven-Step Migration Plan In Parallel with the Seven Steps Cost Management in the Cloud In Conclusion 11 15 18 43 45 46 iii Preface How to best take advantage of the cloud is a frequent topic of dis‐ cussion among all levels of an organization’s IT team Often, the dis‐ cussion will be couched in terms of enterprise transformation, or digital transformation, or datacenter consolidation, but at their heart, these projects usually involve cloud migrations Cloud migrations can bring great benefit, but the technology is new enough, and changing rapidly enough, that even if you develop an accurate business case, your organization may not achieve those benefits, since your staff is probably inexperienced in cloud migra‐ tions That’s exactly the situation this report is intended to help with While there is no universal script for cloud migrations, there are steps you should consider in planning any move to the cloud One of the big risks in any project is the “unknown-unknowns.” This report won’t give you all the answers, but it will help you highlight the questions that you should be asking in planning a cloud adop‐ tion It is intended to be useful for everyone that is involved in, or wants to advocate for, a cloud migration—from the CIO down to the engineering staff And I would posit that practically every orga‐ nization should be thinking about cloud migration in order to main‐ tain the agility it needs to be competitive I would also suggest that for technical staff, knowledge of cloud technologies and cloud migration principles is as sure a thing for career advancement as there is at the moment When LogicMonitor started, the cloud was in its infancy Indeed, virtualization was just becoming big LogicMonitor has been able to navigate the transition from bare metal, to virtualization, and now v the cloud, hybrid cloud, serverless, and whatever else technology brings Much of the wisdom in this report is directly attributable to the expertise, knowledge and insight of our customers, and their will‐ ingness to share and discuss their challenges and solutions For that, I will always be grateful Cheers, Steve Francis vi | Preface Preparing for Your Migration to the Cloud Introduction The cloud is everywhere You know that the cloud stats are trending up, but did you know how fast? According to Forrester, the global public cloud market will jump from $146 billion in 2017 to $178 billion in 2018 After that, it is expected to grow at a 22-percent compound annual growth rate (CAGR) For comparison purposes, growth of the overall global tech sector in 2018 will be just five percent, and even if it smashed predictions it would get only to the seven-percent-plus range Thus, an increasing proportion of global information technology spending will be on the cloud (According to IDC, global information technology spending will reach $4.8 trillion in 2018.) Not surprisingly, the cloud migration market is heating up, as well After all, these businesses investing in cloud technology generally need services to help them succeed in their transformations The global cloud migration services market is predicted to expand from $3.17 billion in 2017 to $9.47 billion by 2022, at an even higher CAGR of 24.5 percent Most notable about all this is the move to the public cloud Accord‐ ing to McKinsey, almost 80 percent of businesses plan to have more than 10 percent of their workloads in the public cloud within three years According to Spiceworks, these workloads range from backup (the most popular), to email hosting, to productivity apps, and everything in between (see Figure 1-1) Figure 1-1 Budget breakdown of cloud spend (source: “The 2018 State of IT,” Spiceworks) What’s driving all this? Largely, businesses searching for cost bene‐ fits A recent study from 451 Research discovered that cost savings is the top motivating factor for CIOs moving to the cloud model, with 38.8 percent of them naming that as a critical driver (Resource scal‐ | Preparing for Your Migration to the Cloud ness function that is not part of your intellectual property,” he said It’s absolutely not worth your developers’ time to write a CRM appli‐ cation if you’re not selling CRM as part of your business There’s a bunch of them out there People smarter than us have already har‐ vested that field.” However, if you have intellectual property that is unique to your business and actually gives you a competitive advantage, you proba‐ bly should consider writing that yourself because that is what will differentiate your business from others, he says “Then start looking to platform services for those sort of applications, because again, the agility, speed of development, and some of the tools that are avail‐ able are still very, very good, but they’re development tools, they’re not actual applications So, you can still leverage the speed and agil‐ ity that I mentioned about the cloud, but to develop on, not to just consume.” And what’s left is just your “lift-and-shift workloads,” says Pelletier “Those are perfect candidates for IaaS,” he says “Just lift them up and shift them over, and drop those on a vanilla cloud infrastruc‐ ture, whether it’s Azure or AWS or any other IaaS cloud provider.” Should you use multiple cloud providers? One thing to consider is how tied you want to be to your cloud provider? Many businesses end up in multiple clouds This is gener‐ ally not a strategic decision It’s rarely because of risk management It’s more the fact that a lot of cloud projects are done on the depart‐ mental level so that the engineers in charge of one application will design things in Amazon The engineers in charge of another appli‐ cation might have a more Microsoft focus, so they’ll their own things in Azure But effectively, the organization is now dependent on both clouds for these applications to work And if these applica‐ tions are components of the same system, that system has now dou‐ bled its dependencies and consequent likelihood of failure According to a 2017 survey by Cloudify, more than half (51 percent) of all businesses that use the cloud are in multiple clouds (see Figure 1-3) 34 | Preparing for Your Migration to the Cloud Figure 1-3 More than half of businesses in the cloud are using multiple clouds (source: IOD Cloud Technologies Research [by Cloudify and IOD Cloud Technologies Research http://bit.ly/2NmRSXn]) There is a valid argument to be made for utilizing multiple cloud providers for fault-tolerance benefits—the odds of two of the major cloud providers going down at the same time are very low However, supporting fault tolerance across clouds constrains your ability to take advantage of the cloud This is because if you design your appli‐ cations in a cloud provider–agnostic way, you’re basically using the cloud only as a compute platform So, you can fire up machines—something that’s relatively easy to —in multiple clouds, but if you want to rely on Amazon’s Dynamo DB and scalable queuing services, you would not be able to trans‐ parently move those systems over to the equivalent queuing service in Microsoft and the equivalent database in Microsoft, because they behave very differently Your application queries will need to be written to abstract away the database or queuing systems, which takes away much of the benefit of using PaaS services A more common approach to cloud portability would be to not rely on the cloud providers’ PaaS services, but to run them yourself in a way that can work on any cloud provider (for example, run Rab‐ bitMQ on guest VMs you provision in the cloud provider) So, if you want to maintain portability across cloud providers, you’re effectively only able to use containers and servers in the cloud, but The Seven-Step Migration Plan | 35 not any of the other myriad services that the cloud provides That inhibits your agility Data sovereignty is another issue that arises with multiple clouds, according to Bell “Every time you choose another cloud provider you have to know where your data’s going,” he says “So, if you employ a strategy of having four cloud providers, that means four different sets of data going to four different places requiring four different audits.” Not only that, he says, but you need four levels of complexity and four different levels of vendor management tasks as far as how you manage your contracts and hold your vendors accountable “I don’t think that is a great strategy,” says Bell Alternatively, the advantage of getting really tight with one vendor is that your team gets experienced in the way that vendor does things “Amazon is pretty good at having consistency across different serv‐ ices; they didn’t start out that way but they are now,” says Bell “If you know how to use their SQS service, it’ll be very similar to using their DynamoDB service, for example So you’ll get efficiencies from that.” The disadvantage of getting tight with one vendor is that you could effectively become locked in Although this isn’t a problem at the moment—because the cloud space is so competitive, prices are dropping across all vendors—the concern is what happens if there does become a dominant player and they begin using their pricing power to drive costs up Because of this, Bell says it’s best to negotiate your “breakup” with your cloud vendor when you’re signing the deal—not after “At the beginning, you’re really excited so you focus on the terms and con‐ ditions and the costs But if for whatever reason two years down the road you want to break up, you’ll have to negotiate how to get your data out with that vendor,” Bell says “Negotiate your breakup at the frontend of that relationship not the backend You want to know exactly what it’s going to take to move your data You want to know what the costs are going to be You want to know what the SLAs are going to be.” 36 | Preparing for Your Migration to the Cloud Why You Need Monitoring Tools Scott Pelletier was originally a mainframe guy Everything was in a glass room inside a building on a single computer, and “we con‐ trolled every damned thing,” he recalls “We controlled power, cool‐ ing, access, applications, code We wrote it all ourselves It was a very, very controlled environment.” Then came minicomputers and the Unix trend, which turned into more open systems and the three-tiered architectures, and Microsoft entered the datacenter Then, the world of virtualization arrived, which made the IT uni‐ verse expand even further “Now we couldn’t even see some of the stars There were actually virtual things inside of other things, and they had this other expansion, this virtual expansion, and what peo‐ ple call ‘virtual sprawl,’” says Pelletier Things were progressively getting harder and harder to control And then the cloud happened “Now it’s outside the building The IT environment goes beyond the walls, let alone from your datacen‐ ter to branch offices,” says Pelletier “And it’s really hard to control because you don’t own the building that it’s in or the people who run it or the Ops teams.” And, of course, the most recent frontier is the Internet of Things Now the IT environment is truly everywhere —even in your home And it keeps expanding further “Frankly, that’s why we use tools like LogicMonitor Because they understand this ever-expanding universe,” says Pelletier “It’s SaaSbased, which makes sense, but more importantly, it’s open-minded enough to say, ‘Let’s monitor everything,’ from a datacenter to a toaster They really don’t have a limit in their mindset with where this might go, which I like.” The main advantages of a platform like LogicMonitor are the ability to monitor all the components of IT universe, even as it expands, and visualize and alert on all of that in a single place; having embedded intelligence that means it will highlight issues without your staff having to be expert in technologies that might be new to them; and, of course, being SaaS Having such a platform that is both agnostic and open is a good bet as the IT universe continues to expand, says Pelletier Adopting a flexible tool that can provide visibility into your cloud or hybrid-cloud infrastructure after your migration, before your migration, is a smart move To plan an effective cloud strategy, you The Seven-Step Migration Plan | 37 need visibility into what applications you have running, where, how they are performing, and what resources they need LogicMonitor and other tools can provide this—but you need to ensure that your tool can provide the same visibility into your application on the cloud infrastructure You certainly want to be able to view performance in one monitor‐ ing platform before, during, and after the migration, so you can quickly see whether your application is performing the same (or better) when running on cloud infrastructure You certainly don’t want to think you’ve completed a successful migration, because you have separate monitoring for your cloud infrastructure, which looks normal, but doesn’t show that the number of users is 20 per‐ cent less than the premigration system was handling You need a complete monitoring system that can cover all the places your infrastructure and application runs—even if that involves spanning multiple datacenters and multiple cloud-providers Step 4: Plan an Iterative, Agile Process of Transformation Think small Use the Agile methodology (see “What Is Agile?” on page 39), which means you not attempt to plan a large migration that changes everything about a critical system at once Move indi‐ vidual components first—perhaps one server out of a pool of 50 See how it works Learn from the experience Iterate a few times to get it right Then, move the next five servers to the cloud and see if it scales Again, learn and iterate And go on to moving 10 servers, and then the next application In effect, you’re breaking up the migration into small bite-size pro‐ cesses—very much like your Agile software processes, where every “sprint” results in a deliverable And like in Agile software develop‐ ment, your cloud team should be delivering value to users (probably your application and development teams) in short timeframes and getting collaborative feedback from them Additionally, try to relieve your people from having to it all Automate as many processes as possible, so you move toward a con‐ tinuous development and deployment model 38 | Preparing for Your Migration to the Cloud What Is Agile? According to the Agile Alliance, an Agile mindset is the “ability to create and respond to change to succeed in an uncertain and turbu‐ lent environment.” When applying this philosophy to software development, Agile becomes an umbrella term for practices that align to 12 principles laid out in the Agile Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software We welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project We build projects around motivated individuals Give them the environment and support they need, and trust them to get the job done The most efficient and effective method of conveying informa‐ tion to and within a development team is face-to-face conver‐ sation Working software is the primary measure of progress Agile processes promote sustainable development The spon‐ sors, developers, and users should be able to maintain a con‐ stant pace indefinitely Continuous attention to technical excellence and good design enhances agility 10 Simplicity—the art of maximizing the amount of work not done—is essential 11 The best architectures, requirements, and designs emerge from self-organizing teams 12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly The Seven-Step Migration Plan | 39 Step 5: Get Buy-In to the Plan This is a critical step As we discussed earlier, you will face chal‐ lenges no matter which approach you take, top-down or bottom-up Bell points out that the bottom-up model, in which engineers or business departments take cloud matters into their own hands without the technical guidance of IT, can result in them getting “led down a garden path pretty quickly” by cloud providers “They don’t know what to ask They don’t understand the implications of some of the decisions that they’re making,” he says Many times, they end up finally going to IT because nothing is working, and the IT folks have a mess to clean up “It’s not good,” says Bell But there are challenges with the top-down approach, too—when IT and the CIO’s office are effectively leading the migration Not only does IT not move fast enough to suit the business, but it has an ITcentric view of the world IT often doesn’t understand the business goals that the migration must meet Another risk with anything top-down is the line engineers and busi‐ ness users can resent it They are being ordered to use something new, and they may not feel it was the right approach Also, top-down approaches tend to be more conservative You might be missing opportunities if IT says it is going to restrain its cloud deployments until it has explored some very safe workloads You can be missing tremendous chances to accelerate within a business unit that desperately needs the agility that the cloud offers You can’t lose sight of the fact that often the business units are the ones who best understand the need and who are the most passionate about cloud opportunities Because of this, doing it from the bottom up can drive efficiencies because there is absolute buy-in The people doing the work are the ones who came up with the idea and they understand the advan‐ tages of it But, on the other hand, you might end up with fragmen‐ ted cloud systems and being enmeshed in multiple providers You can end up with security issues because development might not have coordinated with the central security offices and were simply unaware of some of the risks and issues with their new architecture You can end up with cloud sprawl and the associated costs because no one is ensuring that resources are needed and utilized efficiently 40 | Preparing for Your Migration to the Cloud Driving a cloud initiative from the top down can give you better advantages in terms of operating the cloud as a strategic resource and making sure that central IT mandates security, and that designs are appropriate for the required levels of availability They can facili‐ tate sharing the learnings among all stakeholders The recommendation: take a top-down approach but on a focused departmental basis Do the inventory, determine what the resources are, and find a team that is motivated to realize the benefits of cloud agility and be the vanguard of the company Work closely with that team to help it achieve success, develop practices that work for your organization, and then spread the learning throughout the enter‐ prise Although there are risks to a top-down approach, that generally works best Starting small with a technical expertise at the head of the migration effort, achieving success, and then being evangelical about it Because no one likes a rigid top-down-imposed project, however, you need to build consensus Start with a small, enthusiastic team Get them to evangelize their successes and learnings You want the organization to feel that it’s a user-promoted idea rather than a demand from the top Step 6: Start Simply and Make Learning, Not ROI, Your Priority If you’re new to cloud services, it’s best not to dive into a big project first According to the Cloud Standards Customer Council (CSCC), you should start the migration process with the applications that are most “cloud ready.” But what does that mean? As we showed in Step 3, there are many things to consider when determining which applications and workloads are best moved to the cloud Still, by now, in Step 6, you know which applications are the best candidates for the cloud You know what their attributes are So now it’s time to prioritize them It’s important to not rank them based on their potential value to the business I know that sounds counterintuitive But you want to rank them based on learning potential The Seven-Step Migration Plan | 41 As I alluded to earlier, start with a fairly simple application that’s not business critical, but which will inform how you handle the later migrations of the truly important systems Why? Because if you’re hoping that your first project will give you a high traditional business ROI, it probably means it’s a complex sys‐ tem that is important to your business If you mess up, you could cause a significant outage or end up increasing, not decreasing, your costs Another point: If you decide that agility is one of the issues driving you to the cloud, you probably want to take advantage of PaaS cloud services rather than IaaS sooner rather than later That way, your developers can learn that model, and see how it might meet your particular business needs After you have an initial success or two, internal advocacy is going to be one of your goals Using the cloud changes your constraints— CPU and memory resources become effectively limitless—but the very people who know how to take advantage of the cloud and man‐ age the cloud orchestration systems can become a new bottleneck Advocacy can help motivate your staff to learn and adopt the new cloud-centric technologies, which will really accelerate your agility Advocating also applies to your operations teams, because after you move into the cloud, you’ll need your operations team that was pre‐ viously involved in PXE booting servers and running kickstarts and jump starts and so forth to be aware of how you automate these things in your cloud provider’s environment, using Terraform, Pup‐ pet, and other tools This is a different skill set for a lot of operations people, which is why fostering a learning mindset, and spreading enthusiasm for the cloud projects and their advantages is crucial Make sure to ask yourself what each project will add to your cloud learning This is really your top priority: the most value to the busi‐ ness at this point is the learning you get out of each migration rather than the traditional business value You’re certainly not going to go after the largest financial ROI, or the project that will make the most strategic difference to your business You don’t want to make the mistakes on that project You want to make the mistakes on the projects where you are learning all the important skills, but without the risks 42 | Preparing for Your Migration to the Cloud ROI would be the right thing to if you could accurately assess your risk and if you knew the things that were required The prob‐ lem is that most companies don’t know this at this point in the cloud life cycle Orange’s Tuttle agrees with this approach “An easy dev test is always a great place to start,” he says “Look for smaller scale applications, they’re always good.” Communicate to people within your business that progress is being made so that they get some comfort with the direction being taken, and then build a road map for the migration of the rest of the applications based on the learning you acquire, the suitability for the cloud, and, finally, the benefits of moving to the cloud Always start with low-risk projects, not the ones that will give you the biggest bang for your buck, advises Tuttle “Because the ones that have the potential to give you the greatest benefits are probably those with the greatest risk to the business,” he says Step 7: Rinse and Repeat As you succeed and learn from moving your simplest, least-business critical application, you progressively move to more complex and more critical ones Continue adding to your knowledge with each iteration In Parallel with the Seven Steps Although we recommend doing the seven steps in the order previ‐ ously prescribed, you also have some work to in parallel with these steps: redesigning applications that are being moved to cloudnative architecture, and managing costs Redesigning to Cloud-Native Architectures The single most important aspect of your cloud-native architecture is that your systems are designed under the assumption that compo‐ nents will fail Despite that, the system must keep running Netflix understood how critical this was So, its engineers designed “Chaos Monkey”—a program that randomly shuts down machines on Amazon Knowing this, Netflix software developers design their systems to be fault tolerant to the extreme In Parallel with the Seven Steps | 43 This is important because you lack control In your own datacenter, you can design resilience in your hardware, with fully fault-tolerant drives, memory, and power supplies But Amazon can decide to per‐ form maintenance, or it simply experiences a failure, just as in your own datacenter Chaos Monkey: Netflix’s Secret to Cloud Success According to Netflix, Chaos Monkey “is responsible for randomly terminating instances in production to ensure that engineers imple‐ ment their services to be resilient to instance failures.” Invented in 2011 by Netflix engineers to test their IT infrastructure for resiliency, Chaos Monkey deliberately shuts down computers— in Netflix’s production environment, no less—to see what happens to the other systems So successful was Chaos Monkey internally, Netflix made it available to the rest of the world Today, Chaos Monkey is part of a larger suite of solutions that goes by the name of the “Simian Army,” which tests how infrastructure responds to different kinds of system failures Because systems should be designed to handle failures, the biggest issue in most systems is dealing with state Ideally, you want to mini‐ mize the state kept on any node Ensure that state is kept on systems that are replicated across availability zones (for example, using RDS replicas), or that can be lost without affecting services (such as Memcached—loss of a node will impact performance, but queries will still flow through to the underlying database) Part of designing systems to be cloud ready is ensuring that they are automated and programmatically driven in their configuration and management Given that cloud services are API driven, part of cloud architecture is designing your provisioning system to help deploy and recover from failures For example, if you lost an entire region and had to re-create an application, you would not want to it manually You should have automated systems such as Terraform, Chef, Puppet, Ansible, CloudFormation, and so on that can recreate environments programmatically Of course, you should tie these systems into other systems, such as your monitoring, such that immediately on resources being provi‐ sioned, they are also configured into your monitoring One of the 44 | Preparing for Your Migration to the Cloud best ways to prepare for a cloud migration is in fact to adopt such automated technologies before you move to the cloud—ensure that your current applications, even in your own datacenter, can be man‐ aged by automated configuration management and provisioning tools, have good version control, automated deployments, and auto‐ mated monitoring This will ensure that deploying into the cloud, instead of your own datacenter, is a fairly low-impact process—and because the monitor‐ ing will provide a unified view, it’s easy to validate and to roll back Cost Management in the Cloud “Cloud litter” is one of the prevalent problems of anyone who’s using the cloud You have teams spinning up instances and not shutting them down And because the budget is somewhere else, it looks like a small investment when a developer says, “Oh I’m firing up my server—I don’t know what its performance requirements are going to be, so I’ll solve that by putting lots of CPU and lots of disk on it.” This often leads to over-provisioning—but even if they have chosen correctly, later when they improve their code and the load drops, they forget about their original resource request And because they’ve never changed the type of computer it’s running on, they are paying $8,000 per month for a computer that could be just $2,000 per month At LogicMonitor, we had a problem like that We had logging sys‐ tems in Amazon that were running on systems that had high-speed SSDs attached, ones that were designed to thousands of input and output operations per second This was costing us a reasonable amount of money per month We kept this configuration for more than a year, not realizing that when we changed the way our logging worked, we didn’t need that level of throughput anymore We even replicated this configuration to new pods that had never needed high throughput drives Now we just needed a few tens of opera‐ tions per second, not thousands We had one of our internal tools point this out to us, and just by changing the kind of storage we use and nothing else, we saved about $90,000 a year With no change in performance, no change in availability This is very common Engineers who spin up cloud resources never look to see if they still need the same resources as when a system was first fired up, because, well, that worked, so let’s replicate that, they Cost Management in the Cloud | 45 thought And then there’s the fact that so many things are fired up and forgotten about Getting a tool for this is important from a cost-management view, but it’s not trivial And it’s not exactly in the cloud provider’s inter‐ ests to point these things out to you So, you’re going to need to go to an external tool to get this cleansing of your infrastructure, to make sure that all the resources you are using are sized appropri‐ ately and identify the ones that you aren’t using, and safeguarding the ones that you are depending on In Conclusion So I’m not sure what the work of the future is, but I know that the future of companies is to be hiring people and constantly training people to be prepared for a job that has not been invented yet If you, as a company, are not providing both the resources and the opportunity for lifelong learning, [you’re sunk], because you simply cannot be a lifelong employee anymore unless you are a lifelong learner If you’re training people for a job that’s already been inven‐ ted, or if you’re going to school in preparation for a job that’s already been invented, I would suggest that you’re going to have problems somewhere down the road —Tom Friedman1 Moving to the cloud is not the end of your journey In many ways, it’s the beginning Because many, if not most, innovations today are somehow associated with cloud Every month, new developments are announced by cloud providers that make the cloud even more secure, convenient, cost effective, and attractive “This is a really fundamental big change in the way we consume IT,” says Gadi Oren, CEO and cofounder of ITculate, a cloud monitoring solution recently acquired by LogicMonitor “It’s very attractive, and very powerful, even though the price that you’re paying the cloud is not always cheaper than buying things yourself, it’s still infinitely worthwhile.” “A wave of innovation has created a market of technologies for things you couldn’t build yourself, but which are now available in Source: http://bit.ly/2LcdpVx 46 | Preparing for Your Migration to the Cloud the cloud,” he says “So you have to be in the cloud today, because that’s where the latest products are being served.” But a fairly steep curve lies ahead It pays to take small, carefully cal‐ culated steps, to minimize the risks and maximize the learning In Conclusion | 47 About the Author Steve Francis is the Founder and Chief Evangelist at LogicMonitor As Chief Evangelist, Steve is responsible for building LogicMonitor’s brand as a leading global infrastructure software vendor Steve is an established IT industry veteran with over 20 years of experience His vast IT experience stretches from setting up the first customer BGP peering with MCI, to giving talks on Kubernetes Prior to founding LogicMonitor, Steve was responsible for the operations of a diverse group of organizations including National Geographic, the Univer‐ sity of California, Citrix Online, and Valueclick Steve’s favorite pas‐ times included stand up paddleboarding, jiu jitsu, and biking ... Preparing for Your Migration to the Cloud Steps to Success Steve Francis Beijing Boston Farnham Sebastopol Tokyo Preparing for Your Migration to the Cloud by Steve Francis... replicated in the cloud So, whether a workload is a good fit for the cloud depends on its availability requirements, and again, how it s designed 22 | Preparing for Your Migration to the Cloud Systems... “They don’t want to have to manage and refresh their own infrastructure hosted in their own datacenter They want to leverage the financial benefits of moving to the cloud, the scalability, the