Considering VMware’s enrapturement with vMotion the following news (reported by Salman Naqvi in a comment to my blog post) was clearly inevitable:
I was surprised to learn that LIVE vMotion is supported between on-premise and Vmware on AWS Cloud
What’s more interesting is how did they manage to do it?
I’m too stupid to unwind and relax over summer - there’s always some janitorial task to be done, and I simply cannot leave it alone. This summer, I decided to migrate our server infrastructure to AWS.
TL&DR: It went smoother than I expected, and figuring out how AWS virtual networks, public IP addresses, and security groups work while creating AWS Networking webinar definitely helped, but it also took way longer than I expected.
If you’ve been in networking long enough you’d probably noticed an interesting pattern:
- Some topic is hotly debated;
- No agreement is ever reached even though the issue is an important one;
- The debate dies after participants diverge enough to stop caring about the other group.
I was reminded of this pattern when I was explaining the traffic filtering measures available in private and public clouds during the Designing Infrastructure for Private Clouds workshop.
One of my friends reviewing the material of my AWS Networking webinar sent me this remark:
I'm always interested in hearing more about how AWS network works under the hood – it’s difficult to gain that knowledge.
As always, it’s almost impossible to find out the behind-the-scenes details, and whatever Amazon is telling you at their re:Invent conference should be taken with a truckload of salt… but it’s relatively easy to figure out a lot of things just by observing them and performing controlled experiments.
This is the fourth blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. Previous posts: Network-Infrastructure-as-Code Is Nothing New, Adjusting System State and NETCONF versus REST API.
Dmitri Kalintsev sent me a nice description on how some popular Infrastructure-as-Code (IaC) tools solve the challenges I described in The CRUD Hell section of Infrastructure-as-Code, NETCONF and REST API blog post:
As anyone starting their journey into AWS quickly discovers, cloud is different (or as I wrote in the description of my AWS workshop you feel like Alice in Wonderland). One of the gotchas: when you link multiple routing domains (Virtual Private Clouds – the other VPC) you have to create static routing table entries on both ends. Even worse, there’s no transit VPC – you have to build a full mesh of relationships.
The correct solution to this challenge is automation:
This is the third blog post in “thinking out loud while preparing Network Infrastructure as Code presentation for the network automation course” series. You might want to start with Network-Infrastructure-as-Code Is Nothing New and Adjusting System State blog posts.
As I described in the previous blog post, the hardest problem any infrastructure-as-code (IaC) tool must solve is “how to adjust current system state to desired state described in state definition file(s)”… preferably without restarting or rebuilding the system.
There are two approaches to adjusting system state:
After figuring out how packet forwarding really works within AWS VPC (here’s an overview, the slide deck is already available to ipSpace.net subscribers) the next obvious question should be: “and how do I integrate a network services device like a next-generation firewall I have to use because $securityPolicy into that environment?”
Please don’t get me started on whether that makes sense, that’s a different discussion.
Christer Swartz, an old-time CCIE and occasional guest on Software Gone Wild podcast will show you how to do it with a Palo Alto firewall during my Amazon Web Services Networking Deep Dive workshop on June 13th in Zurich, Switzerland (register here).
Traditional networking engineers, or virtualization engineers familiar with vSphere or VMware NSX, often feel like Alice in Wonderland when entering the world of Amazon Web Services. Everything looks and sounds familiar, and yet it all feels a bit different
I decided to create a half-day workshop (first delivery: June 13th in Zurich, Switzerland) to make it easier to grasp the fundamentals of AWS networking, and will publish high-level summaries as a series of blog posts. Let’s start with an overview of what’s different:
VMware started talking about VMware Cloud on AWS a while ago, and my first response was “yeah, it’s just vCloud Air but they wanted to get rid of CapEx, so it’s running on someone else’s servers”
Last week Frank Denneman published a technical overview of the solution and I was mostly correct.