Anything and Everything About Cloud – Session 2
- March 05, 2018
- Avni Mehta
“A swish here and a swish there, coming to the rescue of many”, Cloud man saves the day for yet another organisation.
Thank you cloud man for saving me tons of money, heaps of effort that went in managing the physical servers, my time and now I can focus on aspects of my work that are dear to me.
“We all love you cloud man”, – Said the owner of a billion dollar company.
Sooner than I could imagine, all the rain poured down on my face with water droplets on my cheeks. The wild dream broke up with the reality of the upcoming session.
Session number 2 was in another 5 minutes where Albert would answer all the questions that pop out of our head.
Into the Session 2
Here in this session, we tried to tone the path. With the agenda of this discussion to be centred around migration, there was a hope to get an in-depth overview of how is data migrated to cloud through servers.
But the avid gamers were furious. They wanted to know the reasons as to why all of the cloud services are affected by updates required to mitigate the meltdown vulnerability.
Oh yes!! It was an issue. The following chart shows the significant impact on CPU usage of one of the back-end services after a host was patched to address the Meltdown vulnerability, as illustrated by Epic Games.
Illustrations of the havoc the patches are wreaking on the cloud in its “Services & Stability Update”.
Indeed this was an issue for not just the gamers but for a lot of individuals who already are sceptical about the compatibility of cloud with the applications they run on.
We were reassured that this was not the fault because of the cloud services providers but the lack in compatibility of our systems and the patches in the security updates. As previously shared, most of the security issues are our responsibility, cloud platforms had nothing to worry about and neither did the users. For a thorough conversation, this topic was scheduled for another day.
Our conversation was back on its track. The path we will follow for the upcoming sessions are:
- Migration to Cloud
- Hybrid and Public Cloud
- Cost Optimization
- Continuous Integration & Continuous Deployment
- Continuous Security and Continuous Compliance
- Configuration Management
- Jenkins, Chef, Puppet, Ansible etc.
3. Big Data
- Processing of Data
- Visualization of Data
- Analytics of Data
- Cloud Native Development
- Cloud Native Serverless Computing such as Lambda
- Re-architecting solution for Serverless Computing
7. Managed Cloud services
- Incident Control
- Cost Optimization
Is travelling always tiring?
Migration is the movement of your data from the physical location to the cloud with the intentions of settling, permanently or temporarily in a new location.
How difficult is it? Is it like the human migration? That is not that easy. Is moving to cloud easy?
Moving to the cloud is effortless. Just lift and shift from servers outside the cloud to cloud. As simple as it could have been. Furthermore, as usually observed we have trouble finding our data from the old-fashioned tools that are visible.
Manage your data
The transparent data storage gives us 3 options to manage our data for seamless retrieval.
These names are very self-elaboratory.
“Hot” storage is data you need to access right away, where performance is at a premium. Hot storage often goes hand in hand with cloud computing. If you’re depending on cloud services not only to store your data but also to process it, you’re looking at hot storage.
“Cold” storage is information that you don’t need to access very often. Inactive data that doesn’t need to be accessed for months, years, decades, potentially ever. That’s the sort of content that cold storage is ideal for. Practical examples of data suitable for cold storage include old projects, records you might need for auditing or bookkeeping purposes at some point in the future, or other content you only need to access infrequently.
This is important!!
After classifying your data to your needs, if the server cloud is not optimised, for that we need to do the following:
- Decouple architecture/ applications
A decoupled architecture allows each component to perform its tasks independently of the others, while also enabling structural variations between source and target.
- Break monolithic to microservice
- Put them into containers.
Containers offer a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run. This decoupling allows container-based applications to be deployed easily and consistently, regardless of whether the target environment is a private data centre, the public cloud, or even a developer’s personal laptop
Elastic Load Balancing
Even after managing our cloud, we cannot predict the load on it. Predefining the load balancing, Elastic Load Balancing(ELB) distributes incoming application traffic across multiple instances, in multiple Availability Zones. This increases the fault tolerance of your applications.
The load balancer serves as a single point of contact for clients, which increases the availability of your application. You can add and remove instances from your load balancer as your needs change, without disrupting the overall flow of requests to your application. Elastic Load Balancing scales your load balancer as traffic to your application changes over time and can scale to the vast majority of workloads automatically.
Uses of ELB
You can configure health checks, which are used to monitor the health of the registered instances so that the load balancer can send requests only to the healthy instances. You can also offload the work of encryption and decryption to your load balancer so that your instances can focus on their main work.
ELB automatically balances the load or traffic across various Amazon EC2 instances, IPs or Network. It can handle or balance load/ traffic in a single Availability Zone or across multiple Availability Zones.
This includes balancing loads, automatic scaling, high availability, robustness and security. There are three types of load balancers AWS offers:
- Application Load Balancers: This one is used for handling or balancing HTTP and HTTPS traffic that is coming to your application.
- Network Load Balancers: The balancing of TCP traffic, Network Load Balancer is capable of handling millions of requests per second.
- Classic Load Balancer: Applications that were built within the EC2-Classic network
To set up the ELB, you just need to configure based on resources like memory, CPU utilisation or the load is more than 75% for 5 min, then scale up your application by one instance or scale down by 1 when resource utilisation is less than 25% for more than 10 min. Your load balancer will then automatically balances the load and auto-scale your application as required.
You can judge now why ELB is critical to almost every situation.
Why Availability Zones?
In reference to the availability zones, we also learnt that there are 16 data centres around this world. There is a peculiar detail about this. Any of the cloud service providers can use a single large shared pool of virtual resources and make a single data centre. That has not been the practice though. The cloud service providers have data centres spread across the world since each country/ region have a different set of rules and policies which govern them. To comply with the set of regulations and cater to specific regions they have different data centres spread over the globe.
So, the day ended with learnings from migration to managing our cloud services which were to be discussed in the later sessions. Stay tuned.
Feel free to contact us for all your queries. It’s a sure thing, you and I, we’re gonna have a hell of a time!
As you know,
Who am I? I’m your friendly neighbourhood Cloud-Man!
Topics of Discussion: http://docs.google.com/document/d/1UxUP9ZDMdIttVKP4hD7Sk-G3BQuA4y9g0lemLpJfZn8/edit