As the pandemic is still playing a key role in our day-to-day life, many companies are trying their best to adapt to the new situation. There are then many extensive reports focusing on the impact of Covid-19 on multiple industries.<\/p>\n
As a common factor, many are seeing the use of Public cloud services, as potential remediation of the current situation. Obviously, there is a long-running and extensive debate between On-Premise VS Cloud-based architecture. There are many aspects to consider such as security\/cost-effectiveness\/vendor-lock-in scalability etc.<\/p>\n
Those who can afford it, may choose a hybrid solution to keep their options open and benefit from most worlds\u2026 However, this is extremely expensive, especially if you starting it from scratch.<\/p>\n
The current situation undeniably changed the odds to the favor of Public cloud services for many users due to its dynamic and cost-effective nature and due to its extensive managed-service offerings which offer the box solution to most small\/medium\/large companies and enterprises who do not want to invest heavily into this area.<\/p>\n
Hence, the amount of \u201cCloud Migration\u201d projects in the industries are skyrocketed, and as it’s not as straightforward, and there are many things to consider, I hope to shed light on some aspects of cloud migration so you can make the best decision.<\/p>\n
<\/p>\n
If you ask Google what is Cloud migration is? \u2013 <\/strong>it will tell you that it<\/p>\n \u201c\u2026<\/strong>\u00a0is the process of moving data, applications, or other business elements to a\u00a0cloud<\/strong>\u00a0computing environment. There are various types of\u00a0cloud<\/strong>\u00a0migrations an enterprise can perform. One common model is the transfer of data and applications from a local, on-premises data center to the public\u00a0cloud<\/strong>.\u201d<\/p>\n As you can guess from the above, there is more than just one way to achieve cloud-migration.<\/p>\n You can do a :<\/p>\n When it comes to Public Cloud, as it\u2019s a very competitive market, there are many BIG players you can choose from:<\/p>\n I\u2019ve been asked a few times before :<\/p>\n \u201c \u2026 but cloud is cloud, right? What is the difference between Private and Public?\u201d<\/p>\n This is something good to understand and take into account when you planning your migration. There are two main types of Cloud environments: Private and Public.<\/p>\n Public cloud<\/strong>\u00a0is what\u2019s delivered via the internet\u00a0and<\/strong>\u00a0shared across organizations.\u00a0Private cloud<\/strong>\u00a0is\u00a0cloud<\/strong>\u00a0computing that is dedicated solely to your organization. Hybrid\u00a0cloud<\/strong>\u00a0environment that uses both\u00a0public and private<\/strong>\u00a0clouds<\/p>\n Try not to confuse these two things:<\/p>\n Based on my personal experience, when you get started, these are the stages you need to go through from 0 to 100:<\/p>\n During your first and second stage \u2013 you need to make a lot of decision, so hope that my personal preferences might help you make the best decision which suits you the best :<\/p>\n <\/p>\n For a\u00a0shallow cloud integration (sometimes called \u201clift-and-shift\u201d)<\/strong>, you move the on-premise application to the cloud, and make no\u2014or limited\u2014changes to the servers you instantiate in the cloud for the purpose of running the application. Any application changes are just enough to get it to run in the new environment. You don\u2019t use cloud-unique services. This model is also known as lift-and-shift because the application is lifted\u00a0\u201cas is\u201d and moved, or shifted, to the cloud intact.<\/p>\n Choosing this option will minimize the effort and involvement, however, you can be sure this will still not going to be an easy sale.<\/p>\n Depending on the complexity of your existing estate this might be a rather counter-productive choice (if its about medium complexity or above)<\/p>\n For a really simple footprint<\/strong>, however, this is your perfect choice.<\/p>\n For a\u00a0deep cloud integration<\/strong>, you may modify your application during the migration process to take advantage of key cloud capabilities. This might be nothing more advanced than using auto-scaling and dynamic load balancing, or it might be as sophisticated as utilizing serverless computing capabilities such as\u00a0AWS Lambda\u00a0for portions of the application. It might also involve using a cloud-specific data store such as\u00a0Amazon S3\u00a0or\u00a0DynamoDB.<\/p>\n In case you feel fairly confident and have the right team at your disposal to execute this project, this is the recommended choice. This might be the best of both worlds and with the relatively minimal investment, you can gain a lot in the long-run.<\/p>\n Rip and Replace\u00a0 (or RIP &R<\/em><\/strong>) is only recommended if you have the army of engineers (and the findings) available for you, and you confident you can build everything up from scratch. <\/p>\n Single Cloud means simpler design, and you can optimize heavily utilizing vendor-specific services, however, you may risk vendor lock-in.<\/p>\n Multi-cloud means you will never be locked into one cloud provider and have a greater sense of freedom with high availability across providers. However, it greatly increases complexity and therefore, the cost of the migration as well.<\/p>\n <\/p>\n During the migration, my personal recommendation would be to put special focus on DevOps best practices and Infrastructure as Code (IaC).<\/p>\n DevOps is a practice that unifies the building and running of systems with an emphasis on <\/em>a<\/em>utomation and monitoring at all stages.\u00a0 <\/em><\/p>\n If you want to be successful in your cloud migration, you need to practice this culture in everything you do. Because of this, you should consider SRE engineering to lead and complete the migration.<\/p>\n \u201cSRE is what you get when you treat operations as if it\u2019s a software problem\u201d – G<\/em>oogle definition<\/p>\n SREs are basically a mixture of software engineers, operation engineers, and Infrastructure architecture all at once, living by DevOps best practices, and owning the product from the top to bottom.<\/p>\n But why is this important \u2013 you may ask?<\/p>\n Because if you want the following in your arsenal, then you should choose to do the migration properly with :<\/p>\n 1] CI-CD<\/strong><\/p>\n In software engineering, CI\/CD or CICD generally refers to the combined practices of continuous integration and either continuous delivery or continuous deployment. CI\/CD bridges the gaps between development and operation activities and teams by enforcing automation in building, testing, and deployment of applications.\u00a0(<\/em>Wikipedia)<\/em><\/p>\n 2] Immutable Infrastructure <\/strong><\/p>\n Immutable infrastructure makes \u201cconfiguration changes by completely replacing servers\u201d (Morris, 2016:70) so rather than working on updates to live service with an immutable approach you ensure that a \u201cdeployed server will remain intact, with no changes made\u201d (BMC, 2020). If an update is needed to be made then the existing instance is retired and a new one takes its place.<\/p>\n Having a templated approach to infrastructure and its implementation \u201cincreases predictability as there is little variance between servers as tested and servers in production.\u201d (Horowitz[Netflix], 2019)<\/p>\n 3] Infrastructure as Code<\/strong><\/p>\n Infrastructure as Code in a nutshell: \u201cevery server could be automatically rebuilt from scratch, and configuration tooling would run continuously\u201d (Morris).<\/p>\n Google\u2019s take is similar: Automate repeatable tasks like provisioning, configuration, and deployments for one machine or millions.<\/p>\n 4] Monitoring as Code \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/strong><\/p>\n Monitoring As Code, first mentioned at AWS Re:Invent in 2017, is about taking the IaC approach to monitoring and alerting. This can be seen in Google’s SRE handbook where they recommend \u201ctreating your monitoring configuration as code\u201d (Beyer et al., 2018:67). To put this into context it would enable all monitoring and alert could be automatically rebuilt from scratch and configuration tooling to run continuously. This would mean that the same monitoring and alerting could be applied to lower environments and also should we ever choose to change vendor the scope of work is easily known.<\/p>\n This is super important if you want to be able to release any changes quickly and securely (and if you do this right \u2013 every tiny modification against your estate defines as a release)<\/p>\n <\/p>\n What Challenges you may face? A LOT\u2026!<\/p>\n But why am I considering doing this \u2026?!<\/p>\n <\/p>\n In short, it’s not a simple task \u2026<\/p>\n However, if you already on the mission to make this a reality for your company (OR for yourself), you should aim to do this right at the first time<\/u><\/strong>, as it will be more costly to correct any unintentional mistakes at a later stage.<\/p>\n If you have to make a decision to do a greater investment at the begging of your journey (choose between Lift and shift \/Improve and Move\/Rip and Replace) go for the 2nd<\/sup> option! Or if you like a challenge \u2013 option 3 might be just for you!<\/p>\n Lift and shift (based on my own personal experience) is never as simple as it sounds, and has greater cost-implication, in the long run, to keep things alive and well.<\/p>\n If you are on this journey, best of luck and be proud, as you are literally paving your business\u2019s future for many years to come!<\/p>\n <\/p>\n Article written by David Jambor<\/strong>, Head of Systems Engineering at Vodafone<\/p>\n <\/p>\n Sources:<\/strong><\/p>\n https:\/\/www.bmc.com\/blogs\/immutable-infrastructure\/<\/em><\/p>\n https:\/\/www.hashicorp.com\/resources\/what-is-mutable-vs-immutable-infrastructure<\/em><\/p>\n https:\/\/www.oreilly.com\/library\/view\/seeking-sre\/9781491978856\/ch24.html<\/em><\/p>\n Beyer, B, et al (2018) The Site Reliability Workbook. 2nd edition. Sebastopol, CA: O’Reilly. Available at:https:\/\/lrita.github.io\/images\/posts\/com\/the-site-reliability-workbook-next18.pdf<\/a><\/em><\/p>\n AWS Re:Invent 2017 – https:\/\/www.youtube.com\/watch?v=JLS6fdiiL_0<\/a><\/em><\/p>\n\n
\n
\n
\n
Lift and Shift Or Cloud Optimised?<\/strong><\/h4>\n
\nThis would deliver the best results in the long term \u2013 however, it most likely will be a really expensive investment with zero or negative ROI in the short-or-medium run. However, it is undeniably the best way to ensure you utilize the cloud provider to its full.<\/p>\nSingle or Multi-Cloud Strategy?<\/strong><\/h3>\n
DevOps and IaC<\/strong><\/h3>\n
The challenges…<\/strong><\/h3>\n
\n
\n
Conclusion<\/strong><\/h3>\n