#virtual machine migration in cloud computing

[monisha1199]

From Novice to Pro: Master the Cloud with AWS Training!

In today's rapidly evolving technology landscape, cloud computing has emerged as a game-changer, providing businesses with unparalleled flexibility, scalability, and cost-efficiency. Among the various cloud platforms available, Amazon Web Services (AWS) stands out as a leader, offering a comprehensive suite of services and solutions. Whether you are a fresh graduate eager to kickstart your career or a seasoned professional looking to upskill, AWS training can be the gateway to success in the cloud. This article explores the key components of AWS training, the reasons why it is a compelling choice, the promising placement opportunities it brings, and the numerous benefits it offers.

Key Components of AWS Training

1. Foundational Knowledge: Building a Strong Base

AWS training starts by laying a solid foundation of cloud computing concepts and AWS-specific terminology. It covers essential topics such as virtualization, storage types, networking, and security fundamentals. This groundwork ensures that even individuals with little to no prior knowledge of cloud computing can grasp the intricacies of AWS technology easily.

2. Core Services: Exploring the AWS Portfolio

Once the fundamentals are in place, AWS training delves into the vast array of core services offered by the platform. Participants learn about compute services like Amazon Elastic Compute Cloud (EC2), storage options such as Amazon Simple Storage Service (S3), and database solutions like Amazon Relational Database Service (RDS). Additionally, they gain insights into services that enhance performance, scalability, and security, such as Amazon Virtual Private Cloud (VPC), AWS Identity and Access Management (IAM), and AWS CloudTrail.

3. Specialized Domains: Nurturing Expertise

As participants progress through the training, they have the opportunity to explore advanced and specialized areas within AWS. These can include topics like machine learning, big data analytics, Internet of Things (IoT), serverless computing, and DevOps practices. By delving into these niches, individuals can gain expertise in specific domains and position themselves as sought-after professionals in the industry.

Reasons to Choose AWS Training

1. Industry Dominance: Aligning with the Market Leader

One of the significant reasons to choose AWS training is the platform's unrivaled market dominance. With a staggering market share, AWS is trusted and adopted by businesses across industries worldwide. By acquiring AWS skills, individuals become part of the ecosystem that powers the digital transformation of numerous organizations, enhancing their career prospects significantly.

2. Comprehensive Learning Resources: Abundance of Educational Tools

AWS training offers a wealth of comprehensive learning resources, ranging from extensive documentation, tutorials, and whitepapers to hands-on labs and interactive courses. These resources cater to different learning preferences, enabling individuals to choose their preferred mode of learning and acquire a deep understanding of AWS services and concepts.

3. Recognized Certifications: Validating Expertise

AWS certifications are globally recognized credentials that validate an individual's competence in using AWS services and solutions effectively. By completing AWS training and obtaining certifications like AWS Certified Solutions Architect or AWS Certified Developer, individuals can boost their professional credibility, open doors to new job opportunities, and command higher salaries in the job market.

Placement Opportunities

Upon completing AWS training, individuals can explore a multitude of placement opportunities. The demand for professionals skilled in AWS is soaring, as organizations increasingly migrate their infrastructure to the cloud or adopt hybrid cloud strategies. From startups to multinational corporations, industries spanning finance, healthcare, retail, and more seek talented individuals who can architect, develop, and manage cloud-based solutions using AWS. This robust demand translates into a plethora of rewarding career options and a higher likelihood of finding positions that align with one's interests and aspirations.

In conclusion, mastering the cloud with AWS training at ACTE institute provides individuals with a solid foundation, comprehensive knowledge, and specialized expertise in one of the most dominant cloud platforms available. The reasons to choose AWS training are compelling, ranging from the industry's unparalleled market position to the top ranking state.

[mostlysignssomeportents]

Adversarial interoperability: reviving an elegant weapon from a more civilized age to slay today's monopolies

Today, Apple is one of the largest, most profitable companies on Earth, but in the early 2000s, the company was

fighting for its life

.

Microsoft's Windows operating system was ascendant

, and Microsoft leveraged its dominance to ensure that every Windows user relied on its Microsoft Office suite (Word, Excel, Powerpoint, etc). Apple users—

a small minority of computer users

—who wanted to exchange documents with the much larger world of Windows users were dependent on Microsoft's Office for the Macintosh operating system (

which worked inconsistently with Windows Office documents

, with unexpected behaviors like corrupting documents so they were no longer readable, or partially/incorrectly displaying parts of exchanged documents). Alternatively, Apple users could ask Windows users to export their Office documents to an "interoperable" file format like Rich Text Format (for text), or Comma-Separated Values (for spreadsheets). These, too, were inconsistent and error-prone, interpreted in different ways by different programs on both Mac and Windows systems.

Apple could have begged Microsoft to improve its Macintosh offerings, or they could have begged the company to standardize its flagship products at a standards body like OASIS or ISO. But Microsoft had little motive to do such a thing: its Office products were a tremendous competitive advantage, and despite the fact that Apple was too small to be a real threat, Microsoft had a well-deserved reputation for going to enormous lengths to snuff out potential competitors, including both Macintosh computers and computers running the GNU/Linux operating system.

Apple did not rely on Microsoft's goodwill and generosity: instead, it relied on reverse-engineering. After its 2002 "Switch" ad campaign—which begged potential Apple customers to ignore the "myths" about how hard it was to integrate Macs into Windows workflows—it intensified work on its iWork productivity suite, which launched in 2005, incorporating a word-processor (Pages), a spreadsheet (Numbers) and a presentation program (Keynote). These were feature-rich applications in their own right, with many innovations that leapfrogged the incumbent Microsoft tools, but this superiority would still not have been sufficient to ensure the adoption of iWork, because the world's greatest spreadsheets are of no use if everyone you need to work with can't open them.

What made iWork a success—and helped re-launch Apple—was the fact that Pages could open and save most Word files; Numbers could open and save most Excel files; and Keynote could open and save most PowerPoint presentations. Apple did not attain this compatibility through Microsoft's cooperation: it attained it despite Microsoft's noncooperation. Apple didn't just make an "interoperable" product that worked with an existing product in the market: they made an adversarially interoperable product whose compatibility was wrested from the incumbent, through diligent reverse-engineering and reimplementation. What's more, Apple committed to maintaining that interoperability, even though Microsoft continued to update its products in ways that temporarily undermined the ability of Apple customers to exchange documents with Microsoft customers, paying engineers to unbreak everything that Microsoft's maneuvers broke. Apple's persistence paid off: over time, Microsoft's customers became dependent on compatibility with Apple customers, and they would complain if Microsoft changed its Office products in ways that broke their cross-platform workflow.

Since Pages' launch, document interoperability has stabilized, with multiple parties entering the market, including Google's cloud-based Docs offerings, and the free/open alternatives from LibreOffice. The convergence on this standard was not undertaken with the blessing of the dominant player: rather, it came about despite Microsoft's opposition. Docs are not just interoperable, they're adversarially interoperable: each has its own file format, but each can read Microsoft's file format.

The document wars are just one of many key junctures in which adversarial interoperability made a dominant player vulnerable to new entrants:

Hayes modems

Usenet's alt.* hierarchy

Supercard's compatibility with Hypercard

Search engines' web-crawlers

Servers of every kind, which routinely impersonate PCs, printers, and other devices

Scratch the surface of most Big Tech giants and you'll find an adversarial interoperability story: Facebook grew by making a tool that let its users stay in touch with MySpace users; Google products from search to Docs and beyond depend on adversarial interoperability layers; Amazon's cloud is full of virtual machines pretending to be discrete CPUs, impersonating real computers so well that the programs running within them have no idea that they're trapped in the Matrix.

Adversarial interoperability converts market dominance from an unassailable asset to a liability. Once Facebook could give new users the ability to stay in touch with MySpace friends, then every message those Facebook users sent back to MySpace—with a footer advertising Facebook's superiority—became a recruiting tool for more Facebook users. MySpace served Facebook as a reservoir of conveniently organized potential users that could be easily reached with a compelling pitch about why they should switch.

Today, Facebook is posting 30-54% annual year-on-year revenue growth and boasts 2.3 billion users, many of whom are deeply unhappy with the service, but who are stuck within its confines because their friends are there (and vice-versa).

A company making billions and growing by double-digits with 2.3 billion unhappy customers should be every investor's white whale, but instead, Facebook and its associated businesses are known as "the kill zone" in investment circles.

Facebook's advantage is in "network effects": the idea that Facebook increases in value with every user who joins it (because more users increase the likelihood that the person you're looking for is on Facebook). But adversarial interoperability could allow new market entrants to arrogate those network effects to themselves, by allowing their users to remain in contact with Facebook friends even after they've left Facebook.

This kind of adversarial interoperability goes beyond the sort of thing envisioned by "data portability," which usually refers to tools that allow users to make a one-off export of all their data, which they can take with them to rival services. Data portability is important, but it is no substitute for the ability to have ongoing access to a service that you're in the process of migrating away from.

Big Tech platforms leverage both their users' behavioral data and the ability to lock their users into "walled gardens" to drive incredible growth and profits. The customers for these systems are treated as though they have entered into a negotiated contract with the companies, trading privacy for service, or vendor lock-in for some kind of subsidy or convenience. And when Big Tech lobbies against privacy regulations and anti-walled-garden measures like Right to Repair legislation, they say that their customers negotiated a deal in which they surrendered their personal information to be plundered and sold, or their freedom to buy service and parts on the open market.

But it's obvious that no such negotiation has taken place. Your browser invisibly and silently hemorrhages your personal information as you move about the web; you paid for your phone or printer and should have the right to decide whose ink or apps go into them.

Adversarial interoperability is the consumer's bargaining chip in these coercive "negotiations." More than a quarter of Internet users have installed ad-blockers, making it the biggest consumer revolt in human history. These users are making counteroffers: the platforms say, "We want all of your data in exchange for this service," and their users say, "How about none?" Now we have a negotiation!

Or think of the iPhone owners who patronize independent service centers instead of using Apple's service: Apple's opening bid is "You only ever get your stuff fixed from us, at a price we set," and the owners of Apple devices say, "Hard pass." Now it's up to Apple to make a counteroffer. We'll know it's a fair one if iPhone owners decide to patronize Apple's service centers.

This is what a competitive market looks like. In the absence of competitive offerings from rival firms, consumers make counteroffers by other means.

There is good reason to want to see a reinvigorated approach to competition in America, but it's important to remember that competition is enabled or constrained not just by mergers and acquisitions. Companies can use a whole package of laws to attain and maintain dominance, to the detriment of the public interest.

Today, consumers and toolsmiths confront a thicket of laws and rules that stand between them and technological self-determination. To change that, we need to reform the Computer Fraud and Abuse Act, Section 1201 of the Digital Millennium Copyright Act, , patent law, and other rules and laws. Adversarial interoperability is in the history of every tech giant that rules today, and if it was good enough for them in the past, it's good enough for the companies that will topple them in the future.

(Crossposted from EFF Deeplinks)

https://boingboing.net/2019/06/07/lightsabers-for-trustbusting.html

[yahooeng]

Operating OpenStack at Scale

By James Penick, Cloud Architect & Gurpreet Kaur, Product Manager

A version of this byline was originally written for and appears in CIO Review.

A successful private cloud presents a consistent and reliable facade over the complexities of hyperscale infrastructure. It must simultaneously handle constant organic traffic growth, unanticipated spikes, a multitude of hardware vendors, and discordant customer demands. The depth of this complexity only increases with the age of the business, leaving a private cloud operator saddled with legacy hardware, old network infrastructure, customers dependent on legacy operating systems, and the list goes on. These are the foundations of the horror stories told by grizzled operators around the campfire.

Providing a plethora of services globally for over a billion active users requires a hyperscale infrastructure. Yahoo’s on-premises infrastructure is comprised of datacenters housing hundreds of thousands of physical and virtual compute resources globally, connected via a multi-terabit network backbone. As one of the very first hyperscale internet companies in the world, Yahoo’s infrastructure had grown organically – things were built, and rebuilt, as the company learned and grew. The resulting web of modern and legacy infrastructure became progressively more difficult to manage. Initial attempts to manage this via IaaS (Infrastructure-as-a-Service) taught some hard lessons. However, those lessons served us well when OpenStack was selected to manage Yahoo’s datacenters, some of which are shared below.

Centralized team offering Infrastructure-as-a-Service

Chief amongst the lessons learned prior to OpenStack was that IaaS must be presented as a core service to the whole organization by a dedicated team. An a-la-carte-IaaS, where each user is expected to manage their own control plane and inventory, just isn’t sustainable at scale. Multiple teams tackling the same challenges involved in the curation of software, deployment, upkeep, and security within an organization is not just a duplication of effort; it removes the opportunity for improved synergy with all levels of the business. The first OpenStack cluster, with a centralized dedicated developer and service engineering team, went live in June 2012.  This model has served us well and has been a crucial piece of making OpenStack succeed at Yahoo. One of the biggest advantages to a centralized, core team is the ability to collaborate with the foundational teams upon which any business is built: Supply chain, Datacenter Site-Operations, Finance, and finally our customers, the engineering teams. Building a close relationship with these vital parts of the business provides the ability to streamline the process of scaling inventory and presenting on-demand infrastructure to the company.

Developers love instant access to compute resources

Our developer productivity clusters, named “OpenHouse,” were a huge hit. Ideation and experimentation are core to developers’ DNA at Yahoo. It empowers our engineers to innovate, prototype, develop, and quickly iterate on ideas. No longer is a developer reliant on a static and costly development machine under their desk. OpenHouse enables developer agility and cost savings by obviating the desktop.

Dynamic infrastructure empowers agile products

From a humble beginning of a single, small OpenStack cluster, Yahoo’s OpenStack footprint is growing beyond 100,000 VM instances globally, with our single largest virtual machine cluster running over a thousand compute nodes, without using Nova Cells.

Until this point, Yahoo’s production footprint was nearly 100% focused on baremetal – a part of the business that one cannot simply ignore. In 2013, Yahoo OpenStack Baremetal began to manage all new compute deployments. Interestingly, after moving to a common API to provision baremetal and virtual machines, there was a marked increase in demand for virtual machines.

Developers across all major business units ranging from Yahoo Mail, Video, News, Finance, Sports and many more, were thrilled with getting instant access to compute resources to hit the ground running on their projects. Today, the OpenStack team is continuing to fully migrate the business to OpenStack-managed. Our baremetal footprint is well beyond that of our VMs, with over 100,000 baremetal instances provisioned by OpenStack Nova via Ironic.

How did Yahoo hit this scale?  

Scaling OpenStack begins with understanding how its various components work and how they communicate with one another. This topic can be very deep and for the sake of brevity, we’ll hit the high points.

1. Start at the bottom and think about the underlying hardware

Do not overlook the unique resource constraints for the services which power your cloud, nor the fashion in which those services are to be used. Leverage that understanding to drive hardware selection. For example, when one examines the role of the database server in an OpenStack cluster, and considers the multitudinous calls to the database: compute node heartbeats, instance state changes, normal user operations, and so on; they would conclude this core component is extremely busy in even a modest-sized Nova cluster, and in need of adequate computational resources to perform. Yet many deployers skimp on the hardware. The performance of the whole cluster is bottlenecked by the DB I/O. By thinking ahead you can save yourself a lot of heartburn later on.

2. Think about how things communicate

Our cluster databases are configured to be multi-master single-writer with automated failover. Control plane services have been modified to split DB reads directly to the read slaves and only write to the write-master. This distributes load across the database servers.

3. Scale wide

OpenStack has many small horizontally-scalable components which can peacefully cohabitate on the same machines: the Nova, Keystone, and Glance APIs, for example. Stripe these across several small or modest hardware. Some services, such as the Nova scheduler, run the risk of race conditions when running multi-active. If the risk of race conditions is unacceptable, use ZooKeeper to manage leader election.

4. Remove dependencies

In a Yahoo datacenter, DHCP is only used to provision baremetal servers. By statically declaring IPs in our instances via cloud-init, our infrastructure is less prone to outage from a failure in the DHCP infrastructure.

5. Don’t be afraid to replace things

Neutron used Dnsmasq to provide DHCP services, however it was not designed to address the complexity or scale of a dynamic environment. For example, Dnsmasq must be restarted for any config change, such as when a new host is being provisioned.  In the Yahoo OpenStack clusters this has been replaced by ISC-DHCPD, which scales far better than Dnsmasq and allows dynamic configuration updates via an API.

6. Or split them apart

Some of the core imaging services provided by Ironic, such as DHCP, TFTP, and HTTPS communicate with a host during the provisioning process. These services are normally  part of the Ironic Conductor (IC) service. In our environment we split these services into a new and physically-distinct service called the Ironic Transport Service (ITS). This brings value by:

Adding security: Splitting the ITS from the IC allows us to block all network traffic from production compute nodes to the IC, and other parts of our control plane. If a malicious entity attacks a node serving production traffic, they cannot escalate from it  to our control plane.

Scale: The ITS hosts allow us to horizontally scale the core provisioning services with which nodes communicate.

Flexibility: ITS allows Yahoo to manage remote sites, such as peering points, without building a new cluster in that site. Resources in those sites can now be managed by the nearest Yahoo owned & operated (O&O) datacenter, without needing to build a whole cluster in each site.

Be prepared for faulty hardware!

Running IaaS reliably at hyperscale is more than just scaling the control plane. One must take a holistic look at the system and consider everything. In fact, when examining provisioning failures, our engineers determined the majority root cause was faulty hardware. For example, there are a number of machines from varying vendors whose IPMI firmware fails from time to time, leaving the host inaccessible to remote power management. Some fail within minutes or weeks of installation. These failures occur on many different models, across many generations, and across many hardware vendors. Exposing these failures to users would create a very negative experience, and the cloud must be built to tolerate this complexity.

Focus on the end state

Yahoo’s experience shows that one can run OpenStack at hyperscale, leveraging it to wrap infrastructure and remove perceived complexity. Correctly leveraged, OpenStack presents an easy, consistent, and error-free interface. Delivering this interface is core to our design philosophy as Yahoo continues to double down on our OpenStack investment. The Yahoo OpenStack team looks forward to continue collaborating with the OpenStack community to share feedback and code.