Newesis - Introduction to the Cloud

Editor's Notes

• #3: We all are using cloud services since years now, this session does not pretend to teach anything technical, there are many cloud services, even assuming I have the skills to teach you what they are and how to operate each of them (and the assumption would be wrong), we would need to stay in this room for months to complete such an exercise and once completed we would discover that what we’ve learned is old and new services have been created in the meantime. Today what we want to achieve is to have a common understanding of what does it mean to work with the Cloud, how this change the paradigms we were following before, how this change the definition of our roles and interactions. This session aims to give a common context and approach when it comes to consider Cloud services.
• #5: We used to have candles to provide light in the houses, this has been replaced by electricity powering light bulb, moving from candles to light bulb is not cost effective, candles are really inexpensive and only dependency to use them is to be able to have an initial flame, light bulb are more expensive than candles and require electrical plants and a subscription to a provider bringing electricity up to your house. But with light bulb the operations to have lights is much easier and it is much easier to vary how much light you want in a certain room compared to one other, and you can easily have light in multiple areas of the house coming up together and the electrical plant can be used for many other things than not just provide light.
• #6: When we all moved from legacy mobile phones to smart phones we got a product that was seriously more expensive, that was bigger, harder to fit into a pocket, often with worst antennas compared to the phones we were using before and with batteries that were lasting incredibly less (we used not to charge the legacy phones for days, with smart phones this became hours). But we all moved from legacy phones to smart phones, because it was enabling us to do much more, to become more efficient, we used to travel with a phone, an agenda, a computer, a camera, a navigator system, a music player. All these things entered into a single product capable to do all they were doing and something more. But it means we had to start using the smart phone on a way that is pretty different from the way we were using the legacy phones.
• #8: The Cloud providers have very good marketing people and marketing had been very good on creating attention to the Cloud even when the concept was very far from what people was used to. Marketing communicates for simple messages, people tend to absorb them quickly and so this caused the creation of a series of false myths that is important to demystify.
• #9: The most common mistake is to believe Cloud will cost less, I can use it without any problem because it is very inexpensive. This is not true, if you take the same computational power in an On Premises setup and in the Cloud (any of the major Cloud providers) and you compare costs, the On Premises will always cost less. This because you are comparing two different things and it is easy to understand with an example. If you make your own pizza you buy some flour, yeast, salt, oil, tomato sauce and you do the job using your own oven with your own electricity. This will cost you around 2 Euro per pizza. If you go and order a pizza in one of the best Pizzeria in town, the same pizza will cost you 5 euro. But if you need to do 100 pizzas at home this would be incredibly slow and difficult or very expensive because you will have buy additional ovens and tables and space, while in the pizzeria it will always cost 5 euro or probably less because they will give you a volume discount. You could decide to buy or build your own big Pizza Machine to be able to prepare 100 pizzas very quickly and in the long term this will cost you less than not keep ordering from the Pizzeria, but what if you discover that you need to make 50 Pizzas only but add 50 Lasagna? Your investment on the big Pizza Machine will be unused and you’ll need a big Lasagna machine too. In the pizzeria any pizza wills keep costing you 5 euro and you will be able to go and ask to have also Lasagna or Spaghetti and change your mind in any moment without the need for plan in advance.
• #10: Coming back to the list: Cloud is not less expensive, it just has a different usage model. I am insisting a lot into this aspect because our experience so far has been an experience of wasting money but it is not only us, the most common result for companies migrating from traditional solutions to the Cloud is that they end up spending more money than in the past. It is dramatically important for everyone to remind that the Cloud has a “per usage” model and also that the Cloud has a very detailed list of explicit costs. When you create a Virtual Machine, the simpler example, you have to remind that you will pay a cost per hour based on the CPU size and Memory size of the VM but you will also in addition pay a cost on top for the disk storage used by the VM based on the size of the space allocated but also on the kind of disk (different models having different scalability, security, performance measures) but you will also pay a cost on top for the number of operations you make on the disk (that Is not included in the pure cost of the disk space availability) and you pay a cost on top for the network traffic generated by the VM and you pay a cost on top for any snapshot you take of the VM and if you enable some special agent or add-on it will also have a separate cost line. And, this is the most important thing, you pay if what you created exist, it does not matter if you are using it or not, you pay per the minutes it does exist so it makes a very big difference if you close a service now or in two hours and if you sized it appropriately for what you need or if you oversize it just to be sure and have contingency. The business model of the Cloud is strictly based on the concept that many people will over provision and will forget to turn off services when not in use. The Cloud providers are constantly creating new services that can be more convenient to run the business cases of your projects than the ones you were using before, they are also constantly updating their API or UI, they also change the prices of existing services on the base of how the market moves and how capacity and capabilities are used in the datacentre. The value of the Cloud is also on the ability to create multiple systems, isolated from each other in terms of deployment, so if you were used to have a cluster of 9 database servers to run all business, when moving in the Cloud you will find yourself having hundreds of them. For all these reasons together, it is clear that the work required to manage and operate the Cloud is increased compared with the work that was required to manage a traditional On Prem solution, reason why the market average went from 1 FTE of a System Engineer every 15 FTE of Development to the current 1FTE of a Cloud Engineer (evolution of the System Engineer) every 5 FTE of Development.
• #11: Technical choices: as said before, if you take what you have On Premises and you move it to the Cloud as is preserving the same operational model, just don’t do it, it will just cost you much more. You have to move to the Cloud operating things as required by the Cloud (so continuous resizing, deletion and creation on the base of the actual needs). One other common mistake is to believe that capacity and scalability, as backup and resiliency or security are available by default. Clouds are composed by hardware physically installed into physical datacentres. It means that each service in each region has its own pretty finite capacity. In most services you have to configure explicitly the capacity and scalability and you have to define and active the rules and you’ll find some limit and so you have to design your solution to be able to run from multiple regions.
• #12: The Clouds are very complex distributed systems, operated by humans and running on physical hardware. For this reason Clouds have incidents and Cloud have failures that some time are able to make an entire region unavailable for long hours. This is common to each and every Cloud provider and can be easily verified looking at the incidents report of each of the main vendors. Azure for example had incidents in the following days: 8 of November, 2 of November, 27 of October, 24 of October, 17 of October, 16 of October, 13 of October, 11 of October, 8 of October, 4 of October, 3 of October, 2 of October. AWS has 40 incidents in the last 30 days. When it comes to SLA, you have to pay attention that each single atomic service has its own independent SLA, is means that if your service depends on the availability of the DNS, a set of App Service, the network, a couple of Virtual Machines and a PaaS based database and the DNS is down and so your service is completely unavailable for your end users, the Cloud providers will pay you only the penalties related to different between the actual uptime of the DNS service and the SLA on that service and will pay only the credits related to the DNS services, without any penalty on the other components that you will keep paying completely without any reimbursement. This, as per the capacity and scalability limitations, means that you have to design your solution to be capable of running into multiple regions and to design it in a way to cope with multiple kind of failures. Ideally, and in extreme, you should also design your solution to run using services from multiple different cloud providers. Please also always remind that Cloud business model is based on the concept of overbooking and abstraction, therefore please consider that when the Cloud refer to 1CPU this is not equal to the capacity you get from 1CPU in your On Premises setup, same for the network throughput. It is also always possible that activities executed by other customers of the same Cloud provider and region will impact the capacity available for your deployment.
• #13: Cloud platforms have all that is needed to manage data replication, data backup, security, monitoring. All these features are available but none of them is activated by default. The deployment has to be designed in order to implement the required configurations for each of these areas. It is also important to take a clear distinction between data backup and data replication. Often people confuse the two things and believe that to have a geographical redundant storage is all that they need to save their data. Data replication means that there are multiple distributed copies of the data, this is necessary to assure data availability, but if you need to assure data reliability you need also to implement a backup policy. When you replicate data you replicate every action done on data, replicating also data corruptions caused by bad editing or deletion. Different mechanisms and levels of data replication and data backup policies are available in each of the Cloud service, it is important to define the business requirement for the specific solution and explicitly implement what is best for the case, taking into consideration the related costs. One of the most common mistakes with Cloud provisioning is to forget about security. Thousands of kubernetes clusters, redis clusters, mongodb replicasets and other services are compromised every year because deployed into the Cloud using public templates without taking the time to configure restriction in network access or to change default usernames and password. As for the other elements we just discussed, services are available in the Cloud to correctly manage any security concern, but rarely they are activated and configured by default. While resources On Prem are by default available only on private office networks, access to services in public Cloud is operated via public internet, it means that when you open access you are potentially opening access to everyone. Almost every company had already experienced multiple services and Virtual Machines that had been configured as completely open to the Internet and in more than a couple of cases, cross multiple cloud providers, we had virtual machines completely hacked. One thing is certain, and you can easily check if you look at the logs of the ADSL router you have at home, any public IP is constantly subjected to scan and attacks, do not think “it has a public IP but none knows about it, so why should someone attack it”, the simple fact to have a public IP means that the service or server is under attack and will constantly be under attack. Encrypt traffic and apply as much network access filtering as possible on any system or service you deploy in the Cloud, change any default username or password, always make a persona copy of any template you want to use and make your own changes, avoiding the direct usage of public images and templates and always select only more than trustable repositories. Logging and Monitoring tools are also available on each Cloud vendor, again these are not configured by default, take your time to analyse the solution you have to deploy into the Cloud and properly configure logging collection, log analysis and monitoring tools, for both security and availability. This is a constant activity, monitoring has to be tuned constantly.
• #15: There has been a gradual approach, often tactical and driven by projects specific needs.
• #19: The usage of Cloud services require a new paradigm, it can not be approached with the same toolset and mindset we had while working On Premises or with traditional infrastructure. Cloud adoption history is full of cases of big success but it is also full of cases of incredibly, and very expensive, failures. As for everything in technology (and organisation or methodology) we do not have in absolute terms a “right thing to do” versus a “wrong thing to do”; Cloud is not “good” and traditional hosting “bad” but which is the best solution depends on each specific context (being the context the architecture, processes and tools, project methodology, team organisation, available skills and business requirements and objectives). It is possible to use Cloud services also with traditional business and processes and solutions, but the best achievements are visible when a DevOps organised team, using Agile methodologies is using automation tools to deploy a Micro Services (or at least modular) architecture.
• #21: If you have a big monolithic application that requires a fixed immutable capacity necessarily based on a IaaS (virtual machines) model, please make yourself a favour and keep it in traditional hosting; with Cloud you will just get higher costs and probably also lower performances. The benefits of the Cloud are the ability to continuously deploy, use dynamically allocated resources and to change deployment topologies cross services and geography; this can be achieved with modular solutions, where you can manage a fully distributed design composed by a series of small independent deployments.
• #23: With the Cloud you will find yourself creating multiple independent deployments, the number of services and instances will constantly grow. Also the interaction between services will gradually become more complex. It is not possible to manage this complexity using documents (as configuration, network or deployment detailed schemas) or to operate manually configurations or updates. Automation tools, orchestrators and solution to manage service mesh (as Istio) must be used to assure the control of the deployments. Only operating exclusively via these tools it is possible to guarantee that the status of each deployment is as it was thought to be (and the documentation is inside the tools, as part of the pipeline, scripts and variables that have been actually used to build the deployment) and only knowing the starting status it is possible to apply safely the changes. Different skills (and so people) from the multidisciplinary team taking care of a project will have to cooperate to define each step of the pipelines for the automation and orchestrations and almost every component of the team will be able to operate it.
• #25: Cloud means elasticity. It is easy and quick to activate a new service or resource or to change an existing one. In the Cloud you pay for what you created, so it is important to be effective, in quick cycles create, test and destroy until you find the right setup, without leaving unused and unneeded resources active, knowing you will always be able to recreate them when needed.
• #27: DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. DevOps is also characterized by operations staff making use of many of the same techniques as developers for their systems work. “DevOps is the application of Agile Methodology to System Administration” (Tom Limoncelli, “The Practice of Cloud System Administration”). Core values: Culture (People, process, tools); Automation (infrastructure as code), Measurement (measure everything), Sharing (collaboration and feedback) – CAMS DevOps is mostly about breaking down barriers between teams. An enormous amount of time is wasted with tickets sitting in queues, or individuals writing handoff documentation for the person sitting right next to them.
• #29: Amazon AWS, Microsoft Azure, Google GCP are clearly recognised globally as the dominant providers. Alibaba, Oracle and IBM (now including Red Hat) are the other competitors, but the distance from the first three is very high. Many other companies tried to enter into the market (as the family Dell\VMWare) but decided to exit because there was no space (and Vmware signed agreements with the cloud providers for hybrid solution services). Other, as Rackspace, decided to just maintain their solution but start to provide professional services on the top three ones to survive.
• #30: Cloud is here to stay, adoption of Cloud Services is keep growing with a rate of more than 50% each quarter.
• #32: Cloud Services are constantly evolving. Different services are made available every month. It is very important to spend effort (and time) to analyse for new (but also for existing projects) what changed in the services we were using (new capabilities or new cost model) and which other new services could be a better fit for the projects’ needs. Each service exists in multiple flavour, for example something basic as a disk space can be provided with very different capabilities (local or geographical redundancies, ability to perform snapshotting, online resizing, native HTTPS or SFTP or Rsync access, etc..), with very different attributes (in terms of number of operations supported, in terms of capacity and available space, etc..) and different SLAs (for example a disk could support up to 500 IOPS but with no guaranteed service and one other could support again 500 IOPS but guaranteed). You need to spend time to operate the right design of the deployment in order to match the business requirements.
• #34: The following are the assumptions you should always have in mind to be ready to design a resilient solution
• #35: This is a given, no matter if it is On Premises, physical or virtual, or in Cloud, no matter the vendor or provider you are using, you will always experience infrastructure failures. For this reason you have to design your deployment in order to cope with failures (multiregion, multicloud, graceful degredation).
• #36: You must have methods and tools to try to reduce as much as possible the probability for a bug to reach the production environment but bugs will always exists and they will always find their way up to the end user. For this reason you need to have in place tools and procedures to react and correct on a fast way. Do not think “zero bug” but think “fast recovery”.
• #37: You need to design your process and tools to minimize the possibility and the impact of human mistakes, but this will never allow to come to a “zero mistake” situation. The process and tools needs to be in place to intercept the mistake and operate corrections.
• #38: You will design your solution to be used on a certain way, but one day a person will use it differently, this happen in frontend applications, backoffice applications but also on tools and pipelines for the development and the deployment. Be ready to recognise a different usage pattern and to support or even embrace it.
• #39: Always remind that a technology is never “good” or “bad” in “essence”, the starting point to evaluate a technical choice are the business requirements and priorities. No IT project can succeed if it does not have a business need behind, a pure technological refactoring can be approached only if it is directly linked with business value. The current business context demands to be fast, to reduce the time to market; the current technology context is constantly changing and increasingly complex, removing a clear distinction between software and infrastructure. The only way to be capable to respond to such demands from business and technology is to run small teams that are including all the required skills (and it is more about skills than roles now), so teams that can design, execute and operate without dependencies from external teams. The giant in the market, as Amazon or Microsoft or Google, are constantly creating services available and other companies are building tools and components, if you have a business need first check if something exist out in the market to be used, but always remind you’ll have to analyse it in deep and integrate it, building something around it or learning how best to use (please remember previous examples about missing backup or monitoring). Reliability and Security are key in Cloud environments because of the public nature of the deployments (so even more important than in the case of On Premises), it is key to keep these two elements always in mind from the design to the operation phase and to constantly evolve the deployment on the base of the changes and evolution.
• #40: The Cloud is an open space, where it is very quick, easy and inexpensive to experiment, don’t miss this opportunity.